Why Meteor will kill Ruby on Rails • Hacker News Board

Re: Why Meteor will kill Ruby on Rails

#201

Post by neya » Thu, Oct 31, 2013, 5:05 AM UTC

yelnatz wrote: post #200

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

Brilliant :) For a moment I thought if I was actually the only one here who found the core of facebook so easy to clone :D. Thank you.

Re: Why Meteor will kill Ruby on Rails

#202

Post by rywalker » Thu, Oct 31, 2013, 5:10 AM UTC

neya wrote: post #166

This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close…

@neya have you tried Meteor yet? I am a Rails dev since 0.8 — but since moving to Meteor the past few months, I'll not go back to Rails.

Re: Why Meteor will kill Ruby on Rails

#203

Post by 1qaz2wsx3edc » Thu, Oct 31, 2013, 5:12 AM UTC

neya wrote: post #197

1qaz2wsx3edc wrote: post #181

Earlier quoted context omitted.

Sure. No one is taking Rails away from you. I don't think it's bullshit. There are use cases for each. I think Meteor offers up a good debate about "how we do development these days", and attempts to answer them, albeit early. Meteor is still new, and it's path is currently bumpy. But it tries, and innovation is a wonderful thing, that's what Rails gave us early on. The sad thing about Rails is it largely stagnated f…

Thank you for your peaceful tone (unlike the author's). But I think there are a lot of opinions mixed up with your facts: >The sad thing about Rails is it largely stagnated for some time >You just have to do so much glueing >These are solved problems on node And to be clear, Node is not a 100% perfect platform either. >I think the author is attempting to elude to the cargo-cult that hit Rails will migrate to Meteor.…

> 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 the current situation.

Yea, there's a problem with how much you get for free with Rails (rubygems), and how much utility a framework provides you (AR, generators, etc). Right now those are areas that need improvement, but the community & time will improve those.

Re the awesomeness of generators: Yea, meteor doesn't have any, and in all fairness we're talking about something that isn't 1.0, but from a practical point of view: this is an easy task in Meteor and would only take 5-10 lines of code.

On something that rails doesn't have is dependency reloading. So imagine a world without `bundle install`. Meteor wants to streamline, it just hasn't gotten all the corner cases yet. It's still early, but it's still got a lot of bang for it's buck.

Perhaps some are jumping ship early or just want to get acclimated with new software in it's infancy. I just like both.

Re: Why Meteor will kill Ruby on Rails

#204

Post by joshowens » Thu, Oct 31, 2013, 5:13 AM UTC

general_failure wrote: post #161

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.

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?

Re: Why Meteor will kill Ruby on Rails

#205

Post by greendata » Thu, Oct 31, 2013, 5:15 AM UTC

misuba wrote: post #183

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…

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 time. He also mentions how meteor reduces context switching when developing. IMO those are signs of a very promising technology. I don't know if meteor will become practical or popular. All I know is if works and it's stupid, it's not stupid.

Re: Why Meteor will kill Ruby on Rails

#206

Post by joshowens » Thu, Oct 31, 2013, 5:17 AM UTC

neya wrote: post #166

This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close…

I'd be willing to go toe to toe on building a clone in Meteor while you build it in rails.

Re: Why Meteor will kill Ruby on Rails

#207

Post by nostrademons » Thu, Oct 31, 2013, 5:22 AM UTC

derefr wrote: post #89

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…

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 as fast if not faster, and there is far less that can go wrong. I'm not constrained by the idioms of the framework in development (this is a major problem with MVPs - all Rails/Django apps seem to end up looking like a bunch of forms over a database, even if that's not the best interface for users), and if one of the approaches works, I have an easier time productionizing.

For my most recent prototype, I started with JQuery (as usual) and then quickly end up removing it when I found that everything I used to use it for is now built into the browser. $ = querySelectorAll; .on = addEventListener; .addClass = .classList; .animate = CSS3; .ajax = iframes. And all of the browser native stuff runs significantly faster, and doesn't require that you download 90k of JS each time you want to refresh.

It's not 2006 any more. You can pretty much prototype in Webkit only, most of the things you need are built into the platform, there are easy minimalist libraries that will let you setup a JSON feed out of AppEngine with barely any code, and JS on the client can do pretty much everything. At least until you start caring about latency, but by then you're out of MVP range.

Re: Why Meteor will kill Ruby on Rails

#208

Post by sanderjd » Thu, Oct 31, 2013, 5:25 AM UTC

dustingetz wrote: post #180

neya wrote: post #166

This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close…

You have no idea what you're talking about. Like, your whole post is false

Care to expand on why you believe this to be the case? You may be right, but it's not obvious that you are.

Re: Why Meteor will kill Ruby on Rails

#209

Post by joshowens » Thu, Oct 31, 2013, 5:29 AM UTC

RockyMcNuts wrote: post #153

1qaz2wsx3edc wrote: post #139

Earlier quoted context omitted.

I don't think that's completely fair. Meteor to me, is more cased for building realtime applications. Should a blog be a realtime application? Probably not, can it? Sure. Not only that but, but the page compensated. It's also kind of neat, that the author has indeed written a realtime blog. For fun: they could magically fix typos while you're reading.

Or users could legitmataly highlight typos and they could get fixed in real time.

Great idea!

Re: Why Meteor will kill Ruby on Rails

#210

Post by joshowens » Thu, Oct 31, 2013, 5:31 AM UTC

xionon wrote: post #167

oliversong wrote: post #150

Earlier quoted context omitted.

To be fair, this is something that you can easily change if you prefer to take the site down while deploying. Hot code pushes are a feature. It's difficult to implement the same functionality with Rails, where the default is to be down while deploying.

It takes maybe a day working with your Capistrano script to implement zero downtime deploys in Rails if you're running Unicorn, Puma, or Passenger Enterprise...

A day we didn't spend for Meteor, for sure. Tradeoffs.