Thingking about Meteor 2.0 🤔

core
10

Also I was thinking why not having something like Vue financial backup for Meteor 2.0, similar to what Vue did here https://vuejs.org/support-vuejs/

2 Likes
11

This (above) is the number one issue, for me.

I’m in a bind right now:

  • Meteor has spoiled me to the extent that I can’t live without realtime and an isomorphic client/server database API
  • The current set up of pub-sub (via oplog) has a very real scaling limit (i.e. when write volume exceeds the server’s ability to consume the oplog)

I can’t run a big SaaS on Meteor pub-sub (as much as I’d love to), but also can’t face the thought of writing software using anything else.

11 Likes
12

This worries me too @babrahams. I’m in the exact same situation.

I believe the conditional usage of: redis oplog and change streams (change streams is somewhat limited) could help Meteor achieves more scalability.

Integration with Apollo as a first class citizen would be great, but I wonder how it would replace minimongo and all the things we are used to (optimistic UI) seamlessly. So, not sure about it.

3 Likes
13

Folks researched this feature and concluded it doesn’t support all CRUD operations.

But redis-oplog solved that scaling limitation while maintaining Meteor pub/sub API, so why is this still an issue?

I noticed that whenever this kind of discussion happen people tend to emphasize different things depending on how they’re using Meteor. I think it’s worth pointing out that the name/concept “Meteor” seems to be overloaded and it’s meaning different thing for different people. I think there’re three concepts here:

  1. Meteor as a Full Stack : if you started before 2015 or follow the Blaze tutorial, then you’re using it and it comes with Blaze, mini-mongo, tracker, DDP, many Atmosphere package etc. This stack is a league on it’s own in terms of speed and simplicity of development, great for starting quickly because you’ve all the layers of a web app integrated, perfect for learning, prototyping and small to medium size production apps.
  2. Meteor as a Backend : if you started after 2015, switched blaze to other view layer and followed the guide with validated methods and minimal pub/sub usage, you’ll end up with this architecture. Here we’re using meteor build system and RPC methods powered with DDP but the client has been replaced with something like react, vue, angular, etc. If you don’t have complex API, integrating with only one client, and have few data sources and using mongo as a DB, yet you might change to something else in the future, then this is a great option to start with.
  3. Meteor as a Build Tool : this is the closet you get to plain node.js project and this is how Vulcan.js and other frameworks are being built on top of meteor, they use meteor to primarily package and compile their files and maybe the accounting system. Most of development effort by MDG over the last years has been (in my opinion rightly) placed here, along with Apollo. The data layer can be rest, but who will go back to rest after DDP, so most likely it’s GraphQL and probably Apollo.

Again as far as I can see, the main push Meteor can get now is supporting VueJS at the same level as React/Angular and continue pushing on lean/fast/flexible build system.

6 Likes
14

I seem to remember hearing it doesn’t support anything except observing a findOne by _id or something like that. Which is not a silver bullet, but it helps.

“Solved” is a strong word; isn’t “mitigated” more accurate?

I guess what I, and others, want is 1) Meteor as a Full Stack with big scaling capacity. For the very reasons you point out:

15

Actually I think the folks holding tight to Blaze/Mini-mongo are preventing Meteor in 2018 from moving forward (and I hope I don’t come across as offensive), the ecosystem in 2018 is very different from that of 2012 (it’s no longer Gulp, Handlebars, and jQuery era).

Take a look at the starter kit that got announced today, that looks like a modern stack to me. Have similar starter kit for Vue with up to date tutorial and guide, coupled with open financial backing from existing customers and “Meteor 2.0” can become the engine behind Vue/React ecosystem. NextJS, Webpack and Parcel all have limitations/constraints and solve one piece of the puzzle, Meteor build system and Apollo are the closest to a complete NodeJS Web platform in my opinion.

6 Likes
16

I totally agree with this statement. This part of Meteor reached a very stable state and should by now already be deprecated.

3 Likes
17

I do agree in principle with this statement. Having dipped my toes on Vue, a modern jQuery-free frontend is the way to go. The choice lies between React and Vue, and I can see how a backend based on an Apollo server has a lot of appeal to many.

Having said that, I have various apps in prod on an enterprise environment (LOB app, no consumer-faced SaaS environment, no multi-tenant complexity), and the simplicity of the traditional Meteor environment (Mongodb/mini-mongo/DDP) has served us very well. And no performance problems whatsoever. I think that if you are careful with the the way you model of data including subscriptions, you will go a long way before you get to oplog-induced performance issues. Ideally I would like to redevelop the front-end of some of those apps (and I am), away from Blaze/jquery into a modern component-based UI framework, while keeping the backend simplicity (including the built-in meteor accounts), and Vue would be my choice over React for various reasons.

In summary, yeah, want to get away from Blaze into Vue on the front end, without loosing all the traditional Meteor-backend stuff. DDP-based pub-sub not an issue, specially with redis-oplog as as an option if ever needed. I can see the benefits of Apollo in a large/complex SaaS where the number of simultaneous users can go quite high, but in corporate environment even in a large company with tens of thousands of employees, we don’t needed that level of scale for Line-of-business applications, while flexibility and simplicity of the backend is very important as business processes do change very often.

2 Likes
18

