Why Meteor will kill Ruby on Rails

As for sending JSON with rich clients vs. rendering HTML on the server; that depends a lot on the intended usage pattern of the app. For apps that you expect will be open for hours at a time, like e-mail or social networking, the former pattern is better - and indeed, GMail and G+ both speak JSON (well, a modified version that gives better latency) to rich client JS. For apps that you open quickly, perform your task, and then close (Search is the canonical example), it's far better to render all your HTML on the server and just ship that down to the browser. There is a large cost to downloading and executing all that JS, and you lose many, many customers if your app is slow.

There are strategic reasons why, if I were founding a startup today, I'd prefer to play in markets where the latter case held, unless I was writing enterprise software. Consumer markets where people spend hours with an app open are rare, and Google/Facebook generally want to own that space. I would rather not compete with them. On mobile, the open-for-hours apps are generally moving to native, where you can interact with the platform's notification API. The sweet spot for long-running webapps is enterprise and intranet applications, which has many fruitful markets, but many technologists shy away from it because there are frequently many arbitrary and difficult requirements.

First of all, I only claimed you have plenty of glueing in Rails (although you glue when working with anything, it's the degree at which I think is important).

Secondly, I was agreeing with about there being options, I didn't really reply to the "why Meteor", I think I went over that enough.

> I have used this stack extensively, and I must say its not even close to Rails. In fact it's not even on the same planet.

They are both used to build web applications, I think they have many similarities. But yes, they do have a wide range of strength and weaknesses.

> After all you guys finish your piddly todo lists, start trying to write some real business logic in Node, and see how far it gets you. There is a reason the Meteor team chose fibers. You can async.waterfall all you want but structuring your code in a synchronous manner, lets you get stuff done.

I don't find it exceedingly difficult to be productive in Rails, Meteor, or MEAN. Again, each has their strength and weaknesses.

And in terms of structuring code: async or not, you have plenty of options to properly organize it (eg: Deps.autorun, promises, npm's async).

> People tout Node and Meteor for real time stuff.

I think because it tools itself well there.

> I could do similar things with SSE and Rails/Ember or Angular.

Right, no one is taking Rails away from you.

> The users of your applications don't care if you use Websockets

True, most users won't care about the specific technologies used to load a page. But it could play a role in the experience, which is something they will care about.

> and really most of the time you don't even need Websockets, you just need SSE or long polling.

See, here's the thing "most of the time", but not all of the time. So there are cases for each.

Long polling has plenty of cons, and SSEs don't provide you with a bidirectional channel. That's important for some applications.

Non trivial example: client wants drag and drop uploads. What browsers support this functionality? Oh we can't do that in browser X Y and Z. Is that a problem? Oh, it turns out it is because manager A promised this to the CEO and she runs IE7 due to corporate IT policies. Crap. OK trade-off time, what should we do? Drag and drop for chrome that my boss runs or just stick to old school uploads? Use some plugin from jquery.com? OK let's do that. Now we have apparent 'automatic fallback' via the plugin but... boss wants it to display the image for confirmation in newer browsers, shit... Does the plugin support this? Yes? No? Let's say no now you're looking for another off the shelf or a roll your own.

Now you can say what you want about 'it should just work bler bler it's easy' but if you extract this attitude out to all areas of a software project you end up with the inmates running the asylum pretty much overnight. Like it or not, but the team or individual you are working with all have varied skill sets and you have to make work with what you have. The trick isn't 'just make it work with javascript off', it's 'deliverer something in the timeframe and on budget with the resources available' and those are different every time you embark on something.