It is over 6 years since the initial Meteor release. Over the years I think Meteor was instrumental in changing the JS landscape (or at least the prophet of change). Obviously as with everything new shiny things come on and people rage on the old things (you can look up all the annoying āIs Meteor dead?ā threads on this forum). In my opinion Meteor has remained relevant and modern, yet I think it is about time that we start brainstorming a way to get back to the top again. Given how much attention and press major releases generate, releasing Meteor 2.0 I think is the best way.
So what Iām looking for would be ideas/feature that would make the Meteor 2.0 headline. This can be repeat of what we already have, but I think it would be nice to add something to make people give it another look.
In your suggestions I would like to ask you to be a bit visionary. Things like āmake Meteor be fully on npmā, or anything else that just copies existing features from create-react-app or next.js doesnāt cut it. What would be the new thing that would make Meteor go beyond all the other competitors (besides what we have now).
Or maybe just we need more projects like Apollo and socialize?
Iām using Meteor in 4 production real applications and Iām pretty happy with it.
For me the main point to sticky with Meteor is Cordova Integration, I like the idea of creating a great PWA and be able to publish to App Store and Google Play with little effort.
That said, I think this effort (to produce a native app) can be smaller and the documentation around it can be also better (that is also my fault as I have a lot of private documentation about it, I need to share more information).
If we have a great way to start a Meteor app, without any configuration (another selling point for Meteor) and easy steps to publish to Stores a great PWA that can cause a good impact in the JS community, currently there is no better tool to do that than Meteor.
Things to also improve:
first class support to Hot Module Replacement (itās already working in many situations using meteor-webpack)
first load time for Meteor Cordova Native apps (currently around 8 seconds in an almost empty application)
Comments:
NextJS is great but does not provide any way to create native apps.
React Native is nice but does not provide a good and complete way to create web apps.
PWA, IMHO, is the future for most companies (not the big ones like Google, Facebook, Airbnb, etc that have money to build native apps).
In Meteor 2,0 I would like to see the improvements to listen internal events not just by hacking and wrapping some methods. I am now developing elastic-apm integration with Meteor and I am tired and annoyed of some kind of dirty hacks. I think @arunoda has tooā¦
I would like Meteor 2.0 to be the defacto fullstack platform. Both Next and Nuxt are powerfull tools for their frontend libraries React and Vue (nuxt clearly being more powerfull and better documented), but both of them lack 1 main thing that Meteor does have: a very simpel API that works on the client and serverside with methods and Pub/sub support. Meteor might become that opinionated platform that grants our app a powerfull polymorphic API and buildtool.
Detachable frontend. Meteor might just be used only for its build tools and API. So Meteor would become a plugable platform that allows someone to add an api layer (rest, ddp style or apollo). And also the clientside part. (Bit like Nuxt plugins do).
Very strong focus on CI. Stuff like testing, reporting and deployments should be a breeze. Right now this is a big step to undertake.
Iād really appreciate newer versions of Meteor focuses on the bundler, not only to improve the performance as last updates are moving forward, but also by supporting HMR, tree shaking and be up to date to be able to get all benefits that other JS bundlers are accomplishing lately. It would be nice to see Meteor to improve in terms of Cordova integration as well.
Meteor is a monolithic framework which main benefit really serves to implement dynamic web/mobile apps easily. I think Itās a really important for most of existing and emerging companies to have this kind of infrastructure to save costs and focus on client needs.
For me, one thing would do it: Ensure Meteor supports Vue at the same level as React or Angular! It would be an āadrenaline shotā into both. Meteor is ideally positioned to become the preferred js backend for Vue, if only the support was there.
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.
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:
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.
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.
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.
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 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!
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.