Hacker News new | comments | show | ask | jobs | submit login
Ask HN: Is Meteor.js dead?
96 points by lakeeffect 8 months ago | hide | past | web | favorite | 89 comments
Is anyone still using meteor.js or planning on using it? Any advantages over just using node?



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.


I respectfully disagree on some key points.

- '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.)


What do you mean by it does not scale well? number of users using it or size of the project?


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:

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.


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).


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.


100K simultaneous connection limit is published here: https://firebase.google.com/docs/database/usage/limits


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.


Thanks, useful to know.


> 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.


Oh I wasn't trying to say it is spaghetti because NodeJS :-). I was saying it might be spaghetti because thats how code sometime is.


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.


Do you mean Meteor Toys? I'm working to get the site back up :) just been busy .. I'm actually contemplating an all-new version.


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.


Were you using Atmosphere packages?

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.


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.


The nice thing about Vue.js is that you can also combine it with Ruby on Rails. For the backend that gives you a very mature ecosystem. At our company that has been a great success https://about.gitlab.com/2017/11/09/gitlab-vue-one-year-late...


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.


So why not combine it with Meteor? Vue.js is mostly a client side stack and can be used easily a Meteor backend.


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.

[0]: https://www.meteor.com/tutorials/react/creating-an-app

[1]: https://www.meteor.com/tutorials/angular/creating-an-app


What're the reasons why it should be dead? Development is very active https://github.com/meteor/meteor/releases and roadmap are up-to-date https://github.com/meteor/meteor/blob/devel/Roadmap.md. What're your requirements? Meteor can solve your problems but can also be too much.


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.

0: https://insights.stackoverflow.com/trends?tags=meteor

1: https://insights.stackoverflow.com/trends?tags=backbone.js


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.


That's because they've encouraged package developers to switch to NPM.


Quite the contrary: There's been a lot of awesome improvements on Meteor lately.


We've been doing doubletime to migrate off of an old Meteor app, due to its bundling of old versions of node and really questionable use of Mongo.

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.


What older version of node? it support Node 8, please get your facts straight https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6


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.


Legacy. Meteor. App.

Doesn't matter what new versions support if we can't update things.

The reactivity choice was made for us (poorly).


We are in the same situation too, I am curious, you are migrating towards what and how ?


Phoenix and Postgres.

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. :(


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.

Don't use Mongo.


We still use it, though we are phasing it out.

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.


You could check out http://vulcanjs.org/, we're trying to get it to be a "Rails for GraphQL/React".


^^ 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.


Is this another layer on top of node. It says you can metwor install?


The Reaction Commerce[0] team is building their version of a modern eCommerce stack with Meteor[1]. They also received a Series A round of funding, lead by GV, in Oct '17 based on the work they've been doing[2]. [0]: https://reactioncommerce.com/ [1]: https://github.com/reactioncommerce/reaction [2]: https://venturebeat.com/2017/10/31/reaction-commerce-raises-...


No. I released Wekan v0.81 today: https://wekan.github.io https://github.com/wekan/wekan/releases

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.


Some of the criticisms of Meteor are out of date. Last year Meteor added exact code splitting, making it a cutting-edge and industry-leading JavaScript build tool. Also, the criticisms of Meteor as something that doesn't scale are out of touch with the current state of the product. Pre-2017 Meteor had difficulty scaling due to its method of oplog tailing wiht Mongo. But last year Redis-Oplog made that a thing of the past. With regard to SQL and other databases, Apollo addresses scaling concerns.

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-...


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.


The concerns regarding scaling with Meteor are outdated. Last year that was solved. Please see my comment in this thread.

https://news.ycombinator.com/item?id=16787682


We replaced a huge Meteor app with Phoenix and elixir.

From 12GB ram required - we went down to 1.1GB.

Not to mention all of the intangibles like better tested, healthier codebase.


Glad to hear we aren't the only ones. :)


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.


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.


Meteor is an "opinionated framework", but there is no lock-in - you can use any NPM package you want.

Even DDP and reactivity can be turned off, though these are powerful and useful features for real-time applications.


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.


We are still using Meteor and haven't stopped. How else can you deploy a scalable reactive production (might I add 'huge') application on Web, Chromebook, Android and iPad with 99% reuse and 1% sweat. Instead of focusing on the nitty-gritty of node.

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).


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.


let's just say that the number of times this question is asked: https://hn.algolia.com/?query=meteor%20js&sort=byPopularity&...

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 never used meteor, but from what I understand it's functionality was, I currently use FeathersJS + SocketIO + VueJS (and nuxtJS for serverside rendering).


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.


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.


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.

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.



Between GraphQL and React, I'm not sure how much Meteor is left in a modern "Meteor" app.


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.


It can be used as a build too, with accounts etc. Some folks here complain about being locked-in while others are complaining it's too think.

I guess you can't please everyone.



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...


If you want to build a real-time collaboration app today, what you would you use instead?


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.


Phoenix


Node.js. Meteor was dead on arrival to be honest.


That is not true, it is the most started Node JS framework https://github.com/topics/framework

and very actively maintained.


Firebase.


We spent a fair amount of time going back and forth over whether to use Meteor or not for our in-house development (in late 2017), before we bit the bullet and moved ahead with Meteor.

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.


"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."

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).


:) It's always nice to have our thinking validated. Thanks for the architecture reference btw. I thought it was something we cobbled together for our use case, but yeah using this pattern makes life so much easier for us.


It's a live and kicking :)

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.


We have been using Meteor at my company https://pitchly.net for a little over two years now with great success. I've used to to develop over half a dozen projects and have really pushed it to the limit. While some things are harder in Meteor, we were able to build and launch a product in a few months that would have otherwise taken most teams with multiple programmers a year or more. I'm not a member of the Meteor team, just a consumer, but I recently gave a talk on Meteor this week to introduce it to my community (http://slides.com/michaelcbrook/rapid-development-meteor) and I plan on teaching it at Des Moines' first code school (http://iowacodeschool.com).

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 hope so


>Is Meteor.js dead?

Yes.



https://github.com/Perl/perl5

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.)


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: