Live data from Hacker News

Why Meteor will kill Ruby on Rails

differential.io

161–170 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#161
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 fail to see how meteor helps build these sites. These can be built by normal CMS can't they?

Re: Why Meteor will kill Ruby on Rails

#162

Earlier quoted context omitted.

Insecure is there to help speed development when you are getting started. All frameworks can do their best to compensate for security holes, but ultimately people need to pay attention to it. That being said, Meteor offers a call method and code runs on the server - if security is a concern then you should pay attention to what happens on the server.

I've not used Meteor. How exactly does "insecure" help speed development? Certainly any code you write with it is worthless, right? I mean, before production you need to remove it and rewrite it using another method, so what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-like data access console?

From meteor.com:

>By default, a new Meteor app includes the autopublish and insecure packages, which together mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools, but typically not appropriate for production applications. When you're ready, just remove the packages.

Re: Why Meteor will kill Ruby on Rails

#163
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'm not going to sing the praises of Rails. I think it is a pretty good framework, but it is one hell of a hype machine. As software gets older and more stable, people get bored and reinvent the wheel again, especially web developers that will stop at nothing until everything is written in Javascript. Rails was a fad. Meteor is a fad. Keep your nose out of hype.

Fads are good. Being able to run everywhere is also good, but frameworks eventually need to give way to new ideas. Not everyone wants to program in COBOL on .NET forever.

Re: Why Meteor will kill Ruby on Rails

#164
post #57
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…

They were right when they said that about rails though. Rails was a fad. It was not good. It codifies industry worst practices into a framework that can most charitably be described as "writing PHP in ruby".

Are we talking PHP before or after CakePHP?

Re: Why Meteor will kill Ruby on Rails

#165

Earlier quoted context omitted.

Insecure is there to help speed development when you are getting started. All frameworks can do their best to compensate for security holes, but ultimately people need to pay attention to it. That being said, Meteor offers a call method and code runs on the server - if security is a concern then you should pay attention to what happens on the server.

I've not used Meteor. How exactly does "insecure" help speed development? Certainly any code you write with it is worthless, right? I mean, before production you need to remove it and rewrite it using another method, so what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-like data access console?

It makes it easy to run DB calls from the chrome console to insert and modify test data

Re: Why Meteor will kill Ruby on Rails

#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 to the scale at which rails gets things done. I truly mean it. And something built out of Javascript replacing a Ruby-based full-bleed framework? I think you must be fucking kidding me. What the author describes is a very specific use-case and maybe, just maybe Meteor JS might replace a portion of that use case. In fact, if I were to do something like what the author suggests, I would still choose rails and Knockout JS (or Angular JS if you know it better).

Do you know how long it takes to build a Facebook backend clone in rails? Maybe a day? And the frontend (all the Ajaxy stuff) should probably add a week or two (worse-case scenario). That's just it. That's the power of rails.

If you were to build the backend in Javascript without the power that Rails provides I'm sure you will need more than just a day, let alone a week.

The point is, nothing is close to what rails is right now. I badly wanted something to replace rails for my work, but I haven't found a single solution that fits my needs. I've tried everything - Play, Sails, Revel, Gorilla, etc etc. But nothing there is that can replace rails. And all the frameworks that claim to be more like Rails, they're simply not true. Have you tried using play (Scala) and PostgreSQL together? The experience is nothing like Rails.

I can make a clone of any complex app out there in the web in a matter of minutes/hours. That's the power that rails gives me and no other framework/combination can't.

I understand that Rails is slow. But this is not the right way to critique it - Claiming something is going to replace it when it actually isn't true.

We develop all our v0.1s in Rails in house and port them to Go (only if necessary and if the project owner is particular about it.) and that seems to work well for us.

Re: Why Meteor will kill Ruby on Rails

#167
post #116

Earlier quoted context omitted.

My skepticism here is due to the use of an "app in my browser" to display a static blog post. A blog post is fairly simple static content. My browser is an app that does fine at displaying it. By making the page an app that dynamically updates upon server changes, you actually substantially damaged my experience, as I was interrupted in the middle of reading the page. I'm not opposed to apps which dynamically update…

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

Re: Why Meteor will kill Ruby on Rails

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

>Do you know how long it takes to build a Facebook backend clone in rails? Maybe a day?

A basic social network clone? Sure, maybe a day. But to emulate all the features Facebook has would probably take well over a month if done alone, even if the dev was very experienced with Rails.

Re: Why Meteor will kill Ruby on Rails

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

>Do you know how long it takes to build a Facebook backend clone in rails? Maybe a day? A basic social network clone? Sure, maybe a day. But to emulate all the features Facebook has would probably take well over a month if done alone, even if the dev was very experienced with Rails.

Well over a month to clone all of facebook. I hope you don't estimate as a living. To clone facebook would take well over a year.

Re: Why Meteor will kill Ruby on Rails

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

Actually, Microsoft did listen to their ASP.NET developer userbase. And ASP.NET developers loved them for it. And yet, despite Microsoft listening to their users, we're still not enchanted with ASP.NET... what gives?

Lets say a framework's user base consists primarily of language-specific consultancy shops that really desire tools for rapidly prototyping applications. And the framework authors listen to these users diligently. You'll likely have a product that's really good at rapidly prototyping applications inside a consultancy. What about people who aren't language-specific consultancy developers? Well if you have a similar use-case you'll surely be happy!

Meteor and Rails strike me as Apples and Oranges - Rails is a general purpose framework that assumes a separation of systems between client and server (And optionally separation between server and database if you forgo Active Record). Meteor assumes you want a tightly coupled, real-time, rich JavaScript web application.

The author assumes Sauce for the Goose is sauce for the gander... but judging by the lack of ASP.NET around here I'm not sure that's the case.

Post reply on HN