
The State of Meteor Part 2: What Happens Next - wsvincent
https://www.discovermeteor.com/blog/the-state-of-meteor-part-2-what-happens-next/
======
apalmer
I am amazed by how the article attempts to look forward to what the future
will hold with JavaScript frameworks... and yet seems to be completely both
dismiss or misunderstand (perhaps willfully) why previous frameworks have
succeeded.

jQuery did not succeed because it was a 'good enough' competitor to dojo or
prototype or mootools or extjs... it succeeded because it went completely the
opposite direction. it did not attempt to be a fundamental ui framework like
those guys, it didn't try to be full featured, it didn't try to change
javascript to look like another language and didn't try to shift the paradigm
of the front end development world.

~~~
incepted
jQuery filled a need.

It's as simple as that.

Its success has nothing to do with looking in the other direction or not
redefining Javascript: it solved a problem that a lot of Javascript developers
were struggling with.

Now what's really fascinating to me now is that while one can safely say
jQuery created a revolution in the Javascript world when it came out, it is
today widely looked as a smell and avoided as much as possible in favor or
frameworks that modify the model instead of the UI.

And this quick rise to success and fall to obscurity could very well happen to
the successful frameworks we are currently using today (including React).

~~~
faceyspacey
it wasn't "quick" though. React had a good run. One of the best "runs" you
could hope for at the end of the day.

~~~
ZoF
You mean JQuery had a good run?

~~~
faceyspacey
oops, yea.

------
dfischer
I said more in the other thread, but I'll leave another note in this one.

What I think Meteor has the most going for them is the ultimate UX experience
for the developer. If they really hone in on making it enjoyable, and dare I
say fun to work on product... then they've won in my book.

Meteor has given me that feeling thus far, and given the new trends in the
community I am sure they are moving in the right direction. I've spoken with
the guys there and they are carefully reviewing what the best routes are to
take that creates the best experience.

Meteor is not just a vision, it's a real experience you can tap into right now
that benefits a very powerful suite of tools to get up and running. We have an
enterprise app built with it and it's going great. Yes, it'll bite you in the
ass if you don't learn how things work (pub/sub/mergebox/reactivity) but just
dive in a little and you'll see it's just a library composed of other
libraries that are well documented and easy to learn. It's all really quite
simple really. The beauty and evil word "magic", is how they all play well
with each other.

React is probably a better choice than Blaze at this point, even for the pure
fact that it allows Meteor to not worry about the view and focus on the
overall UX experience of the developer above all else.

~~~
tonyonodi
I couldn't agree more, it's a god send not to have to wade through
documentation and work around a hundred errors while you set everything up;
before you've written any code. The freedom to iterate on new ideas quickly
that a NoSQL database gives you is rather nice too (even if that's a terrible
reason to choose a performance-critical part of your stack).

I'm sure all this magic comes with a penalty further down the line so I'll let
you know whether it was worth it when I get there...

------
d0m
I completely agree and I'm excited about this vision for Meteor. The dream
would be to have a go-to choice with formidable standards that Just Works.

Personally, what I wish existed was a full-stack framework AND dev ops built
with the "best" open source libraries. I'm fine with not having my favorite X
if it means having a set of well supported, highly performant with lots of
documentation and training materials services that work perfectly together.

Starting a new project the "right way" is a pain right now. Again, I would
gladly trade my favorite libraries/tools for a great full-stack solution
(including dev ops, continuous integration, roll-back deployment, scalable
servers, etc etc.)

Software engineering is still a new field and it's hard to establish "best
ways of doing things", but I'm wondering if it'll start converging to "The
Proper Way". Similar to how building houses is pretty straightforward. Of
course, part of the reason that it's hard to do in software engineering is
because technology keep changing so fast.. I.e. Tools from a few years ago
will most likely not play well with VR stuff.

~~~
jonesb6
I'd strongly disagree with the idea that we need or even want one ring to rule
them all. Remember different frameworks are designed to solve different
problems in different ways [1][2]. Anyone who has dug deep enough into a
framework or tool-set will be able to write out a very long list of unique
quarks, gotchas, caveats, hidden strengths/weaknesses, and what have you. It's
those differences that will make one framework more valuable in a given domain
then the other, we want that because there are many, many, domains to conquer
in software engineering.

