Why Meteor will kill Ruby on Rails • Hacker News Board

Re: Why Meteor will kill Ruby on Rails

#301

Post by hnriot » Thu, Oct 31, 2013, 4:12 PM UTC

nostrademons wrote: post #207

derefr wrote: 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…

that's all correct, but then you ruined it with the .ajax= iframes nonsense and the total waste of time removing jquery. optimizing for the right things is important, but doing the wrong ones is just wasting your time.

Re: Why Meteor will kill Ruby on Rails

#302

Post by DharmaSoldat » Thu, Oct 31, 2013, 4:25 PM UTC

joshowens wrote: post #142

jarsbe wrote: post #119

Earlier quoted context omitted.

I'd love to see some examples of these apps, are you able to please share?

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

I'm sorry but those look like toys. I'm with buddy here, could you please give me an example that is more complex in nature?

Re: Why Meteor will kill Ruby on Rails

#303

Post by DharmaSoldat » Thu, Oct 31, 2013, 4:28 PM UTC

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…

I hear ya... from what I can see it looks like it would be great for rapid prototyping, even big systems... however why anyone would go with a JS-backed framework for a serious application is beyond me - it's just not ready as a language (and a framework)

Re: Why Meteor will kill Ruby on Rails

#304

Post by buu700 » Thu, Oct 31, 2013, 4:34 PM UTC

hippee-lee wrote: post #185

joshowens wrote: post #142

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.

Can you point to some example that are a bit more complex in nature? My issue (that I identified with the backbone tutorials and re affirmed with the Angular tutorials) is that simple apps are easy to do with x, y or z. But if the new one or that one is going to replace the old one there should be 37 signals level complexity type apps out there. While I can't speak for Meteor, I don't see anything running on angular…

napster.fm is a fairly non-trivial Angular application; Angular was pretty fantastic to work with.

Re: Why Meteor will kill Ruby on Rails

#305

Post by kazagistar » Thu, Oct 31, 2013, 4:39 PM UTC

bluedino wrote: post #293

hyperbovine wrote: post #284

Earlier quoted context omitted.

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?

And more importantly, I am pretty sure most startups would gladly have twitter's scaling problems in exchange for being the next twitter.

Re: Why Meteor will kill Ruby on Rails

#306

Post by hyperbovine » Thu, Oct 31, 2013, 4:41 PM UTC

bluedino wrote: post #293

hyperbovine wrote: post #284

Earlier quoted context omitted.

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?

Admittedly very few, although I did run into performance issues on Rails sites handling orders of magnitude less traffic. It's an interesting use case though -- tough to imagine a simpler web app than circa-2006 Twitter. Tellingly, they ultimately threw up their hands and moved it all to Scala.

Re: Why Meteor will kill Ruby on Rails

#307

Post by pa5tabear » Thu, Oct 31, 2013, 4:45 PM UTC

yefim wrote: post #235

arocks wrote: post #218

Earlier quoted context omitted.

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.

So do you do you think Meteor can scale? I don't know if I'm following, but I'm assuming limiting the queries(?) means limiting the size.

Re: Why Meteor will kill Ruby on Rails

#308

Post by awj » Thu, Oct 31, 2013, 4:48 PM UTC

ulisesrmzroche wrote: post #174

nikatwork wrote: post #155

Earlier quoted context omitted.

GP is expressing a personal language preference. I also find JS horrific to work with (and I've worked with it a lot). But that doesn't mean you can't or shouldn't enjoy it.

Horrific is really stretching it too though. I know it's Halloween or whatever but let's just discuss it on technical merits before passing misinformation like that.

> Horrific is really stretching it too though.

I'd love to hear how you're better acquainted with 'nikatwork's feelings on JavaScript than he is.

Re: Why Meteor will kill Ruby on Rails

#309

Post by awj » Thu, Oct 31, 2013, 4:51 PM UTC

porker wrote: post #246

JPKab wrote: post #42

Earlier quoted context omitted.

This is what Java guys said about Rails. "Hipness" is absolutely unrelated to whether something is actually good or not. I firmly believe that Meteor is a super fast way to build a certain kind of web app that just so happens to be very popular in businesses: CRUD apps where users can see other user's changes to data in real time. I will admit that older users are actually creeped out by other people seeing them type…

I missed out the first time around because the Rails community was full of fanboys and nothing turns me off a community more than zealot-like behaviour. I don't want to miss out again.

Then evaluate things on their merits and ignore the fanboys. There are plenty of people in this world looking for silver bullets, that someone excitedly claims to have found one is no reason to believe them.

Re: Why Meteor will kill Ruby on Rails

#310

Post by DCoder » Thu, Oct 31, 2013, 4:54 PM UTC

programminggeek wrote: post #283

beefsack wrote: post #99

Earlier quoted context omitted.

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.

TypeScript only does enough run-time argument checking to support default argument values.

Full run-time type checking would have overhead. It would also be unnecessary in places where data flows from Typescript function to Typescript function — those places should already be foolproof after the compile-time checks.