How can you have first party router when you are supporting multiple views?
I personally like the direction Meteor is heading, leaner bundle, fast build times and up to date with the rest of the Node ecosystem.
The node/JS ecosystem is way more diverse then when Meteor started so staying flexible and modular is crucial I think.
I agree with that statement, and we are not far off, only the guide/tutorial need to be updated and this is something the community can help with.
I think if anything actionable that can come out of this thread it would be updating the Vue docs. The folks using Meteor with Vue can really lead this.
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/
This (above) is the number one issue, for me.
I’m in a bind right now:
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.
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.
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:
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.
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:
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.
I totally agree with this statement. This part of Meteor reached a very stable state and should by now already be deprecated.
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.
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!
“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.
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.
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.
Versions are not only technical. To the outside world its also about marketing. I think Meteor is misunderstood by a lot of developers.
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.
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)
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.
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.
All I want is better APIs for MongoDB(obviously MongoDB 4 support) and a fully fledged router 