Future of meteor?

[Bessonov]

Hey everyone,

sorry for this title. I'm not meteor user yet, but I'm playing with it. Currently, and after usage a wide range of frontend and backend frameworks, meteor feels quite cool for small till mid-size projects. Maybe even for big projects, but later on this one.

My concern is the future of meteor. Since months there is just one committer. I see that Apollo get more love from MDG and it's good, but not for the price of meteor. Is meteor dying? I hope not, because I don't see any competitor for offered features like reactivity, live updates, mobile support with code push and sharing code between apps, web and backend.

Therefore it would be nice to explain some future of meteor. I don't mean this roadmap or this, but more strategic view on meteor from MDG perspective: how it plays with other projects and how MDG process with meteor further?

Some points, which are interesting in this setup:

Why it's beneficial to have blaze?
I can understand, if blaze offers some features, which another libraries don't. May be I overseen something. But then why should another frameworks like angular, react or vue be supported? From my personal point of view, it's better don't spend time to develop own view library. Furthermore, angular and vue has own batteries. I think it's best to focus and go with official support for react only, because it's just view library, get great momentum and contributed by really named players. Other frameworks (and docs and examples) should be supported by community. How see MDG that?

Official docs about limits of meteor
Which use cases are not or not well supported by meteor? For example, can whatsapp or facebook be developed with meteor? Why not? It's limited by local database?

There are some blogposts and experiences with scaling of meteor. But I don't see any official statement how to scale default stack to serve hundreds of thousands users. Where are pitfalls? It's only database? How should the database be prepared? How size servers for average load? I know, it's hard to tell that, but this can be collected and contributed by community. This is my concern to use meteor for mid or big applications.

TypeScript support
Unlike Apollo, TypeScript support for meteor isn't great. Is there any plans to improve it?

Have a great discussion!

[aogaili]

Ah the future worries discussion, I can tell you that these concerns has been raised consistently for the last 3 years. We saw Meteor value proposition and took a chance with it and so far we're extremely pleased with the decision.

But yeah I echo your desire to have more people working on it but that single developer you mentioned (Benjamin) is really a league on this own.

With regards to Blaze, it has been open sourced in 2015, MDG no longer support the view layer, instead the focus has been on the build and integrations.

[Bessonov]

Found this one, from 2016: https://www.discovermeteor.com/blog/the-state-of-meteor-part-2-what-happens-next/

[aogaili]

Yeah and all the points he mentioned happened and more.

1. We've a read good guide compared to what we had in 2015

2. Meteor improved the core build tools, latest node, dynamic imports, build time optimization, bundle visualizer, lighter bundle and now we've build process that produces to build package one for legacy browser and one for the modern browser which has a huge performance implications. Read here.

3. Meteor great supper for NPM packages, most folks are using NPM packages and core packages are well maintained. Furthermore, the community actually introduced new innovative packages (Grapher,, Redis-Oplog, Molecule etc..) to solve many issues associated with building web apps.

[Bessonov]

Hey, @aliogaili , thank you very much for your comments!

Grapher leads me to this awesome presentation.

From my perspective, Meteor (and Kafka) already revolutionized the way how to build modern applications. But there some missing pieces of the puzzle. May be Apollo is just one of them.

Here are my toughs on Meteor. Correct me, if I get something wrong.

Materialized and reactive view on the data
Currently, this is done with mongodb/minimongo with described scaling limitations in the presentation. It gives great developer experience, but overall, and even with redis, it's doesn't feel like right foundation for this job. I think it should be something like RethinkDB (dead, but forked). Performance and scalability are things and should be addressed.

Another view on this, is how data is presented. In the past, I tried to use Query component, but it feels wrong. More sophisticated solution is ReactiveQuery from slide 58. It's impressive to subscribe to a sort of GraphQL and reflect database changes on the view. Maybe it's already supported by Apollo?

