If you had one wish for Meteor, what would it be?

6

Apollo 1.0 :slight_smile:

Thanks for whoever did this: https://www.codetours.xyz/tour/partyparrot/GitHunt-API-code-tour

4 Likes
7

I would also say,

  • Easier integration with frameworks like AuthO.
  • Better alignment with the serverless paradigms.
2 Likes
8

Better build tool: Allow to separate server side from client side to a point, where i could write two client apps (Admin Panel and Main App), publish them through regular ftp upload and let the server side stay on another node-js-only server.

3 Likes
9

Only one thing: webpack-blaze :slight_smile:

5 Likes
10

I still wish MDG could return free tier deployment as two-week-life containers for instance.
It was great. An ease of seeing any prototype/test/tutorial you want with one command.

Code splitting by default is cool to. Yet webpack is here and now…
I’d vote for RethinkDB, I kinda love new paths with no overhead.

1 Like
11

I guess it wouldn’t hurt to link in this post: What is Meteor missing?
Infinite possibilities!

12

Let’s not ressurect super old threads though - I’d suggest keeping the discussion in here.

3 Likes
13

Build tool is of course very important and was biggest pain point for some time but also already worked on. So I voted scaling and performance (second place currently so if MDG is listening it should work on it next). Time for meteor to grow up :slight_smile:

14

Nice poll, but it would’ve been nice to be able to select multiple answers.

2 Likes
15

Indeed - we abandoned the poor thing in its childhood!

16

With the build tool, production source maps that could be sent to various services on deploy (without being deployed to production themselves) would be great (recently mentioned here). I also hope MDG pushes the envelope for something past route-based code-splitting (demand-/ config-/feature-based, etc. Not sure what it’s all called, but with the idea that over- and underbundling and/or over- and underfetching of actual code is kept to a minimum.)

1 Like
17

Indeed - though I wonder if the real solution is something like Fast-Boot by Ember. We actually want all the code/templates to load upfront for performance, we just don’t like how long that takes to render for visitors.

1 Like
18

The one thing I need for Meteor to be usable for me is better offline support with service worker

19

My wish would be a meteor fully transitioned to npm.

20

Ah that would be cool. I suspect someone can roll this functionality on their own though?

21

What is the driving force for you there?

22

I started with meteor without knowing node, and was happy that meteor took care of everything, but now that abstraction layer is broken, so I want to be able to rely mostly on node and opt in to the parts of meteor I really need.

2 Likes
23

awesome and out of box thought!!!

1 Like
24

Not a serious wish but I think that npm is a deeply flawed dependency system. Not only does it allow people to delete their repositories (leaving others in a lurch), not only does it seemingly create a kind of braindeath - this is an actual function from a package used by quite a number of apps

function isBetween(number, upperBound, lowerBound) {
   return number < upperBound && number > lowerBound;
}

… no, it also still seems to pull in everything at least quadruple times.

I’m currently deleting the UbuntuOnWindows subsystem (to reinstall it, due to me installing it when it was in alpha, it behaved a bit bonkers) and due to the long filenames restriction on Windows, I have to rename some folders.

And I think I have seen the module babel-plugin-transform-react-jsx-source at least five(5) times now. A sane system (aka “the system they spent 5 minutes thinking about how it ought to work instead of blindly coding ahead”) would have pulled in a dependecy exactly once.

On a more serious note, easier non-Galaxy deployments would have my vote.

25

Word, to me Node/NPM and Meteor used to be Android vs iPhone