IMO, innovation stops when we believe we've found "the best way of doing
things". I'm all excited to check out Meteor too, but I'm not getting in line
at the Apple store, I mean full-stack framework store, on the day of release
to be a guinea pig for the "new best thing" at my personal expense (time).

[1]:
[https://en.wikipedia.org/wiki/Ruby_on_Rails](https://en.wikipedia.org/wiki/Ruby_on_Rails)

[2]:
[https://en.wikipedia.org/wiki/Django_(web_framework)](https://en.wikipedia.org/wiki/Django_\(web_framework\))

~~~
kevan
What if we replace "best" with "good enough for most common uses"? Most of the
roads and bridges we build today aren't pinnacles of innovation, they're just
good enough that we don't bother optimizing them much more. With how young the
software engineering field is I don't think we'll get to this point in the
near future, but part of me looks forward to a day when we have widely
accepted standard solutions to common problems that don't go out of style for
decades.

~~~
jonesb6
I think there is a difference between "just good enough" and "has reached
maximum efficiency". I think a lot of people want to settle at the first one,
yet I see the second one nowhere in sight.

------
matthewrudy
Meteor's best trick has always been data synchronization.

That was the magic trick that sold your client.

They proved real-time data synchronization could be simple and seamless, and
everyone else had to run to catch up.

But that trick is now 4 years old, and nothing else of substance really
emerged.

As Ember, Angular and React grew, you were never going to want to use their
odd looking front end.

Their data sync also came with dubious claims to scalability, not the least is
their tie to Mongo.

That may be fixed now, but the consequence is being tied into Meteor Galaxy.

Meteor should have thrown everything away, and become just the data layer.

Like Firebase, but open source, and backend / datastore agnostic.

They tried to standardise DDP, but it didn't catch on.

But what the world needs is a standard like GraphQL, but handling data
updates, and with automatic realtime data sync.

Thatd be a wonderful legacy for Meteor.

But this won't happen, as the company needs to make money from hosting.

~~~
dfischer
GraphQL and Relay may be the answer but it's too young to make that switch now
and Meteor is solving that exact problem. Meteor has the momentum and
community to take it further. Maybe it actually adopts the GraphQL standard
and unifies it into the ultimate dev UX experience.

~~~
pacnw
Yeah, I went down the Relay/GraphQL rabbit hole for a good 1.5 months last
year, but unfortunately there is a tremendous amount of work to set up GraphQL
servers to even get your data out to Relay, and it is not real-time at the
moment (although the 'community' appears to be work on it. I so wish Meteor
would provide a drop-in module for just the DDP, I don't even care if its
Mongo, their real-time subscription works.

------
stevebmark
I predict that Meteor will won't go anywhere in 2016. I know this sounds
negative so I'll try to explain. The surface area of Meteor is still too
large. Keep in mind this is a venture backed company, people are getting big
salaries to work on a framework. Look at what it's led to: in house tools like
Blaze which even the creators are already tired of. At best Meteor will be 90%
cannibalized and replaced with open source tools (as this blog post is
implying), and sit properly in the same place as other CMSes, which inherently
don't get that popular. What's worrying about this post in particular is it's
not business focused, and the only long term company goal mentioned is "meteor
will be a back end solution that makes sense." To what end? Why wouldn't you
do that in a non-profit or pure open source model?

~~~
joshowens
Why would the post be business focused? The guy that wrote it doesn't run
"Meteor the business", he just loves the framework itself.

I am not even sure how a CMS got mentioned and compared here.

~~~
faceyspacey
Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do
in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that
many "features" to win over the NPM crowd that it has struggled to acquire
thus far. It's so damn complex to implement all this stuff that most
developers need help doing it.

Meteor's problem thus far has been it makes it easy but provides no way to
"drop down" to a lower level and configure things like you would on "bare
metal" NPM!!!! Despite its easiness, this has scared away many developers from
Meteor--especially the expert developers who would otherwise evangelize once
they joined Meteor.

Therefore, Meteor just needs to provide a way to BOTH do things with
sufficiently less boilerplate (like it's always done well), but also allow you
to drop down to make lower level tweaks as you would on "bare metal" NPM. And
perhaps even an intermediate tier in between for some features.

For example, Relay + GraphQL is great but there should be the "beginner's way
to Relay."

So the killer feature in fact isn't a "feature" in the traditional sense, but
rather a mechanism that only a full stack framework could provide. Being the
only full stack framework that matters (and the only "reactive full stack
framework" in existence), Meteor is well positioned to scoop up the entire NPM
market if it plays its cards right!

~~~
qaq
Unless this comment is from SMM team at Meteor, WTF? What is NPM market :)?
"Bare metal" npm? Name single sizable project that uses Meteor? You do realise
that for 90% of enterprise projects it's a wrong tool. There is no usable
universial/isomorphic option, you can't expose API for external consumption,
if you have to consume services on the backend the only cool feature that
Meteor has is gone. Not to mention long term risks of what will happen to the
project when vc funding runs out.

~~~
faceyspacey
My assumption is that Meteor is moving towards becoming like any other app you
can build on NPM. That means Meteor will be the wrong tool anywhere
NPM/node/javascript is the wrong tool. That's a fine agreed upon limitation.

Currently Meteor is a layer above NPM, which is why I'm referring to NPM as
"bare metal" NPM--you clearly knew exactly what I meant. Meteor needs to
become an adjacent resource to thrive.

So my prediction is if Meteor does this correctly they will no longer scare
away expert developers and grow more than they ever have.

~~~
qaq
NPM is a package manager. Expert developers are not scared it's just Meteor is
horrible solution to majority of use cases that they need to address. You need
to read up on what Meteor actually is and what it's limitations are. Major
ones have being outlined above: 1) No usable uinversial/isomorphic option so
SEO is gone. 2) you can't expose API for external consumption 3) you are tied
to only supported storage backends 4) if you are not talking directly to
storage layer it's only cool feature is useless

None of the above is limitation of node (or has anything to do with npm
package manager).

------
desireco42
It is kind of sad that this wonderful framework, from total awesomeness, came
to this situation where I am not sure what will future bring and should I make
my projects in Meteor.

Meteor started with huge advantage, it is auto reloading, it has data layer
that is very simple to use, it syncs across clients. On top of that, you can
package mobile apps with it.

One thing I really loved is Velocity, testing runner that would display a dot
in the corner of the screen, it would run a testsuite, and if it turns red,
you can click and learn what test failed.

I was hoping it will be more awesomeness, instead, they eliminated Velocity,
testing is not clear cut, db layer that needed most attention is not getting
enough, whole focus is on frontend.

React is awesome and adding it, it really brings a lot to Meteor, but I think
Blaze was good enough.

Anyhow, now I am Elixir/Phoenix dev, don't feel the same pain I did before,
but any positive news from Meteor would be very much welcome.

~~~
dfischer
Phoenix is the only other thing that really appeals to me as something I want
to try that is fun. That was the great thing about Meteor, it got a lot of
shit done, and it was fun. That's important.

What do you do to hook into Elixir? What's your tech-stack for the other side
of the back-end?

I was looking into phoenix/elxir generating GraphQL but that seems pretty
immature and at least a year out to be comparable with Minimongo/ddp.

~~~
desireco42
I just use Phoenix/Elixir. I can wire it with React, but honestly I am
starting to question this. Only if I really need React, I will actually use
it. So far I work on simpler stuff, api's and smaller apps.

~~~
dfischer
Yeah that's the thing though. Meteor made the front end trivial. That's a
vital piece to the whole pie.

Oh well, I guess we'll see how the next year goes.

------
tomcam
Might have been different if they had chosen to embrace SQL, instead of just
putting it on the roadmap and letting it rot.

~~~
glenk
This has been my feelings on meteor as well. It looked neat and I went through
some of the tutorials and such, but really had no projects I could use it on.
All my current projects interact with various sql database at some point. I
realize that isn't as cool as all the nosql stuff, but I kept hoping they
would get to it, and then kept getting disappointed.

It's a pretty narrow full stack to me if you don't have real support for sql
databases. It's been sitting there for 3 years and has about the highest votes
of all them. They had a post about experimental postgresql project in
august([http://info.meteor.com/blog/an-early-look-at-sql-in-
meteor](http://info.meteor.com/blog/an-early-look-at-sql-in-meteor)), but it's
mostly sat there with a few updates since then. It doesn't seem to be much of
a priority.

~~~
siquick
Exactly this..

------
shadowmint
Why will it be any different this time compared to last time with GWT, Dojo or
SproutCore?

Server - client binding javascript widget frameworks are nothing new, and they
have, historically, failed to be capture broad adoption because they require a
very specific backend.

If you had an excellent series of react components with data binding done via
an open server specification and meteor just _happened_ to be one
implementation that backend; people would really dig that!

...but there would be a lot of people who didn't use meteor at all; and just
wrote their own server implementation for it.

    
    
        “but wait, if we end up using React, Relay, and GraphQL,
        what do we even need Meteor for anymore?”.
        ...
        This all boils down to one key fact: Meteor is the only
        framework that controls the whole stack. 
    

So what? Who cares? Controlling the whole stack isn't even remotely
interesting unless there's some _tangible_ benefit from it.

This is by far the weakest and least compelling part of this article.

    
    
        So this is my vision of the future of web development 
        for 2016. React as a common front-end standard, and 
        Meteor starting out as one of many possible back-end
        choices, but slowly becoming the one that just makes 
        sense. 
    

You really need to try harder to explain why Meteor would be a compelling
choice for people then.

If the front-end component api is well defined and backend agnostic, meteor
seems to offer literally no particular benefit over any other backend someone
might choose.

------
ricardobeat

        This is important because development standards are a 
        winner-takes-all game: once jQuery became the default, it enabled an 
        explosion of plugins and components built on top of it, 
        and every JavaScript widget became a jQuery widget.
    
        The exact same thing might very well happen with React.
        And that’s a very exciting  thing for Meteor.
    

Thankfully we know a bit better by now, and build modules with a small surface
area that are not directly tied to frameworks or plugin APIs. So no, I'm not
so excited about that happening to React.

------
NhanH
Can someone chime in as to whether React won the frontend war? As in the super
majority of new project will be developed in React. I'm not that well-versed
in the Node ecosystem (I got my news from ... HN). But from little I've seen,
I found it hard to believe that React would be able to react the place where
jQuery was (is?).

Heck, we even have a post staying on the front page today lamenting the
inferiority of React.

~~~
silviogutierrez
I was about to abandon Angular 1 for future projects and go all in on React.
And it looked fairly promising, except everything is its own little module.
Good for UNIX, but not so good for modules that change so often.

Then I started catching up on Angular 2 and TypeScript. It looks like the
right mix between new and opinionated. I just don't have time to research a
module for data, one for building, one for testing, and one for validation.
That's where an opinionated framework comes in handy.

I do hope Angular 2 takes off.

Any other Angular people out there weighing in between React and Angular 2? If
I were a betting man, I say it's going to come down to those two for the next
few years.

~~~
suhelk
I totally agree with you.

It took me lots of time just to figure out to write a 'PROPER' react
application. There are too many modules to choose from for routing, data acess
etc..

Then I tried with Angular 2, it look me less time to get up and running with
forms, routing and everything...

~~~
stephenhuey
It may take you even less time with Aurelia!

~~~
suhelk
Aurelia too seems interesting. Since I have done development in Angular 1.x
before, Angular 2.0 was the natural choice.

From the look of it, Aurelia seems promising, need to look into more before I
need to comment anything.

------
pm24601
The problem with Meteor is _not_ the front-end. The problem is that data
exists (for the most part) in Relational DBs.

This prevents Meteor from being used in any environment that needs to/wants to
use a SQL db.

This prevents Meteor from being used in any form, for any application that
needs to access existing data in a SQL db.

React does not prevent Meteor being adopted - not having SQL support is a
dealbreaker.

If Meteor does not confront and solve this problem nothing else matters.

The _only_ thing MDG should be doing in 2016, is SQL DB support.

~~~
dror
It's probably too late. The work they've done with blaze is wasted since react
and angular(still) are dominant. The work they've done with MongoDB is wasted
since most of the world wants SQL. So what do they really bring to the table.
It feels like too little too late.

------
EGreg
_This all boils down to one key fact: Meteor is the only framework that
controls the whole stack._

 _After all, the fact that no other company than MDG has even tried to make it
happen should be proof enough that it’s not trivial._

I did it, over the last 4 years
[http://qbix.com/platform](http://qbix.com/platform)

Actually our platform aims to be an entire "Wordpress for social networks". We
realized that identity, security, roles, permissions, consistency and realtime
updates etc. are hard to get right and building a standardized platform will
free up developers to focus on what their app does instead of reinventing the
wheel, etc. Not only that, but it will allow interoperating and reusability of
components across all the sites.

And yes, it does routing, pagination, components and more in a way that will
give Angular and React a run for their money if you check it out.

Also it does a lot more:
[http://qbix.com/platform/features](http://qbix.com/platform/features)

PS: try loading all this on your smartphone!

~~~
strongai
This looks fantastic! Please could you write some words aimed at potential
recruits to qbix? What to expect, what not to expect. I noticed, in scanning
your site quickly (... I think all content should bear the 'scanning user' in
mind, but that's another topic) that php is mentioned. What php knowledge is
required? What JS knowledge is required? Make it easy for people (I mean
really, visitors who are pre-tutorial) to decide if they have the wherewithal
for it to be worth them making a modest commitment to take it for a test
drive.

~~~
EGreg
You can put together a site with hardly any PHP knowledge. Just place reusable
componenets on pages, or widgets that connect to ready-made backends... but
then you don't really need this framework.

But if you have some basic PHP knowledge, you'd create more pages, and perhaps
some backend actions.

As far as the PHP and JS knowledge, see
[http://qbix.com/platform/guide](http://qbix.com/platform/guide)

The more PHP and JS you know, the more you can do. Unlike React and Angular,
though, everything is named in a super-straightforward way, like Q.page and
Q.Tool and tool.children() etc. So you just go ahead and build your site and
Qbix does a ton of things for you, like dynamically swapping out css/js as you
navigate pages, takes care of history and routing, activates and removes tools
and their associated events, lets you subscribe to exctly the events you need,
and documents conventions you should use to play nice with everything else.

------
lambdacomplete
Dove into react and redux and built a couple of small apps. They are amazing
not because they add some "fancy" features but because they train you to think
with a different, much cleaner and simpler, mindset. Before your brain
"clicks" you feel miserable. After it does you think "why on earth isn't
everybody using this??" and any problem is solvable by dispatching actions and
building reducers (thank you Redux!).

Three days ago I spent a couple of hours on Meteor's simple-todos tutorial,
trying to understand how everything was working (that is, at an abstract
level). I felt great after finishing it. Two days ago I started building a
service we'd like to launch within a couple of months, e-commerce like stuff.
I felt miserable. Pushed the first "draft" with a customized sign up and I
felt like I had no idea how to proceed.

Yesterday I spent 4 more hours, started using packages like autoform,
collection2, something for bootstrap, iron-router etc. and I feel FREAKING
GREAT. Again my brain clicked and now I implemented ~70% of the features with
validation, defensive checks on the server for security, nice-looking popups,
good overall UI... I mean, I intended it to be a prototype, maybe mocking some
parts but, damn, we basically already have a MVP! In 3 days (effectively ~12
hours)! And now I already know how to implement the rest, it just feels
_natural_ now. Like when you have a solid plan and you think it through in
your head and you KNOW how to implement each and every step of it.

You can hit a wall with Meteor as much as you can with any other framework (I
mostly use Django). It's all about reading the docs, looking at what the
community is doing and try to adhere to some "guidelines" (if there's no
standard way of doing something). I will let you know how it scales when we
reach a couple million users (bazinga!).

~~~
codesuela
I don't know if you are aware but there is now an official guide which goes
way beyond the scope of the docs.

[http://guide.meteor.com/](http://guide.meteor.com/)

~~~
lambdacomplete
Yes I'm already reading that. Thanks for the hint!

------
joeblau

      >  And Angular is… well, it’s not React.
    

Can someone explain what this statement means in terms of the technical
benefits of React over Angular?

~~~
epmatsw
Probably just means that Angular (at least seems to be) losing momentum and
marketshare to React. It's hard to go a day without seeing something cool or
exciting about React on the front page here, but all you see about Angular is
either nothing or articles about the upcoming(?) transition to 2.0.

------
oliv__
I've been using Meteor for little over a year now and to me, the real selling
point for Meteor was the insane speed, productivity, and almost instant
gratification that results from that speed: all of a sudden you went from
having to configure a million different moving parts to just coding, almost
forgetting that you are coding in the process, enjoying yourself, and suddenly
seeing your features pop out of nowhere. It's quite magical.

For someone like me (I'm more of a designer who can code than the opposite),
the reactivity, feedback and interaction with your code make the whole process
feel much more "hands on", almost like sculpture, in the sense that you are
able to poke things and see them react instantly. And that makes all the
difference.

Yes, many problems do appear once you dive deeper, but I've never used another
tool that brought me closer to my ideas than Meteor. And in the end, that is
for me the single biggest achievement here.

------
neximo4
Meteor started off so brilliantly. I wish the team would focus and just make
it great.

Many people would complain about SQL and what not but the truth is there's a
very large number of people who are quite happy with MongoDB and the fast
experience building an app.

However there are some really big issues that seem to be ignored:

1) It's nice that its backwards compatible but some essential features are
missing such as a router. Iron Router is available but it's practically
abandoned. You can't even have URL's such as /2 on it.

It makes it hard to keep an app for the long run knowing there is a risk of an
essential component about to be abandoned.

Other similar projects include Meteoric (an Ionic wrapper)

2) I wish they'd focus on making Blaze work. It works. Many people don't like
react and just want an App build on V1 to work with V1.5 and V2. The lack of
clarity is harmful to the use of Meteor in The Enterprise.

3) The build time. It used to be that Meteor built a project near instantly
when a file was changed and hot code changed the page. Now it takes a good 20
or so seconds for a simple line change. It seems over the top.

4) Clarity and focus on direction. They spent ages pushing people to their Npm
system, now they're going back. Why not start with node_modules/complete npm
support instead of flipping back and forth. The volatile state of affairs with
Blaze, Npm and the general structure of an app manifests risk in choosing
Meteor for an actual Enteprise grade app.

5) A focus on improving what already works well over adding new features and
degrading the performance of existing features.

I mentioned the build time, but other parts of Meteor such as Cordova, Blaze,
Tracker, Mongo (Meteor uses MongoDb 2.6?!) would certainly help more.

I'm not sure what's happened but it seems a lot like the team is losing focus
of what people actually like about the project.

~~~
raffomania
I especially agree with 3). I was expecting more people to mention this.
Compared with other build systems like wepback or gulp, meteor rebuild times
are insane.

edit: Just checked out the Meteor Roadmap, and build times are not even
mentioned there.

~~~
neximo4
It used to be. The current implementation is the result of the effort in
speeding it up.

------
ryannevius
Only semi-related...but why do you think Mithril is always so easily
dismissed? I kind of get it: huge companies are working on and adopting React.
But after using Mithril, I just can't figure out why it has failed to catch
the attention of more people.

~~~
brlewis
Mithril succeeded in catching my attention because creating a good mobile web
experience is important to me. This does not necessarily explain why it has
failed to catch the attention of others, but might be a clue.

------
devcheese
what major production apps are build with Meteor? This might be the wrong
place to ask but I figured it's worth a shot.

~~~
ollerac
[https://www.quora.com/Which-startups-use-Meteor-in-
productio...](https://www.quora.com/Which-startups-use-Meteor-in-production)

------
dham
I strongly urge you to take a step back and really look at React community
from 30,000 foot view. Please don't get on the hype train without taking a
look at other solutions. Vue.js as far as libraries go, and Ember as far as
framework go. I promise you, you'll have a better experience.

~~~
ocean3
Vue.js seems like backbone. Last time i checked Ember looked way complicated.
What i like about React is the simplicity. Its basically JavaScript with few
React functions thrown in. As a view component its very good. I have used it
in normal rails app as well.

------
matthewvincent
Seeing the Discover Meteor and Kadira guys embrace React with Meteor is
definitely making me want to dive back into the framework after being very
hesitant over the past few months. It's great to see ~someone~ with a clear
vision for the future.

------
oelmekki
Mootools is not an ancestor of jQuery, it actually was released after jQuery
(by a few days).

From what I recall, the success of jQuery was not because it allowed to do
more things. It was mainly because developers by then considered javascript as
a lower citizen language and wanted to do frontend stuff without having to
learn javascript - and jQuery allowed just that.

For (the few) javascript lovers, jQuery main advantage was to be a big
decorator, not extending any native, which guaranteed there will be no
conflict with other libraries when adding jQuery in a page (quite ironic, when
you see how all libraries expect jQuery may be present in the page, nowadays).

------
all_the_things
I gave it a try a few weeks ago but every other package was unsupported
because a new package was being developed rather than following semver, the
standard server logging was terrible when I had to debug a frontend dev's
memory issue. Seems like the Wordpress of realtime applications. The DDP
package is interesting but only helpful to supported DB's as far as I could
see. I think choosing GraphQL will just narrow their 'full stack ecosystem'
again. Why not provide better low level support for your community to write
GraphQL Cypher, SQL and NoSQL themselves. There are some great packages I've
seen for this.

------
khwhahn
I'm sure that Angular 2 would be a better choice for a Ecosystem like Meteor.
React is very nice, but annoying to find tutorials, get a decent size app
going (routing etc) and Angular 2 is more mature (all the good and bad points
of NG1 and other js-libs were considered). Next to Google also Microsoft is
betting on Angular 2 (TypeScript). This will boost the community greatly. NG1
was slow. NG2 is amazingly fast (webworkers/server side rendering). So for a
Meteor Use Case I would pick NG2. If I wanna build a simple Snippet I would
use React.

------
MrBlue
Is Blaze vs React really the issue?

Try running a Meteor app with >500 concurrent connections.

~~~
sergiotapia
Let's say hypothetically I have 600 concurrent users, what steps can a Meteor
dev take to increase performance?

~~~
vskarine
Most meteor apps are stateless on the server so you can safely scale by adding
more servers (and more server to Mongo if that's the bottleneck). This can be
easily done with Cluster package
([https://github.com/meteorhacks/cluster](https://github.com/meteorhacks/cluster)).
It's so easy you don't even need to configure anything.

~~~
sergiotapia
I'll think it's easier (maybe more expensive) to just use Galaxy, and scale.
Then host your Mongo database on Compose.io that also scales.

------
pedalpete
I just started with Meteor a few weeks ago, and thought it was absolutely
amazing as a prototyping tool. I figured I'd be recommending it to anybody
doing an MVP.

I actually do believe there is a business model there, but it seems they are
focused on the high-end with hosting and support starting at $500/month

------
jbhatab
This is fantastic. This removes efforts to maintain a random front end view
layer while legitimizing the numerous react integration attempts. This will
save a lot of time moving forward to phase out blaze.

------
malloryerik
Can anyone here compare Meteor with a full Clojure(Script) stack?

------
sergiotapia
My thoughts: Meteor got popular enough that the Javascript loons started
pecking at it and infesting it with the general lunacy that accompanies NPM
and it's ecosystem.

MDG adding easy React support was a definite win and I think using Meteor with
React is -the- way to write Meteor apps. But they need to start ignoring the
crazies out there and focus on their vision.

