
Why Meteor - sgdesign
http://www.meteorpedia.com/read/Why_Meteor
======
woah
I tried some stuff with Meteor a while back. I was very excited about the
concept and really felt on board with the 'new way to write apps' stuff. It is
pretty cool, but I was trying to implement a site where people could post
stories and have an author badge appear on the page.

This requires joins. Mongo doesn't have joins, and Meteor doesn't even have
fake joins, like Mongoose's 'populate'. There has been a lot written in the
Meteor community about faking joins, as it is a persistent problem. First, I
tried template helpers, but these are impossible to put into a nested
template.

I looked at 5 different open source packages for serverside fake joins, but
ended up doing a clientside solution (to get a feel for the 'basic' way to do
things). This solution involved several functions on the clientside router,
that would be called several times, with different data available each time.
It is a convoluted thing to do, no matter the method.

Another thing I tried to do was purely clientside databinding, to populate the
author badge in real time as the user fills a form. It's trivial to bind data
to the database and have that update in realtime, but I wanted to hold off
saving anything until the user hit the save button. Again, a simple task got
weird. I ended up using an un-synced database collection, then saving to an
identical, but synced collection.

I'm not writing off Meteor completely, but I ended up moving away from it.
Node.js and a solid frontend framework have slightly more boilerplate, but are
generally very flexible for whatever it is you want to do. In retrospect, one
of the best things about Meteor is the one-line auth setup. This is usually a
big pain, and it was nice to have it be so easy.

~~~
notastartup
Along with my team, we built an enterprise app with meteor.js. Huge waste of
resources.

I almost find that the single biggest barrier to fully investing in is
Mongodb. The queries are hideous. But Meteor is heavily invested in Mongodb
and I'm afraid this is what will kill it.

