Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

281–290 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#281
post #61

Earlier quoted context omitted.

So, now you agree with what carsongross originally asked? The client does just want an app and you believe you know better and foist a broken javascript app on them?

Broken javascript app? you're implying that all Meteor apps are broken?

I'm implying his are, based on the fact that his meteor blog is broken.

Re: Why Meteor will kill Ruby on Rails

#282
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…

  > .ajax = iframes
I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?"

I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013.

Why not XMLHttpRequest?

Re: Why Meteor will kill Ruby on Rails

#283

It depends on your definition of kill. 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. 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). I do agree that using one language…

Your feelings towards JavaScript essentially mirror mine, though I've found writing code in TypeScript for Meteor has been a much more pleasant experience and gives me more confidence in the code I write. https://github.com/orefalo/meteor-typescript-compiler http://www.typescriptlang.org/

Does typescript do type checking at runtime or just compile time? I was really excited about typescript initially, especially for use with Obvious Architecture, but then it looked like it was just compile time, not runtime checking which seems problematic to me.

Re: Why Meteor will kill Ruby on Rails

#284
post #183

Earlier quoted context omitted.

The most hilarious thing about this is how uncannily your claims mirror those that Rails had to deal with when it was new - people saw the easy-to-get-rolling-with scaffolds and assumed Rails couldn't make your app look like anything else. It took the better part of two years for people to stop saying so. The "smart, sensible people" condescendingly repeating "you need more than a _scaffold._" It was just as amazing…

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.

Re: Why Meteor will kill Ruby on Rails

#285

Earlier quoted context omitted.

Sure: http://www.shinglecentral.com/ http://assistant.io/ http://lister.io/ Are just a few from the last 1.5 months.

the details pages are all blank for me in FF: http://www.shinglecentral.com/opportunity/HwMGk8B2KgmCppn85

Yea, these don't work for me either. Clicking "Find opportunities", clicking on one, then clicking back also shows just a blank screen too.

Re: Why Meteor will kill Ruby on Rails

#286
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…

It shouldn't be extra work. It's actually less work because it encourages you to play to the browser's strengths and to separate your concerns. It keeps rendering speed high, it makes it easy to debug issues because you can switch off JS to see if the problem is with the underlying HTML/CSS. If one JS component fails it doesn't take down the rest of the site, and so on.

Your website should work in IE7. It's a legitimate browser with real users. This doesn't mean it needs to behave exactly the same way as IE10, but a visitor to my site using lynx should get some level of use out of it.

Again, this helps you massively in the long run because the browser scene changes all the time. If you work hard to make your site work across the browsers you know about, it's more likely to work on the browsers you don't know about, or the ones that haven't been invented yet. (It took the iPhone to take Safari from a browser that nobody cared about to the browser everyone cared about pretty much over night.)

Re: Why Meteor will kill Ruby on Rails

#287

Earlier quoted context omitted.

Then you probably don't eat spaghetti.

You must not be familiar with this utensil. It is a spoon with a fork like end. Many a plate of school lunch spaghettis has been eaten with a spork.

All of the sporks I have used have tines that are too short for proper spaghetti-twirling. Also, their bowls are always so shallow that it makes soup a chore to consume. What kind do you use?

Re: Why Meteor will kill Ruby on Rails

#288
post #97

Earlier quoted context omitted.

What does that have to do with any of the points raised?

I have more faith in open-source community to fix warts vs. closed-source Microsoft. I did ASP.NET back when it launched, and Microsoft wasn't setup to really listen to developers like the Meteor team is.

I work with ASP.NET ASP.NET MVC if open source. So is SignalR for real time. micro$oft, right

Re: Why Meteor will kill Ruby on Rails

#290

Earlier quoted context omitted.

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…

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 ?

jQuery does exactly that, with polyfills for browsers without the native implementation. jQuery 2.x does away with many of the polyfills since older IE versions aren't supported.

If you want an even smaller jQuery, you can build your own[0] without the modules you don't need.

[0] https://github.com/jquery/jquery#how-to-build-your-own-jquer...

Post reply on HN