Thingking about Meteor 2.0 🤔

core
39

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).

3 Likes
40

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.

41

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.

1 Like
42

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 :slight_smile: .

1 Like
43

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:

  • I agree about Fibers being changed to ES6 promises/async-await. I’ve become relatively comfortable with it (as I imagine all the regulars would have), but I can entirely see it being a sticking point/a source of frustrations and quitting for someone new as well as a point of difficulty on boarding someone unfamiliar into the team.
  • Hasn’t been mentioned yet - but SOURCEMAPS. It is my number one front-of-mind ‘want’ for Meteor and I imagine anyone who is used to having source-maps, if they no longer have them as an option when they deploy a sample production app, may well be put off by 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.

3 Likes
44

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.

3 Likes
45

Two Things:

1st: CQRS / Event Sourcing

  • The big one: CQRS / Event Sourcing. The way of the future? It’s really cool technology. It lends itself to many advanced areas. It brings, for example, a near unfake-able audit trail (if complemented with some hashing of events), time-traveling capabilities, and infinite ways to run time-based queries on all the system events after they happened. A good integration, “Meteor-Style”, with a baby-implementation that “just works” and transparently replaces eg. the basic mongodb queries out of the box, with an upgrade path to more complex Domain Driven Design - Principles, multiple Servers / Clustering, containers etc… would make it really enterprise-y and scalable in the long term.

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! :smile:

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.

2. Bring back the old meteor - introduction?

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! :slight_smile:

What do you all think? :slight_smile:

4 Likes
46

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

2 Likes
47

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.

2 Likes
48

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.

6 Likes
49

Where can I find infos about Momentum? Via Google, I only found some jQuery plugins with that name?

50

The Meteor team would love to know, too…

1 Like
51

SSR is a big thing and Next + Nuxt developers understand that

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.

The api as USP is not that valueable for 90% of the developers

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.

People still think that Meteor is an island

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.

Lack of momentum and publications about the platform hurt Meteor

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!

10 Likes
52

Great post :slight_smile:.

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.

7 Likes
53

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.

2 Likes
54

I found Nuxt to be quite good and more complete and better documented then Next, but still. Heavily web focussed. No api, no mobile support like Meteor has.

1 Like
55

Just my ideas and cents in here - and stories of things I saw in other parts of the programming world. It picks up quite something from the current roadmap, but defines some ideas for the long run:

That @cloudspider pointed out that people think that Meteor is an island in my opinion could and should be focussed on in the switch to an NPM package.

I still remember this from my PHP days when Symfony2 came out and revolutionized the community by embracing the idea of bundling your code into packages (and sharing it via composer) and make it all modular. Despite of being a complete rewrite of their earlier system, they also managed to get away from being a big monolithic project to being rather a community with tons of small projects, each fulfilling a small part but doing it perfect - and they took this idea (and a lot others) from the Linux eco-system.

In fact, they ended up with a structure that rather reminded of LEGO, which made the community very flexible and open. Other systems quickly started realizing the potential and kicked in and made use of these packages (https://symfony.com/projects).

I see that the community on JavaScript is quite different from the PHP world and also at a different state.
But seeing Meteor being quite monolithic and creating wrappers (and I do not mean those created to support Fibers), which even go beyond by getting up to a new major version having breaking changes but still keeping e.g. their old naming convention (yes, I’m talking about you mongo) is quite a blocker.

Please don’t misunderstand me here. I want to give out a huge thanks for those keeping the Meteor platform in such a good backwards-compatible state. At the same time I don’t know if this is the right way to go in the future because it adds a new stone of stumbling - and you can’t move as fast as the original package does. On the one side we agree that we should keep the packages updated, on the other side we don’t want the breaking changes they introduce, which brings a huge burden and slows down the development (in my opinion).

I know that the mongo package isn’t trivial - specially because we also need to make it work on the client-side (where only a subset is supported) - and this only is a sharing of my impression.

And this is exactly where the thought of Linux comes into play. Any distribution of Linux decides which program to update when and some setup-scripts just need an update when updating the packages.

I would LOVE if a version 2.0 of Meteor would:

  1. Drops Fibers - which removes the necessity of creating a wrapper for a package to make it look “fit for the environment” (which in itself would qualify to call it a 2.0 from a developers perspective)
  2. Have the courage to remain upstream with other packages and break when things should break (up for discussion and personal taste …)
  3. Be more modular by publishing more npm packages, embrace the usage of them
  4. Take a look at other commonly used libs and define interfaces. Let the main meteor-stack (Symfony called it the standard-distribution) use the previously used package but let the users build a bridge for other libraries which then easily could become the new standard by replacing the self-maintained package with it.

If some of you have worked with PHP and a Symfony project before, you don’t feel bound by anything but you have the impression that everything is so modular that you can just take out the package responsible for the task and write a bridge which makes your favorite package compatible with it.

Pretty long … but I hope you get the point :slight_smile:

56

How does those changes improve the development experience? I’ve been using Meteor for some time now and I can’t see how those 4 items will add any value to the end user? say I’m new dev using Meteor how does those items improve my experience?

Also, where would the development resources come from? sounds like a huge refactoring effort and I’ve not seen any PR coming out of this thread aside from the Vue guide/tutorial (thanks Chris :slight_smile: !), is this something that you or someone in this thread have the knowledge/time to help with? The project has been modernizing for some time now, but JS language and ecosystem changed radically in 2015 and this is a heavy and specialized code base to refactor. Yet huge progress has been made by decoupling the view layer, support ES6, dynamic imports, improving build time, serving modern bundles, and support for node modules.

Personally I’m happy with where Meteor is now, my minimum requirement is that it stays up to date with node LTS & mongo, Github issues resolved, new JS syntax supported and the build time doesn’t regress (or ideally improve), essentially Meteor LTS. Also little marketing is always good, it deserves it since there is still nothing in the ecosystem currently match what Meteor is offering as far as I can see, other frameworks seem to try challenge a piece of the stack leaving developers to glue and maintain the rest. Also, it’s worth noting that Meteor packaging system is really unique and it’s enabling architecture styles that currently seem unachievable (or at least without a lot of effort) in a typical webpack setup.

So to sum up, for Meteor 2.0 I vote for (1) An official Meteor LTS statement from MDG (to counter all those 2015 FUD posts and increase consumer trust/confidence) and (2) Tutorial/guide for Vue coupled with little marketing.

13 Likes
57

Support for Blaze, React and Angular is awesome. Blaze is so simple to use and lowers the barrier to entry for a lot of developers.

3 Likes
58

I’d +1 your post over and over if I could

2 Likes