~~~
Tarang
Meteor recently acquired FathomDB. Additionally SQL is on the cards too
([http://roadmap.meteor.com](http://roadmap.meteor.com)) they're not exactly
heavily invested in MongoDB. If anything it looks like they're giving users
the choice of what to use.

~~~
spyder
SQL is on the to-do cards since "Nov 2, 2012" ... and lot of the comments are
requesting it as critical feature

~~~
notastartup
If you've used other db like OrientDB, you can use SQL to query documents.
Even if MongoDB added this I wouldn't rely on it, as there have been many
deployments that couldn't scale properly due to MongoDB and ended up switching
to another vendor. It already has the reputation of being snake oil salesman
of the DB world.

------
TheAceOfHearts
Every time I see a framework like this I ask myself: if I outgrew this, how
difficult would it be to migrate away from it?

I'd love to hear if anyone has used meteor for something read and if they've
had to deal with migrating to something else: how they've done it, and what
issues they encountered.

For example, I love angular, but migrating away from angular after using it
for one year would doubtless be a very painful process.

~~~
KaoruAoiShiho
I moved from meteor to an angular+pusher solution. I rewrote the entire thing
in about 3 weeks. Almost nothing was reusable.

The app is [http://anonquest.com/](http://anonquest.com/) It's a realtime
story writing community. Be happy to answer questions.

~~~
general_failure
Angular 2 changes everything

------
davedx
This "production ready" "specially for beginners" marketing about Meteor
really needs to stop. They completely changed the API from under my feet, that
is NOT production ready (nor for beginners, I would argue).

Stay away from Meteor until they hit 1.0, unless you're ready for pain.

~~~
primigenus
Could you elaborate on specifically which changes you weren't happy with? Just
curious to hear what made things harder for you.

------
shubhamjain
I just don't get this meteor.js fad. Its not even a production ready framework
and yet I am seeing webapps being designed using it, meetups being held about
it and blogs being written about it as if it is a breakthrough in programming
web. I feel people should cool down and think it through if its architecture
is even worth having or not.

~~~
notastartup
same with node.js I fail to understand why someone would want to deal with
javascript callback chains on the server side to build simple websites. Even
some clients are convinced that somehow their application will run faster.

Even front-end frameworks like Backbone.js doesn't make sense to me. I still
find using jQuery more than adequate.

~~~
general_failure
So what do you use to build simple websites on the backend?

There are bad programmers and bad programming practices for every language. If
you see code that has 5 levels of nested callback chains, it's only because
people don't know how to write code. Have you see chromium code? It's filled
with callback in c++. All this is nothing new.

~~~
notastartup
Interesting, so what do you use to avoid nested callback chains? Use a
workaround library? This just seems like brute force. I don't think you are
required to use asynchronous callbacks in C++ to do anything, while in Node.js
you are almost guaranteed to doing this.

Why would you write a CRUD app using Node.js when you can accomplish this in
multitude of other well established methods? LAMP, Java, Python etc.

Nothing wrong with experimenting but for real world needs, there's no clear
answer as to why you would need Node.js to redo what you used to do.

------
imslavko
Note that this is posted on the community wiki site hosted by one of the
community members. The application running wiki is open-source:
[https://github.com/meteorpedia/wiki](https://github.com/meteorpedia/wiki)

~~~
btipling
Yep, I wrote most of it way back in the day and then someone else took up the
reigns, I don't think it's been updated in a long time. It's definitely not
0.9.4 compatible at this point.

I'm working on an alternative template engine for Meteor now based on django.
Currently in a big branch that's moving slow since I'm pretty busy at my
regular job.

[https://github.com/btipling/djanglets](https://github.com/btipling/djanglets)

~~~
Tarang
I tried to update it/send a PR but there are a lot of packages in there that
are missing so its very difficult to do.

------
greggdourg
We've been using our Meteor-based, multi-tenant CRM/talent-management app in
production for several months now. It's called Exartu and is open source
hosted on github.

We originally wrote the app using sql and signalR and as we've done with many
of company's (Tempworks Software) products, but we switched in no small part
for the real-time reactivity offered natively in Meteor and the productivity
gains from its packaging system.

At one point we used Knockout for all our binding but switched when Meteor's
Blaze matured. The speed and simplicity of the templating engine coupled with
the fact that js is used both client and server side reduces the learning
curve as we add devs to the project.

Contrary to many comments here, I've really enjoyed using mongodb and find it
fast and eminently suitable for a problem domain like CRM that is constantly
in transition.

Our biggest problem with Meteor was that as a new platform there were no
enterprise level apps to model after. We made the app open source
(github->Exartu) in hopes to change that, and we welcome critiques to it.

------
leke
The appealing parts of Meteor is a built in security against common web
insecurities.

The unappealing part of Meteor is having to learn Mongo. Ok, this part is just
me being too comfortable with SQL relational table databases, and being too
lazy to take the time to learn the alternatives.

~~~
weego
The most unappealing part about any framework that claims to get you 90% there
is that the 10% left is always loads of painful bullshit trying to wedge what
you need into a, usually overly opinionated, overly rigid "the framework way"
pattern.

Don't get me wrong, these things are fantastic for MVP/prototyping but nothing
that claims to be one size fits all comes without hidden debt.

~~~
notastartup
I agree with you 100%. This is why I began just vouching for micro-frameworks.
Even that comes with hidden debt in the form of plugins or modules written by
it's communities but it's a step above the 'write a shopping cart website in 5
minutes' type of framework.

I'm very happy with Flask because it complete gets out of the way, it's up to
you to deal with pesistence, models. You choose your own sins type of
approach.

------
andremendes

      *By using browser storage instead of hijackable session cookies, CSRF attacks are impossible.*

Cool, but it makes way harder to scale up without websockets support for load
balancing, since it uses SockJS, which requires sticky sessions.

~~~
swartkrans
It's totally possible to load balance websockets. You turn the web sockets
into a dumb proxy that talks to your service. You could have a bunch of SockJS
servers, with people connecting to different ones communicate with each other
over the actual service. If you were building chat rooms you could assign
rooms to specific servers, or you could tailor your service such that it works
across a distributed system.

~~~
andremendes
It's possible but what I meant (and failed to make clear) is that we can't
actually avoid using cookies and scale up, since websockets connections aren't
widely allowed on devices, calling for SockJS use and therefore, cookies
adoption.

~~~
swartkrans
> websockets connections aren't widely allowed on devices

Like what devices don't allow websockets? Android chrome, Mobile Safari and
Desktop Chrome and Firefox do and that's like almost everyone right there.

~~~
andremendes
They aren't the ones who block it. Instead it's the infrastructure providers
who do it. Cloudfare started supporting it only a few months ago. Many ISP's
use proxies that disallows websockets connections.

Again, the point is: You can't claim you won't need cookies if you want to
consider scaling up.

------
vuldin
What if I just wanted to use Meteor for the same reason as what I currently
use something like Firebase for? I'd like to combine this tool with React/Flux
for the single purpose of server-side database functionality... not the entire
kitchen sink. The closest thing I've found to showing how this could be done
is Pete Hunt's react-meteor-preso project: [https://github.com/petehunt/react-
meteor-preso](https://github.com/petehunt/react-meteor-preso). This doesn't
include Flex functionality, but it looks like a good start. It'd be awesome to
have some more examples of this.

~~~
pscanf
Take a look at
[https://github.com/mondora/asteroid](https://github.com/mondora/asteroid)
(I'm the main developer behind it). It exactly lets you use meteor as a self-
hosted firebase.

~~~
vuldin
This is exactly what I was looking for, now to see if it is as good as it
sounds. Thanks! I'll be watching and trying it out.

------
adam74
One thing that scares me about meteor is performance and scalability. I'm
afraid that if I build an app that takes off, I won't be able to afford the
servers to keep the app running.

------
lingoberry
I'm using Meteor and React for a side project, and compared to a previous
project where I used Backbone and node.js it really is a 10x productivity
boost. Since this is a side project I can spend at most an hour a day on, it
really is the difference between being able to finish or not.

------
drewblaisdell
From the Tinder clone blog post linked in the first paragraph:

 _The days of natively developing apps in Java and Objective-C have an
apparent end in sight._

I love Node.js and Javascript. I wish this was true, but I can't bring myself
to believe it yet.

~~~
BuckRogers
It's not. And, native apps are likely going to make even more ground. I
realize this runs against popular opinion, that webapps are some sort of
inevitable future to replace native apps almost in their entirety, but we will
see.

~~~
notastartup
You make a very good contrarian view and I agree.

I'm just realizing that we may not be innovating as we think we'd like.
Basically, we found a way to force the browser to act like native desktop apps
but without the security and power of native apps. In the process, generating
a great amount of technical barrier and debt. Businesses will still use a java
swing desktop app if they paid millions for it in the 90s. We'll still work on
desktop IDE's to code our stuff.

Another discussion here would be how "mobile" is going to replace desktop
apps. This is simply not true. Lot of important work goes on with a mouse and
keyboard behind a monitor. I just don't buy reinventing the wheel. Sure it
works for activities centered around the mobile phone mainly communication
applications and social apps but i don't see how it can cause disruption.

I have a feeling one of these days, we'll see a major correction in how we
perceive our point in time as being the best possible state and we'll see more
or less the return of old ideas, the true and tested technologies get more
attention they truly deserve.

~~~
uptownJimmy
Good point, valid opinion, etc. But incorrect, I think. I think it's more
likely that we are going to see most metropolitan areas in the US finally get
world-class data/communications infrastructure installed. It's starting to
build momentum now, really. And then there will be no going back. You will
then be unable to convince the vast majority of enterprise users that they
should pay for proprietary Java + server installations when they can get
radically better functionality and useability from client-side technology, and
at a VERY steep discount. I really think the only thing currently preventing a
tidal wave of JavaScript dominance in enterprise is the (weird) reality that
the US is still so retrograde on high-speed internet.

~~~
notastartup
I don't think it has anything to do with the speed of the internet, rather you
won't see large companies who paid millions for infrastructure built on Oracle
or SAP come off it anytime soon. The people that spend this much on money
won't be sold on the wonders of Javascript, that's not how they make their
purchase decisions.

------
chaostheory
I really really want to use this one day, but it really depends on the answer
to this perennial question: When is RDBMS support actually coming?

------
chestnut-tree
The linked site won't display anything with Javascript disabled. Yet, when
Javascript is enabled, we don't get a "web app", all we get is a page of text
that could easily be coded in HTML and CSS. Presumably, building this site in
meteor makes things easier for the developer. Does it make things easy for all
users of the site? Look at the source code of the page after it's loaded.

    
    
        ...
        <body>
    
        </body>
      </html>
    

What would a screen reader user hear? Is this site accessible? Does anyone
really care?

Do sites like this point to a future where more and more web sites (not web
apps) are built with Javascript frameworks? Is this a good thing? And can
these sites acommodate all users? (Assuming they want to.)

~~~
toxicFork
I try to approach things differently: why do people disable javascript? Is it
because of security? There are ways to disable javascript only from third
parties, for example, or disable certain functions (e.g. prevent alerts
(natively in Chrome, or browsers extensions).

Screen readers should be able to get the current state of the page, and not
read from the 'source'.

I can see some advantages of using javascript e.g. less load for the server to
render things, it just becomes a directory host.

~~~
skratlo
So when would you trigger the screen reader? When there is "enough content"
rendered by JS? For sure not the way to go. Just dump Meteor, use React, there
at least you can truly reuse the code and have it render server side.

