Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

231–240 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#231
post #191

Earlier quoted context omitted.

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…

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)

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 :)

Re: Why Meteor will kill Ruby on Rails

#233

Earlier quoted context omitted.

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 ?

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+).

Zepto has an IE10 branch: https://github.com/madrobby/zepto/tree/ie10

Re: Why Meteor will kill Ruby on Rails

#235
post #218

Earlier quoted context omitted.

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

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

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.

Re: Why Meteor will kill Ruby on Rails

#237
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.

Re: Why Meteor will kill Ruby on Rails

#238

  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.

Re: Why Meteor will kill Ruby on Rails

#239
post #89

Earlier quoted context omitted.

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…

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 a…

doesn't require that you download 90k of JS each time you want to refresh.

wait...what?

Re: Why Meteor will kill Ruby on Rails

#240
post #89

Earlier quoted context omitted.

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…

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 a…

> and doesn't require that you download 90k of JS each time you want to refresh.

That's what caching headers are for. You can effectively cache your "big" JS libs indefinitely on the client, as you'll change the URL and therefore require a fresh download when the lib gets updated.

This isn't to say that cold cache performance isn't also important, but even a slow DSL connection should be fine with a once-off jQuery download.

Post reply on HN