
The State of Meteor Part 1: What Went Wrong - JanLaussmann
https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/
======
marknutter
The big mistake was trying to provide anything beyond Minimongo on the client
side. People are very picky about what front-end frameworks they use on the
front end, and typically people who have strong opinions about that are less
opinionated about what they use on the back end. I'm firmly in that camp, for
instance. I've been a huge fan of Firebase for a while because it frees me
from the tedium of having to create another REST application just to talk to a
database. If Meteor had, from the beginning, focused on simply being a kick-
ass open-source alternative to Firebase they would be killing it right now.

It was a monumental task to try to create something that would please both
front-end and back-end web engineers. Another issue with Meteor is that it was
envisioned, not extracted. [1] From Rail's creator, DHH: "First, Rails is not
my job. I don't want it to be my job. The best frameworks are in my opinion
extracted, not envisioned. And the best way to extract is first to actually
do."

Meteor was the goal, not an actual, real-world application. Often when this is
the case the software ends up solving a bunch of problems that seem logical to
solve, but in practice are not actually practical (another framework like this
that comes to mind is the notorious famo.us project). Compare this to Rails
and React which were forged in the crucible of real, day-to-day development
and problem solving.

[1] - [http://david.heinemeierhansson.com/posts/6-why-theres-no-
rai...](http://david.heinemeierhansson.com/posts/6-why-theres-no-rails-inc)

~~~
primigenus
Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment
thread; Meteor is and has been growing consistently since it launched (see:
[https://twitter.com/Rahul/status/673992512768507905](https://twitter.com/Rahul/status/673992512768507905)).
The title of Sacha's post reads a bit inflammatory, suggesting something
"went" wrong and that it's too late now. Rather, as his post explains, the
community is currently in a bit of an identity crisis as two groups with
disparate sets of opinions on where Meteor should go from here collide.

As someone who's been building with Meteor since 2012, I see all of this as a
good thing. It's a sign more and more people are lending their voices and
opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more
agnostic approach to view frameworks becomes part of core, we'll continue to
see more people join, because the platform will be more open towards them.

Meteor _was_ a new platform. It's now a mature, growing platform. And it will
be a successful platform if we all keep contributing.

~~~
at-fates-hands
Agreed.

This seems to be the same issue with other frameworks when they get to a point
where they have enough adaptation and find out they need to change/update
parts of their framework to get it to the next level.

Same thing is happening right now with AngularJS. Been around for a while, had
massive adaptation, then they realized they needed to make major changes.
Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying
down now and people are coming to their senses.

I'm pretty sure at some point React and other frameworks will hit their wall
too.

~~~
yawboakye
Rails didn't hit that wall. Neither will Ember. FYI Ember is introducing new
ideas by the second (pods, composable components, components over controllers,
DDAU, etc) but the community eagerly awaits and embraces them. I don't know
why that is.

~~~
muloka
Rails forked sometime ago (around 2.0) into Merb then later on merged back
into Rails 3.

Similarly Node forked into io.js then later back into Node 4.

~~~
flippyhead
This is really a fantastic point. It's sometimes as if people think these type
of projects exist in isolation and any perceived flaws are permanent. They
often fail to appreciate how much the flaws will invoke a response to address
them, making them better than they would have been had the flaws never been
strongly felt by the community in the first place.

------
magicmu
The startup I'm with right now just finished a meteor/react project that I
led. This article really touched on our major pain-point with the learning
cliff that you hit after a certain point. We used FlowRouter since it has
React support, but managing subscriptions correctly (let alone caching them)
took _way_ more time than we had anticipated. It wasn't until near the end of
the project that we realized none of us actually had a total mastery of what
was going on under the hood in meteor, which was a terrifying realization. All
things considered, though, I think our biggest mistake was biting off more
than we could chew in using React and Meteor, when we had never made an app
using either before. On the other hand, blaze is pretty rough...

~~~
mrcwinn
It's good to realize the mistake here, so good job. Never jump on the new
thing. Always lean toward the _simple_ thing. Always prefer tools closer to
your core competencies. Meteor is really fun to play with and the community is
very good, but Meteor creates _complexity_ over time.

It's also worth mentioning that unless you have a real-time app whose data
model fits nicely with schema-less document storage, Meteor is almost never
the right tool for the job. And even if your project has those requirements,
there are plenty of high-quality alternatives to Meteor.

~~~
keithwhor
I've experienced this pain point (exceedingly complex systems) over and over
again, and it's something I'm pretty passionate about. There's a lot of
experimentation in JavaScriptLand that involves doing something _cool_ or
_novel_ while totally forgetting about managing complexity. This is exactly
why I built Nodal [1], I just wanted a fast, easy solution to build API
servers.

We're a new thing, but the focus is on simplicity and how easy the system is
to grok. The goal is to reduce complexity via separation of concerns as
related to _systems_ , not just programming modules (actually, Nodal itself is
opinionated and some parts are tightly coupled. The argument there is
consistency within the service to keep it easy to reason about. There's no DSL
outside of the ORM, which reads like Django's. Just ES6 JavaScript.) We're not
trying to compete in the space of "real-time apps" at all, because
microservice architectures are tried, tested, and much easier to reason about
(at the expense of having separate codebases - which I actually view as a
positive).

I did a write-up about it this week [2] and we're focused on trying to tackle
pain points re: web app complexity as best we can.

1\. [http://nodaljs.com/](http://nodaljs.com/)

2\. [https://medium.com/@keithwhor/hello-nodal-why-we-re-
building...](https://medium.com/@keithwhor/hello-nodal-why-we-re-building-
node-js-servers-for-everybody-dce14b27a233#.q3nogd5qg)

------
fefifofu
This article does a disservice to Meteor. The article feels drama filled and
says many things are broken when they are not.

"Blaze is threatened by React". You can use React or you can use Blaze. If
React becomes so popular that Blaze is not longer used, that's OK... nothing
to be threatened about. It's nice that Meteor can move with a trend.

"Tracker and Minimongo might eventually disappear as well". Tracker and
Minimongo aren't giant stick bugs near Australia that need to be preserved.
It's ok if they are replaced. They are internal tools for Meteor provide its
"reactivity". I doubt reactivity is going away.

Other non-scary things: Routing is solved by community packages. Pagination,
forms... really? Server-side rendering has the "spiderable" package, but the
SEO / server-side rendering problem isn't unique to Meteor.

The database issue is valid. Meteor uses MongoDB. But, you shouldn't go down
the Meteor road and try to shoe-horn a relational DB into non-relational DB,
then say WTF. You knew from the beginning that non-relational DBs have their
own set of problems. My limited understanding is that MongoDB was picked
because it was the easiest way to get the reactivity that the MDG was looking
for. Meteor road maps says SQL support is on its way.

I don't know where the OP is going with this. Maybe this is the part 1 of the
late night TV commercial where they list all of our problems (think Slap
Chop), then in Part 2 he'll solve all of our Meteor problems if we buy the
next book he writes.

~~~
muloka
RethinkDB is still a strong possibility as an alternative, it's similar enough
to MongoDb.

While there is no official core SQL support yet there are 3rd party add ons
for PostgreSQL and MySQL available.

~~~
zzzmarcus
There are no Postgres or Mysql add-ons for Meteor that are actively maintained
or even close to production ready. Hopefully you can prove me wrong on this,
but I've looked and have only found preview releases and alpha quality
packages.

~~~
muloka
This looks promising [https://github.com/jordangarside/Meteor-GraphQL-
PostgreSQL-D...](https://github.com/jordangarside/Meteor-GraphQL-PostgreSQL-
Demo)

------
wsvincent
I'm currently using Meteor to teach a college-level course on Web Development
for beginners.

[https://csci16.hellometeor.com/](https://csci16.hellometeor.com/)

It's incredible how accessible Meteor is for this purpose:

* One line complete local setup

* One line deployment (to Meteor servers, but still)

* Javascript only (no need to learn Python, Ruby, etc in addition)

* Out of the box User Accounts

* Simple templating engine with Blaze

I can think of no other framework/language combo where true beginners can
deploy a live, database-driven website in a couple of hours. I really wish
Meteor could focus more on this aspect: becoming THE entry-level framework for
learning web development.

However Meteor's business model is around hosting, so it's inevitable they
move further and further towards the needs of professional, rather than entry-
level, developers. And this takes them further into the areas outlined in this
article where they are currently weak.

~~~
heliostatic
I'm biased as the co-teacher, but I've been hugely impressed by progress our
students have made in just three weeks. Meteor really does fit in well to the
beginner curriculum.

~~~
e12e
Looking at the course page, it does indeed look like meteor is a good fit; it
appears that if the course was from the late 90s it would be 2 parts html, 1
part css and 1 part cgi.

But for a _little_ higher level I always liked web2py[1] - it always felt like
they managed to balance bundling/simplicity with _proper_ documentation that
build confidence in what is (and is not) included: like having a db schema
accompanying the section on built-in auth[2].

But it certainly fails the test of "just one language". And it appears their
chosen host (pythonanywhere) need to fresh up their SNI/SSL handling.

[1] [http://www.web2py.com](http://www.web2py.com)

[2] [http://web2py.com/books/default/chapter/29/09/access-
control](http://web2py.com/books/default/chapter/29/09/access-control)

~~~
tim333
I like web2py too though there don't seem to be too many people using it.
Comparing to things like Meteor and Rails it's striking how it's remained
backward compatible and much the same since it was launched 8 years ago.

------
realusername
The thing which prevented me to use meteor for big projects is it looks really
monolithic from the outside.

What happens if suddenly I want to rewrite part of the back-end or part of the
front-end with something else for various reasons ? What happens if I want to
switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to
have default choices but it looks from the outside that the default choices
with meteor are pretty fixed.

But maybe I'm wrong, that's just how it looks like from the outside.

~~~
davnicwil
> What happens if I want to switch from MongoDb to.. Postgres.. The default
> choices with meteor are pretty fixed

This is exactly the reason I'm not using meteor - and it's not so much wanting
the ability to _switch_ backends as knowing in advance I want to use an SQL
database like Postgres, and not Mongo. With meteor, it's Mongo or nothing.

I believe SQL integration is on their roadmap, but I think now it's too late.

You can in fact use React as the view layer with meteor, so for an app using
React, the remaining killer feature of meteor 6 months ago was optimistic
updates, with database sync all handled. But, there was still the hard
limitation that you must use it with Mongo, which simply made it a no go. I
commented about this here, a couple of times, and others did too. I even asked
a few months ago if there was a library that just provided the optimistic
updates feature. Well, now there is one that looks promising, though it's
still early days and I've not used it yet - Facebook's Relay - with complete
React integration, caching, request management and optimisation, and yes,
optimistic updates and sync. The difference though, is that it talks to a
graphql server, which can be written over any database at all - with Relay the
frontend is entirely agnostic about the database used, by design, because it
talks to it through a middle tier. There's no reason for me to wait for meteor
to implement SQL integration any more, because now another solution has come
along.

I still don't understand why meteor made the choice of a hard dependency on
Mongo if they ever wanted to become mainstream. Had they not, it's very likely
that many developers, myself included, would have picked up meteor over the
past year and would be hooked on it. Now though, that train is rapidly leaving
the station, at least for devs on the React stack. I think they missed their
window.

~~~
bjourne
Query subscription is the reason. You can add a monitor to the equivalent of
"select * from docs" in mongodb and get notified by the db when a docs row is
inserted. Some RDBMS:es can solve the same task ad-hoc using triggers, but it
is not the same and is much more resource intensive. That makes it hard to
achieve Meteor's goal of "any data change is immediately reflected in all
clients" with any db other than mongodb.

~~~
Lazare
It's actually even easier in CouchDB than Mongo. One of the smaller mysteries
to me has always been why Meteor went all-in on Mongo rather than Couch.

------
orthoganol
> Meteor has yet to establish itself as a mainstream development technology on
> the same level as Rails or even vanilla Node.js... almost four years after
> Meteor first launched, I have to admit I thought the framework would be more
> widespread by now. So what happened?

A more general answer, I feel like the web programming world doesn't really
need new frameworks, does it? Rails or Django got mainstream adoption because
there was a need at the time, likewise with frontend JS frameworks (which
seems to be consolidating around just 2 - React and Angular), and likewise
with Node as filling a need for easy async. I'm not that knowledgeable on
Meteor [1], however I think by default it's reasonable to expect no new
frameworks to have mainstream adoption without a major change to the web.

[1] I don't know if Meteor's x-platform appeal is enough to convert users from
other x-platform, native and/or hybrid solutions (Ionic, Titanium, RubyMotion,
etc.).

~~~
mariusmg
"likewise with frontend JS frameworks"

And jQuery. Probabil still the most used JS library.

~~~
elbigbad
I believe this is correct to the point where jQuery is synonymous with
javascript and thus doesn't need to be even mentioned. Plus jQuery isn't
really a framework.

~~~
ChristianBundy
I strongly disagree, there are many people (myself included) who strongly
discourage the use of jQuery. There are _much_ better solutions out there that
follow the "do one thing well" philosophy.

------
treenyc
Personally, the one thing I don't like about Meteor is that it insist on using
MongoDb. That along makes me NOT want to use it, despite other cool features.

------
ianamartin
I was never able to get on board with Meteor because of the Mongo dependency.
Not to get too far off topic, but Mongo is guaranteed to lose data under
certain well-defined conditions.

I completely fail to understand why some developers seem to be allergic to
learning about data structures and the means of query-ing them. It's not
really that hard. If you can JS, you can SQL.

~~~
extrapickles
I currently use Meteor for a production app, but only use Mongo as a scratch
pad (holding data until the user is mostly done changing their mind and other
minor UI state). Data is then packaged and sent to MS SQL Server for long term
storage and reporting.

As an example, a user can start updating a piece of data (eg: sales order,
item, etc), with everyone able to see the changes as they happen (no hard need
for locking, easy to support temporary network loss). Once they are done with
changes, they are sent to SQL.

The advantage of doing it this way, is that the data stored in SQL Server can
be completely optimized for reporting/storage and doesn't need the schema to
support UI requirements. This makes things much simpler for people writing the
UI as they don't have to change the SQL schema often to support the shinny new
UI widget of the day and the report writers don't have to sift through a
million useless to them tables/columns or partially entered rows to find the
data they need.

~~~
rashkov
This is very interesting. Could you give a little more details on how you
accomplish this? How do you serialize unstructured Mongo data into MS SQL?
Does this system break down when front-end people change the data structures
in Mongo? I'm not familiar with Meteor but maybe you could explain in broad
strokes

~~~
extrapickles
There are several ways we go about it depending on the needs of the data to be
stored in SQL. All of our data in SQL and Mongo has a uuid as the primary key
and effectively lets us use merge-style replication techniques, and support
temporary offline use of our application.

If the Mongo data is flat, its very easy to go from Mongo->SQL, only a type
mapper is needed.

The lumpy data case gets more complicated, as its dependent on the data. The
complex data generally ends up translating into master/detail tables or
similar ideas. Various pieces of data that is nice to have, but changes with
the UI/customer needs, gets stuffed into several key/value tables (one for
each type).

For the completely dynamic Mongo data we store in SQL, we alter the SQL table
programmatically to meet the new schema (in part of our application, customers
must be able to drive the schema). This way works in our specific application,
but it requires a lot of work to make sure your users cant paint themselves
into corners with their schema.

So far we haven't experienced any issues with the front-end people changing
data structures, as the changes they generally make only impact fields that
are not stored in SQL. Completely new features generally require the addition
of new columns/tables to SQL, but every application has that issue. During
startup of the server it double checks the schema of all of the tables used
and updates as needed.

~~~
rashkov
thanks very much for the explanation. That sounds like interesting work and a
great solution

------
tbrock
> Once a new Meteor user starts to go beyond the basics and look into things
> like routing, pagination, subscription caching & management, server-side
> rendering, or database joins, they realize that the difficulty curve quickly
> ramps up.

Routing? Really? I am not an expert but I think if routing, of all things, is
hard in to do in your web framework, you most likely have a problem. That's
requirement zero!

~~~
sotojuan
Yeah I don't get this part and it has nothing to do with Meteor, just that new
users find it hard to do anything beyond Todos. But that also makes no sense.
So it's hard for the user to not do something very simple? Maybe the user
should take the time to learn what they don't understand.

------
canthonytucci
Give me a box of boards and nails any day. All my ikea furniture is rickety
and much of it is starting to look dated.

I just spent a good amount of time over the last few months building a
prototype for an application in Meteor and it has been a joy.

Out of the box I got happy, grokable app/server communication, I got sane user
account tools and I got a build process that works well enough that I haven't
thought about it at all. I almost never need to look at documentation, I just
build features. I've only needed a few community packages, and the ones I have
used have been working pretty well for me.

I feel like I've been living the dream. So much ceremony and overhead just
melted away.

I'd be curious to hear what kind of issues people have hit with blaze/meteor
package management/etc that make them want to swap in react/npm/etc. (I spent
the better part of 2015 with react/flux and it would take a lot to get me to
switch back).

~~~
debaserab2
> Give me a box of boards and nails any day. All my ikea furniture is rickety
> and much of it is starting to look dated.

This seems to contradict the rest of your post where you go on to talk up the
plug and playness of meteor. That's much more like ikea furniture than a board
and nails. The board and nails approach requires you to do all the planning
that meteor gives you out of the box.

~~~
canthonytucci
I guess I think those things to be the building materials, and folder
structure/routing/etc to be the stuff I don't mind making my self. I get how
this might be opposite for others though.

------
joslin01
I like Meteor and am using it for my current project, but I architected it in
a way to stay away from their pub/sub model where you publish partial data
sets to the client. I believe this only has utility where you have a feed of
data that you want to filter or sort on a lot of different attributes.

Instead, I just utilize `Meteor.Methods` for all client/server interaction. I
actually think it's pretty nice because you define the method on the client as
a "stub" that gets called as it waits on the server response. I think the
tutorials and guides focus too heavily on their fancy client/server mongo
magic.

Though something that is a bit frustrating reading this is that I left React.
I found it overly-complicated for my product and preferred architecting
everything in terms of templates. Blaze is threatened by React? How? I like
React, but I can't exactly get behind writing HTML components in javascript
because whoa man, a diff engine & "look ma! I'm being functional!" I realize
the benefits of uni-directional flow, but all it really did was add a lot more
conceptual weight to a pretty simple interface.

So I said, this is pointless let's just simplify things with Meteor + Blaze.
Now Meteor says, it's "threatened" by React?

------
warcode
Meteor has been perfect for the single page web apps I've been making as side
projects. I don't know any other frameworks where I could have completed an
encrypted chat application as fast and painless as I did with meteor.

All the things mentioned as "going beyond basics" seem like things that meteor
was never designed for and that we have other tools to handle.

I really feel like the problem is with the people behind meteor trying to make
it THE framework, instead of just being a framework that excels at a single
purpose.

~~~
terda12
I resonate with your comment the most.

I feel like Meteor fulfills two niches in the Node world

* Experimental Javascript full stack framework

* Providing a foundation for full stack apps instead of having the developer do it.

------
juanmnl
I loved meteor. Was committed to it for 6/7 months while still learning JS
(and working on ember and rails projects with others). I knew it was a risky
decision, but it seemed like a good choice for making it as a one-man dev
agency. For me, there's no stack selection problem, for me, the main problem
is the co$t of launching a working demo-app or a prototype. The only thing i
wanted was a simpler/cheaper way of deploying apps. I knew there was something
coming, since the beginning i heard about galaxy, an MDG developed deploying
solution, which i thought was the solution for all my problems. But then, then
came the galaxy launch and its price ($495/mo). At that price I felt betrayed,
misrepresented. (still waiting for the individual price several months after)

The big problem i see with meteor for the future, is that MDG has/will have to
answer to its shareholders rather than its community.

~~~
praveenperera
In regards to cost of launching a working demo-app or prototype my solutions
was a Digital Ocean $5/month box + Dokku

[https://github.com/dokku/dokku](https://github.com/dokku/dokku)

~~~
juanmnl
Didn't know about Dokku, thanks!

Worth mentioning that there are many more solutions now than there were a year
ago, when i was facing this challenge.

------
nik736
As long as there is no direct PostgreSQL support, Meteor is no viable option
anyways.

------
edwinnathaniel
There does not seem a day to go by without a NodeJS-based framework/library
get the heat from the community ever since December 2015.

It appears that 2016 is the year when the hype from NodeJS died down and
vendors/OSS-community must now deal with the hard, un-glamorous, work to clean
up, maintain, prepare roadmap, and so on. Which is good!

Or it could also be the year where people realized that the use-case for
NodeJS is fairly very very specific/niche (unless if they love JS so much that
they're willing to absorb the pain using NodeJS + its ecosystem).

SailJS vs TrailJS, ExpressJS is dying, NodeJS vs io.js, StrongLoop+IBM fiasco
(and SL reputation), now MeteorJS!. I had high hopes that MeteorJS can be one
of the premier NodeJS frameworks (Rod Johnson, who created Spring Framework,
invested in the company. I hope they listen to him...).

I love to see competition in NodeJS ecosystem and hopefully sooner than later,
a few solid options emerged because right now, everything is not a good option
except barebone NodeJS and roll-your-own-framework.

~~~
terda12
> Or it could also be the year where people realized that the use-case for
> NodeJS is fairly very very specific/niche (unless if they love JS so much
> that they're willing to absorb the pain using NodeJS + its ecosystem).

I disagree with this point... I think Node is very versatile and solid. I dont
see anything niche about it. It does very few basic jobs well, 1) providing a
good package system (NPM) and 2) giving us javascript on the backend. I feel
like people think that just because Node is associated with Javascript that
its inherently bad.

~~~
edwinnathaniel
I see BigCo who uses NodeJS only use it for their front-end appserver that
farms the actual work to microservices _that are not written in NodeJS_ behind
the scene.

I've had a conversation with someone where I asked "how do you deal with Money
in NodeJS" where the response was to farm it out to a services written in
either C# or Java. No Money processing is done in JS (maybe because JS lack
BigDecimal? or no standard Money library that deals with ISO-level currency?).

LinkedIN used NodeJS for their mobile app back-end if I recalled. I would
assume that NodeJS is just a front-end appserver talking to myriad back-end
microservices written in other languages.

So this is where I stand given the lack of good stable solid libraries
provided by NodeJS: its place is just sitting as a gateway front-end appserver
that pass processed request to a bunch of services in the back-end and get
response back from those services, do minimum massaging, and spits JSON back
to the front-end. This is why I kind of labelled NodeJS as a niche. Sure,
Trello uses NodeJS all the way left and right but I suppose you can write web-
app back-end using Go or C++ too. Painful but works.

My faith in JS for back-end is definitely pretty low given that working with
either callback or promise isn't fun but that's personal preference more than
anything else.

Anyhow... I'd love to see real production level NodeJS code that deals with
complex business logic (as opposed to super-high-level presentations without
insight to the actual code) before I feel comfortable choosing NodeJS in
general.

------
drdaeman
Anything that implies the lock-up unless everything is rewritten completely is
not a viable choice for me.

I'm wary of anything (especially JavaScript as trends change there faster than
one can read the articles) no matter how praised it is. Sometimes things just
do break in the most bizarre manner when you already have everything set up.
If components are modular enough, you can swap them, or at least patch a
completely new piece over the old one, to handle the problematic cases.

When I once had to replace a very old legacy system (non-web, but it still
holds) I've just slapped a dummy do-nothing proxy-like system in the front and
gradually did stuff piece-by-piece. Then threw out the old garbage when it
wasn't doing anything anymore.

But from what little I understood about Meteor from the tutorials and
examples, there's one single giant system, that you either use or don't. This
means, if one hits some bug or - worse - architectural limitation, they're
going to have really tough time.

------
davidw
When I saw MongoDB, Meteor got put on a "check back some day" list. Phoenix is
way more interesting: it's built on some very solid foundations.

~~~
ibarreto
Phoenix the Elixir framework? Or something else?

~~~
davidw
Yes, that Phoenix. Granted, it's much newer than Meteor, but it builds on such
a great base that it really is standing on the shoulders of giants.

------
Sewdn
The challenges discussed by the OP apply to _any_ large-scale complex project
and are not limited to developing in Meteor. True, some are specific to Meteor
(besides the challenges that go with all NoSQL architectures), as is the case
with any tech stack. IMO it’s quite unfair to obsess about the cons only
(especially if they are the kind of “problems” _you_ can’t tackle), and to
take the pros for granted.

Routing in Meteor, for one, is trivial (esp. with Flow Router). Subscription
management and caching are solvable problems too (esp. if you refrain from
doing subscriptions during routing, but instead declare your dependencies
where you are really are dependent on your data: in the UI components).

What’s the problem with using NPM packages inside Meteor, exactly? The fact
that you must write a single additional line in a package? Well, if you’re not
used to organize your code in re-usable Meteor packages, then, I guess, it’s
more _your_ problem, than it is a problem with Meteor.

Meteor does not scale well? How is that? Any Meteor app can scale, as can
every application that has been set up with a well engineered architecture:
implement you logic in micro-services and your Meteor app will scale smoothly,
horizontally, until your _database_ (and not your app layer, that is!) becomes
the bottleneck.

Most of the comments here, seem to emanate from me the degree of freedom that
comes with Meteor (platform vs. framework). If you can’t architect, then,
obviously, Meteor won’t save your day and do your engineering for you.

I put up some slides with Meteor best-practices for building large-scale apps:
[http://meteor.redandivory.com/](http://meteor.redandivory.com/) The
presentation is almost two years old, but most of the guidelines still hold.

tl;dr — It’s not the framework’s job to do your architecting. Don’t blame the
tool if you don’t read the manual.

------
yetanothercoder
I built an app with Meteor right around when 1.0 was released. The absolute
worst part for me was attempting to shim what should have been a relational
database design into the default NOSQL mongoDb (you pretty much had no
choice).

------
DennisP
I tried out Meteor this past spring. I started with a simple Trello clone,
which I got working in a couple hours, including learning time. It was good
enough at that point that my brother started using it at work. I was pretty
impressed.

So I got to work on some more advanced features I'd been thinking about. And
at some point, Meteor started throwing an error from somewhere in its innards,
and for the life of me I couldn't figure it out. Some kind of problem mapping
data to UI, I don't remember the exact message.

I decided I needed to know the guts of Meteor to be able to debug problems
like this, and put the whole project aside to wait for the _Meteor in Action_
book. But now I'm onto other things.

------
metabrew
Seems like a good analysis of Meteor's shortcomings.

I did some research on related areas a few months ago. My ideal stack at the
moment would involve:

* redux or cerebral with immutable model

* react

* css modules

* webpack

* a realtime-enabled version of falcor, which doesn't exist yet.

The last bit is still the missing piece for realtime, as far as i'm aware.
Neither GraphQL not Falcor seem to been designed with realtime model updates
(via websocket) in mind.

~~~
jxm262
Aside from Falcor, this is exactly my current stack and my preferred as well.
React + Redux + Webpack + Immutablejs + Bootstrap/Less. I'd be interested to
hear your thoughts on Falcor or Relay/GraphQL and see what it can offer. For
my backend I run some minimal node webservices. I've recently started making
all my stuff "pre-rendered" by statically generating my files (react
renderToString -> Mustache -> create a file) , with all my needed data in a
json file, and only access the webservices when absolutely needed.

------
nichochar
Honestly, I used meteor and tried pretty hard, I went to their hackathons,
etc...

I just don't think it's as good as the other options technically (does not
scale well as a server, which is a problem for most applications).

More importantly, as a developer, I do not believe VC money should be bringing
opinions to the open source community (which is what this is) is a bad idea.
The whole point of open source projects is to have natural selection happen.
Meteor having VC money allows them to get it wrong but still market it etc...
Which just seems like a poor idea.

~~~
vjeux
How would you like ambitious projects to be funded instead?

~~~
nichochar
I think the idea is good, but in this case the funding happened too early.

I think open source should have a VC mechanism going on, but first you have to
prove your worth to the community.

------
harel
I did a little project with meteor in its early (pre 0.5) days. At some point
internal errors I could not understand started cropping up. Nobody in the
community at the time could help. In the end I wrote the app in go and
angular. The idea of meteor seemed nice at the time but in practice it wasn't
fun. The all in approach means you should also understand what goes on under
the hood because when the engine fails and nobody knows why, you are stuck.

------
rgoomar
This article is really great. Yes, Meteor is still one of my favorite
platforms, but every library / framework / platform always comes with its pain
points. I have had a great experience with it so far and I have to admit, I
did get to a point recently where I was having trouble recommending it to
other people and companies due to the various points stated in the post.

But, having said that, there is still a very bright future ahead for Meteor.
The people at Meteor Development Group have identified these pain points and
have plans to improve some of it. There are various tasks that they are
working on now that will change Meteor a bit, but also make it a better
platform (in my opinion). Things such as better NPM / module support, support
for multiple different types of databases, faster build times, better testing
support, etc.

The platform has been around for awhile and I still think that it can reach
the goal of being the go-to JS platform for building cross-platform
applications.

------
rafaquintanilha
The major benefit of Meteor (at least for me) always was its quick bootstrap.
So you want start coding or work on a mock-up? Just _meteor create myapp_ and
start. No boilerplate. No script and style tags. Heck, add bootstrap with a
single line of command and you start with fine-grained classes! Sure you might
need a database... don't worry! No need for schema, modeling, whatever, the
server is already there and so the database.

Eventually you might want to scale and then, as in any
library/framework/platform things will get a little more complicated. I don't
see it as a problem, really.

Meteor always was opinionated and maybe some opinions were unpopular from the
beginning (MongoDB, for example). But when you start adding multiciplity
(React/Blaze/Angular for the frontend, Iron Router/Flow Router/React Router
for routing, Meteor Package System/NPM...) you can lose the track. I'm afraid
this is happening now.

~~~
stared
I concur. The strong part of Meteor is its easy way start (both a project and
diving in web dev).

For experienced web developers, or people building bigger projects, easy start
(and whole magics) is incompatible with high modularization and ability to
easily tweak anything.

------
ClashTheBunny
'All happy families are alike; each unhappy family is unhappy in its own way.'
-Tolstoy

It seems that many people are unhappy with Meteor in its own way. It takes 375
factors to make a 'Rails' and Meteor has 370 for each person, but each person
is missing a different five.

------
YogeeKnows
As a newcomer to Javascript frameworks I totally love Meteor JS. I come from
Java backend programming and My Job/Client always worked on proven not so
recent frameworks like Spring etc. I always wanted to learn the Javascript
frameworks but the vast options there are made it very difficult. Too many JS
frameworks, Too many choices. I started learning Angular and they decided to
do a makeover which requires learning from start. Even React isn't something
quick to master.

But Meteor, it just made my move into Javascript webapps so easier. I'm seeing
results instead of that paralysis of am I learning the right framework. I'm
also almost 80% done with my niche Classified ads site.

Meteor JS is best thing I picked up In 2015.

------
pygy_
So, Meteor is going to turn into what SocketStream was, five years ago, before
it was completely eclipsed by Meteor's marketing steamroller.

------
Geee
Meteor is easily the most productive webstack I've ever tried (couple of years
ago) including learning, app setup, configuration etc vs some of other popular
choices. I hope at least some of that carries over to what ever is coming out
next.

------
pm24601
We used meteor at my last company. By far and away the biggest issue was being
stuck with Mongo. NoSQL databases have their place. But they are not a
universal solution to everything (or even most things).

Relational DBs exist for a reason.

Being stuck with Mongo is the major reason why I wouldn't use meteor again.

The other stuff was minor and had solutions. We also built an open source
library that wrapped up collections well.

[https://atmospherejs.com/patmoore/meteor-collection-
manageme...](https://atmospherejs.com/patmoore/meteor-collection-management)

~~~
dack
Yeah this might be one of the biggest complaints about Meteor, and is
definitely valid. It's being worked on actively!

~~~
pm24601
Good to hear. Most data resides in RDBs. If Meteor can't access that data....
Meteor limits itself.

------
eibrahim
The reason I picked firebase over meteor was ember support. Ember and ember
data on top of meteor would be a killer combo for me.

------
cpplinuxdude
This is a little worrying; after much research I'm starting a new project for
a startup using the meteor stack.

~~~
marknutter
Why worry? Does it solve your problem today? Don't fall into the same trap
that so many people fall into who worry far too much about how popular the
tools they use today will be 3 years from now. Focus on what makes you
productive _now_. Your startup has a far greater chance of failing than
Meteor.

~~~
bryanrasmussen
and if it takes longer to get what you need to do done with meteor your
startup might have a far greater chance of failing because of meteor.

------
dvt
So, full disclosure: I recently co-authored a book on Meteor which comes out
in a few months[1]. I don't think Meteor is a cure-all panacea or that it's
the Best Framework Ever®. I've come to Meteor with a fair bit of experience
(Play 1.0/2.0, Sails.js, Flask, etc.) and a fair bit of skepticism. However, I
really don't think much went wrong with Meteor. In fact, it treads some of the
same ground as its predecessors. As far as OP's article is concerned, I have
some very specific squabbles with it:

> This creates a bigger barrier to entry compared to front-end frameworks like
> React and Angular, or server languages like Go or Elixir.

Okay, Meteor has an arguably bigger barrier to entry than React or Angular
(maybe), but definitely 100% _not_ Go or Elixir. I think this is just
disingenuous.

> I believe some of Meteor’s early choices may have ended up handicapping it.
> For example, Meteor’s focus on real-time applications makes them a lot
> easier to build compared to any other platform out there. But it does also
> come at the cost of hidden complexity, and potential performance problems
> down the road.

This is the #1 problem of every framework, ever. Mr. Greif is not saying much,
if anything at all.

> Once a new Meteor user starts to go beyond the basics and look into things
> like routing, pagination, subscription caching & management, server-side
> rendering, or database joins, they realize that the difficulty curve quickly
> ramps up.

Here, he's conflating things that are easy (routing and pagination) with
things that are hard (subscription caching), so it's hard to see exactly what
the criticism is here. Not to mention that Iron Router are pretty mature. I
haven't run into a routing issue yet that it couldn't solve. As far as joins
and caching, etc., these are definitely difficult things. I don't think _any_
framework out there completely (and in the general case) solves these out-of-
the-box. Maybe someone could introduce me to one.

> The result of all this is that Meteor has ended up in an awkward place.

I think it just ended up where almost all other frameworks end up: useful, but
not completely generalized. In fact, I think striving for a very high degree
generality might be a mistake, lest we want to end up with something like
Hibernate.

[1] [http://www.amazon.com/Introducing-Meteor-Josh-
Robinson/dp/14...](http://www.amazon.com/Introducing-Meteor-Josh-
Robinson/dp/1430268360)

------
waitingkuo
In my experience, the best part of Meteor is its tightly couple stack so that
I can developer very smoothly. But the worst part is also its tightly couple
stack when my web/app grows. Really hope that it would be easier to decouple
some important package like tracker or minimongo

------
dfischer
Lots of fear mongering here and as you'll notice, a lot of voice from
inexperience with meteor itself.

We bet on Meteor and it's doing phenomenal. The development experience is
great. I haven't been this happy and impressed since rails .9 ripping me a new
case of programming love.

Look, meteor has it's downfalls but so does any stack. There's nothing working
against you, it's all just code. There's no magic. You don't understand
subscriptions, merge box, and how to handle joins? Level up a little bit. It's
not a hard thing to figure out. Open source code makes it easy to dig in.

Yes, mongo is looked at in bad light, it's also incredibly powerful when used
right. The trick is to not be oblivious to the tools you use and work around
it when it matters.

The most important thing for a product, startup, and company is the ability to
make the right calls and grow at the right time and then be able to handle and
accommodate problematic areas when you need to.

Does meteor scale? Yes. Does it have a theoretical limit? Yes. The trick there
is to be cognizant of the limit and plan around it when you are approaching.

It's all just JavaScript at the end of the day.

Oh you want to scale out your processing? Easy. Fan out some back end nodes in
whatever language you want. Pull from mongo, do your crunching, and then feed
it back in. Then meteor will sync it to all clients. This is pretty powerful.
You can completely swap out and fan pieces out with meteor.

We have a massive app in meteor. It's also architected to be modular if we
have to break it up.

The isomorphic nature of the code base has created pleasant APIs on both the
front end and back end and has drastically simplified a real time app
experience. Meteor sets a new standard for web applications and demands new
perspectives. When you embrace it you get an ecosystem that is quite
revolutionary to work with. Everything from the web-app, latency compensation,
pub/sub, down to Cordova builds.

Overall, we are very happy. Yes things can be better, and we are looking
forward to seeing meteor evolve.

Meteor shouldn't focus on supporting new view frameworks like blaze vs react.
Just focus on adopting the tools out there and making it better. That's why
meteor doesn't need blaze. Meteor doesn't need a router. Meteor should pick
the best open source versions of that in the Js community and make it easy to
work with inline with the "vision". Meteor should focus on the developer UX.
This is their power. An opinionated framework that removes the stress of
configuration and has tools that fit really well together to allow an
individual, team, and company to focus on building what matters: features.

The vision is grand and I believe it in and I'm also not worried about scale.
People said the same shit about rails, and x, y, z. Scale is a good problem to
have and when you have that problem you'll figure out what you have to do.

If anyone has any questions about meteor architecture feel free to ping me.

\---

------
premasagar
Another place I'd love to see Meteor move towards the (future) standards would
be an eventual replacement of Fibers with async/await throughout, which to me
is more explicit and intuitive.

------
applepple
I think the problem with Meteor is that it's not meaty enough...

[https://github.com/mattkrick/meatier](https://github.com/mattkrick/meatier)

------
elchief
"Project Foo: The Greatest Thing Ever". What is that? I should look into that.

A year or two later. "Project Foo: Total Crap". Glad I didn't look into that.

~~~
m52go
Meteor is different. It's been over 4 years. It's not going anywhere. It has
more stars on GitHub than Rails.

If you haven't looked into it, and you're in a remotely adjacent field, you're
behind. Even if you don't decide to use it. The ideas underpinning the
framework are very progressive and sure to continue in some form even if
Meteor itself ultimately doesn't.

With all that said, I think Meteor is simply going through some growing pains.
Given how ambitious its vision is, it simply _can 't_ avoid them. I look
forward to Sacha's next, hopefully more optimistic, post!

~~~
webjprgm
There are too many JS frameworks/platforms/libraries to keep up with. I can't
spend my time investigating them all. I've heard of Meteor several times but
in my mind it was associated with (a) real-time apps, and (b) not free. I'm
guessing that was because it is the free alternative to a paid thing? Anyway,
that's what stuck in my head so I've ignored this one.

Is looking at GitHub stars a recommended way to find the best frameworks? Or
what would you suggest for that?

I recently started looking at Nodal since it was mentioned here on HN a couple
weeks ago. It looks pretty cool at first glance but I haven't tried building
anything with it yet. (I don't have infinite time.)

I remember when there was Prototype.js vs jQuery vs Yahoo's library vs
MooTools vs fill-in-the-blank. I only switched to jQuery when virtually
everyone else had. Until then I stuck with Prototype because its the one I
already knew (because I tried it first), even though I _had_ played with
jQuery a little bit.

So, again I say there are just too many frameworks to keep up with. (And ask
if anyone has a good site / method for dealing with this.)

~~~
m52go
There's nothing (I know of) with a more radical approach to the full-stack web
than Meteor.

No one's saying you need to keep up with _all_ the JS frameworks, but if I
were hiring a JS dev, I'd expect the person to understand the pros and cons of
the most important ones. Meteor is categorically one of the most important JS
frameworks out there.

I'm not sure about a way to determine the "best" or "most important"
frameworks. Perhaps number of appearance on the HN front page could be a
heuristic?

"Not free" is not quite right. The software is open-source & MIT licensed. The
entity is for-profit, as it intends to sell services adjacent to the software,
not unlike Acquia & Drupal.

------
ricardobeat
> The recent Blaze/React debate

Can someone point to the backstory here?

~~~
teleclimber
I was curious too, found this: [https://www.discovermeteor.com/blog/blaze-
react-meteor/](https://www.discovermeteor.com/blog/blaze-react-meteor/)

------
yclept
I was turned off to Meteor when one of the initial releases was touting being
able to use the browser console as a Mongo shell. Never took it seriously
since.

~~~
patates
I think it is for development only.

~~~
sundaeofshock
The intended use doesn't matter. That's a huge potential exploit. I would
never deploy an application based on a framework where database access from
the browser is baked in.

~~~
eterpstra
Database access from the browser is not baked in. This is a misunderstanding.
Meteor has a browser cache that mimics a subset of Mongo commands, and auto-
syncs with the back-end based on security rules you define.

~~~
sundaeofshock
Thanks for the clarity. That will teach about commenting during the morning
commute.

------
oldmanjay
I can sympathize greatly. I played around a bit creating an isomorphic
"framework for frameworks" to explore some techniques I didn't get to use in
my day-to-day. There is a constant tension between leaky abstractions and
expressing functionality meant to run in very different environments that I
personally am taking years to fully grok [0]. Of course, unlike the meteor
folks, I'm doing it for fun, so there is no pressure to make any money doing
it on my end.

[0] for instance, I made it trivial to invoke client functions asynchronously
from server code using normal call syntax. Now how to deal with timeouts? The
syntax doesn't permit much without leaking, destroying the original point.

~~~
goldenkey
Off topic but is there a reason I keep seeing this word 'grok' used all over
HN? Just say 'understand' unless there's a reason to sound like you have
aspergers.

And 'fully grok' is redundant anyhow - grok implies a full and deep low level
understanding with no lapses, you cannot partially grok something. It's
dissapointing to see uncommon words used in poor ways, I'm seeing this word
misused all over HN as if its now a cult jargon.

~~~
brandonmenc
jargonfile or gtfo

There's nothing wrong with saying "grok."

~~~
goldenkey
"Grok" in is original use is something more like a deep and complete
understanding. Here is Heinlein's explanation from "Stranger in a Strange
Land": "Grok means to understand so thoroughly that the observer becomes a
part of the observed—to merge, blend, intermarry, lose identity in group
experience. It means almost everything that we mean by religion, philosophy,
and science—and it means as little to us (because of our Earthling
assumptions) as color means to a blind man."

But 'grok' is supposed to mean something more like understand various
arbitrary things at a low and intimate level, not at a high level.

------
sneezeplease
Meteor is great and Im optimistic what 1.3 will bring with better NPM support.

------
popmystack
I'm sorry, but how are you in a lead position but somehow didn't understand a
timeless principle of software development?

~~~
wreford
I'm sorry... Literally your entire posting history is negative without adding
any value. Why is that?

I personally enjoy seeing people voice their mistakes in a honest way so the
rest of us can learn.

Edit *your

~~~
popmystack
Where do you see negativity? How is his comment adding any value? "We chose a
stack we didn't fully understand after trying it for less than a week and it
turns out we didn't know everything about it!"

Also it's "your", not "you're."

~~~
ccallebs
> Where do you see negativity?

The same place you saw the negativity, which is why you prefaced the sentence
with "I'm sorry."

One should not assume someone's technical prowess based on one poor decision
(a decision they've recognized as suboptimal). Also, they still shipped.

~~~
popmystack
That's a ridiculous statement. "I'm sorry" is not an indication of negativity.
Nor is it indicative of my posting history. Apparently criticism is simply not
allowed. Sorry to poke the fluff that is somehow being perceived as value.

You most definitely can judge someone's technical prowess as well based on
their decisions. I am not sure how you're going to grey-wash this into some
kind of innocent mistake. The decision that was made reeks of novice
motivations and perspectives.

I asked a very blatant question, if one is going to go off of titles, how does
a CTO and lead engineer (or anyone leading any kind of project) make such a
novice mistake, together nonetheless. My apologies for not echoing
commendations.

~~~
cloverich
> Apparently criticism is simply not allowed. Sorry to poke the fluff that is
> somehow being perceived as value.

Your original comment suggested this person mis-understood a foundational
principle of software development. I, and I suppose many others, have been
reading Hacker news since before we were senior engineers. So its not being
"perceived" as having value; by your own admission, it is full of value (for a
large portion of hacker news). While criticism is indeed tolerated, it must
provide some value to the discussion. your original comment effectively read:
"You are so incompetent, how did you ever get hired". That is not conducive to
discussion; hence the down votes.

~~~
popmystack
I like how a very forthright question has been met with utterly ridiculous
characterizations of what was stated. I didn't say "how did you ever get
hired." I specifically mentioned the lead/CTO aspect. It's a crudely
constructed sentence that should result in a struggle to interpret any other
way.

My comment then was meet with trivialities, outlandish statements, and
generally nitpicking of tiny parts of my posts. And it appears that because
they simply took a position seemingly contradictory (in the lightest sense of
the word) to mine, they have been spared any amount of criticism despite
significantly diminishing any hope of constructive conversation. Quite
honestly, if I had simply ignored these responses there'd be far less noise
and general non-sense. My question was not a top level post, it was specific
to what was stated and based on one other comment the OP made in the same
thread. It's not complicated to respond to nor to understand the motivations
of.

Based on his comments, both the lead of the project and the CTO chose an
entire stack for their product after seemingly one hackathon, maybe even
hosted by Meteor itself.

I am sure the industry doesn't need to have a conversation about how huge
amounts of capital are being used at various companies, with people who lack
the experience (or sometimes, and not necessarily in this case, intelligence)
to make such decisions, all while giving marching orders to who knows how many
engineers under them. And again, this type of problem and others like it are
something that the industry as a whole has plenty of talent do deal with and
appropriately handle. So, how did this non-sense of picking this shiny new toy
come about? How did he become lead? Which is why my question was asked. This
isn't some isolated incident. I see it far too often, especially
professionally.

Oh and let's not forget this is all on a post about the schism between
development motivations in the Meteor community.

Calling me a troll for not using an endearing tone and having a question that
is part of a larger conversation on the state of the tech industry is
maddening. That being said, this is clearly not the right audience, especially
using the responses as benchmark, so I'm dropping it and sticking with "just
ignore everyone but OP" after this.

