
Why Meteor will kill Ruby on Rails - joshowens
http://differential.io/blog/meteor-killin-rails
======
bowlofpetunias
Why do people put so much effort in comparing tool A to tool B when either of
those tools only cover 5% of all the work that goes into any serious
application, and the time saved by any advantage tool A has over tool B is
pretty much negligible?

I mean cool, so Meteor is maybe better for prototyping. Because that's all
we're talking about here, prototypes and ultra-simple websites.

It's always the same story, a shiny new tools that make the first weeks a
little smoother, and after that it's business as usually for entire life cycle
of the application.

Except of course you now have to deal with a tool that still has years to go
before it's really mature and stable, and any advantage you gained in the
first few weeks is completely lost.

This has nothing to do with software development, this is just about fashion.

~~~
derefr
Making repeated prototypes (in est, _experiments_ ), quickly, is how you
approach entrepreneurialism in any sort of scientific manner. Nothing _needs_
to scale, or work at the edge-cases, until it has product-market fit; and you
might need to write twelve or twenty or two-hundred different apps until you
find one that works out that way.

That's what makes these frameworks popular with HN: startup founders are not
in the business of executing on a known business model (which might be viably
accomplished even through a waterfall process and code written in C); rather,
we're in the business of searching for a business model by building MVP after
MVP, as quickly as we can.

MVPs don't need to be able to be evolved into stable, well-engineered
products. They just need to prove product-market fit. Once you've got your
traction, your proof, your intent-to-buy, you can use that to get the loans or
capital, to hire the talent, to build the Well-Engineered Version. Until then,
"engineering" is not even a consideration.

~~~
nostrademons
That's all true, but I'm also beginning to wonder how much you actually need
those frameworks to build MVPs quickly.

