
I like Meteor.js because I'm lazy - halisaurus
http://paul.molluzzo.com/i-like-meteor-js-because-im-lazy/
======
ilaksh
There is an unfortunate belief that any programming system which is
significantly easier to use must automatically have caveats that make it unfit
for 'production' use. And another similar belief that such systems are unfit
for use by 'real' engineers. For example, if AngularJS had come up with an
easier-to-understand way of creating components (directives) then it may have
been dismissed as just another tool for novices. But some aspects of AngularJS
are sufficiently complex that it is acceptable to 'real' engineers.

These are false beliefs and one of the reasons that (this is obviously an
estimate off the top of my head) about 95% of programmer time is wasted
solving problems that have already been solved numerous times. I see people
hinting at security or other concerns related to using Meteor in production,
but I have yet to see an example where one of these concerns actually caused a
production issue.

I would be very interested to hear if anyone had actually tested Meteor in
production, or had specific concerns related to security or anything that
leads them to the conclusion that they must come up with their own
different/more complex solutions to problems that Meteor solves.

Taking advantage of a system that solves 90% of your problems rather than
reinventing six wheels is not lazy. Its just sane and mature.

The psychology of programmers related to tools and frameworks is childlike.
Its as if everyone is in a playroom with a bunch of tiny blocks of different
shapes. Every once in awhile a kid figures out how to construct generally
useful connector shapes or recognizable objects from the smaller blocks. Then
when another kid wants to use the larger pre-composed structures to play with,
everyone makes fun of him because he is 'cheating' and must be too dumb to use
the tiny blocks.

~~~
eatmyshorts
I've used it on a production site. There still is a learning curve, as with
any new technology, but I've been very happy with it. I hope to do more with
it. I'm working on a CMS built with Meteor, as my clients tend to be less than
technically proficient.

The main problem I've had with it relates to IE7/IE8. The standard password
encryption results in a JS error on those browsers due to the password
encryption taking too long. We run the whole site on top of HTTPS, though, so
we took a little hack to remove the extra client-side encryption on IE7/IE8.
It's not ideal, but then again the default encryption for passwords is there
primarily for those that don't use HTTPS (passwords are sent over the wire
hashed such that HTTP sessions still maintain safety with the passwords...this
hashing is slow by design, and the IE7/8 javascript engine isn't good enough
to do it in a reasonable time frame).

------
muraiki
I've been learning programming for about a year and Meteor was the first
Javascript framework that I used. I found it remarkable how quickly and easily
I was able to get something up and running, given that I had relatively little
experience with Javascript (I read most but not all of Eloquent Javascript).

