
Ask HN: Thoughts on Meteor.js? - karlcoelho1
I recently read a lot about Meteor.js and its excellent packaging system. I went through their site also, but not my info give a holistic view on it. Do you think it&#x27;s worth learning?
======
harrylove
I've been using Meteor in paid gigs for over a year now. I don't regret giving
it a try. It was hard to get my mind around for a few weeks. But then it
clicked and I saw a lot of possibilities. I've never been happier as a
developer. But that's me. It fits me.

I started using Rails in professional work in late 2005. That turned out to be
a good decision. There is hype around Meteor in the same way there was hype
around Rails in 2004/2005\. The praise and objections are similar. Meteor is
not Rails, so don't go looking for too many parallels. And the development
climate in 2013 is not the same as 2005. You won't be able to predict Meteor's
success or failure in five years, so it's not worth speculating.

When Rails came out, I was ready for it, technically speaking. My skills were
in the right place and I was ready for a change. Similarly, I felt I was in a
good spot to learn Meteor last year.

So the real question is, are you excited, ready, and able to learn it? If so,
go for it. The worst that will happen is you will learn a new programming
paradigm (perhaps) and it will inform any other development work you do.

~~~
dannytatom
Where are you finding paid gigs for it? I'm a freelance rails dev right now
doing meteor stuff on the side and wouldn't mind doing some real work with it.

------
tobinharris
I'd recommend writing a few sample apps just to get a peek in to the
awesomeness of where web technology could be going. It's hugely different to
the Rails, .NET and Node stuff I've worked with to date.

Meteor buzzed me out - the auto-updating views, syncing data across client &
server. Your app can achieve amazing real-time capabilities with very little
code.

But now I'm a few thousand LOC into an application, admittedly I've pretty
much hit the "wall". The magic baffles me. I'm struggling to solve problems in
performance, code organisation and security.

I've been disappointed by the progress and the team behind it. All that
funding and I can't see it progressing quickly. The docs are quite weak,
there's not many example apps, progress seems slow.

So... on one hand it's awesome and well worth learning. But I'm reluctant to
back it for the long term, as I don't see the team/framework moving in the
right direction.

T

~~~
emily37
Core dev here -- I've been doing some work here and there on framework
security and I'd love to talk about the security problems you're running into,
if you wouldn't mind shooting me an email sometime.

