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?<p>I mean cool, so Meteor is maybe better for prototyping. Because that's all we're talking about here, prototypes and ultra-simple websites.<p>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.<p>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.<p>This has nothing to do with software development, this is just about fashion.
I'll make an even bolder claim: Meteor doesn't work at all for anything except small toy apps.<p>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.<p>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.<p>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.
It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net.<p>- 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.<p>- Both tout the ability to do all your development in a single language<p>- Both claim impressive gains for RAD<p>ASP.Net had some impressive demos for its time. But as we know, the warts emerged:<p>- 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?<p>- The "one language" (VB.Net for ASP.Net, before C# became big) wasn't so hot a foundation. One word: Javascript.<p>- 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?
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.<p>Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.
<i>"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."</i><p>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.
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 :)<p>My team builds <a href="http://vida.io" rel="nofollow">http://vida.io</a> with meteor. We've got 100-200 visits a day, few thousands at our peak.<p>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.<p>Some of the serious problems I found developing with meteor:<p>- 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.<p>- Organizing, switching views/templates can get confusing for site navigation.<p>- Package system is still infancy, has a VERY long way to catch up with Rails ecosystem.<p>- Pub/sub model introduces a lot of performance issues. We have to limit the amount of data we send back.<p>- Security: this is related to pub/sub model in previous point. It's very easy to publish unauthorized data to client side.<p>- 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.<p>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.
Is your blog powered by Meteor? I ask because your blog has some major issues:<p>First, when I load <a href="http://differential.io/blog" rel="nofollow">http://differential.io/blog</a> 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.<p>Second, when I load <a href="http://differential.io/blog" rel="nofollow">http://differential.io/blog</a>, scroll down to an old article, click the article's link, and then click my Back button, I'm directed to the top of <a href="http://differential.io/blog" rel="nofollow">http://differential.io/blog</a>, not to the middle of the page where I left off. Very annoying.
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.
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.<p>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 <i>might</i> 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).<p>Do you know how long it takes to build a Facebook <i>backend</i> 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.<p>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.<p>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.<p>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.<p>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.<p>We develop all our v0.1s in Rails in house and port them to Go (<i>only</i> if necessary and if the project owner is particular about it.) and that seems to work well for us.
It depends on your definition of kill.<p>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.<p>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).<p>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.
> Java promised this too us back in the 90's, but it was too big and bloated and hard to work with<p>LOL @ Java being described as "hard to work with" in comparison to JavaScript. Major indicator of JS developer Stockholm Syndrome right there.
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:<p>Server side routing: a nice thing for APIs and RSS feeds.<p>Server side template rendering, because running phantom.js to get SEO is kinda crazy.<p>Can't get access to any kind of request object/info on the server side because you know, maybe HTTP still matters.<p>Have to do file/io to get reactivity (save to mongo). Try getting webrtc started that way, it's not fun.<p>Can't get direct access to who is connected without hacks. See above about webrtc.<p>It uses mongo, because mongo: <a href="http://aphyr.com/posts/284-call-me-maybe-mongodb" rel="nofollow">http://aphyr.com/posts/284-call-me-maybe-mongodb</a><p>It erases event listeners on the client side with reactivity, so the vast majority of JavaScript libraries on the internet are incompatible with it.<p>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!<p>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.<p>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.<p>The built in less can't import recursively.<p>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.
"Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere."<p>Similarly, anal sex is the best kind because it works on all genital configurations. /snark
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.
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?
Derby (<a href="http://derbyjs.com/" rel="nofollow">http://derbyjs.com/</a>) 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.
<p><pre><code> 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.
</code></pre>
Just, no. When a client asks you to build an app, they are really asking you to solve a problem. <i>How</i> you solve that problem <i>might</i> 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.
Having made some fairly substantial web-apps using Meteor such as <a href="http://subtitles.fiddlware.com" rel="nofollow">http://subtitles.fiddlware.com</a>, 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.<p>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.<p>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...
I use Meteor alot.<p>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.<p>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.<p>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:<p>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.<p>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.<p>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.<p>RoR is nice but when it comes to a funky front-end user experience its not nice. The backend is loads of fun!
Just to add to the chorus of disapproval.<p>I got a white screen on my phone. Had to switch to my laptop.<p>Here's the thing. You're building a mainly content-driven site (still the bulk of websites).<p>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.<p>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.<p>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.<p>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.
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.<p>Rails may well find it's popularity and prestige diminished, but I doubt it'll "die" anytime in any of our lifetimes.
Josh, it's an increasing article.<p>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.<p>I would get more out of your article if you provide some context around the types of apps your company is focused on.
That's a bold claim to make when your blog can't function without cookies.<p>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.
> Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere.<p>Cancer is #1 disease in the world, but that doesn't mean I want it.
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.<p>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.<p>So is Meteor cool? Absolutely. And it could be great <i>if</i> it matures fast enough to still be relevant, <i>and</i> 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 <i>why</i> and <i>how</i> it worked.<p>So we'll see. But for now, Rails is untouchable.
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.<p>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 <i></i>lots<i></i> more features. Really no comparison. Unless you really dislike Javascript I suggest you try Meteor.
"The problem is when you start with something like rails then javascript was an afterthought - something bolted on long after the technology was built."<p>TCP: 1974
HTTP: 1991<p>Your point?
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?)
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).
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?<p>This makes about as much sense to me as "Why Flask will kill Zend".
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.<p>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?
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.
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.
For those saying Meteor is for toy apps, I just launched a fairly complex app written 100% in Meteor (yes, with paying customers): <a href="https://properapp.com" rel="nofollow">https://properapp.com</a>. Runs like a charm, easy to develop with, and not even 1.0 yet.<p>Don't dismiss the author, Meteor is going to change a lot.
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.
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!<p>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.<p>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.<p>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.
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?
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.
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, <a href="https://modulus.io/" rel="nofollow">https://modulus.io/</a> that's having problems?
Technically, you can use meteor with rails <a href="https://github.com/tmeasday/ruby-ddp-client" rel="nofollow">https://github.com/tmeasday/ruby-ddp-client</a>, so I don't know if meteor is killing rails anytime soon.
I think there is some degree of conflation here. You can have different views/communication for session state and separate that from database state.<p>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.<p>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.<p>Oh, wait, there's the first two problems in CS again — caching and naming things.
It's amazing for hackathons. I wrote <a href="http://battlehack.meteor.com" rel="nofollow">http://battlehack.meteor.com</a> in 24 hours by myself after having done meteor as a hobbyist for 2 months.
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".
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?
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.
> 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<p>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.
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?
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.<p>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.<p>I may be wrong, but I have history on my side.
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.<p>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.
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.
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?<p>Maybe it's common not to have good unit-tests? (integration/functional-test does not count as unit-test).
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.
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.
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.