I used it to make an online multiplayer Go board where you can see your
opponent moving the pieces, for the purpose of teaching games:
[https://github.com/muraiki/senseinogoban](https://github.com/muraiki/senseinogoban)
Being able to make something like this as a beginning programmer was really
exciting! Since I'm pretty new to programming I don't know if the code is that
great but it might give some ideas to people who are interested in using
Meteor in a graphical way (as opposed to something like a To Do list).

------
rglover
I'm a big fan of Meteor. As a front-end dev that got his start in JavaScript
with jQuery, it's been really easy to settle into. I did a pre-release of a
Meteor app into production today
([https://properapp.com](https://properapp.com)) and it's running pretty well.

The latest dev shop outlines what's in store for the 1.0 release
([http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-
devsh...](http://www.meteor.com/blog/2013/10/01/geoff-schmidt-at-
devshop-8-getting-meteor-to-10)) and based on where they're at now, it's
exciting to think of what will be possible.

Definitely not a toy, though, and something that should be evaluated
carefully.

~~~
creamyhorror
I'm surprised that you're using Meteor for what would seem to be a single-user
use-case. Meteor's strength seems to be multi-user real-time apps, but this
looks more like a job for Angular/Ember plus an API backend.

I was looking toward Meteor for a similar project because of its handy client-
server syncing capability, but decided not to use it because it didn't seem to
suit the more traditional webpage model and the click-to-save-changes
paradigm. But your site is making me reconsider this. I've been learning and
implementing my site in Angular/Restangular, which involves me writing code to
POST to/GET from my Rails backend. I'm aiming to let users add and remove
nodes in a plan/document and rearrange their ordering - would that be easier
to do in Meteor? I'd love to make use of Meteor's object syncing and other
features. What's your experience been like? Did you try Angular or other JS
MV* frameworks?

By the way, I love your site's design and iconography. If you built the whole
service alone, I'd be very impressed.

~~~
rglover
Re: the choice for Meteor, this was somewhat of a fluke. I'm not a traditional
developer, and only dabbled with Rails and the like on an anecdotal basis. My
past experience with things like jQuery made it easy to pick up Meteor and its
basic concepts, so I just started building the app above (it's something I
really wanted/needed and I didn't want to waste a lot of time inner-bickering
about what tech to build it with).

I guess for your idea I'd have to see a sketch, but on the surface, yes, I'd
say something like that would be pretty easy. The cool thing about Meteor is
that it takes a lot of the thinking/logic out of the loop. So for example, you
would have the nodes as a Mongo collection and for each plan/doc, just store
their position info. Meteor/Mongo update automatically, so if say you used
something like jQuery UI drag/drop, you would just have it update the given
object in Mongo when you pick it up or put it down. Make sense?

My overall experience has been that I haven't gotten frustrated with Meteor
like I did with other frameworks. It's not as rigid, sure, but if you take the
time to develop a good design practice, it can be really efficient. Plus,
having both front and backend code in JS is a serious time saver.

Thanks for the complements on design. Save for the octopus, logo, and animated
gifs outlining the process (oh, and the nice header on the blog), this was a
100% solo effort.

------
nonchalance
Have you tried similar frameworks like Derby
([http://derbyjs.com/](http://derbyjs.com/))? If so, can you compare your
experiences?

~~~
hansgru
> Have you tried similar frameworks like Derby
> ([http://derbyjs.com/](http://derbyjs.com/))? If so, can you compare your
> experiences?

I tried Derby.js because of one important for me missing feature of Meteor:
serverside HTML rendering - required for search engines and also for CMS or
content like applications. IMO Derby.js got it right there.

Unfortunately Derby.js is seriously lacking professional documentation of any
kind: Meteor already has books and 2 very good and long enough video courses
(from pluralsight and tutsplus)

~~~
andersnolsen
Did you check out the meteor package "spiderable"? It might need to mature a
bit but it might do the trick

~~~
hansgru
> Did you check out the meteor package "spiderable"? It might need to mature a
> bit but it might do the trick

Of course I did :). It's not usable at all :). It's also not reducing the
initial loading time (very high for any public webpage).

------
wc-
It was fun developing the MVP for
[https://lawyermatch.me](https://lawyermatch.me) on top of Meteor. Would I
recommend meteor in its current form (v0.6.5 or so) for a large production
website? No, but neither do the core meteor devs. Would I use it again for a
quick prototype? Absolutely, especially if you are already planning to use
mongo, node, handlebars, or the other core meteor technologies.

I saw one of the core devs speak in Chicago a week or two ago, and the main
feeling I came away with was that the Meteor team has a well planned roadmap
of features, solid funding, and a plan for generating revenue, all of which
will hopefully mean Meteor isn't going anywhere.

Edit - I think this article hits on some of Meteor's strengths re: ease of
development, but some of the features Meteor uses to accomplish this turn into
gotchas later. For example, the autopublish and insecure packages are awesome
for a 5 minute demo but for anything further they should be removed. Without
them, devs are back to thinking about queries and what clients receive what
data, permissions, etc. These are very important things obviously but it might
be a little misleading for someone using Meteor for the first time.

------
prezjordan
Totally acceptable to use Meteor first because you don't want to "reinvent the
wheel" so to speak. It's fantastic for prototyping real-time concepts.

If your idea works, then you can "mature" your codebase a little. But, from
the get-go, you'll want to make something usable, to see if your idea works at
all. Meteor is perfect for that sort of thing.

~~~
ilaksh
If you build a working system with Meteor and then re-implement some or all of
it, doesn't that mean you are in fact re-inventing the wheel?

~~~
mercer
Maybe it's more like custom-building a wheel to the exact specifications that
you figured out when using a 'normal' wheel. Sometimes customization matters.

------
jumpman222
I really like Meteor too. It makes developing a sophisticated app incredibly
easy. Even though it is only in preview mode, it is extremely polished. I
can't wait to see what version 1.0 has in store!

------
joecarpenter
Interesting enough, I found that Meteor is not production ready, in both
current implementation (not mature) and some design decisions. I was thinking
about writing blog post about it, but no idea when I'll have time to do it, so
I decided to stop by.

I have experience with Meteor in production and had some serious performance-
related problems. Not that they're not solvable, but some solutions kill some
core design decisions of Meteor. Just in case - I didn't pick Meteor for the
project, I was asked to help with it.

Anyway, here's short list:

1\. Collection synchronization does not really work even for relatively small
amounts of data (say 10k records).

\- It does not make much sense to send few MB of initial data to the client.
Paging API was moved to some distant future and you end up writing REST-like
API on top of Meteor, which breaks idea of collection synchronization, which
contradicts statement on their website - "no need to write REST APIs anymore".
I don't say it is not usable at all, you just need to be really-really careful
about what you send to client and it is easy to fail at this.

\- SockJS (transport protocol used by Meteor) does not have rate-limiting
built-in. If client connects using one of the polling transports and payload
is too large to be received in 30 (? - vanilla SockJS uses 5) seconds, server
drops connection thinking that client timed out. Partially, it is SockJS
problem and partially it is Meteor problem, as Meteor will just send all
outgoing data without caring if client is on slow connection. But because of
previous point, generally it is bad idea to send large amount of data anyway.

\- Server-side subscription API is very limited. Official documentation has
following sample: reactively count number of admins in collection. This is
done by listening on collection changes and counting admins by incrementing
(when admin is added) and decrementing (when admin is removed) single
variable. If there are 10k admins in database, increment function will be
called 10k times.

2\. Minimongo is interesting concept, but fails on many levels:

\- It is MongoDB written in JS, but slow

\- Does not have indexes ("client won't handle amounts of data for indexes to
be viable"), aggregation, map reduce, etc. There's no official API to create
index on server-side either.

\- Its reactive - whenever model is changed, Meteor figures out which fields
were changed and broadcasts changes to all listeners. And this is _not_ fast.
Inserting 10k items to collection will take around 2 minutes on AWS large
instance with node executable using 100% CPU.

\- Because MongoDB is not "reactive", Meteor just polls collections every 5
seconds to see if they changed by outside application. I really hope it only
tracks addition/deletion of records and not scanning through all rows in
database during each polling iteration

\- Meteor API is hiding MongoDB handle, but there's a way to get it (through
hack) and use it directly. And it takes 3 seconds to insert same 10k items

3\. Client-side is not as convenient as current MV* frameworks

\- Meteor is using non-reactive templating engines and attempts to make them
reactive. And this might be performance bottleneck, especially on mobile
devices. When single variable changes, Meteor will re-render whole template.
If you have some 3rd party plugins (like WYSIWYG editor, which injects own DOM
markup), you have to wrap it with special blocks, which prevent Meteor from
re-rendering them.

\- As a result of previous point, DOM is not stable.

\- Unlike AngularJS/Ember/etc, Meteor does not track individual variables.
AngularJS does it by checking if variable changed in digest loop, Ember uses
property-like system, etc. Meteor has global, flat namespace called
"Meteor.session", where application stores _all_ reactive variables that can
be referenced by their name. `Meteor.session.set('mymodule.hello', 10)`. It is
hard to structure application, when core reactive part is just a singleton
dictionary.

\- Once you get used to bidirectional data binding between forms and models,
it is hard to get away with events. But that's minor.

4\. Overall architecture (nitpicking):

\- Meteor API likes singletons. `Meteor.session`, `Meteor.methods`,
`Meteor.templates`, etc. Single, flat namespaces everywhere

\- Even though code can be written in a way it can run on both client and
server, there are subtle core API differences. Like it is not possible to use
`HTTP.get` on the client without callback, but it works on the server, just
blocks the fiber. If you use callback on the server, you need to block the
fiber manually (using future or fiber API), etc.

\- No server-side templates. Yes, there's crawlable package for Meteor, but it
is just PhantomJS (WebKit) that runs on the server and renders pages for
crawlers. Yikes.

This pretty much sums my experience with Meteor.

~~~
chandika
I'm running a Meteor production app myself and found similar performance
bottlenecks.

However, the Meteor community has really done some great work in solving some
core issues and others are on the 1.0 roadmap.

Some comments on this below based on our own experience.

> 1\. Collection synchronization does not really work even for relatively
> small amounts of data (say 10k records).

The issues around polling and how the server side cursors/observe works is
definitely not perfect. Started using the SmartCollections package which
ditches polling altogether and goes with the MongoDB OPLOG for synchonization.
Has been performing well for us so far and solved many issues around
performance.

[https://github.com/arunoda/meteor-smart-
collections](https://github.com/arunoda/meteor-smart-collections)

>2\. Minimongo is interesting concept, but fails on many levels:

Really depends on the usecase. I'am not sure if there is any other alternative
to MiniMongo at the moment for other frameworks.

The key thing is you really shouldn't expect to do many MB's of client data
storage in your app.

>3\. Client-side is not as convenient as current MV* frameworks

The key issue here is the how the DOM is re-written with the current rendering
engine.

The new 'Meteor UI' rendering engine and component architecture is promising
to solve this issues with html element level reactive-rendering as well as an
method for proper UI components delivering similar capability to what Angular
offers.

\---

The framework is still growing up, but we are hard pressed to find something
that delivers similar developer productivity.

Once you understand the framework and IF it fits your needs, Meteor can work
well for production.

~~~
joecarpenter
> Started using the SmartCollections package which ditches polling altogether
> and goes with the MongoDB OPLOG for synchonization.

Yes, I'm aware about this package. However, in my case, I had to reactively
count number of items in collection. SmartCollections does not have `observe`
for server-side cursors and core Collection implementation is slow, so I
decided to use `setTimeout` to check collection size every few seconds, which
turned out to be much faster than generic collection implementation.

> The key thing is you really shouldn't expect to do many MB's of client data
> storage in your app.

True, it just contradicts point 003 on
[http://www.meteor.com/](http://www.meteor.com/)

Plus, I was also referring server-side. Application does not work with node.js
MongoDB driver, it still goes through thin minimongo layer, which hides most
of the driver API. And it is not fast either (due to reactivity) - see insert
performance example.

Overall, I don't say it is not possible to run Meteor app in production (I
have one). It is just there are alot of different quirks and gotchas in Meteor
that should be worked out manually or with help of community-created packages.
And all this information is mostly scattered around StackOverflow, Meteor
bugtracker or in Meteor source code itself.

It is quite unpleasant to stumble upon collection synchronization performance
when you have most of the application in place.

------
dpearce
We ([http://differential.io](http://differential.io)) have been using
Meteor.js almost exclusively since switching from rails about 5 or 6 months
ago and are very excited about where the framework is headed.

Obviously, it's still new and has some kinks but 1.0 is around the corner, and
we've found the ease of development is well worth the few issues we've had to
work around.

An example app: [http://assistant.io](http://assistant.io)

------
sgdesign
If you're curious, here's another example (open-source) Meteor app:
[http://telesc.pe](http://telesc.pe)

------
Herbert2
I was hoping some of meteor's users could answer a few questions about it.

Can meteor use Postgres instead of MongoDB? Could meteor do sync with the
database through a server-side rest client (instead of mongodb)? Is TDD
possible? Is CoffeeScript possible?

------
omarrr
Always amazes me how some posts like this one have zero comments in the blog
itself but a dozen in HN.

~~~
flylib
that's pretty common, HN threads usually get more comments then on the actual
site, comments on actual sites usually don't do that good at all

------
oddshocks
Stop it, JavaScript.

Stop it. Stop being used for application programming.

Stop.

~~~
collypops
Why?

~~~
sfjailbird
Because JavaScript sucks in a multitude of ways? I don't think anyone with
experience developing in a few different languages disputes this, nor do I
probably have to namedrop A-list developers who have renounced JavaScript for
large systems.

It used to be the only choice for cross-platform web applications, but with
cross-compilation emerging as a real alternative that is no longer true, so
the sentiment has merit, and it is a proper criticism of a framework that
relies entirely on writing everything in JS.

~~~
tete
I am sorry, but this sounds like you simply don't know the language.

Javascript has one big problem and that is that most people either know it
from front end people who are NOT really into programming and on the other
side there are many people that just don't know JavaScript and use it like
C-style languages, just because it might have some similarities with it.

That's actually a problem a lot of multi-paradigm, flexible, expressive and
powerful languages suffer. People want to use it like the language they mostly
used, get frustrated about how it's a different language and not just a
slightly different syntax.

So either you do it like Python and force people into something or you have to
deal with a lot of people, complaining about something they don't understand,
which simply is easy with JavaScript, because it has a lot of features.

I mostly blame it to the fact that most people learn Java and a certain style
of Java as their first language. It's actually saddening, because it causes
computer science to become more and more a "just good enough" thing. It's sad,
because it started with people (and with that I mean Ada Lovelace, just like
various scientists in nearly every decade of the last century) who did what
they did not because it was cool and well-paid to do computer stuff, have your
own startup, etc., but because they had enough enthusiasm and imagination to
make this possible. Lovelace in the 1th century(!) imagined that there could
one day be "calculating machines" used to draw paintings!

