Sure, it's being actively developed, but I haven't really heard of it being used in big production systems, which could indicate the community's interest has moved on.
Not that this is the definitive answer by any means, but simple measures like SO trends suggest that the community has moved on a bit[0].
Obviously I don't think that's definitive proof of Meteor being dead, but usually it seems like that's an indicator of declining new interest (which leads to extinction over time).
For another example, while I wouldn't say Backbone.js is completely dead[1], it's hard to pretend that it hasn't been largely supplanted by React and ES6, and Backbone probably doesn't have a bright future. There's undoubtedly a community around it still, but I would be shocked if that community doesn't get smaller each year.
I don't doubt that Meteor will continue to live for quite some time, but I think there's valid reasons to suggest the community will continue to shrink.
MDG has been focused pretty heavily on Apollo for quite some time. I’m not convinced Meteor has been shown much love. The package ecosystem has dramatically declined in quality over the last year.
And while the Phoenix part has all kinds of issues--especially when you make it work with Mongo instead of Postgres and Ecto--it's waaaay better than the Meteor bilge we inherited.
EDIT: And honestly, at this point we all think that Rails or Node or anything else would've been a better move than Phoenix, but hey hindsight is 20/20 and we inherited the legacy Phoenix app.
Could you describe the issues you've had with Phoenix and why you would have preferred something else? I am about to commit to Elixir and Phoenix for a project, perhaps a long-term one, and I would love to hear stories about how it doesn't work out.
So, I think that Elixir/Phoenix for a new project, if you're careful, is totally great.
Make sure you do happy-path integration tests first before screwing around with unit tests. Don't use Mongo, use Postgres + Ecto. Don't put changesets/business logic into controllers, call out to a dedicated business app. Don't use Mongo. Switch away from Brunch to Webpack early. Don't use Mongo. Don't do everything in maps, only use that at the edges of the web logic until you parse things into normal business objects. Don't use Mongo. Use a linter like Credo, customize the settings for your project early on. Don't use Mongo. Think about the "community standards" and make sure they actually apply to your problem.
Meteor 1.6 supports Node 8.9.x. What's questionable about Meteor's use of Mongo? Reading the oplog? You don't need to use the reactivity if you don't want it. There is a simple API to either use polling or turn off reactivity altogether if you don't care about it.
Anecdotally, everyone I knew who tried it complained about lock-in (environment too prescriptive and has behavior you can't opt-out of) and no longer uses it.
There is development activity in the repo, but I would say the 'hype' has moved to other projects.
There is no lock-in, developers can migrate in and out, and you choose the view layer, the backend is build on node, third party packages are from NPM and the DB is MongoDB. The data layer can be DDP or Apollo.
Of course if you use all the aspects unique to the stack (reactivity, accounts, blaze, pub/sub etc.) then you'll to re-implement those when switching, but then again that's an architecture choice, you can choose to ignore those and just use Meteor as a build tool.
I wish dearly to see the blaze-npm package, that would allow re-purposing blaze templates + helpers + events with a different backend in a non-meteor node.js context.
it's been "coming soon" for years, so I don't think it is...
I've got more than a few blaze meteor apps that could use a new lease on life...
Our Meteor webapp designed for real-time vehicle tracking was built in 2015 using Blaze, DDP, Pub/Sub and Iron Router.
Today, our webapp continues to work better than ever with the above technologies thanks to the continuous improvements made to Meteor by the MDG and the community.
Our business currently has no use for GraphQL or React.
I built a major project in Meteor last summer, and it was a big mistake. For the most part, Meteor itself is stable and being actively developed, but many of the packages are experiencing severe rot, and one of the developers of a few of the most used meteor packages recently went out of business and took all their documentation down with them.
Ever since Meteor added native support for NPM packages, many Meteor package developers are only publishing them as NPMs instead of on Atmosphere. That might be why you believe that there's rot.
The Meteor official guide (https://guide.meteor.com/) clearly encourages using NPM packages when possible since many Atmosphere packages are simpler wrapper around a NPM package.
But can also poorly choose NPM packages, thus the mistake in this case is on the poor choice of third party packages by the developer and not on the framework.
My company https://cleverbeagle.com is based on Meteor.js and we have an active customer base. I also run themeteorchef.com (tutorials on Meteor) and while we've definitely seen the hype die down, we still get organic traffic upwards of 25k uniques a month. Dead? No. We see a lot of new interest from overseas (Africa/Middle East/Asia).
Technically speaking, Meteor's in the best state it's ever been: latest Node version, full Babel support (zero config), great accounts system, full NPM support, ready-to-go MongoDB support and access to multiple DBs via Apollo. Things like Atmosphere, Meteor's package system—which have been earmarked to be phased out in favor of NPM—get Meteor some negative press.
It's a shame, too, because having actively explored alternatives over the last six months, the only platform that came close to being comparable (in respect to being fully featured out of the box) has been Firebase. It's not the only option but it's a damn good one.
Meteor deserves far more attention that it receives—miscommunication around 2015 regarding Meteor's choice of UI framework and the Meteor Development Group's shift to focus on Apollo put a serious ding in its trajectory. A guess: MDG had to make a return for investors and Meteor itself—and their hosting product, Galaxy—wasn't growing quickly enough (just a guess).
I’m using it for a side project which has been running for over a year. It’s not something to which I can devote much time and Meteor is easy to set up for what I need.
I suppose that if it dies I can re-write the application using some other framework (I’ve done Android/Java and iOS/RubyMotion versions), though it would be a bit of a pain. For now, with no new features planned, I can keep it running as long as the Meteor bug and security fixes keep coming.
Technically you can run it indefinitely. Meteor is open source and the Meteor team has been actively working with community members to do PRs and what not. There are enough people on it that the ball (to some extent) would be picked up by community folks. Perhaps not a bad thing, either, as it could breathe some new life into it.
> It's not the only option but it's a damn good one.
I've been using Parse, is another good option in your opinion? I quite like it, especially as everything is available via REST so it is easy to use it with Elm
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.
I like that it is open source, but the question is how well is it being maintained? Having said that one can self-maintain as I think it is NodeJS. That's what you'd have to do if you write your own Backend - so the only problem is how spaghetti like the code is.
It’s just Node.js. All of the Meteor-related code can be removed if you really wanted and just rely on the build system. Even if you had to do a port to a vanilla Node.js app, a large reasonably well-structured app might take a month or two tops to port.
Side note: frameworks don’t write spaghetti, developers do.
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.
does not bode well for any open source software project. there is a vast expanse between "dead dead" and "vivaciously alive". You will not get a straight answer because there is no good answer.
I started using Meteor in 2014. I was active for two years, posting frequently on their forums, writing packages, building MVPs, etc. As I started building more things with Meteor, I realized that it doesn't scale well. It's great for proof-of-concept work. Frameworks can be incredibly productive for low-scale work, but they are painful to scale. No framework that can be simultaneously optimized for every use-case. Now, I always DIY with a router like Express.
Meteor's problems were rooted in its real-time protocol, DDP, which had some problems. Firstly, everything is real-time by default. It's better to minimize the amount of real-time components in your application as there are very few things that need to be real-time. Secondly, the pub-sub caching mechanism made it infeasible for situations with many concurrent users. I was able to get around this by proxying some of their internal functions.
Significant people in the ecosystem started leaving (e.g. Arunoda), probably for the same reasons. AFAIK, it's still the best JavaScript framework out there for prototyping and MVPs. Their accounts system makes whipping up a user-driven application trivial. MDG (the phenomenal team behind Meteor) is likely focusing their efforts on Apollo now, because they understand DDP's shortcomings. If you're interested in Meteor, I suggest looking into Apollo.
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.
For real-time webapps when you need minimum latency updates, Meteor is a dream. IoT, GPS tracking, messaging apps and stockmarket trading apps are all well suited to being implemented in Meteor.
DDP is a simple protocol that runs on top of WebSockets, which runs over TCP. Back in 2013, someone achieved 12 million concurrent WebSocket connections on a commodity server. There is no reason why Meteor should not be able to handle a comparable number:
Meteor fully supports the NPM ecosystem. Meteor does not have to always use DDP. You can implement RESTful APIs and serve static pages using the many router packages available.
- 'key' people left because they were service providers (including Arunoda). When the platform became mature and easier to use, they could not get business.
- DDP works great, Apollo is a GraphQL layer, two separate projects and target users. If you have a lot of users you need to design pub/sub carefully regardless of tool. Reactivity makes it a bit tougher, but comes with great benefits (unless your project is 'simple' or more static)
- Scalability? It's great, and we are the proof -- you just need to know what you are doing (i.e. redis)
About: "we are the proof" — who are you? :- ) It'd be interesting to have a look at your website or web app or Git repo or something. And, if you have time, I think it'd be interesting with a few words about how / why that shows Meteor works well? E.g. num concurrent users that get pub/sub messages? (Your HN profile is blank, there's a GitHub user though with your username, who seem to do lots of Meteor related work. I'm using Nginx and Nchan for pub/sub messages, and ... I'm curious about Meteor and other things too. No plans to switch from Nchan though.)
I would use Meteor again as it excels in this area. Meteor 1.6 works with the latest Node LTS version (currently 8.11.1) and therefore is compatible with all modern code.
I never used meteor, but from what I understand it's functionality was, I currently use FeathersJS + SocketIO + VueJS (and nuxtJS for serverside rendering).
I built an app that was 90% CRUD a year ago and I choose Loopback, but FeathersJS was on my radar. Loopback did the trick, but I just hated defining models in JSON instead of JavaScript objects. Good to hear FeathersJS on HN. I’ll check out the project again.
I tried FeathersJS for a recent project but ended up dropping it. Documentation was all over the place, many of the example repos didn't work out of the box, and I found some of their solutions were half baked. I also found their core ideas added as much mental overhead compared to "standard" express routes and so wasn't worth the proposition of consistently setting up routes. Maybe if you came in at the right moment when a release's documentation has settled down, outdated documentation is clearly marked, and a majority of users have settled on particular libraries, but that was not the case when I checked it.
I'm thinking of checking out Meteor now since on balance people here are saying it's good for prototyping at least, and I'd like some real-time functionality.
In general, its solid for its use cases, but you need to understand what its good at. Its pretty great for small apps, prototyping, hobby projects, etc.
There are a few things we learned that I'd share:
Use React. Should be obvious. Meteor's react support is pretty great.
Stay away from Meteor packages as much as possible. Its better to look for a similar NPM package and do the integration work yourself then to rely on the "magic sauce" that many Meteor packages use. The only ones I can really suggest using are the official MDG ones.
You don't have to use pub/sub to fetch data. You can absolutely fetch data through Meteor Methods in situations where real-time isn't important. Meteor methods are just simple request/response RPC. Pub/sub can become stupidly hard to reason about, though in simple applications can make your app seem really fast and responsive.
That being said, its got great integration with Apollo. If you start with Meteor, ignore all of the DDP stuff (pub/sub, methods, etc) and just build the API with Apollo, you wont regret it.
If you think you'll want to deploy a mobile app, maybe don't do Meteor. You still definitely can, but Meteor's semantics around the always-on websocket connection tend to severely hurt a mobile-first experience.
Today, I'm not sure I can recommend new projects go with it. That being said, I also feel like a normal GraphQL server on Node isn't "far enough" down the path that Meteor set. The JS backend world is still really far away from an AIO framework like Rails/Phoenix; Meteor is the closest we got, but its not the answer.
^^ I did lots of research on whether Meteor was the right move for us. I ended up learning about Vulcan.js, which is developed by the Sacha who built the very popular Telegram on Meteor back in the day.
I have to say I'm impressed so far. Lot's of nice things to get one up and running quickly. But it's been thought about in a way that should allow you to mix and match the defaults it comes with in a modular way as your application grows.
With Apollo/GraphQL at its core and React on the front end it really does make a lot of sense given current trends and I'd urge anyone looking at Meteor to check it out. Great active Slack group too.
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.
so how is vue/laravel any better then vue/meteor, react/meteor or angular/meteor which are all officially supported?
react native and ionic framework all can be used with meteor in which meteor can be used as a backend (providing API such as rest, apollo or DDP) and many active projects used this approach.
As far as I know Meteor is losing a lot of support, while I used to like meteor, I wouldn't touch it with a 10 foot pole today because of some of the concerns others have brought up.. I'd say using microservices/api on any platform -python, koa, express, java, go, elixir, laravel, etc.. with vue or react on the frontend is the current trend/best practice.
For me, I know laravel inside/out. For me it's way better because I can build an app in a week using Vue+Laravel. Laravel also isn't coupled to mongodb which, personally I cannot stand nosql db's. There's been so many cases where companies have used nosql and then had to migrate to postgres because they need 'acid', or other features. PG has json data types, so there's no reason not to use it as a doc store within a rdbm.
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.
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.
Yes, there are advantages to being decoupled from the underlying framework, as you point out.
If you're a Ruby on Rails shop, Meteor is probably not for you.
But I think people under-appreciate Meteor's value proposition of not having to piece together multiple frameworks -- especially in JavaScript world, which seemingly produces a new framework every other day.
Indeed there's nothing stopping it. Meteor have tutorials for react [0] and angular [1], so although there isn't a tutorial for it, the JavaScript fundamentals of Meteor won't change if you use Vue.js.
Apparently it’s not the only thing that is as good as dead with activity on GitHub.
Meteor might not literally be dead, but it may as well be. Don’t use it. Even MDG seems mostly focused on GraphQL these days (and that sucks, too. But that’s a whole different topic.)
Eh, that repo is a mirror. Issues are still handled by RT. And if you look at the actual activity, you see that it not quite dead yet (https://github.com/Perl/perl5/graphs/commit-activity). And afaik, Perl 5 is in code freeze at the moment in preparation for the yearly release in May.
There are almost daily commits going to it, but the rate of commits is not the same as when a project started. By your logic any stable project on Github is dead. Also by your logic, when person grows in height until they reach their mid twenties and their growth stagnate, as they've reached their maximum potential, we can call them dead. Assuming you're above 25, by your logic you are dead as well.
If you spend little time at the forums you'll realize there are plenty of people using it with active community contributions and thriving open source projects and commercial businesses built on top of it.
Technology goes through phases (hype cycle) and Meteor is at a stable phase.
A lot of the comments here are ignorant about the the progress made in the last two years, to be able to form objective opinion, one need to proper research and not just listen to the FUD.
I run my SaaS https://focuster.com on Meteor and I have also built several SaaS projects for clients using Meteor as the base. Some have criticized the scalability of DDP. While out of the box the real-time reactivity won’t scale infinitely, the community has released packages like https://github.com/cult-of-coders/redis-oplog which is a great solution for scaling.
If I had to start over I’d probably still use Meteor but with Apollo as my data layer instead of DDP/pub-sub.
As we usually say technologies does not die easily. But they become legacy when no one want to use them for new project. The main problem of Meteor is scaling problem. Due to it's fundamental design and platform it's relying on (Mongo and node.js). It's very hard to solve the problem for current Meteor.
But anyway on the other hand Meteor has extremely high velocity, higher than any framework I have seen (Of course even higher then Rails) due to it's isomorphic nature.
Nowadays I'm betting on Elixir and Phoenix to achieve both high velocity and performance. The performance is literally crazy since it runs on Erlang/OTP. But frankly MVC + RDBMS is not something comparable to Meteor on velocity. Currently I'm trying to throw databases away and use WebSocket + GraphQL + GenServer(some in memory process storing data) to boost up velocity, only use data base as a process backup (message + process IS transaction. Then dirty write all the way down). Now there's still some boilerplate, but I found it's promising.
Meteor is alive and well! In 2015, my business implemented a Meteor-based real-time vehicle tracking app utilising Blaze, Iron Router, DDP, Pub/Sub - features and packages that a vocal minority of misguided people seem to want to kill off or at least disseminate Fear, Uncertainty and Doubt (FUD) over.
This anti-Meteor FUD is being spread for the following reasons:
1) Someone doesn’t know how to use the Meteor feature properly or have the engineering/computer science background to design a system to be able to manage computational complexity or scalability.
2) The Meteor feature or package is stable and mature so it hasn’t been generating much news or required drastic updates.
3) A competitor wants to promote a Meteor or Meteor package alternative that they have a vested interest in and are trying to manipulate people by creating self-fulfilling prophecies to kill off rivals.
Our Meteor app runs 24hrs/day and handles hundreds of drivers tracking in every few seconds whilst publishing real-time updates and reports to many connected clients. Yes, this means Pub/Sub and DDP.
This is easily being handled by a single Node.js process on a commodity Linux server consuming a fraction of a single core’s available CPU power during peak periods, using only several hundred megabytes of RAM.
How was this achieved?
We chose to use Meteor with MySQL instead of MongoDB. When using the Meteor MySQL package, reactivity is triggered by the MySQL binary log instead of the MongoDB oplog. The MySQL package provides finer-grained control over reactivity by allowing you to provide your own custom trigger functions.
Accordingly, we put a lot of thought into our MySQL schema design and coded our custom trigger functions to be selective as possible to prevent SQL queries from being needlessly executed and wasting CPU, IO and network bandwidth by publishing redundant updates to the client.
As we know, Meteor is tightly integrated with MongoDB which we did not consider to be well-suited to our needs. Did this result in us ranting publicly about how Meteor and/or MongoDB are “dying” or “having no future”? No!
Instead, we found a way to embrace and extend Meteor - an ongoing task.
In terms of scalability in general, are we limited to a single Node.js process? Absolutely not - we use Nginx to terminate the connection from the client and spread the load across multiple Node.js processes. Similarly, MySQL master-slave replication allows us to spread the load across a cluster of servers.
In my view, the reason why Meteor is not more popular is because too few people are sharing their Meteor success stories and the MDG has not been doing much to promote Meteor publicly.
More people need to showcase their Meteor-based solutions and stories of success at technical conferences and developer meetups and events - especially those that concern NodeJS, MongoDB, MySQL, Databases, IoT and WebApps in general.
And what makes Meteor superior to plain Node.js development? We get much higher productivity from our programmers who can write less code and make fewer mistakes developing in Meteor compared to say using Node.js with express. Here are 3 benefits we enjoy:
1) Meteor's use of fibers allows a synchronous programming style whilst avoiding callback hell. Meteor has an easy to use facility Meteor.wrapAsync() that allows you to use run any callback function, e.g. from a third-party package, within a fiber. There is also Promise.await() that does the same thing for packages that use Promises.
2) The isomorphic design promotes code reuse between the client and server-side and simplifies client-server communications. You simply decide whether you want to implement a Meteor method or a Meteor publication based on your application's needs.
You'd think majority people of at HH can do basic objective research and look beyond the FUD, but it seems not. Well, let me give you some facts, over the last two years Meteor added support for:
There has been major FUD since 2015 when Meteor pivoted out of Blaze (original view layer which has been open sourced) to open up to the rest of the ecosystem and some folks were not happy with that so they wrote few articles which shaped a lot of the FUD we read about here. It's a fact that today Meteor is way more flexible, you can use it as a full-stack, back end or build tool only, and you can pick which area of the stack you'd like to leverage.
It's very active and still, by the far, the most started Node JS framework on Github, it's very mature and stable and growing everyday.
Still using it, and I would still choose it over many others for most use cases.
People get Meteor wrong. It's basically a sophisticated build tool that takes away a lot of the burden of setting up a working build setup. If you want, Meteor will also provide a robust account management system and a seamless connection between server and client and a few other niceties, such as reactivity out-of-the-box and most recently, my favorite feature, dynamic imports.
I also love Meteor's own package system which provides so much more than Npm-packages ever can. I'd also like to mention Blaze, which seems now pretty unmaintained, but it's actually very solid and stable and works brilliantly with Meteor, especially with the ViewModel-package (supports both React and Blaze).
Meteor is awesome and it's only getting better.
The only use cases I wouldn't pick Meteor for are the ones where static sites shine, for those I'd opt for Gatsby or Nuxt.
92 comments
[ 3.4 ms ] story [ 157 ms ] threadBy the way: https://www.reddit.com/r/javascript/comments/672nrk/is_meteo... the second comment ;)
Obviously I don't think that's definitive proof of Meteor being dead, but usually it seems like that's an indicator of declining new interest (which leads to extinction over time).
For another example, while I wouldn't say Backbone.js is completely dead[1], it's hard to pretend that it hasn't been largely supplanted by React and ES6, and Backbone probably doesn't have a bright future. There's undoubtedly a community around it still, but I would be shocked if that community doesn't get smaller each year.
I don't doubt that Meteor will continue to live for quite some time, but I think there's valid reasons to suggest the community will continue to shrink.
0: https://insights.stackoverflow.com/trends?tags=meteor
1: https://insights.stackoverflow.com/trends?tags=backbone.js
I think that, in the right hands, Meteor is a great prototyping tool--putting into production and scaling it though is a fool's errand.
And while the Phoenix part has all kinds of issues--especially when you make it work with Mongo instead of Postgres and Ecto--it's waaaay better than the Meteor bilge we inherited.
EDIT: And honestly, at this point we all think that Rails or Node or anything else would've been a better move than Phoenix, but hey hindsight is 20/20 and we inherited the legacy Phoenix app.
Bet folks don't even know that those exist. :(
Make sure you do happy-path integration tests first before screwing around with unit tests. Don't use Mongo, use Postgres + Ecto. Don't put changesets/business logic into controllers, call out to a dedicated business app. Don't use Mongo. Switch away from Brunch to Webpack early. Don't use Mongo. Don't do everything in maps, only use that at the edges of the web logic until you parse things into normal business objects. Don't use Mongo. Use a linter like Credo, customize the settings for your project early on. Don't use Mongo. Think about the "community standards" and make sure they actually apply to your problem.
Don't use Mongo.
Doesn't matter what new versions support if we can't update things.
The reactivity choice was made for us (poorly).
There is development activity in the repo, but I would say the 'hype' has moved to other projects.
Even DDP and reactivity can be turned off, though these are powerful and useful features for real-time applications.
Of course if you use all the aspects unique to the stack (reactivity, accounts, blaze, pub/sub etc.) then you'll to re-implement those when switching, but then again that's an architecture choice, you can choose to ignore those and just use Meteor as a build tool.
I've got more than a few blaze meteor apps that could use a new lease on life...
I guess you can't please everyone.
Today, our webapp continues to work better than ever with the above technologies thanks to the continuous improvements made to Meteor by the MDG and the community.
Our business currently has no use for GraphQL or React.
Ever since Meteor added native support for NPM packages, many Meteor package developers are only publishing them as NPMs instead of on Atmosphere. That might be why you believe that there's rot.
But can also poorly choose NPM packages, thus the mistake in this case is on the poor choice of third party packages by the developer and not on the framework.
Technically speaking, Meteor's in the best state it's ever been: latest Node version, full Babel support (zero config), great accounts system, full NPM support, ready-to-go MongoDB support and access to multiple DBs via Apollo. Things like Atmosphere, Meteor's package system—which have been earmarked to be phased out in favor of NPM—get Meteor some negative press.
It's a shame, too, because having actively explored alternatives over the last six months, the only platform that came close to being comparable (in respect to being fully featured out of the box) has been Firebase. It's not the only option but it's a damn good one.
Meteor deserves far more attention that it receives—miscommunication around 2015 regarding Meteor's choice of UI framework and the Meteor Development Group's shift to focus on Apollo put a serious ding in its trajectory. A guess: MDG had to make a return for investors and Meteor itself—and their hosting product, Galaxy—wasn't growing quickly enough (just a guess).
I suppose that if it dies I can re-write the application using some other framework (I’ve done Android/Java and iOS/RubyMotion versions), though it would be a bit of a pain. For now, with no new features planned, I can keep it running as long as the Meteor bug and security fixes keep coming.
I've been using Parse, is another good option in your opinion? I quite like it, especially as everything is available via REST so it is easy to use it with Elm
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.
Side note: frameworks don’t write spaghetti, developers do.
does not bode well for any open source software project. there is a vast expanse between "dead dead" and "vivaciously alive". You will not get a straight answer because there is no good answer.
Meteor's problems were rooted in its real-time protocol, DDP, which had some problems. Firstly, everything is real-time by default. It's better to minimize the amount of real-time components in your application as there are very few things that need to be real-time. Secondly, the pub-sub caching mechanism made it infeasible for situations with many concurrent users. I was able to get around this by proxying some of their internal functions.
Significant people in the ecosystem started leaving (e.g. Arunoda), probably for the same reasons. AFAIK, it's still the best JavaScript framework out there for prototyping and MVPs. Their accounts system makes whipping up a user-driven application trivial. MDG (the phenomenal team behind Meteor) is likely focusing their efforts on Apollo now, because they understand DDP's shortcomings. If you're interested in Meteor, I suggest looking into Apollo.
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.
DDP is a simple protocol that runs on top of WebSockets, which runs over TCP. Back in 2013, someone achieved 12 million concurrent WebSocket connections on a commodity server. There is no reason why Meteor should not be able to handle a comparable number:
https://mrotaru.wordpress.com/2013/10/10/scaling-to-12-milli...
Meteor fully supports the NPM ecosystem. Meteor does not have to always use DDP. You can implement RESTful APIs and serve static pages using the many router packages available.
- 'key' people left because they were service providers (including Arunoda). When the platform became mature and easier to use, they could not get business.
- DDP works great, Apollo is a GraphQL layer, two separate projects and target users. If you have a lot of users you need to design pub/sub carefully regardless of tool. Reactivity makes it a bit tougher, but comes with great benefits (unless your project is 'simple' or more static)
- Scalability? It's great, and we are the proof -- you just need to know what you are doing (i.e. redis)
and very actively maintained.
I'm thinking of checking out Meteor now since on balance people here are saying it's good for prototyping at least, and I'd like some real-time functionality.
In general, its solid for its use cases, but you need to understand what its good at. Its pretty great for small apps, prototyping, hobby projects, etc.
There are a few things we learned that I'd share:
Use React. Should be obvious. Meteor's react support is pretty great.
Stay away from Meteor packages as much as possible. Its better to look for a similar NPM package and do the integration work yourself then to rely on the "magic sauce" that many Meteor packages use. The only ones I can really suggest using are the official MDG ones.
You don't have to use pub/sub to fetch data. You can absolutely fetch data through Meteor Methods in situations where real-time isn't important. Meteor methods are just simple request/response RPC. Pub/sub can become stupidly hard to reason about, though in simple applications can make your app seem really fast and responsive.
That being said, its got great integration with Apollo. If you start with Meteor, ignore all of the DDP stuff (pub/sub, methods, etc) and just build the API with Apollo, you wont regret it.
If you think you'll want to deploy a mobile app, maybe don't do Meteor. You still definitely can, but Meteor's semantics around the always-on websocket connection tend to severely hurt a mobile-first experience.
Today, I'm not sure I can recommend new projects go with it. That being said, I also feel like a normal GraphQL server on Node isn't "far enough" down the path that Meteor set. The JS backend world is still really far away from an AIO framework like Rails/Phoenix; Meteor is the closest we got, but its not the answer.
I have to say I'm impressed so far. Lot's of nice things to get one up and running quickly. But it's been thought about in a way that should allow you to mix and match the defaults it comes with in a modular way as your application grows.
With Apollo/GraphQL at its core and React on the front end it really does make a lot of sense given current trends and I'd urge anyone looking at Meteor to check it out. Great active Slack group too.
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.
react native and ionic framework all can be used with meteor in which meteor can be used as a backend (providing API such as rest, apollo or DDP) and many active projects used this approach.
For me, I know laravel inside/out. For me it's way better because I can build an app in a week using Vue+Laravel. Laravel also isn't coupled to mongodb which, personally I cannot stand nosql db's. There's been so many cases where companies have used nosql and then had to migrate to postgres because they need 'acid', or other features. PG has json data types, so there's no reason not to use it as a doc store within a rdbm.
"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.
If you're a Ruby on Rails shop, Meteor is probably not for you.
But I think people under-appreciate Meteor's value proposition of not having to piece together multiple frameworks -- especially in JavaScript world, which seemingly produces a new framework every other day.
[0]: https://www.meteor.com/tutorials/react/creating-an-app
[1]: https://www.meteor.com/tutorials/angular/creating-an-app
Yes.
Apparently it’s not the only thing that is as good as dead with activity on GitHub.
Meteor might not literally be dead, but it may as well be. Don’t use it. Even MDG seems mostly focused on GraphQL these days (and that sucks, too. But that’s a whole different topic.)
If you spend little time at the forums you'll realize there are plenty of people using it with active community contributions and thriving open source projects and commercial businesses built on top of it.
Technology goes through phases (hype cycle) and Meteor is at a stable phase.
A lot of the comments here are ignorant about the the progress made in the last two years, to be able to form objective opinion, one need to proper research and not just listen to the FUD.
If I had to start over I’d probably still use Meteor but with Apollo as my data layer instead of DDP/pub-sub.
From 12GB ram required - we went down to 1.1GB.
Not to mention all of the intangibles like better tested, healthier codebase.
https://news.ycombinator.com/item?id=16787682
This anti-Meteor FUD is being spread for the following reasons:
1) Someone doesn’t know how to use the Meteor feature properly or have the engineering/computer science background to design a system to be able to manage computational complexity or scalability.
2) The Meteor feature or package is stable and mature so it hasn’t been generating much news or required drastic updates.
3) A competitor wants to promote a Meteor or Meteor package alternative that they have a vested interest in and are trying to manipulate people by creating self-fulfilling prophecies to kill off rivals.
Our Meteor app runs 24hrs/day and handles hundreds of drivers tracking in every few seconds whilst publishing real-time updates and reports to many connected clients. Yes, this means Pub/Sub and DDP.
This is easily being handled by a single Node.js process on a commodity Linux server consuming a fraction of a single core’s available CPU power during peak periods, using only several hundred megabytes of RAM.
How was this achieved?
We chose to use Meteor with MySQL instead of MongoDB. When using the Meteor MySQL package, reactivity is triggered by the MySQL binary log instead of the MongoDB oplog. The MySQL package provides finer-grained control over reactivity by allowing you to provide your own custom trigger functions.
Accordingly, we put a lot of thought into our MySQL schema design and coded our custom trigger functions to be selective as possible to prevent SQL queries from being needlessly executed and wasting CPU, IO and network bandwidth by publishing redundant updates to the client.
As we know, Meteor is tightly integrated with MongoDB which we did not consider to be well-suited to our needs. Did this result in us ranting publicly about how Meteor and/or MongoDB are “dying” or “having no future”? No!
Instead, we found a way to embrace and extend Meteor - an ongoing task.
In terms of scalability in general, are we limited to a single Node.js process? Absolutely not - we use Nginx to terminate the connection from the client and spread the load across multiple Node.js processes. Similarly, MySQL master-slave replication allows us to spread the load across a cluster of servers.
In my view, the reason why Meteor is not more popular is because too few people are sharing their Meteor success stories and the MDG has not been doing much to promote Meteor publicly.
More people need to showcase their Meteor-based solutions and stories of success at technical conferences and developer meetups and events - especially those that concern NodeJS, MongoDB, MySQL, Databases, IoT and WebApps in general.
And what makes Meteor superior to plain Node.js development? We get much higher productivity from our programmers who can write less code and make fewer mistakes developing in Meteor compared to say using Node.js with express. Here are 3 benefits we enjoy:
1) Meteor's use of fibers allows a synchronous programming style whilst avoiding callback hell. Meteor has an easy to use facility Meteor.wrapAsync() that allows you to use run any callback function, e.g. from a third-party package, within a fiber. There is also Promise.await() that does the same thing for packages that use Promises.
2) The isomorphic design promotes code reuse between the client and server-side and simplifies client-server communications. You simply decide whether you want to implement a Meteor method or a Meteor publication based on your application's needs.
3) Meteor's inbuilt, easy-to-use data validation methods promote secure, robust code.
In summary, Meteor is much greater than the sum of its parts.
You'd think majority people of at HH can do basic objective research and look beyond the FUD, but it seems not. Well, let me give you some facts, over the last two years Meteor added support for:
- Out of the box dynamic import https://blog.meteor.com/dynamic-imports-in-meteor-1-5-c61304...
- Importing NPM packages
- React, Vue, and Angular as view layers
- Latest release of Node JS: https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6
- Galaxy hosting just for Meteor apps, but you can also deploy anywhere using MUP: https://www.npmjs.com/package/mup
- SSR: https://blog.meteor.com/meteor-platform-is-still-alive-5f642...
- Infinite out of the box reactive scaling using RedisOplog: https://github.com/cult-of-coders/redis-oplog
- Innovative data fetching using Grapher: https://github.com/cult-of-coders/grapher
- Ability to start minimal apps without DDP or Blaze (here meteor is just used as build tool)
- Many popular and active open source packages such as vulcan js and rocket chat, and commercially successful business Qualia with 32 million funding https://www.housingwire.com/articles/42710-qualia-raises-33-...
- Being taught at universities https://blog.meteor.com/teaching-software-engineering-with-m...
There has been major FUD since 2015 when Meteor pivoted out of Blaze (original view layer which has been open sourced) to open up to the rest of the ecosystem and some folks were not happy with that so they wrote few articles which shaped a lot of the FUD we read about here. It's a fact that today Meteor is way more flexible, you can use it as a full-stack, back end or build tool only, and you can pick which area of the stack you'd like to leverage.
It's very active and still, by the far, the most started Node JS framework on Github, it's very mature and stable and growing everyday.
People get Meteor wrong. It's basically a sophisticated build tool that takes away a lot of the burden of setting up a working build setup. If you want, Meteor will also provide a robust account management system and a seamless connection between server and client and a few other niceties, such as reactivity out-of-the-box and most recently, my favorite feature, dynamic imports.
I also love Meteor's own package system which provides so much more than Npm-packages ever can. I'd also like to mention Blaze, which seems now pretty unmaintained, but it's actually very solid and stable and works brilliantly with Meteor, especially with the ViewModel-package (supports both React and Blaze).
Meteor is awesome and it's only getting better.
The only use cases I wouldn't pick Meteor for are the ones where static sites shine, for those I'd opt for Gatsby or Nuxt.