While I did take a good look at it, was the first to “like” it, and sincerely appreciate the creator’s work, I can’t help but think: “That looks kinda complex.” It’s getting similar to the extensive tooling set-ups that non-Meteor users have to deal with.

Back in 2012/2013, Meteor allowed a whole bunch of non-professionals (myself included) to create amazing apps, with real-time capabilities, at unbelievable speed. This provided a massive point of difference from anything else (and still does, I think). This was all very magical, provided the app only served a relatively small group of users.

Since then, Meteor has made some great strides in keeping up with trends in javascript development (while miraculously maintaining back-compat) but, if you look objectively, from the perspective of an entry-level dev, every major development since 2013 has involved a small trade-off: more flexibility and robustness, but at the price of more complexity.

Now we’re at a point where a “modern stack” probably has little to no appeal to a new dev, with or without Meteor.

If Meteor wants to be groundbreaking again (and I’m not sure it does), I think it needs to do what it did back in 2012/2013 and come up with something that completely revolutionizes javascript development. That is: create something that gives all the benefits of a modern stack, but with all the ease of Blaze/Minimongo. If this involves dropping Blaze/Minimongo completely, fine. But the replacement should be just as easy as Meteor was at its rapid-prototyping best, only with the ability to scale this time!

3 Likes
19

“That looks kinda complex."

It is more complex but at least the framework can cater for advanced use cases. Not everyone wants PWA, Apollo, Styled Component, but for those who want the framework can support it (i.e. you don’t need to switch later for webpack or something else).

Yes, but those small group of users proved to be not a good business case for MDG (they don’t pay much). With that said, if someone wants the simplicity of Blaze why not use Vue (and help to write tutorial for it?) it’s arguably even faster then Blaze to develop since their entire ecosystem is integrated (it has router ^^) and well documented.

Again you can start simple and progressively build up, but you don’t want to start simple and get locked-in forever with simple stack.

I respectfully disagree, I don’t think this is feasible (given the current team size or the complexity of ecosystem) or necessary, all that needs to be done, at least in my mind, is to position Meteor as the go-to backend from Vue/React and market it in such away and I’m sure it’ll be the number one NodeJS framework.

2 Likes
20

I agree this a good setup, I use meteor (with RPC Methods/Accounts and DDP) with React, it’s a good setup if you don’t need flexible API. I think it’s about time to move to Vue from Blaze and help to write some of tutorials for the folks who are on the Blaze camp.

21

I haven’t seen anything suggested in this thread so far that would require a breaking change so fundamental as to require a 2.0 version.

1 Like
22

Versions are not only technical. To the outside world its also about marketing. I think Meteor is misunderstood by a lot of developers.

3 Likes
23

There’s a whole lot of enterprises out there in the world that would prefer a Meteor 1.78 over a Meteor 2.0. Marketing wise, the former says the stack has been stable and improved over N versions. The latter says that something was broken and needed overhauling and there are bugs to be worked out and the entire system is unstable.

6 Likes
24

When I look at the operating system of my phone, I don’t really care about the version, I care about its features. 2.0 means stable. Also, Meteor has improved so much over time with both Features (frontend framework support, npm support etc) and performance… Will you notice it as a client when Meteor gets rewritten entirely? Not really. Will there be a bussiness case to do it then? Not really! Only if new features are added and development slows down.

I feel that Meteor combined with Galaxy is a cashcow for MDG at the moment. It feels clear that Apollo gets much more attention. This makes it even less desireable to build any 2.0 version.

Look at all the bigger companies like samsung, apple, google and microsoft. Even if the new phone has some more features (no major stuff), its still the same, but they still make it a major version upgrade, they even name their versions. Do you think that’s a technical decision? No thats marketing.

MDG needs to be much more bold in its marketing techniques. Not only on the technical part. Its how the world works (unfortunatly)

1 Like
25

Moving away from semver would mean everybody’s tooling would break; deployment pipelines would break; etc. Doesn’t seem you’re thinking through the implications of what you’re suggesting.

1 Like
26

I’m not suggesting that Meteor should move away from semver, I’m suggesting that they should reconsider the definition of a major change. Personally I found the added support for React and Angular quite major.

27

All I want is better APIs for MongoDB(obviously MongoDB 4 support) and a fully fledged router :slight_smile:

28

This topic feels a bit like a nagging topic, but I think we are still here for a reason right? We all feel that it would be a shame to let a platform like this fade away, while it’s actually a really good platform and still (opinion here) much better then most alternatives.

1 Like
29

Two things must-do for Meteor 2.0 imo:

  1. Get rid of fibers and convert all core APIs and popular packages (hopefully community chimes in for this) to be promise-based.

    • The use of fibers has brought with it a lot of overhead like Meteor having to implement its own version of Promise and bugs like the infamous Fiber bomb.
    • It also messes up with how a developer normally thinks about the execution model on Node.js.
    • async / await is now a well accepted solution to callback hell, so we no longer have to inherit all the known and unknown problems associated with fibers, just so that we can pretend writing “synchronous code”.

  2. Expose core functionality as NPM packages

These changes will truly open the door for inter-operability with the rest of the Node/JS ecosystem, including alternate build tools, eventually broadening the reach and expanding the community

5 Likes