@benjamn described things that are coming next in the 1.8 release article:
In summary:
meteor create --apollo and others. (Would this satisfy our desire for first class apollo integration?)autoupdate **package for minimal Meteor apps
meteor create --apolloand others. (Would this satisfy our desire for first class apollo integration?)
I think that depends on how itâs integrated.
You donât need to setup mongo anywhere with connectionStrings etc, it just works. If apolloServer also âjust worksâ, then yes. If you still need to have a config file; then IMO itâs not âfirst classâ.
For me a config file is fine, but if you just get started with Meteor, itâs so awesome that all you need is a index.html, without any config.js.
Sounds awesome, if the npm install is then also automatically being run when meteor detects changes in package.json. Meteor packages are udpated / reinstalled when I switch between branches. npm modules are not.
This would be awesome for me. Managing submodules between projects is a PITA.
Currently have 18 local packages using git submodules shared between 12+ meteor apps.
Iâd much rather have them on a private npm registry, so the only one step is needed to install or update
Iâm surprised it hasnât been mentioned yet. I would love to have an âofficial docker imageâ;
FROM mdg/meteor:1.8
RUN meteor build .
Another thing I thought of a couple of days ago, is this feature request
Basically; I think that it would be quite possible to have a meteor.bundle.js and a app.bundle.js now that Meteor has dynamic imports. This meteor.bundle.js doesnât need to be recompiled on every app change. Not even on every app update.
Benefith 1, the user can have a more aggresive cache
Benefith 2, meteor builder can treat this meteor.bundle.js as a single, static file. And have way faster build times. (package recompiling / scanning still takes a lot of time here)
I know you can manage the client-cache benefith yourself already, by using an import() as early as possible. But, I think this can be stretched, by hosting the meteor.bundle.js on a CDN, allowing all meteor apps to share some cache.
<body>
<script src="https://cdn.meteor.com/meteor-1.8.min.js" />
<script src="/e58e...3d8.js" />
</body>
Yes, that does mean that you would possibly have some packages loaded that you donât use. ButâŚ, if looking on the bigger picture. The more sites use Meteor, the bigger the chance that your visitor already has this bundle in itâs cache any way.
Stretching the idea bove, using precompiled bundles that are slightly âover completeâ, could perhaps be used to build the official meteor docker images.
Imagine building FROM a base container with the meteor assets already precompiled, and only need to compile my own additions and node_modules.
My top layer could be under 10mb, where as the base layer is a simple download from docker hub.
Realistically, I think a Meteor 2.0 would be a lot more front-end agnostic, meaning no Minimongo, DDP, etc. And Apollo would be the recommended solution. That does mean no automatic optimistic UI, store updates, etc. out of the box.
I also think Meteor will have a hard time competing with things like Next.js unless it implements key features like hot module reloading and SSR. They might not be that important in the grand scheme of things, but they are very visible to any new developer (while some of Meteorâs more âhiddenâ advantages are not).
I strongly agree with your statement on being more front-agnostic and provide better integration with Apollo.
Do you think it would make sense to have special meteor react package that can provide SSR/HMR?
Aside from those two, does Next.js have any other notable techinical advantages over todayâs Meteor?
Also does Next.js have any packaging system similar to Meteor? In fact, is there any mature other Node JS framework with packaging system similar to what Meteor has? I wonder becauae we have hard dependcy on the packaging system. Next.js looks very opinionated to me and its usage has been limited to websites as far as I can see, are you aware of any enterprise like app using Next.js? I think Meteor history shows clearly that it easy to lure new developers with shiny new features but itâs hard to win over enterprises and advanced users in the long-run.
Do you think it would make sense to have special meteor react package that can provide SSR/HMR?
Yes, I think providing more features to handle this out of the box would always be good.
Aside from those two, does Next.js have any other notable techinical advantages over todayâs Meteor?
Momentum is probably the biggest advantage, the project seems a lot more dynamic than Meteor in terms of contributors, frequent updates, feature announcements, etc. (at least from the outside).
Next.js looks very opinionated to me and its usage has been limited to websites as far as I can see
Typically youâd use Next.js to render your React front-end and run something else (such as Meteor, or more likely Node) on the back-end for your API server.
So aside from HMR & out of the box SSR for React no other differentiation in term of technical capabilities as of now, in fact itâs lacking relative to Meteor (no support for multiple views, no packaging system, no build-in accounts, no dual bundle system, no optimistic UI, no built-in RPC/methods, no pub/sub etc.). But I think what Next.js got going for it is that they made it dead simple to start react project with SSR and routing.
Momentum is understandable given itâs young and still climbing the hype cycle, what I personally look for is real innovation/differentiation once the framework plateau and the dust settles. If all it focuses on is SSR then thatâs easily achievable with plain react/express/webpack or even gatsbyjs nowadays.
Ok maybe Iâm little biased 
.
Love this discussion!
My 2c based on what Iâve read and my use over the last 3ish years - this being not so much about what new features would make Meteor head and shoulders above the rest of the ecosystem, but rather what common features is it lacking that are likely preventing uptake/experimentation with Meteor:
Beyond that, Iâm personally really happy with Meteor. I think it has a fantastic balance between being opinionated (allows getting a new full stack project up and running extremely quickly) yet flexible enough to do whatever customisations are needed.
Unfortunately itâs not just an overhead in onboarding, but also a source of potential incompatibility with other libraries.
A recent example:
This issue was also raised on Reactâs repo, and the note from Reactâs team member is an indication of how the use of node-fibers is still keeping Meteor from becoming a part of the âmainstreamâ:
React supports standard-compliant JavaScript environments, so using an environment with non-compliant concurrency primitives is going to cause problems.
Two Things:
There would of course be a lot to work out with how this could work with meteorâŚ
But there are already lots of great building blocks in the right place with meteor, at least for the CQRS - Side: Commands - via Meteor Methods, and Query - via Pub/Sub -> You have the 2 separate chains / paths almost out of the box if you are discipled.
Now, the Event Sourcing part is more tricky: First, Meteor doesnât really bring with it a proper âObject Modelâ to work with - just collections and documents - might it be possible to work with event sourcing in a way that you persist your actions to document objects and build âvirtualâ minimongo - result - collections? - otherwise weâd maybe need some other object model to work with⌠Donât know yet. Thatâs why I hope somebody picks this up and makes it clean and easy for me to use! 
I donât know if / how the still very cool meteor âlatency compensationâ could work with this, if the methods only send the events to the server, the server updates the projections of the view model and sends back the updated state via pub-sub - it might be hard or impossible to keep all the right events in the client for the latency compensation to figure out all the results for the client. But maybe thatâs something we can sacrifice on the altar of all the amazing features of event sourcingâŚ
This also brings a lot of other stuff to the table, such as the introduction of a number of DDD concepts and if / how much of those would be required and / or helpful and could be added without removing the basic simplicissity still possible with meteor at the moment.
I think I remember that there was more âproseâ and a longer introductory chapter in ye olde Meteor docs, before they were switched to the new doc website around meteor version 0.7-1.0-ish?
It really pulled me in back then and gave me a great overview over the system. It iterated over the big picture - ideas behind meteor and some reasons for the implementation and how awesome it all was.
It reminded me a bit of the âZen of Pythonâ, which I am a sucker for⌠I just like the simplicity of basic, strong rules and focus, well executed⌠and then a whole platform and community which gathers around those core principles and keeps it going.
It must still be around somewhere in some git commit or somesuchâŚ
So, TL;DR: BRING BACK AND REFRESH THE OLD NEW METEOR CONSTITUTION!
What do you all think?
1st: CQRS / Event Sourcing
I absolutely love your mention about CQRS and ES. Meteor works really well on top of it with its full stack reactivity. It might become one of the few platforms that provides a low entry into being a full stack solution for this architecture. Though keep in mind that CQRS and ES are quite advanced concepts. Its nothing like a getting started building apps type of thing
Actually, CQRS and event sourcing have already been explored in full detail accompanied with an ecosystem of packages that ease and guide with the paradigm within the context of Meteor.
Take a look at https://github.com/meteor-space/event-sourcing and https://atmospherejs.com/space for some packages and a nice example at https://github.com/meteor-space/example-app-event-sourced-shop along with some ui packages that kind of worked with react/flux principles which fit the paradigm quite wel.
So what I want to say is, thereâs nothing that holds you back from implementing any architecture on meteor. Meteor in essence is a javascript build tool with some goodies that you can leverage to implement your desired architecture.
Fibers seem to be the thing that moving away from them could be considered Meteor 2.0 due to how significant of a change that is going to be. Personally Iâm going to run with that.
Where can I find infos about Momentum? Via Google, I only found some jQuery plugins with that name?
The Meteor team would love to know, tooâŚ
I think that the momentum of NextJS is purely based on the fact that it provides a bit of abstraction over the SSR part, which is relatively complex compared to other things. The same goes for file structure. Though Meteor recommends it in the guide, its not as clear as the project already being in a structure like Next and Nuxt do.
Mostly a lack of knowledge about existing tools like Meteorâs DDP api or Apollo. People also underestimate building their own API, because REST (most used) seems deceptively easy at first. Its only further down a projectâs process where people start to realize that their API implementation and standards are crap. By that time the decision to go ânot meteorâ has already been taken and people will be reluctant to switch to any other platform, because of dependencies and lack of business value to do a rewrite. This ofcourse hurts Meteor, because Meteor should be that first choice when it comes to its powerfull DDP based API.
The bad experiences of expert beginners really hurts Meteor. Ofcourse there were some issues, but most of them are now completely obsilete. I hear this as the motivation for a lot of developers to not choose Meteor.
People forget that Meteor just runs node in the end. There should be no issue in switching. Tell that to those people that donât understand it.
Momentum has been mentioned already. But here in the Netherlands for example, the community and meetup groups seem stale. Because of that, people are afraid that when they need help, there wonât be any or that Meteor will cease to exist soon (again lack of good news and company related stories in the Media)
Iâm trying to reach out to the meetup.com Meteor group co-owners for Amsterdam, but unfortunatly no response yet. @benjamn any chance you can help me bring the Meteor Meetup group for Amsterdam back to life? Me and my company Passionate People organize a lot of Frontend meetups including Vue, Angular and React with speakers like Evan You (Vue creator) and @akryum (core developer and creator of the Meteor Vue integration packages). We are eager to help and spread the word here!
Great post .
That link about expert beginners was awesome - thanks for sharing that.
I fully agree about momentum. There was an incredible commitment to Meteor back in the early days by MDG - does anyone remember the 1.0 release event? I would love to see even 20% of that come back again - and why not? Meteor still does many things so much better than other frameworks/platforms. Thatâs something we should continue to shout about.
I agree. I still love Meteor, but for me, one of its biggest downsides is that MDG started to neglect the mobile side of it. Plus the upgrade issues. Though many people insist they do not exist, at least for me I am having a lot of troubles each time I upgrade. Maybe itâs because I am focusing on mobile, maybe itâs because I am using SCSS which nearly always breaks to some extent. Dunno. This, combined with the neglect of mobile support, caused a lot of frustration and increased interest in other frameworks.
Still, I havenât found a good alternative, so Meteor is probably the best out there. I tried NextJS, but it was more for pure frontend / web page development and did not come close to what I could do with Meteor. Itâs been a while since I had a look at it, though, maybe this has changed in the meantime.