Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

Post reply on HN
Print view View original

291–300 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#291

Post by mattgreenrocks »

bjourne wrote: post #92

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

Most frameworks aim squarely at programming in the small/medium scope.

The Big Lie is that you should outsource your design to them completely, because the people who designed them are smart. Nobody ever calls out the implicit appeal to authority there.

Re: Why Meteor will kill Ruby on Rails

#292

Post by Grue3 »

ryan-allen wrote: post #272
Grue3 wrote: post #263

Earlier quoted context omitted.

There's no reason why server-side javascript cannot generate static HTML.

There is when the client doesn't want to pay for the extra work for the 0.1% of tinfoil hat-wearing people who turn off JavaScript. "You need to spend an extra 30,000 to get this to work for the 3 crypto-anarchist wannabes who live in your state". I don't think the client is going to want to pay for that kind of interop. EDIT: I don't mean to be snarky but you absolutely HAVE to make these kinds of trade offs when wo…

I think you're ripping off your client if such basic functionality as displaying a static page on a website is "extra work" for you.

Re: Why Meteor will kill Ruby on Rails

#293

Post by bluedino »

hyperbovine wrote: post #284
greendata wrote: post #205

Earlier quoted context omitted.

I was thinking the same thing. There were literally the same arguments against rails in 2006-2008: - it won't scale - too much magic - it's is too opinionated. Only good to do things one way - it's ok. but only for toy apps - I can do that easily in X framework, language (php, java, and now rails) - these are just toy example. can you do anything "complex" The author says this is significantly cutting down on his dev…

FWIW Rails did not scale well during that time period. (One word: Twitter.) I don't know what the situation is like now but performance was a serious issue with rails in the early days.

What sites are going to have Twitter's scaling problems, though?

Re: Why Meteor will kill Ruby on Rails

#295

Post by general_failure »

joshowens wrote: post #204
general_failure wrote: post #161

Earlier quoted context omitted.

I fail to see how meteor helps build these sites. These can be built by normal CMS can't they?

Sure they could. Maybe we could just switch to assembler?

Wow. Did you just compare a cms like WP or Drupal to assembly language?

Re: Why Meteor will kill Ruby on Rails

#296

Post by edwinnathaniel »

joshowens wrote: post #77
edwinnathaniel wrote: post #36

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

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

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.

Re: Why Meteor will kill Ruby on Rails

#298

Post by jaegerpicker »

dham wrote: post #269
1qaz2wsx3edc wrote: post #203

Earlier quoted context omitted.

> And to be clear, Node is not a 100% perfect platform either. Absolutely. But as a software piece, I think it can apply itself to the web more easily than Ruby currently can. > Of all the options available, why Meteor? Right, there are plenty of options, MEAN is getting nicely popularized. You also have Derby. > Like someone on this thread said, it has a lot more evolving to do, to even become on par with rails in t…

First you say > . You just have to do so much glueing In your previous post. Then you list out MEAN(Mongo, Express, Angular, Node), which is all glueing. 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. 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…

Yes because no one has built real business logic in node.js. and clearly node.js is only good for piddly todo lists. I've worked with python/Django, rails, and node.js on real complex apps with huge amounts of business logic built in them. Each one had advantages and disadvantages. I will say that MEAN certainly compared very well to both type of apps once in production. I was more productive in the other two but performance and scaling were far easier on node. You like rails, that's great but if you dismiss node and other approaches that's your loss. You'll be a poorer developer for it.

Re: Why Meteor will kill Ruby on Rails

#299

Post by mbesto »

bowlofpetunias wrote: post #43

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…

I'll just leave this here:

Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer. All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables are identical, but the utility is different. Now let’s say your utility as a carpenter is 5 (we’ll call this carpenter ‘ME’). The value of the tables is now: Table A – 50 and Table B – 75. Now, my carpenter friend (we’ll call this carpenter ’FR’) has a utility of 4 and he builds the same tables using the same respective hammers. He now has two tables at the following values: Table A – 40 and Table B – 60. So we can build a simple comparative matrix now. Table B built by FR has a higher utility than Table A built by ME but it was built by a less skilled carpenter! We therefore logically assume the hammer is the key driver for the overall utility, not because it has a higher multiplier, but because we believe we have better ability over assessing what the utility of the hammer is. We then therefore place much more importance on it.

http://www.techdisruptive.com/2012/06/29/the-cyclical-nature...

Re: Why Meteor will kill Ruby on Rails

#300

Post by awj »

joshowens wrote: post #211
awj wrote: post #111

Earlier quoted context omitted.

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.

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

...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.
Post reply on HN