
Ask HN: Is Meteor.js dead? - lakeeffect
Is anyone still using meteor.js or planning on using it?  Any advantages over just using node?
======
anonytrary
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.

~~~
ramezrafla
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)

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

------
rglover
My company [https://cleverbeagle.com](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).

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

~~~
abalone
100K simultaneous connection limit is published here:
[https://firebase.google.com/docs/database/usage/limits](https://firebase.google.com/docs/database/usage/limits)

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

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

------
ordinaryperson
This comes up every so often here on HN:

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

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

"Is Meteor(JS framework) is dying slowly?" \- 1 year+
[https://news.ycombinator.com/item?id=13303345](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](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.

~~~
sytse
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...](https://about.gitlab.com/2017/11/09/gitlab-vue-one-year-
later/)

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

~~~
icc97
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](https://www.meteor.com/tutorials/react/creating-an-app)

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

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

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

~~~
starptech
Why do you have that feeling?
[https://www.meteor.com/](https://www.meteor.com/) or
[https://www.meteor.com/showcase](https://www.meteor.com/showcase)

By the way:
[https://www.reddit.com/r/javascript/comments/672nrk/is_meteo...](https://www.reddit.com/r/javascript/comments/672nrk/is_meteorjs_dying_where_are_people_moving_to/)
the second comment ;)

~~~
wgerard
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](https://insights.stackoverflow.com/trends?tags=meteor)

1:
[https://insights.stackoverflow.com/trends?tags=backbone.js](https://insights.stackoverflow.com/trends?tags=backbone.js)

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

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

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

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

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

------
rascoe
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/](https://reactioncommerce.com/) [1]:
[https://github.com/reactioncommerce/reaction](https://github.com/reactioncommerce/reaction)
[2]: [https://venturebeat.com/2017/10/31/reaction-commerce-
raises-...](https://venturebeat.com/2017/10/31/reaction-commerce-
raises-8-5-million/)

------
VikR
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/dynamic-imports-in-
meteor-1-5-c6130419c3cd)

[https://blog.meteor.com/modernizing-the-real-estate-
industry...](https://blog.meteor.com/modernizing-the-real-estate-industry-
with-meteor-an-interview-with-qualia-founder-lucas-hansen-b3b70d2f5dea)

[https://www.forbes.com/sites/omribarzilay/2018/03/07/qualia-...](https://www.forbes.com/sites/omribarzilay/2018/03/07/qualia-
grabs-33m-series-b-led-by-menlo-ventures-to-simplify-the-home-closing-
process/#5b6522067ccc)

------
xet7
No. I released Wekan v0.81 today:
[https://wekan.github.io](https://wekan.github.io)
[https://github.com/wekan/wekan/releases](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.

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

~~~
VikR
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](https://news.ycombinator.com/item?id=16787682)

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

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

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

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

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

------
hexsprite
I run my SaaS [https://focuster.com](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](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.

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

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

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

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

------
swyx
let's just say that the number of times this question is asked:
[https://hn.algolia.com/?query=meteor%20js&sort=byPopularity&...](https://hn.algolia.com/?query=meteor%20js&sort=byPopularity&prefix=false&page=0&dateRange=all&type=story)

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.

------
Can_Not
I never used meteor, but from what I understand it's functionality was, I
currently use FeathersJS + SocketIO + VueJS (and nuxtJS for serverside
rendering).

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

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

------
pagoad
[https://forums.meteor.com/t/meteor-is-not-dead-in-fact-
its-q...](https://forums.meteor.com/t/meteor-is-not-dead-in-fact-its-quite-
all-right/42762/71)

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

~~~
clishem
Blaze still works!
[http://blazejs.org/guide/introduction.html](http://blazejs.org/guide/introduction.html)

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

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

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

~~~
aogaili
That is not true, it is the most started Node JS framework
[https://github.com/topics/framework](https://github.com/topics/framework)

and very actively maintained.

------
shankspeaks
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](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.

~~~
aogaili
"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/](https://micro-frontends.org/) and enabled (I believe uniquely
by Meteor's build system).

~~~
shankspeaks
:) 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.

------
aogaili
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...](https://blog.meteor.com/dynamic-imports-in-
meteor-1-5-c6130419c3cd)

\- Importing NPM packages

\- React, Vue, and Angular as view layers

\- Latest release of Node JS: [https://blog.meteor.com/announcing-
meteor-1-6-abf30f29e2c6](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](https://www.npmjs.com/package/mup)

\- SSR: [https://blog.meteor.com/meteor-platform-is-still-
alive-5f642...](https://blog.meteor.com/meteor-platform-is-still-
alive-5f6426644555)

\- Infinite out of the box reactive scaling using RedisOplog:
[https://github.com/cult-of-coders/redis-oplog](https://github.com/cult-of-
coders/redis-oplog)

\- Innovative data fetching using Grapher: [https://github.com/cult-of-
coders/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-...](https://www.housingwire.com/articles/42710-qualia-
raises-33-million-to-improve-home-closing-process)

\- Being taught at universities [https://blog.meteor.com/teaching-software-
engineering-with-m...](https://blog.meteor.com/teaching-software-engineering-
with-meteor-lessons-learned-after-three-years-793d8a16077)

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.

------
michaelcbrook
We have been using Meteor at my company
[https://pitchly.net](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](http://slides.com/michaelcbrook/rapid-development-meteor)) and I plan
on teaching it at Des Moines' first code school
([http://iowacodeschool.com](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.

------
lerax
I hope so

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

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

~~~
angersock
Legacy. Meteor. App.

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

The reactivity choice was made for us (poorly).

------
jrs95
>Is Meteor.js dead?

Yes.

~~~
aogaili
No. [https://github.com/meteor/meteor](https://github.com/meteor/meteor)

~~~
jrs95
[https://github.com/Perl/perl5](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.)

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

