Scaling is good, having your website actually work is IMO better.
Looks like it's the header and footer joint together waiting for content to appear in between delivered via websockets.
Never tried Meteor but I don't get the point of using websockets for blog posts unless it's purely for learning. Does Meteor encourage such use of websockets? If yes, why? (Genuinely curious)
I also think it is cool that I can fix typos realtime while people are reading.
But it's not going to 'kill' Rails any more than Rails killed PHP. I've seen loads of frameworks and indeed developers pop up who have taken the great ideas that frameworks like Rails had, and incorporated them into PHP projects. No doubt we'll see the same over time as new frameworks and tools arise elsewhere. And ultimately what we want is a better, more diverse selection of tools which are competing with and learning from each other.
Would I build a production app in Meteor? Almost certainly not. I'll probably have a crack at a prototype sometime soon (last time I tried, it was too underdeveloped to use) and no doubt I'll learn a bit on the way. But Differential's site is not an encouraging example - it requires JS, feels pretty slow and broken in places, and offers nothing that couldn't be executed as well (or better!) using any other toolset or framework.
This is a trend that I sort of understand, but in another way entirely baffles me. While front-end apps are awesome, in this case the content could easily be compiled and served immediately with the page. This would make the load huge amounts faster, and a lot less confusing when every single user shows up and sees a header and collapsed footer every time they visit the page (no cacheing with this ajax method).
On the other hand, like some other people mentioned here, there are cool benefits to running js apps. A realtime post count is a nice tweak you couldn't have with an entirely static site... wait, or is it? No, you definitely could. Have the blog post content as static and then a snippet of js connects to your server's socket and displays the count as soon as it can.
I've seen a lot of people jump all in onto trends in building web apps when they make no sense, and this kind of bothers me. Blogs especially should be static, always. There is simply no reason to be hitting a server every time someone hits your blog, and especially no reason to be hitting an ajax call on page load, because this just makes the blog slow and puts additional unnecessary load on your server. (The number of sites running wordpress that could easily be static and would be much faster and less expensive that way baffles me - a problem begging for a solution.)
So I guess my conclusion is that while I am sure Meteor has a lot of value for real-time intensive apps, it is a ridiculous decision to use it for something like a blog. As web developers, we have a large toolset and the luxury to choose among hundreds of awesome, mostly free tools for any project we work on. Don't get stuck in the mindset where you have one tool that solves every problem (I saw a lot of people do this with rails too) - engineer your app to be the quickest and most efficient it can be : )
- When I first hit the linked blog post, I saw a blank page for four or five seconds. Not so bad, because I know what's happening, but jarring.
- Then I see a footer for five or six more seconds, with no page content. Again, I know what's happening, but I can see that looking sketchy for people who aren't developers: https://www.dropbox.com/s/d1mezohgixlneeu/Screenshot%202013-... - and it's going to be worse on a slower connection.
- I see that same view on several different pages when I initially navigate to them.
- Hitting the home page occasionally freaks the browser out. I don't know what it's doing, but I get multiple animations of the main banner and some flickering etc.
I may have been a bit dismissive - sorry about that. I do get that "dogfooding" a tech stack as it were is pretty important. What Meteor's going to be good for though is highly-interactive, collaborative apps, and it'll be really nice to see some demos of that, rather than yet-another-could-be-static site.
(Meteor doesn't appear to trap exceptions when using localStorage/sessionStorage, and even something as simple as "if (window.sessionStorage) ..." may throw an exception.)
And for the record, I really dug that feature. I often wonder exactly how valuable HN exposure is, it was nice to see a real metric.
Would i build my production app in meteor right now? For a prototype, yes. Would I transition from an established web application with a large userbase to meteor? Almost definitely no, at the current stage. But what we glorify here in this startup culture is to get an idea out and see if it works, and Meteor is absolutely amazing for exactly that. The simple deployment, the ease of use, and the freedom to build the structure as you choose (for better or for worse) truly opens many, many more doors than it closes at the early stage.
I'm no fanboy but I'm very excited to see where Meteor heads in the future and am extremely glad that it continues to gain traction and attention, be it positive or negative.
The main reason to not use it was scaling but It's evident the meteor guys are working on that for the 1.0 release. (See https://trello.com/board/meteor-roadmap/508721606e02bb9d5700...)
Hopefully they do this well but I feel from their work before they will. I've been using Meteor since it was sub v0.2 and its just improved each iteration.
First it was the license, then authentication, then it was routing, then its ability to play well with JQuery. Slowly all of the issues with it are disappearing.
One thing I like is in meteor code is isomorphic. And on the server I'm not in the callback hell I was having with node. So there are evented fibers that do all this stuff and the code remains clean! Best of both worlds.
They've really done a lot of work. The jump from 0.6.4 to 0.6.5 was 775 commits. Wow. We're seeing concepts being fleshed out, they'll be refactored and strengthen in time. The team seems to be fully focused on 1.0.
Scalability is still a big concern, but it's only a problem you can be so lucky too have.
Meteor still needs to improve code structure, there's no common architectural pattern yet (just some lose guide lines). In my opinion, it would be a benefit. Meteor is still in its infancy and a developer is left to their own devices, rather then common sharable patterns. Rails does this well with the plethora of use-case strengthened API design, a benefit of it's maturity. Meteor will get there.
The JS runtime is nearly, or is now perhaps, perfectly capable of being what your own language "compiles" to - for instance, I love Ruby so I'm betting on Opal (execute REAL client-side Ruby). Others like JS variants such as CoffeeScript or TypeScript.
So...Rails isn't going to get killed - it's simply going to evolve to support rich real-time client + server apps written in Ruby, period. That's my take on it, anyway, and that's what I'm planning on.
On the topic of constructive criticism, differential.io could really do with ditching that "We work at Cintrifuse" interstitial before the blog post is displayed. In the spirit of being constructive, I will simply say that my experience as a reader would have been vastly better without it.
My mind initially had trouble accepting the changes in how to think about data and reactivity, but I think it has been worth it in the end. Very much a "there is no spoon" type of moment.
If you are looking to get into Meteor, check out http://yauh.de/articles/376/best-learning-resources-for-mete... and be sure to join http://crater.io to keep up on the latest news.