I used to do the bulk of my prototyping with Python + Django + JQuery +
Postgres or AppEngine Datastore. Of late, I've switched a lot of it to just
straight HTML + Javascript + a JSON feed from backends. If I need server-side
computation, I'll build a quick Go or webapp2 app on AppEngine. I work just as
fast if not faster, and there is far less that can go wrong. I'm not
constrained by the idioms of the framework in development (this is a major
problem with MVPs - all Rails/Django apps seem to end up looking like a bunch
of forms over a database, even if that's not the best interface for users),
and if one of the approaches works, I have an easier time productionizing.

For my most recent prototype, I started with JQuery (as usual) and then
quickly end up removing it when I found that everything I used to use it for
is now built into the browser. $ = querySelectorAll; .on = addEventListener;
.addClass = .classList; .animate = CSS3; .ajax = iframes. And all of the
browser native stuff runs significantly faster, and doesn't require that you
download 90k of JS each time you want to refresh.

It's not 2006 any more. You can pretty much prototype in Webkit only, most of
the things you need are built into the platform, there are easy minimalist
libraries that will let you setup a JSON feed out of AppEngine with barely any
code, and JS on the client can do pretty much everything. At least until you
start caring about latency, but by then you're out of MVP range.

~~~
salimane
is there any small library ala "notjquery.js" that is a drop in replacement
for jquery but that calls the browser native stuff directly ? serious question
?

~~~
spamizbad
You probably want something like Zepto.js. I'd also look into Lo-dash, which
is a better, more functional-friendly version of Underscore.js that provides a
ton of useful helper functions.

Be warned: Zepto doesn't claim to support any version of IE, so if you need IE
support you'll want to fall back to jquery (yepnope works. Conditional HTML
won't in IE10+).

~~~
bgarbiak
Zepto has an IE10 branch:
[https://github.com/madrobby/zepto/tree/ie10](https://github.com/madrobby/zepto/tree/ie10)

------
bjourne
I'll make an even bolder claim: Meteor doesn't work at all for anything except
small toy apps.

Meteor is built on the idea of reactiveness between server and clients. That
is if the servers view of the data changes, then the clients views' must also
change at the same time. It accomplishes that using websockets and letting
each client have a full copy of all the servers data in memory. Works great
for simple chats and for highscore lists consisting of 10-20 items. Not so
great when there are 500k items ordered by score and someone wants to paginate
through all of them.

It's trivial in a sql-database backed application, but more or less impossible
with Meteor because you can't listen to arbitrary queries without having the
whole collection in the clients memory.

Btw, I'd love to be proven wrong though. I tried to write an equivalent of
phpMyAdmin for the Meteor+MongoDB combination, but I couldn't figure out how
to how to provide clients with an always updated view of mongo collections
without running them out of memory.

~~~
qiqing
Z-mongo-admin, the Meteor equivalent of phpMyAdmin, was a project that won a
prize at the Meteor hackathon earlier this year. [1] Here's one of its
authors, Geoffrey Vedernikoff, speaking at HackMIT. [2] Perhaps you could
compare notes with the team to see what's going wrong in your version.

[1] [http://www.meteor.com/blog/2013/07/09/congratulations-to-
the...](http://www.meteor.com/blog/2013/07/09/congratulations-to-the-meteor-
summer-hackathon-2013-teams)

[2] [http://www.meteor.com/blog/2013/10/11/meteor-at-hackmit-
onet...](http://www.meteor.com/blog/2013/10/11/meteor-at-hackmit-onetimebox-
codebox-pulse)

~~~
rafekett
I'm sure his project worked, too, it just didn't scale.

~~~
arocks
This is true. In the Q&A of this video [1], the creator of Z Mongo Admin
mentions that the browser will hang if the collections are huge.

[1]:
[https://www.youtube.com/watch?v=yeF_b8EQcK0](https://www.youtube.com/watch?v=yeF_b8EQcK0)

~~~
yefim
Speaking as the author of Z Mongo Admin, it's mainly because we haven't
implemented pagination yet. Can't be too hard to add {limit: 20} to the
queries though.

~~~
pa5tabear
So do you do you think Meteor can scale? I don't know if I'm following, but
I'm assuming limiting the queries(?) means limiting the size.

------
curveship
It concerns me that the selling points of Meteor are the same as the old
selling points of ASP.Net.

\- Both seek to make the divide between server and client "seamless",
marshaling data back and forth so that you can "call" server code from the
client and vice-versa.

\- Both tout the ability to do all your development in a single language

\- Both claim impressive gains for RAD

ASP.Net had some impressive demos for its time. But as we know, the warts
emerged:

\- as apps grew larger and more complicated, the claim of "seamless"
integration started to break down. The background traffic increased until the
latency became untenable. Now you had to diagnose problems in a system that
had been designed to be "invisible," meaning it was hostile to exploration.
Why will Meteor be different?

\- The "one language" (VB.Net for ASP.Net, before C# became big) wasn't so hot
a foundation. One word: Javascript.

\- It was an island. The background data-marshaling framework meant that it
didn't play well with other software unless that software had been explicitly
written/adapted to work with ASP.Net. ASP.Net wasn't bad at first, but the
vaster ecosystem of the web quickly distanced it. What's the upgrade path for
a Meteor app? What if I want to use Angular with it?

~~~
MichaelGG
ASP.NET enabled a lot of certain types of developers to quickly drag-n-drop
web apps just like they did with VB Windows GUIs. The amount of code needed
was pretty cool. Sure, it resulted in a less-than-ideal webpage, but it
worked. VB.NET wasn't really a foundation; it had major changes from VB6 and
had feature parity with C# (and more in some cases). Javascript is by far a
much worse language. What should we expect from a 10-day design?

If this guys is going off about how it shaves a week or so off a 5 week
project, problems that appear on bigger apps might not be high on his priority
list.

I wonder if Meteor will end up introducing security holes like ASP.NET, as
developers forget there's an abstraction and clients can't be trusted? (In
ASP.NET, things like being able to screw with viewstate or fire events for
disabled controls.)

I still have the hope for a unified platform. But I'd much prefer it to be on
a solid language that compiles down to JS. I'm not sure it's an unattainable
goal. I think you nailed it with "seamless" and "invisible" \- abstracting
major things like client versus server, or local versus network, can really
end up biting developers.

~~~
jaredsohn
>I wonder if Meteor will end up introducing security holes like ASP.NET, as
developers forget there's an abstraction and clients can't be trusted? (In
ASP.NET, things like being able to screw with viewstate or fire events for
disabled controls.)

This is a thing for Meteor already. For example, if you have the insecure
package enabled, you can can make changes directly to the database from the
browser console. However, this particular issue can easily be detected prior
to deploying to production.

~~~
joshowens
Insecure is there to help speed development when you are getting started.

All frameworks can do their best to compensate for security holes, but
ultimately people need to pay attention to it. That being said, Meteor offers
a call method and code runs on the server - if security is a concern then you
should pay attention to what happens on the server.

~~~
MichaelGG
I've not used Meteor. How exactly does "insecure" help speed development?
Certainly any code you write with it is worthless, right? I mean, before
production you need to remove it and rewrite it using another method, so
what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-
like data access console?

~~~
jaredsohn
From meteor.com:

>By default, a new Meteor app includes the autopublish and insecure packages,
which together mimic the effect of each client having full read/write access
to the server's database. These are useful prototyping tools, but typically
not appropriate for production applications. When you're ready, just remove
the packages.

------
lambda
While I was reading this post, the page automatically reloaded to something
that said "oops, this page can't be found", and then a few seconds later
loaded back to the original. This is while I was simply reading the text, not
interacting with the page at all.

Somehow, through the magic of JavaScript and Websockets, they managed break
passively reading static content.

~~~
acqq
It's not static and it's not readable HTML when accessed without JavaScript.
If I understand, that's _the feature_ of the framework that is being praised.

~~~
1qaz2wsx3edc
I don't think that's completely fair. Meteor to me, is more cased for building
realtime applications. Should a blog be a realtime application? Probably not,
can it? Sure.

Not only that but, but the page compensated.

It's also kind of neat, that the author has indeed written a realtime blog.
For fun: they could magically fix typos while you're reading.

~~~
RockyMcNuts
Or users could legitmataly highlight typos and they could get fixed in real
time.

~~~
joshowens
Great idea!

------
carsongross
_" When a client asks us to build an app, they are really asking for a fully
interactive web app that utilizes javascript to get rich client interfaces."_

Or maybe they really are just asking you for an app, but you'd rather build a
fully interactive web app that utilizes javascript to get rich client
interfaces.

~~~
joshowens
No, the client that spawned this blog post was specifically asked for heavy
google maps integration. We haven't had one client asking for just a server
side app in years.

I've been doing this for 8-9 years, I have a good idea on how to talk with my
clients :)

~~~
asdasf
And I haven't had a client ask for a javascript app ever. This is why
anecdotes aren't very useful.

~~~
joshowens
Insert mis-attributed Henry Ford quote about customers wanting faster horses

~~~
mtkd
If you're going to make a bold prediction about Meteor killing Rails be
prepared for some heat - your responses to that heat may progress or regress
the argument.

~~~
joshowens
I'm cool with the heat. I am not perfect, don't pretend to be. I welcome the
conversations and I am seeing interesting responses.

------
dnprock
Catchy title but misleading. I can't access the blog. Josh, do you run your
blog on meteor.com? You should migrate to a production-like environment. We
ran into this issue before :)

My team builds [http://vida.io](http://vida.io) with meteor. We've got 100-200
visits a day, few thousands at our peak.

I'm an experienced Rails developer and dabbled a little with nodejs. I can say
meteor will change nodejs framework dev, but not kill Rails.

Some of the serious problems I found developing with meteor:

\- Reactive template is nice but can lead to very hard to debug issues. Small
portion of applications (in general) need real-time. I often spend time
disabling reactive update. There's no really good way to debug reactive update
trigger.

\- Organizing, switching views/templates can get confusing for site
navigation.

\- Package system is still infancy, has a VERY long way to catch up with Rails
ecosystem.

\- Pub/sub model introduces a lot of performance issues. We have to limit the
amount of data we send back.

\- Security: this is related to pub/sub model in previous point. It's very
easy to publish unauthorized data to client side.

\- No best practices with the exception of authentication. So everything else
takes LONGER to do than Rails. Developing in Rails is still way faster in most
scenarios.

Despite of these problems, I think meteor is a promising framework. I like how
it unifies client and server. And hopefully, meteor dev team will address the
above problems.

~~~
rco8786
> I can say meteor will kill nodejs

meteor runs on nodejs...

~~~
dnprock
True, corrected.

------
subsection1h
Is your blog powered by Meteor? I ask because your blog has some major issues:

First, when I load [http://differential.io/blog](http://differential.io/blog)
and click a link for an old article, the content of the "Why Meteor will kill
Ruby on Rails" article is displayed instead of the content of the article I
wanted to read. This happens for every article.

Second, when I load
[http://differential.io/blog](http://differential.io/blog), scroll down to an
old article, click the article's link, and then click my Back button, I'm
directed to the top of
[http://differential.io/blog](http://differential.io/blog), not to the middle
of the page where I left off. Very annoying.

~~~
subsection1h
I visited Meteor's blog just now at
[http://www.meteor.com/blog](http://www.meteor.com/blog) to see if it would
break my Back button the way that your blog did. Indeed, it did. Clicking my
Back button at a Meteor-powered site seems to always direct me to the top of
the previous page, not to the location on the previous page where I left off.
As I wrote in the parent comment, this issue is very annoying.

Is this a problem that the Meteor developers are working to resolve?

~~~
bhauer
I don't use Meteor, but If I recall correctly, when we added client-side
composition to our blog [1], I had to capture the scroll position when I
pushed a new entry into the history stack. When that entry is popped back off,
I manually move the scroll position since the browser doesn't know to do that
itself.

I _think_ it more or less works. If you scroll down and click one of the older
entries and then press back, it should remember where you were in the bigger
page.

Kind of a pain in the rear, frankly. It was sort of fun doing the client-side
composition, and I like the immediacy of it, but I'm left a little
apprehensive.

[1] [http://www.techempower.com/blog/](http://www.techempower.com/blog/)

------
acqq
I can't read the site (there's nothing in HTML) but is this a framework that
doesn't produce pages viewable without JavaScript? If it is against HTML, my
vote is against it.

~~~
ambiate
[http://docs.meteor.com/#spiderable](http://docs.meteor.com/#spiderable)

Could this could be used if the browser does not support JS?

~~~
joshowens
Yes, and you can control a list of user agents that it activates for.

~~~
acqq
Assuming that google-bot has its own user agent isn't the excuse for not
generating the HTML for the people who want to _read_ the site.

------
neya
This is bullshit. In my whole experience as a full stack developer, after
having tried various technologies and languages and frameworks - including
ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with
full confidence and can afford to put my name and credibility to stake -
Nothing is going to replace Ruby on rails anytime soon.

I wish something would, but nothing at the moment, is even close to the scale
at which rails gets things done. I truly mean it. And something built out of
Javascript replacing a Ruby-based full-bleed framework? I think you must be
fucking kidding me. What the author describes is a very specific use-case and
maybe, just maybe Meteor JS _might_ replace a portion of that use case. In
fact, if I were to do something like what the author suggests, I would still
choose rails and Knockout JS (or Angular JS if you know it better).

Do you know how long it takes to build a Facebook _backend_ clone in rails?
Maybe a day? And the frontend (all the Ajaxy stuff) should probably add a week
or two (worse-case scenario). That's just it. That's the power of rails.

If you were to build the backend in Javascript without the power that Rails
provides I'm sure you will need more than just a day, let alone a week.

The point is, nothing is close to what rails is right now. I badly wanted
something to replace rails for my work, but I haven't found a single solution
that fits my needs. I've tried everything - Play, Sails, Revel, Gorilla, etc
etc. But nothing there is that can replace rails. And all the frameworks that
claim to be more like Rails, they're simply not true. Have you tried using
play (Scala) and PostgreSQL together? The experience is nothing like Rails.

I can make a clone of any complex app out there in the web in a matter of
minutes/hours. That's the power that rails gives me and no other
framework/combination can't.

I understand that Rails is slow. But this is not the right way to critique it
- Claiming something is going to replace it when it actually isn't true.

We develop all our v0.1s in Rails in house and port them to Go ( _only_ if
necessary and if the project owner is particular about it.) and that seems to
work well for us.

~~~
kamaal
I'm a back end developer and don't have much experience with web technologies,
so may be some one can enlighten me.

Have we really come to a stage, where what Facebook has done after billions of
worth investment and thousands of people working, can be cloned with a open
source technology in hours?

>>I can make a clone of any complex app out there in the web in a matter of
minutes/hours.

Again how is this possible. Or let me word it this way, if some thing can be
copied in minutes how can it be called complex?

~~~
yelnatz
I'm a beginner web developer and I can clone facebook in a few hours.

In its core, the app is just users who can friend each other.

Add AJAX to that... and tada, something that resembles facebook.

Scaling the app to be very reactive, available to millions accessing it at the
same time, and with near 100% up time is where the hundreds millions of
dollars go. (and all that data mining)

~~~
gizzlon
You underestimate how complex facebook is nowadays. Even the core is much more
than just people friending each other.

If you mean "mimicking on or two of the features" I'm with you :)

------
programminggeek
It depends on your definition of kill.

If you mean for new project starts, it might severely diminish it, but I don't
think it will flat out end its popularity any more than Rails killed Java.

Also, it depends on what type of project you are talking about. For something
at large scale, my guess is meteor won't be any more successful than Rails has
been at huge scale (like Twitter).

I do agree that using one language end to end might be an awesome developer
experience, but I wish that language wasn't JavaScript. I won't go into great
detail as to why, but I would not want to build a large JavaScript app. That
sounds incredibly painful and unpleasant to me.

~~~
orclev
Ruby and Java don't really compete in the same space, it would probably be
better to compare Ruby and PHP as those two are the primary competitor with
each other. If you wanted to point to a competitor to Java, .Net would
probably be the closest match.

~~~
programminggeek
I agree, but when Rails came out, there was a whole lot of Ruby on Rails is
going to kill Java type posts. I guess this means Meteor is reaching some
mindshare.

~~~
awj
Yeah, and we saw how well that worked. Java projects sprung up to incorporate
the good ideas from Rails, Rails itself picked up a load of developers and
evolved into something decent, and the world moved on. Nothing was killed, but
all the boats rose.

I'm thinking maybe the _drama_ wasn't a requirement for this to happen.
Perhaps Meteor devs could experiment with that idea.

~~~
joshowens
Without the drama, this post with a different title would have fallen off the
front page in about 15 minutes.

~~~
awj
...then the solution is to write a post that can stand on its own merits. That
shouldn't be difficult if Meteor can live up to this kind of hype.

------
AndrewBissell
> Java promised this too us back in the 90's, but it was too big and bloated
> and hard to work with

LOL @ Java being described as "hard to work with" in comparison to JavaScript.
Major indicator of JS developer Stockholm Syndrome right there.

~~~
tieTYT
Care to elaborate? I'm a Java developer, but I'd guess you're referring to
browser fragmentation, not the JS language.

~~~
AndrewBissell
No, I'm referring to the languages themselves. JS does a very few things
better than Java, but it is simply chock full of bizarre type coercion rules,
strange semantics, and other "hall of mirrors" gotchas which make it much
harder to learn and work with than other dynamic languages. And yes, Java has
some of these too, but they occupy a much smaller share of the language base,
and are often a side-effect of useful features (such as signed integer types)
which JS doesn't provide.

We're stuck with JS because it's "the language that runs in every browser,"
but that's no reason to grant it praise that it hasn't earned such as "easy to
use."

Fragmentation will create headaches regardless of which language is running in
the browser.

~~~
woah
I've never had any type coercion bugs, can you elaborate?

~~~
hrjet
[https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

------
leokun
Meteor is cool, and there's a lot that I love and is awesome about it, but it
has quite a few problems, some of which are on the roadmap for 1.0:

Server side routing: a nice thing for APIs and RSS feeds.

Server side template rendering, because running phantom.js to get SEO is kinda
crazy.

Can't get access to any kind of request object/info on the server side because
you know, maybe HTTP still matters.

Have to do file/io to get reactivity (save to mongo). Try getting webrtc
started that way, it's not fun.

Can't get direct access to who is connected without hacks. See above about
webrtc.

It uses mongo, because mongo: [http://aphyr.com/posts/284-call-me-maybe-
mongodb](http://aphyr.com/posts/284-call-me-maybe-mongodb)

It erases event listeners on the client side with reactivity, so the vast
majority of JavaScript libraries on the internet are incompatible with it.

The javascript globbing system at load time is incompatible with popular ways
to manage dependencies like node'js require or require.js. Like having files
load in alphabetical order? Meteor.js is for you!

There actually is a package system, which is the new way to do this, but the
old system still exists and the new system while easy to use is not yet
documented, last I checked, and you have to create packages just to wrap
node.js packages.

Meteorite. Was created to easily hack meteor.js to fix some of the issues
already listed, but now is the way to grab things from atmosphere. Meteor
comes with packages, but those are all official. I never liked the idea of
using Meteorite because you couldn't upgrade Meteor until packages you
depended on upgraded too. Now though meteorite is this thing you have to use
to import to from atmosphere which has turned into a bunch of wrappers for
npm.

The built in less can't import recursively.

I love meteor and if I created a list of all the things awesome about it, it
would be larger than those issues up there ^^^ and the team is working on it.
They're also really smart people.

------
al2o3cr
"Let's be real, Javascript is the #1 language on Github and for good reason -
it runs everywhere."

Similarly, anal sex is the best kind because it works on all genital
configurations. /snark

~~~
petercooper
I suspect there's a significant number of people who would actually agree with
that though.

~~~
dfischer
Touché Peter, touché.

------
davexunit
Let's all hop on the next hip web trend, guys! Rails has become so boring and
mature. There are many languages better than Javascript for server-side
programs, but monoculture is so much cooler. One size fits all and you'll like
it.

~~~
JPKab
This is what Java guys said about Rails. "Hipness" is absolutely unrelated to
whether something is actually good or not. I firmly believe that Meteor is a
super fast way to build a certain kind of web app that just so happens to be
very popular in businesses: CRUD apps where users can see other user's changes
to data in real time. I will admit that older users are actually creeped out
by other people seeing them type though. I guess its a generational thing.

~~~
davexunit
I'm not going to sing the praises of Rails. I think it is a pretty good
framework, but it is one hell of a hype machine. As software gets older and
more stable, people get bored and reinvent the wheel again, especially web
developers that will stop at nothing until everything is written in
Javascript.

Rails was a fad. Meteor is a fad. Keep your nose out of hype.

~~~
camus2
Rails was such a fad it influenced every web framework after rails, and made
Microsoft drop webforms.

------
mmanfrin
I was halfway through reading the article, then the page refreshed and blanked
out. Now it displays 'Oops, this page can not be found'. What?

------
squidsoup
Derby ([http://derbyjs.com/](http://derbyjs.com/)) ostensibly does everything
that Meteor does, but seems to be flying a bit under the radar. I'd be
interested to hear comments from anyone that has had experience building apps
in both Derby and Meteor.

~~~
morgante
I've used both and actually prefer Derby. They don't toss out Node (which the
Meteor team did), thus making it easy to leverage the growing Node ecosystem.
Also, I'm constantly left scratching my head as to why the Meteor team chose
to make backend code synchronous.

That being said, Meteor simply has a lot more developer talent (and money)
behind it. Hence it's improving at a much faster rate than Derby.

------
donw

      When a client asks us to build an app, they are really asking for a fully interactive web app that utilizes javascript to get rich client interfaces.
    

Just, no. When a client asks you to build an app, they are really asking you
to solve a problem. _How_ you solve that problem _might_ be a rich Javascript
client interface, but in general, your client probably doesn't give a shit as
long as they can find other people to work on it when you're gone.

------
ben_mcmahen
Having made some fairly substantial web-apps using Meteor such as
[http://subtitles.fiddlware.com](http://subtitles.fiddlware.com), I can say
that Meteor does make it incredibly easy, at least at the outset, to create a
certain kind of application. It's great for something that is fairly self-
contained; i.e., the task of the app is fairly narrow, and only consists of 1
- 2 pages... which may still make up multiple views. It's incredibly easy to
implement a login system. And if you're at all dealing with something that is
real-time, Meteor basically gives you socket.io style functionality for free.
It was a good fit for the subtitles application.

But there are definitely some weaknesses. It doesn't scale particularly well
-- and I don't mean, necessarily, in terms of performance, I mean in terms of
creating a large application... or a page with many sub-applications. And
while the reactivity is awesome... and the auto-real-time can be awesome...
sometimes you can feel "locked in" to the Meteor-way, when another
(declarative) approach may be more suitable. In a weird way, you end up
"working around" the features of Meteor.

I'm increasingly convinced that a more modular approach is ultimately the best
route... which is what something that express, sockjs, and component.js
provide. I like using reactivity when I want to. And I like being able to swap
different parts of the stack when desirable. It's typically more work at the
beginning, but the flexibility can ultimately be liberating...

------
Tarang
I use Meteor alot.

Some of the issues mentioned here were about a lack of scalability in terms of
larger sized apps and to the number of simultaneous users it can handle.

If you have a large app you can use subscriptions that change as you view
them. You can indeed have large 100,000 item collections without any hiccups
or slowness. The issues people display here are if you have this 100k database
downloaded on your browser which is unrealistic.

The second as to scalability user-wise. It is possible to scale meteor by
altering some code. Meteor's still a baby but their 1.0 release will
definitely sort this out:

The issues relate to how publish functions are handled & how mongodb interacts
with meteor. These will be heavily optimized by running publish functions less
& using a mongodb replica set emulated via meteor or through mongodb's oplog.

I have built before with .NET (I hate it the most), Java, Rails, PHP,
Coldfusion, you name it! One thing Meteor helps me do is build fast and expect
something that works without bugs at the end. Its nice to experiment around
with what people like till we get it right.

I'm going to go so bold as to say Meteor will let people experiment with many
ideas just as VCs do with ideas but here you can get that one which works
without much cost & time to develop it.

RoR is nice but when it comes to a funky front-end user experience its not
nice. The backend is loads of fun!

------
gnufied
Why will a blog load _anything_ over websocket? Link bait title and a blog
that doesn't load.

~~~
scotth
I can think of one reason, although it's not necessarily a good one, or the
only way to do it.

Once the connection is established, the server could push down all required
resources for the page, rather than wait for the browser to request them one
by one.

~~~
joshowens
It is built in Meteor, we just switch our whole site to use it. We switch from
rails because we have much more Meteor knowledge on our team.

~~~
rurounijones
"Right tools for the job"

Meteor is not (and rails probably isn't either) the right tool for a simple
blog like that. jekyll or something like that is.

The fact that you used an inappropriate tool for a blog and then say on the
blog how you use that tool for all your clients casts a shadow on your
professionalism I feel.

------
nemoniac
If you don't accept its cookies, it shows you a blank page.

I hate to be negative but that's not how to win my confidence.

~~~
rwty
I'm thinking of setting up a wall of shame for sites that won't load w/
cookies off.

------
andybak
Just to add to the chorus of disapproval.

I got a white screen on my phone. Had to switch to my laptop.

Here's the thing. You're building a mainly content-driven site (still the bulk
of websites).

If you go down the route of some javascript-based 'app' that squirts all the
content in dynamically then you might get everything right and end up with a
beautiful, fast website that works across a range of devices, is accessibly,
doesn't break bookmarking or the back-button and doesn't kill your SEO.

But you've got to get everything right so the odds are that you'll get a part
of this wrong. Debugging and testing are also suddenly a much bigger part of
the equation.

So what have you gained over plain old HTML and CSS with progressive
enhancement? If you want the possible speed advantages of not re-rendering
whole pages then techniques such as Pjax can be used to get the best of both
worlds.

In short - with an app-based approach over a html-based approach - there are
lots of ways to get it wrong and only a few ways to get it right. You're
probably not clever enough to get everything right. Gawker weren't.

------
mindcrime
Did not read TFA, but my immediate thought on seeing this headline is "No, it
won't". Why? Because software never really seems to die. Look at the billions
of lines of COBOL or PL/I or FORTRAN still in use around the world. Look at
the fact that (a few) people still use OS/2, which is about as dead as
software ever really gets.

Rails may well find it's popularity and prestige diminished, but I doubt it'll
"die" anytime in any of our lifetimes.

~~~
j1z0
100% agree here. Way to many Rails developers around for it to die. Also as
cool as Meteor is, and it's pretty cool. There is a huge continent of
developers that will resist javascript for as long as possible, because even
though it is ubiquitous, let's be honesty, it does suck in a number of ways.
Ruby / Python / Go / etc.. are all so much nicer languages from a developer
happiness perspective. Ultimately javascript will become more and more
prevalent for sure, and Meteor along with it, but only because all the
browsers decided to support it, NOT because of developer happiness.

~~~
pyGuru
if only all the browsers would run python... now that would be developer
happiness. ;)

~~~
krapp
unless you happen to be one of those sickos who thinks significant whitespace
is a terrible idea....

------
avenger123
Josh, it's an increasing article.

I don't know what types of apps your company builds but it would be nice to
state that. I certainly don't think you believe that Meteor is a good fit for
all kinds of web apps. It does seem like its a really good fit for the apps
that your company builds.

I would get more out of your article if you provide some context around the
types of apps your company is focused on.

~~~
joshowens
We generally build MVP apps for clients, we are a venture shop. I do think
Meteor could be used for most web app cases and the ones it doesn't fit for
now will be taken care of in the near term.

------
awj
That's a bold claim to make when your blog can't function without cookies.

Also, after it loaded, the only point that seemed to be directly related to
Rails had to do with teaching designers to use templates and the asset
pipeline. If that's your only Rails-specific issue then you're really claiming
that Meteor will kill all other kinds of web development.

------
NARKOZ
> Let's be real, Javascript is the #1 language on Github and for good reason -
> it runs everywhere.

Cancer is #1 disease in the world, but that doesn't mean I want it.

~~~
Iuz
I choose to use javascript, nobody chooses to have cancer.

~~~
CmonDev
I don't like the analogy because it's not a laughing matter. Nevertheless
there is no choice of script language in browser either.

------
laughfactory
As a relative newcomer to web dev, I find Meteor very challenging to work
with. It's got too much magic going on. Part of that is the simple fact that
the documentation, while sufficient for pros, simply doesn't hold your hand.
At all. And beyond the documentation there's a dearth of other resources for
finding out how to do things. The community is too small to be effective, and
any books which have been written are out-of-date already. Answers to
questions on StackOverflow normally don't even apply anymore because the
platform has changed so much. This is all very typical pre-1.0 stuff, so the
point is that I'm not sure Meteor is maturing fast enough. It might be too
late to the party once it finally stabilizes.

Either way, I strongly dispute the implied claim that Meteor is easy to learn.
It certainly is not. Rails makes a lot of intuitive sense--at least to me--
whereas Meteor doesn't. As the author mentions it has the whole kitchen sink
approach going on, and that makes it very unapproachable to someone like
me...because it's difficult to make sense of unless I understand all the
components on which it's built.

So is Meteor cool? Absolutely. And it could be great _if_ it matures fast
enough to still be relevant, _and_ if it manages to be associated with some
truly tremendous learning resources which not only display its potential, but
assist in learning the intricacies of the platform. I worked my way through
the Discover Meteor book and was impressed by all the magic Meteor slings, but
I didn't really understand much of _why_ and _how_ it worked.

So we'll see. But for now, Rails is untouchable.

~~~
imslavko
For more "how magic works" a lot of people watch eventedmind.com screencasts.
But it's not the case that you can't use any magic without fully understanding
it (otherwise we wouldn't be able to use anything in this world).

In my opinion, problem with explaining all the magic - it takes a significant
amount of time but the code and underlying system can actually change in
several months. I think, it makes more sense once core parts stabilize.

------
mark_l_watson
I am very impressed by Meteor! Earlier this year I did an experiment: I coded
a complete application in Clojurescript + Clojure back end, and then
afterwards in Meteor.

I have tons of Clojure experience (with little bit of Clojurescript), and not
too much use of Javascript. I spent much less time on the Meteor version and
it had __lots __more features. Really no comparison. Unless you really dislike
Javascript I suggest you try Meteor.

------
wonnage
"The problem is when you start with something like rails then javascript was
an afterthought - something bolted on long after the technology was built."

TCP: 1974 HTTP: 1991

Your point?

------
cjbprime
Is the inability to get HTML without being a javascript engine going to be a
problem for major adoption? (I know there are hacks around using phantomjs to
generate HTML for non-JS clients -- is that a viable solution for serious
sites?)

~~~
rywalker
Meteor has a package 'spiderable' which allows Google to index the content —
we're having no problems with it.

~~~
cjbprime
Yes, that's the PhantomJS hack.

------
CmonDev
Differential looks like a small designer shop which does small UX-centric web
apps. If they will be doing any serious server-side development in future they
will have to hire guys who know serious non-script languages. But for now
Meteor looks like a good fit for their needs. And of course they want some
cheap PR, so it's good to over-generalize to make Rails developers pissed (for
no good reason).

------
vezzy-fnord
How exactly did the author come to this Meteor and Rails dichotomy? What do
they have alike besides being web application frameworks, of which there are
endless?

This makes about as much sense to me as "Why Flask will kill Zend".

~~~
joshowens
I came from Rails after using it for 8 years, so it is my easiest comparison
point.

~~~
dham
Give this whole Meteor thing some more time to sink in.

Your still in the honeymoon phase. I know this because you list context
switching. Anyone that moves to Node(or meteor) and lists context switching as
a reason, is not long for this world... of switching to node.

I'm not going to convince you here, but just proceed with caution. It would be
like me convincing my friend after he's dated a girl for a year that she's a
total ass. Not going to happen.

------
jsnk
I watch some videos on Meteor website a while ago and I was really impressed.
Stuff that's pain in the ass in Rails, you can do it quite easily on Meteor.

One aspect that prohibits me from making the jump though is Ruby's third party
gem ecosystem. Ruby has so many tried and proven gems for everything you can
think of. Is there a website like rubygems.org in Meteor world?

~~~
akbar501
Community developed Meteor packages are on
[https://atmosphere.meteor.com/](https://atmosphere.meteor.com/).

------
rywalker
It might take some time, but I have to agree after working in Meteor for a few
months, the developer experience is much better than trying to do
Rails/Backbone Rails/Ember or Rails/Angular.

~~~
brucehubbard
It's not quite there yet but it's getting better by the day. There are still
some things like UI animations that _are_ possible in Meteor but aren't quite
as easy as they are in client side Javascript frameworks.

It makes me feel a little better though that they are trying to be transparent
about the flaws by publishing their roadmap:

[https://trello.com/b/hjBDflxp/meteor-
roadmap](https://trello.com/b/hjBDflxp/meteor-roadmap)

------
TallboyOne
God I hate stupid titles like this. How about something like "This is why I
think A will kill off B". Instead it's always some ridiculous, over-
generalized all or none fucktard title.

------
rglover
For those saying Meteor is for toy apps, I just launched a fairly complex app
written 100% in Meteor (yes, with paying customers):
[https://properapp.com](https://properapp.com). Runs like a charm, easy to
develop with, and not even 1.0 yet.

Don't dismiss the author, Meteor is going to change a lot.

~~~
dham
But why. Why does your app need realtime? That's the part I'm missing. I see a
Rails/Angular app right there, and in the end you'll feel good because your
data is in the capable hands of Postgres/Mysql

~~~
rglover
Simple: I'm a front-end developer by trade and Meteor gave me something I
understood (JavaScript) on both the client and server. To build this in Rails
would have meant learning both Rails and Ruby.

My app doesn't _need_ to be realtime, and that's a narrow way to look at
Meteor. Real time is just a nice bonus that the framework enables.

~~~
dham
But why? Meteor is a paradigm shift from the front end. Front end Javascript
is asynchronous and event based. Meteor is synchronous.

You're going to take a hit learning any framework, no matter the language. I
picked up Rails just as fast as I did Play framework, and I had never looked
at Ruby before.

The whole NodeJS appeals to front end programmers thing kind of reeks to me. I
think it's an irrelevant argument. I maybe wrong, but an end to end JS
stack(MEAN) didn't feel any more right then using Rails.

~~~
rglover
_I think it 's an irrelevant argument._

I could say exactly the same thing. For example, say a new Ruby framework was
released that you really enjoyed and you "got it" because it was similar to
Rails or aligned well with Ruby. The same principle applies: if something is
familiar, it stands to reason that you'll have an easier time comprehending
it.

Regardless, does what framework I use _really_ matter? As long as I'm able to
solve problems in a way that makes sense to me, I don't really see the point
in wasting time debating what to use.

If the pajamas are comfortable, they're comfortable. Who cares if they're blue
or green?

------
Kynlyn
The link is now a 404..I hope it wasn't powered by Meteor...

~~~
JPKab
The fact that its hosted at Modulus (the guys behind Demeteorizer, which
allows you to host meteor apps on Node.js services) would indicate that its
almost certainly a Meteor app to me.

I DO think that Meteor is fucking awesome, due to the sheer speed you can
crank out commonly requested features (you can add a Google/Facebook/Github
Oauth login widget with one line of code), but it sure as hell doesn't seem to
scale well these days.

------
weixiyen
I still prefer a clear separation of server and client. The main issue I have
with Meteor is that it assumes 1 client and for most businesses mobile &
tablet is going to matter more than web sooner or later. It's sort of a
technology solving problems in a space that is not really in hyper-growth.

------
zyang
Bold claims - at least fix the glitches in your blog first.

------
koffiezet
The biggest issue I see with this is: MongoDB. Anyone who worked with serious
SQL databases who looks at MongoDB shivers. It has not even solved problems
'classic' databases have solved for over 20 years. The entire "it is fast"
thing is based on very smart Linux disk-caching strategies. It's reliability
is questionable. It might work very well for you, but when it would go wrong,
good luck!

Also I hate being tied down to 1 database back-end. At least make it a plugin
or smth. That you use a NoSQL db for rapid prototyping, I do understand
(although I don't like it), but you can do exactly the the same with Postgres
9.3 with the JSON extensions, and more. That way you build on a reliable,
proven database which has solved the problems MongoDB is facing now a LONG
time ago.

Oh, and the 'big data' argument for using NoSQL is plain bullshit, only a very
small percentage of developers actually have worked with 'big data' that
requires clusters to process.

Don't get me wrong, better frameworks are good, and I would be interested in
Meteor if it wasn't for MongoDB being tightly integrated.

------
Eptis
I don't really see you making good points as to why Meteor would kill Rails.
So Meteor lets you deploy apps quickly, but how is the rest of the development
cycle after that? You can find more JS developers than Rails developers, but
since when is more always better? You write JS on the front and backend and
don't have to switch all the time because Meteor does a lot, but why is easier
better?

------
chiurox
Sensationalist title but there are some parts with which I agree to some
extent. I've heard about Meteor over a year ago but never thought about a use
case where I felt the need to use it. Last week, we had a last minute project
that required some sort of webapp that could allow X number of users viewing a
certain page on the browser and editing things off simultaneously with good
enough conflict resolution. Of course, I could have done it with Rails on the
backend, rolling out my own reactive system with Server Sent Events updating
the client. But as curious as I am, I decided to checkout Meteor and it was
perfect for my case. In less than an hour (with Meteor) I had everything
working as expected. The app was for a big social event and all it mattered in
the end is that it worked and impressed everyone involved. No one really cares
what you build it with, as long as you deliver. In my opinion, Meteor is worth
a shot if you're building a small scale reactive system.

------
smathieu
Before meteor kills Rails, it should really fix the offline mode :)

Blog try to refresh after HN traffic killed the backend.

------
hmart
Both frameworks use port 3000 in development, if you start Meteor first, sure
it will kill Rails. Haha.

------
davidbanham
Does Meteor scale beyond a single server yet? Because until then I can't see
much use for it.

------
podman
Is this blog also running on Meteor? I can't get it to load so that's not
instilling confidence. Maybe it's their host,
[https://modulus.io/](https://modulus.io/) that's having problems?

~~~
rywalker
it was us — HN blew up the single dyno the site was running on.

------
xacaxulu
Meteor will automatically refresh your browser if you are reading a blog post
about Meteor.

------
xsighted
Technically, you can use meteor with rails [https://github.com/tmeasday/ruby-
ddp-client](https://github.com/tmeasday/ruby-ddp-client), so I don't know if
meteor is killing rails anytime soon.

------
vetrom
I think there is some degree of conflation here. You can have different
views/communication for session state and separate that from database state.

Websocket apps are almost invariably in the family of apps that act on some
sort of session synchronization, and if you are depending on a synchronized
full-view between server<->client, then yes, you will have a bad time if your
working set grows without bounds.

If you are more concerned with just prediction/event/streaming and have a
decent invalidation/resync mechanism, then meteor becomes a natural choice for
interactivity.

Oh, wait, there's the first two problems in CS again — caching and naming
things.

------
UUMMUU
It's amazing for hackathons. I wrote
[http://battlehack.meteor.com](http://battlehack.meteor.com) in 24 hours by
myself after having done meteor as a hobbyist for 2 months.

~~~
sumanyu
I've been meaning to learn more about meteor. I've read the official docs,
tutorials here and there, but haven't really found any resource that clicked.
Would you mind sharing resources you used to learn meteor? My email is sumanyu
at hotmail

Thanks a ton!

~~~
imslavko
[http://www.discovermeteor.com/](http://www.discovermeteor.com/) is a great
book but starts from 40$. There are some starting points those are up to date:
[http://www.discovermeteor.com/2013/09/17/meteor-for-front-
en...](http://www.discovermeteor.com/2013/09/17/meteor-for-front-end-
engineers/), [http://yauh.de/articles/376/best-learning-resources-for-
mete...](http://yauh.de/articles/376/best-learning-resources-for-meteorjs)

------
throwmeaway2525
What about the Mongo dependency? I like Meteor, but that's one concern.

------
harel
Kill? Really? Is this a fight to the death and there can be only one survivor
leaving the ring? Both Meteor and Rails will live on side by side, happy and
unaware that somewhere there are groups of people fighting their fight for
them. This is the same like the Spectrum Vs Commodore 64, or Amiga Vs Atari St
fights... Pointless in any practical term, but I guess it gives some people a
sense of some messianic gratification. "Hey, I blogged about X killing Y
before X was cool".

------
pbreit
When someone writes a headline like that and it doesn't happen, should the
writer lose a substantial amount of credibility? Or should we just chalk it up
to provocativeness?

------
dasil003
Before we get carried away, let's remember that the web has tremendous utility
outside of applications. Progressive enhancement is still the best way to do a
great many types of websites. Rails succeeded because it tied together the
fundamentals of the web in a nice package. Meteor is another step-change for a
certain kind of real time application, but that is by definition a much
narrower use-case.

~~~
joshowens
I see realtime as a great side effect coming with the framework, to be honest.

Meteor itself makes it easier to write clean client side JS code where I care
much less about the backend when I start.

------
ryderm
> We spent over two days recently getting angular.js and rails wired up for a
> brand new project, that comes out to 12-16 hours spent on configuration
> instead of writing actual code to build an app that does something the
> customer wants

Am I the only one who was confused by this? There is no "wiring up" rails and
angular js. Just include the source js in your application, or use the google
CDN. One line of code.

------
jcoder
What about long-term maintainability of a large application? Rails has its
issues there, but a body of best practices has grown up around maintaining
long-lived rails apps. I wonder what the author's opinion would look like were
it building the single app that is core to their business, and maintaining it
for 3 years, instead of spitting out a Meteor app for a client every 6 weeks?

------
dham
I'll make a bold claim. Meteor is not the future of web programming. Why?
Because JSF, that's why. This has already been done in the Java world.

I believe the future of web programming is REST apis(in whatever the hell
language/framework you want) and a nice framework such as EmberJS/Angular on
the front end.

I may be wrong, but I have history on my side.

------
thepicard
I'm tempted to say: "unless mongoDB gets a lot better, this is not going to be
true." However, a minute fraction of the rails community is large sites, so it
doesn't matter.

I also think a lot of people like rails because they find ruby extraordinarily
beautiful. As much as I like JS, beautiful syntax is not its strong suit.

------
bashcoder
Nah. Because JavaScript.

------
izietto
I don't think so. Javascript frameworks are for real time applications, while
RoR (and the other "classic" web frameworks) are simpler to set and to use for
the classic dynamic HTML applications, and I don't think real time apps will
overwhelm classic HTML apps.

------
edwinnathaniel
When Meteor was released couple months ago on "Show: HN" or something, I
recalled unit-testing is not part of the release. Wonder if that's still the
case?

Maybe it's common not to have good unit-tests? (integration/functional-test
does not count as unit-test).

~~~
joshowens
There are plenty of easy to install unit-test packages. Laika, Chai, etc.

~~~
edwinnathaniel
Sure, there are plenty easy-to-install-but-not-necessary-to-use-properly tools
out there as well. Not to knock off your argument but would love to see
stronger emphasis on proper automation test (QUnit does not count as "proper")
over the JavaScript community in overall.

------
purephase
It's the framework I'm most excited about and watching closely. I still think
Rails has a place in the back-end (e.g. API) but Meteor is showing a lot of
promise.

------
dodyg
I am just waiting for somebody to present "MongoDB+Meteor:Perform like a pr0n
star" in a conference to have the Meteor "douchebaggery cycle" completed.

------
Keats
Is seeing the bottom of the page flash before the page is loaded when clicking
a page intended? It's not very good either way. Especially for a blog.

------
gaoshan
Grenade! Take cover!!

------
rimantas

      > What if you could spend your time in one language
      > and one framework?
    

What if you eat everything with a fork?

~~~
buckbova
What if you eat everything with a spork?

~~~
oftenwrong
Then you probably don't eat spaghetti.

~~~
buckbova
You must not be familiar with this utensil. It is a spoon with a fork like
end.

Many a plate of school lunch spaghettis has been eaten with a spork.

~~~
FooBarWidget
It's still much easier and more efficient to eat spaghetti with chopsticks.

------
bolder88
Silly linkbait. Tools barely matter to any competent programmer, it's just
fashion.

------
dschiptsov
There is rather an unpopular opinion, that we need less piles-upon-piles of J*
crap do serve a web-page, not more.)