------
jasoncrawford
I wrote about Meteor here: [http://blog.jasoncrawford.org/meteor-
demystified](http://blog.jasoncrawford.org/meteor-demystified)

Bottom line: Very interesting platform; nicely done in many ways; some
concerns about architectural choices; not quite ready for prime time
(production use) but probably will be soon.

------
ollymorgs
My biggest issue with all of the frameworks is their lack of maturity. If
you're working on a large platform with a team of people, you're going to want
database migrations, localisation/i18n, asset management, proper testing
framework, continuous integration and general proof of scale.

Meteor.js seems great but is still a bit of a gimmick in my eyes. But If I'm
pressed to pick one, I have to say I'm much more interested to see what
happens with Go and web frameworks like martini.

------
lampe3
I want to clear some things:

0\. Meteor is in version 0.6.6.4 so there are things not as good as they
could/will be.

1\. scaling: meteor is 100% scalable. There are meteor smartcollections which
use the MongoDB optlog. Nice read: [http://meteorhacks.com/lets-scale-
meteor.html](http://meteorhacks.com/lets-scale-meteor.html) .

2\. Right now you have to stick to MongoDB this will change in a later
version.

3\. Meteor will get a new rendering engine which will allow you to put
angularjs( god only knows why ) or haml or some other templating thingy in
meteor.

4\. You can use meteor with phonegap right now.

Will meteor solve all your problems? No!

Will meteor will make you not think? No!

It's a great new piece of technology and you will learn new pattern and
things. the livedata package and ddp package are great packages on their own.

~~~
aaronblohowiak
Using the oplog of a single mongodb server limits you to the write capacity of
one server. This is not scalable at all in the use of scalable that means more
machines== more throughput.

~~~
lampe3
have you read the article ?

~~~
aaronblohowiak
Yes it lets you add multiple meteor servers not multiple mongo servers

------
ezequiel-garzon
... or Derby [1]. I'm curious about things the HN crowd has been building with
this kind of stack.

[1] [http://derbyjs.com](http://derbyjs.com)

------
camus2
> Do you think it's worth learning?

Everything(almost) is worth learning , the question is , is it worth using ?
you give 0 clue as to why you'd need that stuff.

~~~
ancarda
+1 for this point. In the end, you've only spent time if you learn a
technology that you end up not using. Meteor.js might teach you lots about
modern web apps. That knowledge will be transferrable, even if you don't end
up working on web apps.

------
christian_fei
Reading 'Discover Meteor' and consulting the docs will give you all you need
to create a great realtime application in short time. It's a real pleasure to
work with Meteor and the realtime web feels just a few steps away.

I built [http://opentalk.me](http://opentalk.me) with it

~~~
ocfx
+1 for this book. Super straightforward and easy to follow.

------
Tarang
Its lots of fun learning with it. It tries to remove as much boilerplate as
possible.

They have packages to take care of most of the stuff for you such as their
accounts-ui package.

One helpful place to learn meteor from beginner to advanced is via the
screencasts on.

[http://EventedMind.com](http://EventedMind.com)

------
arunoda
Of Course Yes. Just spend few hours with DiscoverMeteor[0] book. You'll be
amazed.

[0] - [http://www.discovermeteor.com/](http://www.discovermeteor.com/)

~~~
dpmehta02
I would work through a short Meteor tutorial before buying the book. The
following is an excellent working intro:
[http://www.smashingmagazine.com/2013/06/13/build-
app-45-minu...](http://www.smashingmagazine.com/2013/06/13/build-
app-45-minutes-meteor/)

~~~
arunoda
Yes. Go ahead with that. Author is the same. But I highly suggest to follow
the book, since it talk to the point and saves a lot of time.

------
gerrys0
Our company has doubled down on Meteor. We start all greenfield apps in meteor
now.

The biggest negative is simply the immaturity of the ecosystem. Everyone has
different standards. There are no de facto standard packages (yet). Everything
is changing rapidly. What worked well last week may not work well this week.
The bleeding edge truly bleeds.

From a pure technology perspective, I'm excited about meteor because (to use a
cliché) it shifts the paradigm. I wouldn't compare it to
Rails/Ember/Backbone/etc because meteor is full-stack. There is no
client/server. There's no ajax. Everything is one codebase. Even though it's
built on top of node, it doesn't even feel like node because of the reasons
above, and most of meteor is synchronous.

We wrote a couple blog posts about making the jump to meteor. I think the 1st
one directly answers your question. The 2nd caused quite a stir here on HN.

[http://differential.io/blog/the-current-challenges-of-
buildi...](http://differential.io/blog/the-current-challenges-of-building-a-
meteor-app)

[http://differential.io/blog/meteor-killin-
rails](http://differential.io/blog/meteor-killin-rails)

------
hannibalhorn
I looked at it pretty heavily about 6 months ago (version 0.6.3 I think), so
things have certainly changed some, but my thoughts were:

\- It's nice that it comes with pretty much all the grunt work done, out of
the box (asset packaging, live reload, deployment bundles, even the database!)

\- It reminds me of early Rails, as it is still in a bit of a "hacky" phase.
The level of commenting in the code is very low, there's TODO's everywhere,
lots of things are shoved into the global namespace, etc. This is a sharp
contrast with Angular or Ember, which have codebases I'd be proud to have my
name on.

\- The template binding is done in a simple-yet-effective way, which works
without being too complicated but if your data isn't just a simple key/value
map you'll need to learn a bit about it.

\- Perhaps due to the simple binding, it's possible to use legacy code (e.g.,
jQuery plugins) in a lot of places where it would be tricky with
Angular/Ember.

\- It's very opinionated and you certainly wouldn't want to stray from the
"happy path" of what's included in the stack (e.g., mongodb.) This was pretty
much a deal killer for my app, though every case is different.

------
Sewdn
Yes, it's worth learning.

3 good reasons why:

1\. It's ambitious.

Meteor is not yet another nodeJS web-framework or client side JS framework. It
also doesn't stop at combining the both (with a beautiful DDP to share data
between C/S). Meteor' s architecture will make it possible to use it's
components for all sorts of applications (other then the obvious web-apps).

2\. It's as easy or as complex as you want it to be.

You can write a meteor app in 4 files or in a complex packaged structure. No
need to overcomplexify, if you dont't want to. But you cán write large,
complex, stable and maintainable code.

3\. It embraces the eco-system.

You can rely on all of the NPM packages out there for your serverside logic
and use all of the available frontend UI libraries and scripts. It will also
enable writing complete reusable components in 1 package: servers-side logic,
data-model, client-side logic, UI, ... all in one.

Biggest upcoming updates:

* Meteor UI. Better approach then any other UI framework out there (including Facebook's react or FTLab's fruitmachine)

* Galaxy. Deploy and scale your app on your own infrastructure or in the cloud by pressing a few buttons.

To counter a few of the cons in this thread:

* It's not reached 1.0 and it is therefor not production ready. I'd suggest writing your new applications in meteor anyway. Meteor matures quicker then any other framework out there. Is is well funded and here to stay.

* It is not scalable. Maybe not easy right now to make it scalable. But it certainly will be soon, when using mongodb oplog and galaxy will make it really easy to scale your service.

I run an agency in Belgium (redandivory.com) and we switched completely to
meteor for all of our new projects. I think it's the framework of the near
future.

~~~
KaoruAoiShiho
>* Meteor UI. Better approach then any other UI framework out there (including
Facebook's react or FTLab's fruitmachine)

Why is it better? I've used Meteor UI and it blows (so far). I'm interested in
knowing why the new one will be better than react or say angular.

------
bhurlow
Meteor is one of the most comprehensive and smooth frameworks for making web
applications available today. It solves a ton of problems with a few
overarching concepts:
[http://docs.meteor.com/#sevenprinciples](http://docs.meteor.com/#sevenprinciples)

------
possibilistic
How well does Meteor scale? Could a multiplayer game written with Meteor
handle the HN crowd hitting it? I'm thinking of writing something like this
and Meteor would be perfect if it's amenable to authoritatively sharing state
between thousands of connections.

------
jorganisak
If you are familiar with front-end JS frameworks like Backbone/Ember/Angular,
then learning Meteor is as simple as a read through the docs and building a
sample app.

If not, then learning Meteor would be a great way to become familiar with JS
frameworks, and make the move to more complex frameworks (Angular FTW!) in the
future.

Either way, awesome tool!

------
mmgutz
As a developer I think "Wow, impressive". They have serious creativity and
brainpower on that team. But, as a developer I also think how much magic must
be going on there. I've always been a lightweight framework kind of guy
Sinatra over Rails, Backbone over Angular. I'm not their target.

------
enay
I use Meteor for a dashboard app and this seems to be the ideal use case for
this stack: take JSON documents via third-party APIs, aggregate them (hence
MongoDB is fine for the job) and push to clients.

Was it worth learning? I'd say yes, it has a low barrier to entry and is great
for practicing front-end development.

------
napoleond
Meteor is good, but not at everything, so it's very important to understand
the trade-offs.

 _Pros:_

0\. Obviously, its major strength is its "real-time"[0] nature: I have built
multiple chat systems (and presumably so has anyone else who's used Meteor,
because it's an example of something that's fun and easy with Meteor but
relatively hard with a traditional stack) as well as a map application that
tracked the motion of a company's employees in relation to their destination
(as part of a dispatching system).

1\. It's also the least complicated way of sharing code between the browser
and the server that I've seen to date.

 _Cons:_

0\. It's non-npm package manager feels like NIH to me (although I'm sure the
team had valid reasons, I've never looked into it). Apparently it's still
possible to require npm modules[1], although I've never tried it.

1\. You're more or less stuck with MongoDB for the time being, which I guess a
lot of people like but it's not really my thing.

2\. There's not really any SEO capability, but that's sort of a given. Just
don't use Javascript frameworks for that sort of project (or do, and do all
sorts of weird shit to help Google).

3\. It's kind of too auto-magic for me sometimes. The documentation is
generally very good, but I occasionally run into weird variable scoping issues
and the like, without any way of really figuring out what's happening. Of
course, the source code is available[2] if I had time to read it. (Well-
written, but big, and I find reading Node code to be mentally more taxing
because of all the callbacks.)

4\. The biggest con, for me, is that Meteor is basically limited to web
applications. I really enjoy the typical single-page web app approach of
building an API first, which you can access from other apps later (ie.
mobile/tablet). I have no idea how I'd do that with Meteor. I'm experimenting
with bundling a Meteor project and inserting the client-side code into a
Phonegap app, for a mobile chat thing I'm working on, but that's obviously not
ideal.

Generally, I love working with Meteor. I know I've written more cons than
pros, but the pros I've listed are _huge_ , and they've allowed me to work on
cool stuff. You just need to know what you're getting into.

 _Footnotes /Links:_

0\. The scare quotes are for the people familiar with embedded real-time
systems who seem to always find these comments and complain about how that
word has an entirely different meaning when it comes to web applications.

1\. [http://stackoverflow.com/questions/10165978/how-do-we-or-
can...](http://stackoverflow.com/questions/10165978/how-do-we-or-can-we-use-
node-modules-via-npm-with-meteor)

2\. [https://github.com/meteor/meteor](https://github.com/meteor/meteor)

~~~
debergalis
[core dev] If you like to think about your application starting with its API,
I think you'll really like learning more about DDP [1], the websocket JSON-
based protocol that Meteor clients and servers speak. This is one of my
favorite parts of the stack.

Rich clients built against a REST API tend to need some sort of client-side
cache so that clients can avoid repeated RTTs back to the server for data, and
thus some sort of websocket-based invalidation system so that the server can
push fresh data into that cache in real time. That's doable, but a total
bummer for interoperability and shared tooling. Since the implementation of
those things is usually custom to each app, it's rare to see one real-time app
connected to another the way we can bolt server-based REST apps together. And
there's no `curl` for this kind of endpoint.

DDP is actually quite simple. The spec is just a couple pages of markdown. It
lets servers publish changing data sets to the client and it implements once-
and-only-once remote procedure invocation. It runs over a websocket or over
SockJS. Eventually we'll also define a binary TCP/TLS mapping for use between
servers.

When you write `Meteor.publish` in a Meteor server, you're defining a real-
time DDP endpoint, like a streaming version of GET. The server makes the
common cases easy -- publishing a realtime MongoDB query to a client is a one-
line function in Meteor -- but you also have access to the low-level DDP
messages if you want to do something more advanced like publishing the output
of a GPS sensor or a stock ticker.

There aren't any special bindings between Meteor clients and servers, just the
standard DDP messages that go back and forth. So you can implement either side
of the wire using something else. And there are some third-party
implementations of both the client and server in the field now. You can write
a Meteor front-end against a Java DDP backend. You can connect a native iPhone
app to a Meteor backend. Or you can have two Meteor server processes, one
subscribed to the other. (There's been discussion of all these cases on the
mailing lists. We use server-to-server DDP heavily in Galaxy, the hosting
product we're working on.)

[1]
[https://github.com/meteor/meteor/blob/devel/packages/livedat...](https://github.com/meteor/meteor/blob/devel/packages/livedata/DDP.md)

~~~
napoleond
Very cool! I had seen the DDP notes in your repo when Meteor was first
announced, but wasn't sure how established that protocol was, and how closely
Meteor intended to follow it (I didn't realise it came from the Meteor team).
Sounds like it's time to take another look :)

------
jbuzbee
I've played with meteor a bit and and also hacked on drorm's mysql back-end:

[https://github.com/drorm/meteor-sql](https://github.com/drorm/meteor-sql)

It works for some cases, but it quite limited in the type of database tables
it will support. And in the end it's polling mysql for changes to feed to
meteor clients.

I also added meteor support to a leaflet-draw package to allow users to share
drawing on a map:

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

Powerful and fun!

------
seniorsassycat
I have dabbled in it. I found it hard to learn and mysterious, but when things
work it is amazing.

Meteor is a combination of handlebars, jquery, mongo, sockets, and a handful
of other technologies. It can be hard to debug or develop unless you are
familiar with those technologies. I think meteor would benefit from more
transparency, make it clear which frameworks provide which features.

You will find more applicable documentation by searching "Handlebars
Templates" instead of "Meteor Templates".

------
wavesounds
It's really great technology and a lot of fun to program in! My only problem
with it is its so closely tied to Mongo. There are ways around this already I
believe. However official SQL support is coming soon, which I'm very excited
about.

If real time collaboration is at the core of your web app, then you'll love
Meteor.js.

------
albiabia
If you're looking for an alternative thats much more versatile and less
opinionated I would recommend Sails.js
[http://sailsjs.org/](http://sailsjs.org/) which is basically Rails for JS
based on Express.

------
reustle
As other have hinted at, it's definitely worth learning, like most things. Get
roughly familiar with it and other projects, that way when it comes time to
pick a tool for a project, you'll have a better set of options to pick from.

------
leke
I would like it to be supported on my RaspberryPi, but it isn't (apparently),
so I don't use it. There are other nodey frameworks out there that just
require node itself, so I'm looking at those for the moment.

~~~
imslavko
There is a project PiJS: [http://www.meteor.com/blog/2013/05/28/pijs-embedded-
raspberr...](http://www.meteor.com/blog/2013/05/28/pijs-embedded-raspberry-pi-
apps-in-javascript)?

------
filipedeschamps
I feel scared to how incredible this framework is. It's magic that scares me
the most.

~~~
tmikaeld
You and me both buddy.

------
igl
after reading some github issues and some source code... There is also sails,
and probably tons of other express/socker-io boilerplate frameworks. But
meteor has this facebook guy on the homepage. Your boss will love it.

~~~
arunoda
Nice :)

------
shire
What is the big difference between Meteor and Express?

~~~
d0m
Simply put, express is a server-side node library, Meteor is everything
possible. Server-side, client-side, database, different package system,
different philosophy.

------
tel
Can anyone compare it to Opa?

------
laughfactory
Hard as hell to learn, IMHO.

~~~
sgdesign
Really? Would be curious to know what makes you say that?

