Ask HN: Is Meteor.js dead?

I'd personally avoid Parse as it's been shut down. I worked with someone who had inherited a Parse-based app last year and we had to do a fair amount of gymnastics to get it working smoothly. That was just my personal experience, though.

A good rule of thumb: if it works for you, use it. There's a lot of ballyhoo about keeping up with the tech Joneses which is mostly unnecessary. It's the most common excuse I see people using for not sitting down and just building their idea (we teach people how to build their own products at Clever Beagle). Tech always changes. If you're truly successful, at some point you will have to migrate to some new technology. Most concern about "blowing up" is just hubris disguised as optimism.

There isn't, hasn't, and will likely never be a permanent, perfect solution. Every single piece of technology has gotchas and idiosyncrasies. Use what you understand and makes you productive—the rest will take care of itself in time.

The server "publishes" particular queries as a kind of feed, and the client "subscribes" to some number of these feeds and behind the scenes, a miniature mongodb-like-api (mini-mongo) in local storage gets filled with all the published data you are subscribed to, so both the number of documents needed should be limited, as well as the scope of the query itself, for performance reasons... Scaling in the sense of: 1) number of simultaneous users maintaining a DDP connection with the server and the beating the db and backend take 2) amount of documents that get shoved down the tubes.

So, the more fundamental issue: Nothing about meteor's approach allows substituting components from the rest of the javascript ecosystem, other than the view layer, as the server side only speaks DDP, as does the client, etc.

One cannot easily optimize the various routes of the application as it's all just one very tightly coupled SPA with a ddp backend?!

I ended up being able to use an apps existing data, and taking the templates/components and patching in 1)routes and all dynamic data and what not from the server side needed to "dish-up" the template plus some 2) vanilla javascript to post data to server routes that may return either markup + data or simply data that get's patched into the specific place in the dom that needs updating.

This at least provided a basis for further work on individual routes/views etc.

Probably not dead yet, but in 2018 it makes more sense to use lightweight tools and frameworks that you can easily extend and make your own, and setup microservices.

Vue + Koajs might be good if you want to stick with js, vue/laravel go well together, or vue+(pick one: django, phoenix, rails, flask, sinatra, etc...).

With react native or ionic framework you can easily built mobile apps for ios/android off the same api, so meteor doesn't have a lot of advantages. It was nice for a time, but I think JS is moving in different directions now.

My experience with firebase is that it gets way more credit than it deserves. It's easy to develop on, but we had connectivity issues almost weekly with it, despite their status page saying everything was running smoothly. Firebase also has scaling issues. Last I heard, you can't have over 100,000 concurrent users, but it's not really publicly stated anywhere.

This comes up every so often here on HN:

"Is Meteor.js dead?" - 19 days ago https://news.ycombinator.com/item?id=16622231

"Is Meteor.js still a thing?" - 5 months ago https://news.ycombinator.com/item?id=15624623

"Is Meteor(JS framework) is dying slowly?" - 1 year+ https://news.ycombinator.com/item?id=13303345

Personally I still use it but I think MDG made a big strategic mistake in organizing its marketing around DDP (its data protocol that allows for "real-time" updates where the database pushes messages upon update) when I find its biggest assets are its single ecosystem and overall speed.

It's hip to say Vue.js is better but you'll still need an underlying framework -- Express, Nuxt, Koa2, etc. Even if you like the features of Vue better you're likely making the life of some future developer difficult by pairing two relatively unknown frameworks whereas at least with Meteor they only have to contend with a single system.

I also like Meteor's integration with Cordova and have built a single codebase that my company uses for a website, iOS and Android apps. For a very small company like mine having just one technology to deal with the website and mobile apps makes Meteor 100% worth it.

MDG is very active in supporting the platform, just see https://github.com/meteor/meteor/releases

But I can't speak for every use case, nor am I measuring commits or StackOverflow questions so maybe it is declining. But anecdotally it isn't from my POV as a Meteor user.