One of our use case is a chat-like app with huge amount of scrollable data with dynamic heights. We implemented it with a sliding window strategy. I'm not sure that this can be implemented with Meteor.

Mobile support
It's great to have much or less single code base for the browser, backend and mobile apps. Despite endless count of bugs in Cordova and WkWebView, I think it's a reasonable choice. But I think MDG should concentrate power on react native.

Offline support
It seems like the current solution supports some offline capabilities. I played with react todo app in the browser a little bit and it was able to propagate offline changes to the database after connection is established again. There are some packages, which store events locally to let survive changes between restarts: GroundDB (may be dead) and redux store.

There are not many technologies with offline (first) support. PouchDB and Hoodie seems to be good on syncing (not tried both), but Meteor's approach with DDP seems more promising, especially because of tight integration with database.

Alternatives to Meteor
ATM, I don't see any more promising technology to implement super powered apps beside of Meteor. It would nice to have a statement of MDG strategy. For me, it seems like MDG want to replace Meteor with Apollo. It is true?

[aogaili]

Grapher leads me to this awesome presentation.

Yes, that was presented at Meteor Night past May, you can find the video here.

This is my subjective opinion after using Meteor for several years now on a complex enterprise app, I've looked closely into all the items you raised.

Materialized and reactive view on the data

even with redis, it's doesn't feel like right foundation for this job. I think it should be something like RethinkDB (dead, but forked)

There were many discussion on how to scale meteor (using RethinkDB, new Mongo Streams etc) but the redis-oplog provided a solution that can be applied incrementally without change in the code and with enough flexibility that it pretty much solved the Meteor scaling limitation as far as I can see.

Mobile support
Agreed, but react-native would be yet another integration MDG has to maintain so it'll need be done by the community.

Offline support
I don't think meteor provide any capabilities for offline support, it basically leaves this to the front-end developers.

Alternatives to Meteor
I agree with that statement, I think Meteor is in a really unique position within the Node ecosystem and outside as well.

[CaptainN]

Meteor has more contributes than just Ben Newman, but he is a monster! He has an outsized portion of commits. :-)

I'm currently building a large social media app with material-ui and react on top of Meteor, and there is no problem at all with any of it. I'm using MiniMongo (I didn't have space in the budget for any new learning - and haven't picked up Apollo yet), and storing data into GroundDB over meteor methods for performance (I have many posts in the forums describing these decisions). It's all offline-first - so data in the views is driven directly from GroundDB. I may change my offline store eventually, but it's all working pretty well - and even if I traded meteor methods for Apollo at the data transport tier, I could keep using minimongo with GroundDB for offline first architecture. All my queries are isolated into what I call "Connectors" - these are designed so that when I move to Apollo (and likely a relational database) I can just swap out the connectors. Very clean.

I've also got SSR, modern/legacy bundles, code splitting through dynamic imports and all that working, including offline first with meteor's appcache and GroundDB - though I do admit appcache needs an update (it uses the old deprecated browser appcache API, and really needs to be updated with service workers - but it does work as is today).

All this with hardly touching the build system (added one babel plugin for SSR to get Loadable working). To me that's a lot of value.

If you are just getting into Meteor now, bite the bullet and learn Apollo, you won't be sorry!

Since I'm doing a react web app, I added all the necessary stuff for PWA - the only thing meteor is missing for that is a service worker, but you can just add a file to the /public directory and register it (or reach into the connect API to expose a file with the correct mime-type if that's important to you - the browsers don't care). It's a bummer there is no easy way to use Meteor's build system yet, but that doesn't mean it's not possible to get one working.

So PWA is a good mobile story - PWAs have a lot of feature access on device these days (even on iOS), and they start up faster than Cordova. That said, there is also Cordova still built in if you need that, and there are ways to pull the bundle into a React Native project (and it makes sense to keep those world separate IMHO).

[mitar]

In any case, I think this discussion is better suited for the forum and not this repository.

[StorytellerCZ]

This is no longer relevant after acquisition by Tiny Capital, so closing.