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.
- '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)
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.
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.
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.
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.
"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.
By the way: https://www.reddit.com/r/javascript/comments/672nrk/is_meteo... the second comment ;)
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.
As a relevant data point, Qualia uses Meteor and recently raised $30M.
https://blog.meteor.com/dynamic-imports-in-meteor-1-5-c61304...
https://blog.meteor.com/modernizing-the-real-estate-industry...
https://www.forbes.com/sites/omribarzilay/2018/03/07/qualia-...
Currently using Meteor 1.6.0.1 with Node 8.9.3 and MongoDB 3.2.19. Planning to upgrade to newer version of Meteor, add new platforms, etc. Wekan is in use at companies that have thousands of users.
From 12GB ram required - we went down to 1.1GB.
Not to mention all of the intangibles like better tested, healthier codebase.
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.
There is development activity in the repo, but I would say the 'hype' has moved to other projects.
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.
Even DDP and reactivity can be turned off, though these are powerful and useful features for real-time applications.
If I had to start over I’d probably still use Meteor but with Apollo as my data layer instead of DDP/pub-sub.
Everytime we look out there for replacement we have a hard time finding a better platform. When it comes along, we'll switch. But we are not there yet.
All the negativity around the platform has to do with bad communication by the platform developer (after all, they are developers not marketers).
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.
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'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.
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.
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 guess you can't please everyone.
I've got more than a few blaze meteor apps that could use a new lease on life...
and very actively maintained.
Finding people is the hard part for us as a business, so finding a balance between technology and available skills was a priority. Since Meteor is a public framework, it has a ready ecosystem for onboarding (tutorials, etc), plus with being standardized it reduces complexity for onboarding. Any JS dev can pick it up in a few weeks. It has enough checks and balances to ensure some level of consistency in implementation, but beyond that, you need to setup your own process anyway. Again being standardized, it helps with BCP as well.
Since Meteor is isomorphic, it gives us a very interesting advantage of tying code ownership to both front and backend code, which results in functional ownership not just code ownership. That emphasizes full-stack development, which is a priority for us. Our mantra is to do more with few people as we can, and Meteor lets us do that very well.
Technologically, Meteor gives us access to a wide variety of capabilities as a technology team. NPM opens up the JS ecosystem, Apollo/MDG gives us the ability to move towards GraphQL if needed, build tools allows us to push code for web and mobile environments out-of-the-box, integrations allow us to handle scaling, and Meteor has gotten better at opening up options to allow for more granular tuning (queries, reactivity, etc.).
It might not be the most performant, but honestly I'd rather throw an extra $50-100/m at hardware on DO/Linode, than justify having to hire more people.
It helps that we're not planning at building apps targeted at millions of users, but when you hit that kind of scale, refactoring is anyway going to happen. This quote from DHH (https://twitter.com/dhh/status/885445986943868929) is the best way to explain this anyway :)
As has been highlighted by others, MDG is still releasing updates to Meteor regularly, so there's not much reason to doubt they're stopping anytime soon. In addition, there's been a resurgence in the community to contribute modules to addressing gaps in the ecosystem, which have made Meteor more relevant again for a lot of us.
This is highly opinionated, but for us and the fact that its about doing business, not just the best technology, Meteor ticks enough boxes to make it our choice moving forward.
If you look at it through that lens, I think it makes it viable (valuable even) in 2018.
IMO, I think Meteor is a victim of promising too much too soon. The real value only got unlocked IMO when they made NPM a first-class citizen. As a team, we aren't really missing out on anything being on Meteor. We think it makes us more effective as developers.
This for us is also the main selling point, it allowed us to group client, server, routing, assets, static files all in one package thus enabling architects to split web apps and by extensions teams vertically instead of the typical horizontal split (client/server) thus full functional ownership instead of code ownership.
This architecture pattern is discussed here: https://micro-frontends.org/ and enabled (I believe uniquely by Meteor's build system).
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.
As for advantages of Meteor over Node, I see many. Meteor is not this monolithic framework but rather a collection of sensible and well-intergrated tools. You don't need to mess around with Babel or Webpack or write a bunch of boilerplate config or code. You can start running out the gate and write the code for your app exactly and only where it needs to be written. No cumbersome boilerplate or maintaining a million different tools and checking compatibility between versions. It just works.
Now, I'll speak to why I think Meteor has lost some of its luster the last year or two, despite its advantages.
1) Meteor was way ahead of its time when it came out in 2012 - 6 years ago! Reactive programming wasn't really a thing then, but they found a narrow pathway between several different tools that would allow for rapid development, combining the capabilities of websockets, MongoDB, and did some novel things that made development seamless between all these different tools. But in more recent years, we're seeing more reactive frameworks rise up, like React and Vue, and in a way the rest of the world is only just now catching up. At the same time, we've got a phenomenon of framework fatigue going on, with developers just trying to catch up and understand this world of a million frameworks. It's very easy for newcomers to think Meteor and React are the same thing. But they're not. Meteor is a full-stack framework whereas React is only a frontend framework. React would only replace the Blaze portion of Meteor, and in fact many people do replace that part and use both together. But the fallacy continues.
2) Since the rise of React and GraphQL, Meteor Development Group has diversified. They are now behind the #1 GraphQL client for Node-based apps, Apollo. It happens to fit well with Meteor too. A common complaint of Meteor used to be that you couldn't use it with data stores other than MongoDB, but with GraphQL and Apollo, that is no longer the case. It's a welcome complement to the Meteor stack, however, it has its downsides. While it makes Meteor more flexible and highly compatible, it also makes it harder to use for newcomers. Working with Apollo and GraphQL can be a headache even for experienced developers, and if you're still only using MongoDB, you actually lose functionality with it, like automatic pub/sub. More confusion and less function for those who want to make apps quickly kinda kills it for newcomers who came to Meteor for its simplicity in the first place. And Meteor's simplicity was its main selling point. Not to say, though, that you can't still use Meteor without Apollo. You definitely still can, and in fact, I recommend newcomers do not use Apollo until they've bolstered their skills. It will just make everything more confusing. But all of this has muddied the water and undermined the simplicity that was once so lucrative to creating Meteor apps.
To conclude, Meteor is stronger than ever and is a very capable and powerful framework on which to build your product. The things that once made it sexy are not quite as new and shiny anymore, but I think it's because we're coming to this convergence of JavaScript frameworks and tools that are doing more of what Meteor has done over the last 6 years. At the same time, Meteor is trying to place themselves in the larger community and accommodate a wider ecosystem, sometimes at the cost of increasing complexity. Overall, though, I still believe Meteor is ahead of its time, and I have yet to find any other framework that does everything Meteor offers. And it is still more convenient for me to use Meteor than use a million independent tools. It's quite an impressive tool and is a pleasure to use.
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.
Doesn't matter what new versions support if we can't update things.
The reactivity choice was made for us (poorly).
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. :(
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.)
