
Ask HN: Is Meteor.js still a thing? - tiri
Should I use Meteor for production apps? If not, which Framework should I use for reactive realtime apps?
======
Blixs
I speak from personal experience when I say companies are migrating away from
Meteor. For me personally it's to a React/RxJS front-end stack in combination
with a traditional Ruby/PostgreSQL/REST api back-end. This had the
disadvantage of losing the back-end reactivity Meteor is known for, but at the
same time it's a much more stable, decoupled and scalable stack. Meteor simply
felt too much like a black box that caused a lot of scalability and
maintainability problems in production. Its "make reactive all the things"
model also gave (less experienced) developers a huge gun to shoot themselves
in the foot with, causing a lot of performance issues.

If you want to keep all the reactivity goodness from Meteor I'd suggest taking
a look at Firebase. Their new Cloud Firestore is very impressive and basically
gives you all the features Meteor offers when you combined with a front-end
framework like react or angular. Or you could take a more low-level approach
and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create
your own reactive push streams, and subscribe to them in the front-end using a
reactive library like RxJS.

~~~
michaelsbradley
Any thoughts on RxDB?

[https://github.com/pubkey/rxdb](https://github.com/pubkey/rxdb)

~~~
Blixs
I'm a fan of RxDB. It makes a lot of sense to combine something like PouchDB
with RxJS to create a reactive datastore. The only thing that bothers me a bit
about it is the dependency on CouchDB (at least in case you want to have
online sync). Not that I have anything against CouchDB (it's a great piece of
technology IMO), but it's definitely not suited for all use cases and is in
general a lot more restrictive/less powerful than a more general-purpose
database like PostgreSQL.

------
kabes
Contrary to many here, I feel over the last year they made themselves totally
relevant again. And I think that the negative reactions here are from people
that aren't fully aware of the current state of the project.

Note that Meteor is much more than a data layer. Even though you won't find
any easier system to deal with reactive data than their livequery system, I
get that you don't want to be bound to Mongo or even need reactivity.

But it's also a server and build tool that has given our application:

\- A stable upgrade path for almost 4 years where we could keep up with new ES
features incrementally, with full backwards compatibility. In Javascript-
framework land this is really unique. We've been able to keep adding features,
expanding our product and building for our customers. While at the same time
continuously update our codebase to the latest and greatest.

\- By far the best easiest way to do code splitting (since 1.5) without any
configuration or overlap in bundles. I don't know about any other tool that
offers something similar. Webpack doesn't even come close in this area.

\- Because they had node-fibers to get synchronous code from the start, now
it's really easy to adopt to async/await.

\- They have good integrations for React, Angular 1 & 2, Blaze and there are
third-party integrations for Vue (haven't used that one myself)

\- They're also the same people behind Apollo which people do seem to like for
their data layer. And they announced Meteor will focus on full Apollo
integration.

But yeah, their current data layer requires you to buy in to Mongo. And yes,
there's no good separation of concerns in their data layer. And yes, the oplog
tailing can't handle "facebook-scale" and I know you believe you need this.
But picking this allowed our application (that needs a reactive data layer) to
be delivered fast, gain customers and grow. Without Meteor, I'm pretty sure I
would have ended up 2 years later with a nicer codebase and no customers.

TL;DR Have a look at their latest release (1.6), build a small application and
chances are you might really like it.

~~~
albertTJames
I agree with this assessment. But meteor's main problem is being able to
interface with providers that are not Galaxy, at least they dont have good
documentation on it and you have to rely on blog posts. Plus galaxy is at
least twice as expensive as aws for small projects.

~~~
sumoboy
I've chosen meteor for a project recently and like where v1.6 is going. I
agree the deployment docs for non-galaxy hosting being challenging and it took
a bit to figure using PM2 from blog posts. Just starting to test Galaxy which
integrates the kadira APM that I think is essential for scaling meteor, too
bad the open source version hasn't been updated for 7 months so DIY meteor
hosting. If

The meteor docs in general need more examples and best practices. The udemy
course on meteor/react is extremely well done as a starting point.

------
j6m8
We used Meteor for a long time as our primary stack at my current company. We
just finalized the switch to React/Webpack + AWS Lambda/DynamoDB this week.

The main motivator was that Meteor's big sell — the "zero-latency" data sync —
wasn't enough to outweigh the overhead of having to keep up with the
constantly shifting landscape of which libraries were now deprecated, which
were suddenly "anti-patterns", which were suddenly insecure...

That being said, I still prototype all new projects with Meteor. It's by far
the fastest to go from 0 to 60, and it's extremely pleasant to ignore data
transit and focus on the Big Ideas.

tldr; Prototype things in Meteor because it's a great platform. Your
production stack may or may not need the same things your prototype stack
needs.

------
ordinaryperson
So much hate for Meteor here, but I use it at work and it's been great for
what we wanted.

I inherited a vendor-built website that was Craft CMS (a Yii framework)
sitting atop a Laravel application that was integrated with Google Maps and
indexed by Solr -- debugging even a minor issue could take days.

Meteor is fast and full-stack, no more knitting together 13 different
frameworks. It's integrated with Apache Cordova, so you can easily port your
website to mobile apps. It supports importing of node packages. Is Meteor the
answer for everything? Of course not. But for a fast, data-driven app it's
still great, IMHO.

The alternatives recommended in this thread so far are:

1\. Firebase + React/Angular

2\. Elixir/Phoenix + PostgreSQL's LISTEN/NOTIFY

3\. Deepstream.io

4\. Kotlin

5\. .NET Core

6\. Vue and Rails

If those things work for you, great, but I'm not sure they're 10x better than
Meteor or that MDG is in some kind of death spiral -- it's still a viable
solution for fast NodeJS apps.

~~~
throwanem
> Is Meteor the answer for everything? Of course not.

It sure does claim to be.

~~~
stvrbbns
And poptarts claim(ed) to be part of a "complete breakfast"... \-
[https://www.youtube.com/watch?v=_nqhoP_ychc](https://www.youtube.com/watch?v=_nqhoP_ychc)

Promotion/marketing speak is promotion/marketing speak.

~~~
throwanem
At least Pop Tarts throw in "part of a". Meteor wants to be your entire stack,
to such an extent that I'm honestly a little surprised they don't ship their
own editor.

------
neoh
It depends entirely on the budget really. Meteor is great for turning over
applications quickly, but that's it. Ember is a better frontend full stack
framework and if the server is to be built by someone else, go with Ember. If
the budget is large, there's a good dev team and the project needs a
performance kick then React is the better choice, if built right. We've been
handed over React codebases though that needed saving and while the previous
devs might have been fairly competent, React has a lot more work involved
which can make people get lazy after a while and have the opposite effect of
what it was intended for, and that's speed. For personal projects I will never
go for React. I love the concept of React and how it works, but there's too
much boilerplate and I personally prefer more full stack solutions.

~~~
cies
> I personally prefer more full stack solutions.

You might like Elm. If you also control the backend you may want to look into
PostgREST (there's an Elm lib for it iirc). See also `elm-mtl`.

------
DerWOK
If you look at some quite active meteor open source repos with a non-trivial
size, you may also see that meteor is still alive and kicking. ;-)

* WeKan - FOSS Trello clone [https://github.com/wekan/wekan](https://github.com/wekan/wekan)

* Rocket.Chat - FOSS Slack clone [https://github.com/RocketChat/Rocket.Chat](https://github.com/RocketChat/Rocket.Chat)

* Vulcan - React, GraphQL & Meteor toolkit [https://github.com/vulcanjs/vulcan](https://github.com/vulcanjs/vulcan)

* 4Minitz - FOSS Collaborative Meeting Minutes and Protocols WebApp [https://github.com/4minitz/4minitz](https://github.com/4minitz/4minitz) & [https://www.4minitz.com/](https://www.4minitz.com/)

Disclaimer: I'm one of the contributors of 4Minitz. ;-)

~~~
M4v3R
Thumbs up for Rocket.Chat, love it!

~~~
jadbox
How does Rocket compare with Mattermost these days?

~~~
M4v3R
I didn't use Mattermost, but probably the biggest advantage of Rocket.Chat is
that it is totally free to use. On the other hand the UI is sometimes not as
polished as other commercial solutions.

------
felipellrocha
No. You should just build a regular app, and build reactivity wherever is
necessary.

You _don 't_ need reactivity everywhere, the way they do reactivity is really
expensive, and you can't turn it off because they are so opinionated about how
they do things.

Just build a react app, and add a websocket layer wherever possible.

~~~
anonytrary
You can turn it off with about 10-15 lines of code. It has been a while, but
IIRC they just cache and diff way too much data for the reason that it saves
bandwidth. Wrap their caching functions to forget the data when you know you
don't need it, and Meteor can become much more performant.

Still, I wouldn't use Meteor for any kind of traditional website. It's way too
easy to introduce state on the server, but there shouldn't be state on the
server, and it's way too easy to abuse reactivity and end up with a toy that
tanks with trivial traffic.

I think polling is ultimately a better model because it allows each component
to throttle itself at whatever pace is necessary. I can see Meteor being
useful for applications that require a shared state on the server (or in Redis
or something) like in online games, chat, or any other online multi-user real-
time application.

But then Meteor became a tool for common websites that didn't actually need
reactivity, and people started abusing server state, reactivity, etc. I think
at some point, the community was begging for options to turn reactivity off by
default or in certain cases.

Meteor apps consume less data but take up a ton of server resources. Overall,
the problems introduced by polling were just traded for DDP's own problems.
The problem of "sending data to the client in real time" might not even be an
important problem. If the client looks at a page every 20 seconds, then
there's no reason for the page to be updating for an empty audience.

I think Meteor is building something called Apollo now which uses some sort of
intermediary caching server to keep track of data versions, which the client
then polls for updates to the data it depends on. At a first glance, it looks
like they just took the problem with DDP and moved it into an independent
system. I could be wrong, maybe their polling solution would end up fixing the
issues.

~~~
petrbela
> I think Meteor is building something called Apollo

Apollo is a library for GraphQL, primarily client side but there's also a
server component (sort of like ExpressJS for GraphQL). While GraphQL also
includes real-time web-socket based subscriptions, they are an extension
rather than the core, and, in practice, most clients/servers (including
Apollo) use polling to fetch updates because it requires a much simpler server
architecture.

------
maxsavin
Lol - a thread like this seems to pop up every couple of months.

They are updating it like all the time with new features.

The biggest problem with it is that the data layer does not scale well for
large apps, and that has tainted the reputation of Meteor as a whole.

However, there are community packages on the way to fix it, and hopefully
Meteor will implement MongoDB's new Change Streams feature, which essentially
puts the reactivity on to the database.

I'm still holding my bet on Meteor, having recently launched an admin panel
tool for it: [http://meteorcandy.com](http://meteorcandy.com)

------
vazamb
The team behind it released version 1.6 just a few days ago, so it is
definitely still alive. I haven't used it since a few versions ago but I don't
see we it wouldn't still solve the same use case as it did before: making it
trivial to build real time collaborative web apps (that don't require extreme
scale). With rethinkdb being an unsure bet and graphql not offering the same
ease of development I am also not aware of a competing framework. Arguably
meteor is getting better and better by integrating more with the broad
node/Javascript community.

This sounds like a huge advertisment but I simply thoroughly enjoyed using
meteor. If it fits your use case I'd say go for it. You can build the frontend
in react and re-use it should you decide to move away from meteor. The amount
of backend code you need to write to make all the realtime stuff work is
significantly less than with other frameworks, so not much in terms of sunk
cost there.

------
d0m
From my experience (a.k.a tried and failed..), I'd rather take a bit more time
to glue a few amazing open-source tools together than to use an "all-in-one"
framework that will screw me down the road.

Over the years, I've built the equivalent of those real-time systems using
postgres, redis, rabbitmq and node that can scale horizontally. It's obviously
longer than using firebase, but at least I know what's going on under the
hood, I can easily optimize and debug it, I can add any missing features or
switch any tools (I.e. can easily switch off postgres to something else if I
needed it).

It's for the same reasons that I use React on the front-end. It's great for
the view layer, but I still get to pick and use great libraries for the rest
of the app (in-memory database, state management, routing, etc etc.) I can
easily switch off React to something else because the surface API that I'm
using is extremely small.

I would still use meteor or any of the competitors for a hackathon or
prototype, but never for a long-term project. YMMV

------
clement75009
I've used Meteor a lot over the last 4 years. Recently I had to start a new
project and I wanted to move away from Meteor because clearly it has less
traction lately.

I've considered a lot of things, but I couldn't find a setup as simple as
Meteor with database integration. I ended up going back to Meteor and I'm very
happy with it.

The tooling keeps getting better (recent 1.6 release), server-side rendering
is almost there (already possible but no clear best practices yet), and
scaling seems like it will be getting better soon (MongoDB upade + a path
toward GraphQL with Apollo).

I had my doubts but I'm back on board. I recommend every JS developer give
Meteor a good look.

------
mariopt
Meteor developer for a long time here.

Meteor, today, is still a good match for small to medium applications that
provide real-time features in more than 50% components/pages. For most
applications Meteor becomes a real pain in the ass. I wrote several
applications for multiple clients, in 4 years I haven't wrote a single one
that used the real-time features properly. A tradicional stack is simply much
more flexible when compared to Meteor.

The problem today is that Meteor is not a component that you can't easily plug
and play like Angular, React, Express, etc. Example: You would like provided a
real-time widget on another website? Open an iframe and load the entire
application and waste more than 300 megabytes on the browser. Or use a non-
official package and hack the shit out of it.

MDG (Company who developed and maintains Meteor) went too greedy. In order to
use Meteor you have to be fully committed to the stack. Although the project
is open source, you will waste several hours trying to modify Meteor to be
make it more modular. Event today if you want to use the DDP protocol outside
of Meteor, you've to use 3rd party non official packages. Meteor was great in
the beginning but failed to play nicely with the rest of the JS ecosystem even
although some work was done in that direction. Arunoda played a HUGE role by
building and writing a lot.

As a prototype tool Meteor is excellent, it's very hard to find a
framework/tool that provides what Meteor provides. Building a real-time
application with modular components isn't trivial, Meteor just offers a lot
for free: LiveQuery, Authentication, Server-Client shared code, Consistent
API, client side implementation of MongoDB (minimongo), painless build system,
easy deployment, etc. You can build a prototype in record time.

Play with Meteor, you won't regret it. Scaling applications is always hard,
requires in depth knowledge and time. Meteor is websocket based, there is not
need to compare with an HTTP based API since it is unfair. Scaling a real-time
application is hard on any language/framework. For most projects FireBase will
do the trick if you've a small number of real-time components.

My advice: Pick the right tool for the right job. Most of the complains
typically come from project that are not a decent match for real-time
applications. I worked on many project because someone decided to use Meteor
regardless of their technical knowledge to decide so.

~~~
Y7ZCQtNo39
With Meteor, I wanted legos but they provided an assembled fortress. It just
didn't work out for me. I'm not saying that my situation is everyone else's,
but the lack of flexibility led to me to turn away from it.

I have, at a high level, looked at the Apollo project and I think they are
beginning to become more modular. So the direction is good, but it no longer
has the selling points that it once had: it's no a longer a one-size-fits-all
solution.

------
andrew_wc_brown
I really wanted to buy into Meteor. It felt like the second coming of Rails.

I just couldn't get onboard with something I couldn't plug SQL into. A psql
adapter never came.

~~~
petre
I wonder if you can run it over ToroDB.

~~~
xet7
Yes, it's possible to have Wekan Meteor.js <=> MongoDB <=> ToroDB => PosgreSQL
or MySQL read-only mirroring, for reporting etc if needed

[https://github.com/wekan/wekan-postgresql](https://github.com/wekan/wekan-
postgresql)

[https://github.com/torodb/stampede/issues/203](https://github.com/torodb/stampede/issues/203)

------
goloroden
Spoiler: I am one of the authors of a competitor product (wolkenkit), so my
answer won't be perfectly objective.

IMHO Meteor is not a thing, as it builds on a wrong assumption: At the heart
of Meteor is modeling your data, and it basically builds upon a CRUD approach.
This is perfectly fine for very simple use cases, but it doesn't work well for
more complex things, because limiting yourself to _create_ , _read_ , _update_
and _delete_ limits your expressive power dramatically.

In contrast, when we designed and developed wolkenkit, we put the _verbs_ into
the center of the development process. With wolkenkit, you model processes
that describe what your application does. This way, wolkenkit is a pretty good
fit if you do domain-driven design (DDD), but you do not need to do DDD to use
wolkenkit.

wolkenkit gives you the option to focus on your domain expertise, and provides
all the technical stuff below, such as persistence, authentication, real-time
updates, and so on…

We built it based upon CQRS and event-sourcing, so you have a pretty good
foundation for scaling and reporting / analyzing data. As it's only for the
backend, you are free to use any UI framework you want to use, but we have a
client-side SDK for JavaScript to assist you.

You can find more information at
[https://www.wolkenkit.io/](https://www.wolkenkit.io/) and in its
documentation
[https://docs.wolkenkit.io/1.1.0/](https://docs.wolkenkit.io/1.1.0/)

If you just want to get started with the concepts, have a look at our 68-pages
brochure on DDD, CQRS, event-sourcing and wolkenkit:
[https://docs.wolkenkit.io/1.1.0/downloads/brochure/](https://docs.wolkenkit.io/1.1.0/downloads/brochure/)

wolkenkit is available as open-source and under a commercial license. If you
have any questions, feel free to contact us.

PS: At first, wolkenkit feels somewhat strange, if you are not used to CQRS,
event-sourcing & co., but once you get it, I think it is a pretty good
approach to developing software.

~~~
maxsavin
I think you might need to give Meteor a second look, if only to learn a few
things from it. It has nothing to do with (and does much more than) CRUD.

~~~
goloroden
I know that Meteor is not only CRUD, but thinking in CRUD is at its center of
how it deals with data.

~~~
maxsavin
Well - if you mean that MongoDB has a CRUD-like API, and Meteor uses MongoDB,
yes, but other than that I do not see the connection. Can you explain?

~~~
goloroden
E.g., if you have a look at Meteor's documenation, especially the part on
collections
([https://guide.meteor.com/collections.html](https://guide.meteor.com/collections.html)),
it is all about the classical MongoDB-like functions to access data which
perfectly represent CRUD. It also describes hooks on INSERT/UPDATE/DELETE
([https://guide.meteor.com/collections.html#hooks](https://guide.meteor.com/collections.html#hooks)).

This pretty much shows how Meteor sees data: It's a "thing" that can be
created, edited, deleted. That's it. It does not live on its own.

E.g., when you design a shopping cart, you can create a shopping cart, you can
update it (which means adding items to it, or removing items from it, or
changing the numbers of items in it, …), and you can finally delete it (when
the user submits their order, or when they cancel their shopping tour).

What you can NOT do is to access your data using the verbs that are relevant
for your domain:

\- Put an item to the shopping cart \- Increase the count of a specific item
\- Decrease the count of a specific item \- Remove an item from the shopping
cart \- Discard the shopping card

For the domain "shopping", all these actions are relevant, and if you have to
map them to CRUD actions, you lose semantics. What's even worse, update and
delete are destructive actions, so you don't have any historical data. Of
course you can implement all this, but you have to do it on your own.

wolkenkit, in contrast, uses event-sourcing, which works more like Git:
Changes are collected, and you can replay them (either all to get the current
state, or some of them for arbitrary analytics).

That's IMHO a major difference on whether you are using a CRUD-like
foundation, or another approach.

We have also blogged about this:
[https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-
co...](https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co-
part-1-whats-wrong-with-crud/) and
[https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-
co...](https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co-
part-2-semantics-over-crud/)

~~~
maxsavin
I'm not super familiar with DDD but I do like the ideas behind it - in some
cases I think I am doing something similar to it.

However - isn't that essentially creating another layer on top of MongoDB? It
looks like this could be implemented as a library for Meteor.

I'm only saying that to clarify that I do not think it's Meteor CRUD versus
this. I think of Meteor more as a boilerplate than an application framework.

------
mxxx
I've been working on Meteor apps for a few years now, and my TLDR answer for
you is, no, don't use it.

The releases since 1.3 have definitely pushed it in the right direction:

* NPM instead of atmosphere

* React/Vue/whatever instead of Blaze

* ES Modules (import/export syntax) in place of global variables everywhere and a dependency loading system that i-shit-you-not came down to loading things in alphabetical order

* ESNext support

* Getting Node and NPM up to current LTS versions

Next stop on their roadmap is integrating Apollo, at which point it'll
basically be a turnkey system for building React/Vue apps on top of GraphQL.
Most of what originally made Meteor what it was will have been removed in
place of sensible best practices that everybody else in the JS world has since
moved on to.

But for me the sticking point is that Meteor is built on a couple of
assumptions that, in my humble opinion, are fundamentally incorrect.

1\. Focusing on writing code that runs on both the server and the client is a
useful idea.

2\. MiniMongo is a sensible way to handle the data layer and reactivity
everywhere is helpful.

I personally reckon these are both crappy ideas, and combined with the "magic"
parts of the framework, they encourage people who are new to full stack JS to
develop bad habits and skip learning some of the real fundamentals that every
developer should know in relation to security, performance and scalability.

------
whois
Yes! The company I work for uses it for most of its user facing apps.

No matter what poeple say about Meteor, the fact remains that having the
ability to live push data to the frontend, and share code between client and
server, with absolutely no extra work is supper appealing.

------
sergiotapia
Reposting my comment because it's going to help you:

Meteor projects are quick to ramp up but the second something goes wrong it's
just a nightmare. Code is not structured at all, strange packages to do things
that fall by to the sides, performance issues that are hard to track/debug.

Testing is still a third-class citizen in Meteor for some reason. The official
guide mentions testing, but in the four times I've tried to follow it over the
course of a year, I could never get it to work properly.

On the flipside, using Elixir and Phoenix you know exactly what's going on and
why, you have real control over your DB queries. You can benchmark properly.
Your tests are 100% real and accurate, and run properly. It's much better. You
sleep better at night that's for sure.

I say this as someone who has used Meteor for multiple projects and used to
love it!

~~~
alonisser
"Testing is still a third-class citizen" The exact reason meteor is
disqualified for me. Even the basic manual is broken and wrong in some ways.
Internet searches point to frameworks which are broken or obselete and to the
meteor testing site (If I recall correctly even docs point to it) which has a
notification for a long time about being "rewritten" and no actual content
(and would be a paid book .. :( ) If testing is a third class citizen then No
real professional software development can take place with it. A real deal
breaker

------
ikatalan
Do not touch this platform. it caused us so much problems and didnt seem to
solve any real issue. each new project we start without it is a bliss. you
dont need it and the voodoo bugs it will create.

you can just use react+node js. works great together and will be lot easier to
solve platform issues when they come

------
squid3
If you want to look at it from popularity angle, we continue to see many
meteor deployments on
[https://nodechef.com/meteorhosting](https://nodechef.com/meteorhosting)
suggesting it's still a popular choice out there.

~~~
maxsavin
More details please :)

------
egeozcan
I don't know a better tool for prototyping but I found it too slow even with
~1000 clients and that is on a beefy server. If, by some magic, they switch to
a more modular design (maybe they already did, not following closely) and that
in some way enables the use of postgres (as a 1st class citizen), I'd give it
another go for something more than a prototype.

Here is my humble opinion: If you aren't writing business logic, and will do
mostly network programming, try Go. If you are doing something enterprise-y,
use Kotlin or (IMHO even better) .NET Core. If you want to like writing code,
try Elixir with (on?) Phoenix (or Django/Rails depending on your love affair
with Python/Ruby).

~~~
cies
> If you want to like writing code [then names dynamically typed languages]

Huh? :)

~~~
egeozcan
That's why I explicitly stated that it's my personal opinion, although
"comment" already means "a verbal or written remark expressing an opinion" :)

I actually like JavaScript more than many typed languages but I don't like
writing a server that runs on an event loop. Again, preference.

ps. You seem to be downvoted, I tried to compensate by upvoting. It is just a
tease with a smiley at the end. Relax, people.

~~~
cies
> I tried to compensate by upvoting.

Thanks..

> It is just a tease with a smiley at the end. Relax, people.

Indeed, what's wrong with these people! :-P

(I was a dynamic typer myself, but changed sides when learning about strong
typing, especially in FP langugaes)

------
icc97
Yes, built a React front end on meteor a few months ago. Well documented,
excellent tutorial. They worked well together.

------
api
Few things on the web are still a thing a year later. That's why I favor a
thinner less complex stack.

------
sova
After a couple years of research, my next project will be incarnated from the
following DNA:

    
    
        ▪Clojure backend
        ▪Clojurescript frontend page
        ▪Rum (react cljs lib)

------
mariushop
I would say yes. I used it for over 10 projects over the years and haven't
found something more compelling in the JS ecosystem in terms of speed,
database integration, easy of use. Reactivity should be off by default, that's
right. Last thing I build has a React front (it's a text editor for medium-
long form writing) and I'm super happy with the data layer on Meteor.

------
virgil_disgr4ce
As a product designer and entrepreneur, Meteor is still _absolutely_ a thing.
The products I've built simply wouldn't exist without the massive
(development) speed boost it gave me. I'm well aware of its problems and
faults, but I love it for the amount of work I _don 't_ have to do.

------
Can_Not
I missed the opportunity to use meteor, but these days the big appeal of
meteor (minus one opininated framework) is that I can get the same experience
with VueJS/React and Feathersjs

------
_mrmnmly
For some time, I was amazed by Meteor.js developer-friendy approach and it's
"magic" stuff. But after some time I've found that I had to do many hacks to
achieve something and gave Express.js a shot - it was a purification
experience for me - You have more control what framework do out of the box and
You can avoid using hacks easily.

------
M4v3R
I am using Meteor in my work on a daily basis, and still love it! On the
frontend I use Vuejs instead of Blaze, though.

~~~
thsowers
Late to the party here, but could you comment on your experience with Meteor-
Vue? I just ported an app from Viewmodel back to traditional blaze, but really
want to rebuild the frontend in Vue for performance.

What do you use for forms and other items that have packages in the blaze
ecosystem?

------
je42
Lot's of people mentioning "reactivity as being expensive/non-scalable". is
there a good read up on what reactivity in the context of meteor.js is and why
it is expensive ?

~~~
mxxx
TLDR is:

\- Meteor uses MongoDB as a data store

\- You write queries on the server called "publications", that make documents
available to the client

\- The client implements "MiniMongo", which basically lets you query the
documents that have been published via your publications using Mongo queries
as if you were writing them straight from the server

\- The publications are (by default) reactive, so whenever any of the
documents in your queries is added/removed/modified, the changes propagate
instantly to your client.

\- The original view library (Blaze) would seamlessly update with these
changes in your UI.

From memory, the performance bottlenecks here are:

\- It uses the Mongo OpLog to determine when changes have been made to the
collections, which makes the queries themselves quite slow.

\- For every dataset published to the client, Mongo keeps a cache of that
dataset on the server so it knows when it needs to send deltas over the wire.

So for both of these reasons, once your queries get big, they get SLOW.

The other thing that is costly (but not fundamentally a fault of Meteor
itself), is that most people building web apps model their data in relational
terms. If you try and apply that to Mongo, (ie, treating collections as tables
and "joining" across them instead of nesting data hierarchically inside your
documents), you'll end up writing slow queries.

------
rishav_sharan
For me its mithril (frontend) + micro (server) + Hasura (BaaS)

------
neximo64
It used to be, now I find it quite bloated and slow. There was a time a save
diff would be instant and startup was also just as quick. Now even to run
'meteor shell' and meteor mongo in an admin environment spits out instructions
which are unnecessary and bloated. I could really go on..

Also, they used to have focus in 'blaze' which served a good purpose and then
they reverted to a generic model where you use React (which needs all sorts of
plugins to be reactive). It used to have direction and was very well thought
out.

------
kharms
What's the best framework for a personal/learning project? My only recent .js
experience has been with d3.js.

~~~
brlewis
Mithril is light but still batteries-included (routing, fetching). See my
essay: [https://medium.com/front-end-hacking/how-it-feels-to-
learn-j...](https://medium.com/front-end-hacking/how-it-feels-to-learn-
javascript-in-2017-a934b801fbe)

------
michaelrambeau
About the first part of the question, Meteor is still a thing for several
reasons:

* It's a project with a strong community (364 contributors) that still has traction among developers (+ 8 stars by day on average over the last month, check the numbers here [https://bestof.js.org/projects/meteor](https://bestof.js.org/projects/meteor))

* They keep moving in the right direction: moving away from their own package manager ([https://atmospherejs.com/](https://atmospherejs.com/)) to NPM, accepting ES6 syntax everywhere, client and server-side without config, enabling AngularJS or React for the front-end layer... Since Meteor 1.6 version, they use under the hood one of the latest versions of node.js.

* Other contenders with such a combination "no config / real time / full-stack JS" features out of the box have less traction (check some contenders here [https://bestof.js.org/tags/fullstack](https://bestof.js.org/tags/fullstack))

Some great projects on GitHub are built on top of Meteor:

\- [https://rocket.chat/](https://rocket.chat/) a clone of Slack chat app

\- [https://wekan.github.io/](https://wekan.github.io/) a clone of Trello app

\- [http://vulcanjs.org/](http://vulcanjs.org/) "The full-stack React+GraphQL
framework"

The drawback is that the Meteor is quite opinionated about a lot of things,
it's a monster of its own, blurring the boundary between client and server-
side code. It can be difficult to debug, test, deploy and scale.

So there is no definitive answer about the question "Should I use it in
production?".

The team behind Meteor is really committed to keep on moving forward, GraphQL
and Apollo support are coming soon, the post about the latest release gives
interesting insight about their vision: [https://blog.meteor.com/announcing-
meteor-1-6-abf30f29e2c6](https://blog.meteor.com/announcing-
meteor-1-6-abf30f29e2c6) The author said that, at the end of the process,
"Meteor may look less like a framework and more like a library of middleware
that can be used in any existing application, JavaScript or otherwise".

One important thing is that they move forward steadily, without breaking
things, which is important when you run applications in production.

------
markoshust
I've had great success with Meteor. I started with v1.2, and it was quite
painful to develop in. However, with improvements start within 1.3 and onward,
every release has gotten better. Meteor 1.6 has the same concepts as Meteor
1.0, however it is extremely different and is up to date with standards of the
Node/JS ecosystem.

I think it's important to know it's application and use-case. I use it for a
hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of
developer productivity for a small/medium-sized app. As a startup, I wouldn't
consider anything else right now for new projects. React Native has a higher
learning overhead, and with other architectures you always have to deal with
user registration & authentication, something Meteor supplies out of the box.

In terms of performance, it is important to understand the core concepts of
Meteor. This is not easy. The reactivity layer and publish concepts make it
extremely easy to overpublish data, reckoning your Meteor app completely
useless. Afaik, something like Kadira is required for Meteor apps, as it will
quickly tell you when something is wrong. If a Meteor app is correctly
designed, it should rarely have performance issues.

I've wanted to integrate Redux into my Meteor app, however there are a lot of
moving parts getting both working together, so I'm opting for smaller
container components. React performance is tricky in any case, and Meteor +
React is no exception. This combo makes it a bit difficult to diagnose
performance issues on the rendering layer. I would love to migrate to VueJS,
however the it would require a complete re-write, just as I'm getting comfy
with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React
for new projects, so you don't deal with diagnosing rendering performance
problems with Meteor's reactivity layer.

You can definitely run your own React stack that is decoupled. For a larger
app, I would recommend going this route, due to the big build system of
Meteor. Once your app gets a bit too large, the builds still take forever. You
can offset it by using something like React Storybook with hot module reloads,
but if you have a high number of users or a requirement to not use Mongo, you
are better moving the other way. Meteor Development Group is moving out of the
built-in reactivity layer that it is known for, and into GraphQL. I'm not
planning to move to this new architecture anytime soon, and will run with
Meteor's reactivity layer for the foreseeable future. I'm concerned once the
reactivity layer loses focus and development, that Meteor may start to fade
away. GraphQL has a high learning overhead IMO and presents it's own sets of
issues. Perhaps those will be worked out over time.

My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now
with both iOS and Android builds, up and running as quickly and easily as I
have. It's been a godsend.

------
kimjongman
We migrated on of our customer app from Meteor to Vue and Rails. By doing
this, the app is much more easier to scale. They are happy with the result.

It's is easier to find developer for Rails and Vue.js

~~~
forgot-my-pw
The author of Vuejs used to work for Meteor and he proposed them to officially
integrate Vue as the front end layer. They didn't like the idea.

------
troika
I've switched to [https://deepstream.io](https://deepstream.io) for my
projects. It's just the realtime aspect of meteor, but in an entirely
different league when it comes to performance

~~~
rfrey
"switched to"? Aren't you the CTO of Deepstream?

~~~
VeejayRampay
Looking at troika's submissions, there's one "Show HN" about Deepstream so
yeah, definitely involved in the project. Don't understand why one would say
"I've switched to" for an application they've created or contributed to,
especially if there's proof in your history that you have marbles in the game.

~~~
rfrey
He also posted the who's hiring entries.

Regardless, deepstream seems pretty awesome.

