12 ms·

Went Off The Rails: Why I'm Rebuilding Archaeopteryx In CoffeeScript

209 points by mnazim 15y ago

deleted 15y ago
[deleted]
railsjedi 15y ago
I'm not ready to ditch rails yet, but I think the framework (and Ruby itself) needs an intervention. Bundler, Ruby 1.9.2, 1.9.3, and a ton of gems are all making life harder than it used to be. I have faith the community is self critical enough to identify these problems and fix them. Posts like this are needed though to give us all a kick in the ass and make things better.
- mnazim 15y ago
  I don't think the author is hinting at ditching rails altogether. IMO, he is just pointing out his disappointments, starting at the start and doing what he thinks is good for him.
- Fluxx 15y ago
  How are things harder with these technologies?
  - railsjedi 15y ago
    Having to learn the ins and out of bundler `bundle exec, update, --without :darwin`.. just to use a package handler. I had growl_notify installed, and now we've forced our team to be mac only because we got tired of dealing with linux issues. Ruby Debug is impossible to get working in 1.9.3. The maintainer of ruby-debug has gone AWOL so we're forced to deal with solutions like this http://blog.wyeworks.com/2011/11/1/ruby-1-9-3-and-ruby-debug http://blog.wyeworks.com/2011/11/1/ruby-1-9-3-and-ruby-debug that don't work within bundler or a team environment. 1.9.2 + Rails 3.x is attrociously slow (30+sec). With falcon (a very unstable ruby hack) the startup speed goes to 10seconds. But 10sec is still way too slow Sorry, it sounds bad when I just rant. In the grand of scheme of things, Rails makes me more productive as a web dev than I ever thought possible. It's just easy to pull out the daily frustrations and complain. I've been trying to help fix these issues but they are so dependent on a web of gem authors, and core ruby fixes that it takes an extraordinary amount of time. I'm almost to the point where I think things need to be fixed top down. Matz needs to take control and try to make stuff not suck as soon as possible. Since he's working for Heroku now, it's in his best interest to push the platform and keep new users engaged.
    - rohitarondekar 15y ago
      You don't have to use Bundler. Just delete the Gemfile and manage the dependencies yourself.
      - subwindow 15y ago
        The problem is that there's no third option- something to manage dependencies that's not bundler. We all want and need dependency management, but bundler should not be the One True Solution.
        rohitarondekar 15y ago
        Write your own? I'm sorry but if Bundler doesn't solve your problem (or introduces other problems) either try and fix those issues OR write your own dependency management lib.
        secoif 15y ago
        And discussions like this, raising awareness and exchanging ideas, are a part of getting the problem fixed.
        rohitarondekar 15y ago
        The correct place for these discussions is on the issue trackers & mailing lists of Bundler.
        sha90 15y ago
        The unfortunate reality about writing your own new Bundler is that you'll inevitably end up rewriting Bundler. Isolate is basically just a mini-Bundler with a different (arguably simpler) storage location, but the storage location is really not where the complaints about Bundler are coming from. Rewriting things just to shed complexity or "bloat" will often just put you in a position where your library just can't do things it will need to do, and then you end up rewriting those things and adding back the complexity. It's the circle of life. Lack of SCM support in Isolate is a good example-- I'm pretty confident that Bundler's support of git is heavily used and taken for granted, but if you were to rewrite or use a simpler dependency manager, you're throwing this out. This point feeds back into the larger issue of Rails vs. Node, I think. Rails ended up with all the complexity it has now because it was [mostly] necessary-- not all of it was, but much of it was. The idea that you're somehow liberating yourself by shedding complexity is often just the short-sighted pleasure of running faster test suites. And it's usually followed by a little bit of claustrophobia when you realize you can't do X, Y, or Z anymore. Wait until the claustrophobia kicks in, because it will. And the solution to this claustrophobia? More cowb-- complexity.
- mtkd 15y ago
  I'm not sure the community is self critical enough to fix the issues. The maintainers are highly opinionated and have shown very little concern about the bloat up to now - mitigating it by targeted optimisations not by removal of bloat itself. The community will just move on to something less bloaty - many Rails developers I know spend more (side project) time with JS now.
mtkd 15y ago
Rails is very suited to big API projects now - but there is no escaping the fact that all the action is moving clientside. The Rails learning curve is now very steep for new users and the accusation that it has become all it set out to solve is a fair one. For me it's a mature/stable framework and ripe for using commercially now, but I can understand the new kids gravitating to something more disruptive.
- troyk 15y ago
  agree plus add Rails is very well suited for the client side hotness with the asset pipeline in Rails 3. However I just tossed Rails after many years for 2 primary reasons: 1) Anything that might take a sec or more has to be moved out of the request cycle and into a background process. That just gets annoying after a bit. Node.js can serve requests, grab data from to world's slowest API's, send emails, etc, all from a single process. 2) Although I think Ruby's strong point is readability and succinct LOC, it's hard to beat using the same language for everything and not context switching. Maybe my brain is broken, but I used to drive myself nuts writing client js and using Ruby's nil instead of null and Object.new instead of new Object. For the project I'm working on now, I had to make my own asset pipeline. It uses less for css (and bootstrap), precompiles handlebar templates and concats all the js into a single file and uglifies it. Cost me 2-3 hours, about the same time it took me to learn Rails asset pipeline and was about 10x more fun. Last point I'll add is when Rails was a baby it made fun of all the xml configs etc that other frameworks bogged developers down with. Now it's grown up a little, and although sprocket and yaml files aren't xml, the concept is the same. If you've been around Rails for awhile and dive through the code of project like Spree, you just scratch your head and little simple things like node appear shimmering sexy!
  - rimantas 15y ago
    > For the project I'm working on now, I had to make my own > asset pipeline. It uses less for css (and bootstrap), > precompiles handlebar templates and concats all the js > into a single file and uglifies it. Cost me 2-3 hours, > about the same time it took me to learn Rails asset > pipeline and was about 10x more fun. Sounds familiar: http://documentcloud.github.com/jammit/ http://documentcloud.github.com/jammit/
fullmoon 15y ago
You can't compare a web framework with an event reactor.
- karterk 15y ago
  Actually, node is also a web framework. It's just not a web framework to build CRUD apps like Rails is tailored for. So, it all depends on how you define what web is.
  - fullmoon 15y ago
    Node is a web framework because it has a HTTP server built in? By this logic, EventMachine is also a web framework
karterk 15y ago
As far as Node goes, there is still no "holy grail" framework that can help one build a web app seamlessly across both client and server side. The momentum will definitely shift heavily towards Node if and when that happens. Right now, there is still a lot of manual glue work needed to set-up a client side MVC app using Node + Backbone while also taking care of graceful degradation etc.
- jeswin 15y ago
  Should we really worry about graceful degradation anymore? Personally, I don't waste much time on this like I did years back.
jamesu 15y ago
This came across to me as a long rambling rant which amongst other things interchangeably referred to ruby as both "ruby" and "rails", but i got the feeling it was more about bashing rails. Rebuilding something because the older stuff is is "bloated" and the new stuff is somehow superior always seems like a weak excuse to me. The new stuff quickly becomes the old "bloated" stuff and you're back to square 1. In fact I have no doubt that within 5 years something else new will come along and perhaps Giles will be writing another article about "Node Went Off The Script: Why I'm Rebuilding Clyde In TheNextBestThing". Personally I would rather concentrate on making something which is actually good in its own right.
- batista 15y ago
  In fact I have no doubt that within 5 years something else new will come along and perhaps Giles will be writing another article about "Node Went Off The Script: Why I'm Rebuilding Clyde In TheNextBestThing" Which possibillity he mentions in TFA. But this is what we call progress (or, to a more bitter viewpoint) change. It doesn't stop.
  - hello_moto 15y ago
    Aside from async, I don't see a single drop of progress moving from Rails to Node.JS.
    - ascendant 15y ago
      Much smaller memory footprint, faster execution times, consistency of writing your server code and client code in the same language, etc. You could say all of these things are subjective, but so is the word "progress".
betageek 15y ago
tl/dr Rails is not the new hotness anymore, the Rails 3 rewrite was a waste of time and it's strayed far from its initial ease of use. Node & Coffeescript, the new hotness, are awesome, here's my new video series, the first one's free.
- kristianp 15y ago
  Thanks for the tl/dr, that post certainly needed one.
- drostie 15y ago
  You missed the most important part: And as for overly ceremonial code, let me tell you about my balls. I actually have a rake task to scratch my balls. Somebody told me a good entrepreneurial programmer writes code to scratch their own itch, and I took them literally. The code uses a serial port to power an Arduino board. The Arduino's got a servo with a backscratcher attached. I keep it on a shelf at scrotum height underneath my desk. I literally need to type bundle exec every single time I want to scratch my balls. I don't like having to type bundle exec every single time I scratch my balls. I named the task balls, so I can type rake balls, because it rakes my balls, and Bundler pisses all over my tidy syntax, but am I going to complain? Am I going to point out that asking me to type bundle exec every time I want to scratch my own balls shows incredible contempt for me as a user, particularly considering that the whole reason I'm a user of this particular thing is because I work in a language which was designed to optimize for programmer happiness? Of course not. It's not productive or helpful to say that, so I simply type bundle exec rake balls and scratch my balls in sullen silence. Typing bundle exec every single time I want to scratch my balls is the epitome of the overly ceremonial code which Rails defined itself against from 2005 to 2007. The problem with tl/dr is that it misses out on the funny. :-(
  - zedshaw 15y ago
    Nope, the tl;dr didn't miss a thing.
    - functionform 15y ago
prosa 15y ago
I love Giles. His first Archaeopteryx talk was one of the best Ruby-related talks of all time. He's way too harsh on Rails though. The original "blog in 15 minutes" demos that catapulted Rails into the limelight are still possible with Rails 3. Things like 'gem install rails' still work. If you are determined to skip bundler, you can do that too. What's more, unlike 2005, in the 15 minutes it takes to build a Rails blog, you can deploy to Heroku and have a live site running. Node is fun. V8 smokes MRI. But Node's web framework ecosystem has a long, long, long way to go before one can reasonably say that Rails is a bad investment. If anything, we should be celebrating the number of options that are open to us. It's a great time to be developing for the web. Good things will come from Node's ascendancy, whether its frameworks dethrone Rails or not. The negativity is unnecessary.
- fullmoon 15y ago
  I'd go further and say, that it will be very hard to have a good MVC framework with Node before the async callback mess is brought under control. Maybe we'll even need something like Iced CoffeeScript for this.
  - ypcx 15y ago
    The async callback mess is not really a problem, there is about zillion patterns and libraries to handle it. The problem is error handling in callbacks, capturing stack traces from the async parent callers, and generally not crashing Node if you forget to try/catch your async handler. However, this problem is known, and this is being worked on in the form of "domains". Btw. Iced CoffeeScript doesn't solve this a single bit.
    - stock_toaster 15y ago
      > The async callback mess is not really a problem, there is about zillion patterns and libraries to handle it. Doesn't that seem to imply that it is such a problem that people have come up with a myriad of disparate solutions to try to solve it?
      - 15y ago
bad_user 15y ago
Rails has always been bloated. That's what you get from frameworks that come with automation for common tasks. However, let me provide a counter-point ... I think that Rails 3 is finally a good framework that I want to use. Blogs written in 5 minutes (which you can still do in Rails 3) have never impressed me. What impresses me is code-reuse, modularity and readability. Which is why I preferred Django instead of Rails 2. The biggest reason was that I can read Django's source-code, but Rails (prior to 3) was really awful in that regard and cargo-culting is OK, but only when you're starting out. Node & Coffeescript are indeed cool and have their place. However I prefer mature frameworks that save me effort when building yet-another-admin or yet-another-facebook-login. Not pursuing hotness is the new hotness IMHO.
- irahul 15y ago
  > Blogs written in 5 minutes (which you can still do in Rails 3) have never impressed me. I don't know. I liked the rails 5 minutes blog demo. I wasn't into rails from the beginning - I followed the recent one http://guides.rubyonrails.org/getting_started.html http://guides.rubyonrails.org/getting_started.html I think it's the ideal example for demonstrating a web framework. 1. It gives basic introduction to the framework and installation notes. 2. It's simple enough to follow, yet large enough to show major aspects of development with rails. 3. It shows all major aspects of the web application development - db access layers, db creation and migration, models and validation, request routing, controllers, views, partials... > What impresses me is code-reuse, modularity and readability. Which is why I preferred Django instead of Rails 2. I use both Django and Rails. Rails has various stuff which I need for a basic app out of the box, which Django doesn't have - asset pipelines, coffeescript integration, swappable templates, bundler for dependencies, rvm(not exactly rails) for isolating ruby version and gemset, tested gems for basic tasks(kaminari, devise, paperclip) etc. I know I can do all of it in Django/Python(pip, virtualenv, coffee --watch, webassets etc etc), but rails sets up things for me and I can begin coding. Rails does require more peripheral knowledge, but it's optimized for people who know rails. Beginners will be more at home with Django, but you are a beginner for a very short period of time, and optimizing for beginners while forfeiting comfort for people who are on-board isn't a good compromise IMO. In an ideal world, we can have frameworks which is both beginner and power-user friendly, but I seldom see it happening it in the real world. As far as reading code goes, I have trouble following Rails code, and my only friend is the interactive debugger - I set breakpoints, read code in the editor, continue, break... I haven't read Django's code in a while, but it used to be quite heavy on magic - not sure about the current status.
DanielRibeiro 15y ago
As Smalltalk creator Alan Kay said: "Once you have something that grows faster than education grows, you’re always going to get a pop culture." This is so true in so many levels, that I feel I bit sad just thinking about it.
- Jare 15y ago
  Why? Exploration and evolution are in many ways the opposite of education, but that doesn't mean they are bad things.
ajsharp 15y ago
Glad you published this Giles. I really think you hit the nail on the head in your criticism of rails, and not necessarily ruby. I think some of the framework decisions in the 3.0 release were kind "abstraction for abstraction's sake" moves. In other areas, I think the framework has pushed beyond what the language is capable of handling in a reasonable manner, from a performance perspective (I'm talking about development efficiency performance, not production performance). No doubt, these features were implemented with good solid principles in mind. But, imo, at this point in Rails' lifecycle as a framework (something that has been in public release for 5+ years) performance (both production and in development) should have held more weight in the decision-making process than doing things for what appeared to be because they were the "right" things to do. For one, the startup time of the framework is just, atrocious. If it takes me 15-30 seconds to boot up the framework (and on my quad core dual processor 8gb ram MBP running a small-to-medium-sized project, it does) just to run one test, that is just plain ridiculous. A lot of that time is spent loading the large dependency graph of gems with which most new rails apps these days are packaged. I think this trend -- rigorous packaging open source library code as a first-class dependency, instead of writing it yourself, or snapshotting that actual code in your SCM -- is a good thing. But I think the performance characteristics of the ruby language, and of the ruby community, make trying to cram 150+ gems into the load path and then require all of them, serially, in a single thread, unacceptably slow for modern web development. I will say that I think the situation has improved quite a bit more recently, and the focus seems to be honing in more on development performance, but it might be a tad too late for me. I'm focused more on building api's than I am building "web apps". For that, sinatra is just a much simpler, faster and elegant stack IMHO.
- jonathanwallace 15y ago
  You'll get no argument from me that sinatra is simpler, faster and elegant. However, I've often found that sinatra APIs end up re-implementing rails features one by one over time. Have you not seen a similar trend?
  - ajsharp 15y ago
    In some cases, definitely. However, I rarely find myself missing most of the features that you don't get.
mcantelon 15y ago
Tldr: Giles discovers 2011.
- batista 15y ago
  Too short, expanding: Giles BS reasoning of what 2012 should be resonates so well with you, that you not only consider it the truth, but also "so yesterday, dude". i.e another fad-chaser.
  - deleted 15y ago
    [deleted]
  - iamgilesbowkett 15y ago
    Yeah, but you have to give the guy credit, his was the only comment that made me laugh. And it's basically true. Not in the sense that this is new to me, I did a bunch with node and jasmine-node (etc.) in 2010, maybe earlier, but I went to a Ruby conf and was shocked how many people hadn't heard of it. even heard people saying you don't have to test JS because it's hard. so I decided the Ruby community needed to have a look at all the stuff that's already been going on for quite some time in JS-land.
ypcx 15y ago
Recently, I actually started to learn the Ruby spec because I was offered a well paid work in Ruby for many months to come, and I thought it would be cool to work in something new. Besides web dev, my past is C/C++, then many years of Java, and recently Node.js. I turned the Ruby project down because very early down the spec I realized that I don't want to work with technology belonging to 5 (or at least 2) years ago, language design-wise. I'm now on Node and I have great fun. The JS community is great, the Node.js subset even greater. The NPM repository is exploding with new libraries. You can see a new framework literally every week, but you also have tested ones to rely on. Good patterns are taken from anywhere, anytime, and new ones are being created. I'm not saying this to bash Ruby, it's just my personal story. I approached Ruby with optimism, but what I saw was a badly designed language. I can understand it being so popular compared to Java, I know I would be Ruby coder today had I discovered it during my Java days. But today I have Node.
- rurounijones 15y ago
  Sorry, one thing I do not get. You refused a ruby job because the language (Ruby) was "5 (or at least 2) years old language design wise" and instead you went for.... node.js? Technology based on a language designed...17 years ago!? (God that makes me feel old) I feel there is a flaw in your reasoning, or at least other reasons which you are not going into. EDIT: I know ruby has been around a long time. Just found it first appeared around the same time as JavaScript.
- batista 15y ago
  I turned the Ruby project down because very early down the spec I realized that I don't want to work with technology belonging to 5 (or at least 2) years ago, language design-wise. Ah, so you don't want to work with mature, proven technologies, language design-wise, that bring benefits to the company and the user base. Good thing that you don't WANT to work with this kind of technology, because I too don't think you SHOULD be working anywhere near client projects with that mentality.
Uchikoma 15y ago
tl/dr What I take from the post: Guy has no fun with underlying technology, rewrites from scratch with more fun framework, does not care about current users, thinks this is offset by future users who can more easily use coffeescript.
- xinuc 15y ago
  what zed said about him is not absolutely wrong http://oppugn.us/posts/1276150607.html http://oppugn.us/posts/1276150607.html
  - mythrowaway2 15y ago
    I'm ranting about shit fucking loser pricks like Giles A litany of bilious libel as useful an indicator as asking Kim Jong Un for opinions on Dick Cheney.
  - nathan_f77 15y ago
    Wow, that post was terribly offensive. ... as was the code that zed linked to - https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb91471fdb91b534b7e0d6632b2b6f4b98/lib/arkx.rb https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb9...
charlysisto 15y ago
That's called throwing the baby out with the bathwater. There might be a few issues when your newbie & want to kickstart a rails app, but they're easily overcome with a good template.rb (the later being as small as possible, many of them are bloated). Also I find the Rails 3.0 bashing cheap and unfair since it's a huge step forward in terms of robustness, modularity & coherence. But yes I agree the fine tuning you need to get your quicky rails app up & running with your special flavor (eg: rspec, haml, inherited_resources etc) should be better advertised & explained. I also spend more time on js nowadays but with backbone.js, throwing out the legacy of rails on the server seems a huge waste of time at this stage.
dgregd 15y ago
Now it is risky to bet on Node.js. Especially for bigger projects. I'll wait two years and see how Node.js evolves. For now I'll continue to use RoR. I really would like to see something like Google Dart to succeed. Node.js feels like PHP in early 2000s.
glenjamin 15y ago
While I agree with most of the points, you can just do require 'bundler' Bundler.setup In your Rakefile, and never have to type bundle exec. This is exactly what I use in my commandline Node.JS project which is BDD tested using cucumber and aruba.
- gurkendoktor 15y ago
  Does this help if you even bloody `rake` is not backwards compatible? 0.9.x has caused all sorts of trouble for me...
DiabloD3 15y ago
I'm going to preserve the best thing I've read in awhile in a HN comment: "And as for overly ceremonial code, let me tell you about my balls. I actually have a rake task to scratch my balls. Somebody told me a good entrepreneurial programmer writes code to scratch their own itch, and I took them literally. The code uses a serial port to power an Arduino board. The Arduino's got a servo with a backscratcher attached. I keep it on a shelf at scrotum height underneath my desk."
mrjd 15y ago
Can't Rails and Node play together (see: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-application-with-nodejs http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...)? To me it falls back to 'the best tool for the job'. Both Rails and Node have their strong points.
cageface 15y ago
If fashion is dictating your technology choices you're not choosing hard enough problems to solve.
- iamgilesbowkett 15y ago
  Upvoted! But here's the thing. How many technology choices does fashion dictate? I've seen fashion determine huge amounts of technology choices, and wheels get reinvented constantly in this industry as a result. In 2006ish I did a talk about MVC JavaScript at a tiny FooCamp in Albuquerque. At the time people were all excited about Rails MVC, and I was like, "hey, initially MVC was for GUIs, and Ajax is headed towards GUIs." Because of that, it was easy to see that this particular wheel was headed for imminent reinvention. It's easy to sneer at individuals for making technology choices based on fashion, but that's petty. Take a minute to look at communities making technology choices based on fashion. The periodic re-invention of wheels in programming mirrors the cyclical nature of fashion in terms of what people wear. Embarrassing fashion confession: I used to be a raver in the 90s. I wore big baggy jeans. In the disco era, people wore pants like that. They called them flares in the UK and bell-bottoms in the US. Clothing fashions cycle, and programmer fashions cycle too. If fashion is dictating an entire community's technology choices, you can learn something about the fundamental problem they're solving by asking yourself what wheel they're re-inventing, and looking into the history of computer science a little to see how programmers solved it last time.
Tichy 15y ago
"It's a bloated meta framework that requires enormous amounts of peripheral knowledge to understand." Unfortunately I think that might be because web development requires enormous amounts of peripheral knowledge to understand. It might be overkill for the first prototype of a new web app, but after a while that web app will probably acquire lots of peripheral hacks, too.
pjmlp 15y ago
Right on. Being old enough in this industry I have seen technologies come and go, while a few are able to stick around for a little longer. The Node.js hype will be gone in the next 5 years, being replaced by whatever is hype, while giving me and other consultants lots of money to port existing applications to more mature enterprise level technologies.
dasil003 15y ago
I agree Rails has evolved to become many of the things that DHH first complained about in so-called Enterprise frameworks. But that's because a wider audience has wider problems to solve than Basecamp 1.0. At the end of the day, Rails 3.2 for all its complexity still "gets" server-side web development better than the antiquated Java frameworks that it replaced ever did. What Rails really never got was client-side development. Even as it ushered in the era of easy AJAX support in 2005, it was based on a poor fundamental understanding of how to do good client-side development (to be fair, no one really had that understanding for javascript apps back then because we were lost in the weeds of browser compatibility). Over the years it's improved only in fits and starts, with bandaids and ancillary features like the asset pipeline and coffeescript (RJS was probably one of the worst ideas ever hyped). So to me what the new crop of frameworks bring to the table is rethinking things from a deep understanding of client-side development, in much the same way that Rails rethought things from a deep understanding of server-side web development. I don't hold much hope for Rails to get good at client-side development due to the fact that DHH doesn't really like client-side development (as indicated by some of his commentary in the Basecamp Next caching article). He likes coffeescript because it's more like ruby and thus less painful, but the fertile ground of client-side development techniques will never be tilled by someone with this attitude. Javascript may not be the prettiest language, but it is powerful and paradigm-shifting when embraced to its fullest. All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps. If Rails was fast I would happily stick it on the server as I explored client-side development independently. Unfortunately I'm really starting to feel like Ruby performance is holding me back and that it will be impossible to fix regardless of how seriously Ruby and Rails core get about performance. Who was it that said "everything can be fixed with another layer of indirection, except performance"?
- MatthewPhillips 15y ago
  > All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps. I'm not sure. You only need a server-side if you have users, there are a lot of apps that don't need users. For those that do there's no reason why your server-side code needs to sit next to your web server as it does today. What you need is a good API framework, which Ruby does well today, but perhaps should be its primary focus in the future.
gudjon 15y ago
Rails is missing the V8-like phenomena Node.js has. Imagine if we would see something like V12 in the future, a JavaScript engine running on nVidia CUDA. That's where I would like to run my Node.js from ;-)
- mistercow 15y ago
  >Imagine if we would see something like V12 in the future, a JavaScript engine running on nVidia CUDA. For that concept even to make sense, we would have to have massive leaps forward beyond what is currently even believed possible in the realm of auto parallelization.
functionform 15y ago
The people who learned with Rails always make me chuckle. The only reason Rails got anywhere was because of scaffolding and the hype that surrounded it - which of course already existed in some form in other platforms. It's completely revisionist to think that platforms like Java or .NET didn't already have application creators and ORM. The genius of Rails and DHH was the marketing which isn't surprising seeing as how much he loves Apple for it. They can always try to say the other platforms were bloated, but this is coming from people who thought full Unicode support at launch wasn't necessary.
- subwindow 15y ago
  I don't know where you got that from. Struts was my first proper web framework- the kind where adding a column was an all-day affair. The simplicity of Rails, even now, is that you'd only need to put it in two places- the migration and the view. You don't need to mess around with Hibernate XML configurations all day. Just add the damned column and get on with your life.
  - chromatic 15y ago
    Struts was hardly the be-all end-all of web development. Sure, Rails was a lot better than Struts--but so were a lot of other platforms.
jgeerts 15y ago
We are developers and we can learn and use any language if we just know the concepts of what we are doing. Same thing, different language... who cares. Hope it's the last "why I switched" blogpost because I never found them useful.
jamesbritt 15y ago
Dupe: http://news.ycombinator.com/item?id=3627368 http://news.ycombinator.com/item?id=3627368
ciparis 15y ago
I don't get the frequent comparisons (mostly by bloggers) between Rails and Node.js. The things you most want Node.js for you don't really want to be doing in Rails, and vice-versa.
f4stjack 15y ago
This is not a fashion show, or "my framework is leaner and executes faster than yours" competition. "Rails is old and busted; Node.js is the new hotness." Seriously? is this the mentality we should adhere to? What happened to the problem solving, or building stuff? Old is bad, eh? If that is our credo we should quit javascript altogether because it is oldness itself! Please don't get me wrong but I see a problem here. The attitude is quite problematic. You choose a programming language based on what do you want to achieve, and how that language helps you to achieve, not on buzzwords. If I want to build a weblog application, I won't try to learn c++ for example. Not because "it is old and bloaty and requires a peripheral knowledge", it won't help me to solve my problem. And I wonder, what kind of programming language does not require peripheral knowledge? I can go on and on about how hard is it to do such a shift in a corporate environment and maturity of a codebase is good, and code is not a thing that rusts but I think I made my point. tl;dr: you choose programming languages based on what you want to do and how that language makes your job easier; not because it is new or old or bloaty or "lean".
jpdoctor 15y ago
FTA > I literally need to type bundle exec every single time I want to scratch my balls. I don't like having to type bundle exec every single time I scratch my balls. I named the task balls, so I can type rake balls, because it rakes my balls, and Bundler pisses all over my tidy syntax, but am I going to complain? Am I going to point out that asking me to type bundle exec every time I want to scratch my own balls shows incredible contempt for me as a user Really? This what passes for A vs B discussion at the top of HN?
deleted 15y ago
[deleted]
enko 15y ago
I guess the first of many things I don't understand about this post is that Archaeopteryx is not built in Rails, has nothing to do with Rails, nor is it a web site nor has anything to do with http nor even requires active_support or similar. I know some people think Rails is going in the wrong direction - I disagree, but it's a topic on which reasonable minds can differ. This post may have something valuable to say on that subject, or not. Regardless, it's got nothing to do with the author's music library and I suspect the only reason Rails was mentioned at all was to stir controversy and bring attention to an otherwise unrelated announcement.
politician 15y ago
I can't say much about Rails, but I will say that after doing a CoffeeScript, Backbone, and require.js with clientside compilation project -- debugging is pain and tears. Even though Chrome supports source maps, CoffeeScript doesn't, and the error messages raised by require.js are of the "you fucking peon" variety referred to in the article. I like CoffeeScript and AMD, but they aren't ready to be in the same room together. Hopefully, jrburke's almond will let me build a serverside compilation strategy that isn't awful to debug. On the other hand, Backbone kicks ass, and I wrote a DOM-twiddling Knockout.js inspired data binder called _outback.js_ to make it better. It's up on github (politician/outback) if anyone's interested.
socratic 15y ago
Has anyone made a comprehensive comparison of the top web frameworks and how mature the libraries/plug-ins/services around them are? Frankly, Rails and Node.js seem to have much more in common than apart. Both are based around relatively inconsistent languages (though conforming to some BDD or Good Parts style can help), both have deeply flawed runtimes in terms of performance and especially parallelism, and they seem to have extremely high overlap in the people who program in both frameworks. What I care about is libraries, plug-ins, and services. Specifically, if I have some new web task, what I care about is that there is some library/plug-in/service that exists to perform that task (e.g., user auth, Facebook API, exception logging, Heroku, resque, state machines), that the library/plug-in/service is mature enough that I can pretend it works, and that it has enough of a community around it that it won't break in the future. Is there some comprehensive list of use cases, plug-ins/libraries/services, and relative maturity of those plug-ins/libraries/services across web frameworks? For example, the maturity of the various ORMs across frameworks, or the various testing tools, or the various Facebook libraries. It would be great to see it change over time, and to know when to jump ship to the next flawed language/runtime that has good plug-ins/libraries/services.
nwmcsween 15y ago
This is garbage, why is it being voted up? Rails is not bloated it's modular and quite simple if you understand ruby and can read - look at the source. That said his to address his _complaints_: * Rspec / Testing is slow as it has to reinitialize a whole rails stack every time it runs - run it async smartass it's what you're preaching, use inotify or fsevent with watchr or guard. * Bundle exec for Gemfile changes? This guy is inept.. async yet again with inotfiy / fsevent * HTML5 - It's a server side framework, if you want HTML5 you do it in the markup or the included coffeescript pipeline, why not pure coffeescript / javascript? because I value my time and sanity over the new hotness
- ssmoot 15y ago
  > Rails is not bloated it's modular and quite simple if you understand ruby and can read - look at the source. You've got to be kidding. The Routing has got to be the canonical example of bloated and confusing code. Is inotify/fsevent built into the "full stack" framework? No? "Hey guys, I wrote/found/whatever this code to solve a problem that another bit of code I chose to use caused for my development. Oh BTW you're a complete tool if you aren't already doing the same." You must be awful proud of that Yak.
  - nwmcsween 15y ago
    Confusing? you map resources to URL's it's confusing if you are inept. Inotify / fsevent and such aren't built into rails just as they aren't in _EVERY OTHER FRAMEWORK_ because it's complete voodoo to make side effects of editing a file default.
    - ssmoot 15y ago
      > you map resources to URL's it's confusing if you are inept. Inept? Kids these days. Forking my code then calling me inept. It's precious is what it is. But you're moving the goal-posts. You said read the source. Since you're clearly unfamiliar with it, here's a couple handy links to the Routing code I mentioned. https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb https://github.com/rails/rails/blob/master/actionpack/lib/ac... https://github.com/rails/journey https://github.com/rails/journey > it's complete voodoo to make side effects of editing a file default You seem to be under the impression Rails doesn't have any facilities to reload files after modification.
tmanderson 15y ago
Wait. Node is a framework now?

209 points by mnazim 15y ago

deleted 15y ago

[deleted]

I'm not ready to ditch rails yet, but I think the framework (and Ruby itself) needs an intervention. Bundler, Ruby 1.9.2, 1.9.3, and a ton of gems are all making life harder than it used to be. I have faith the community is self critical enough to identify these problems and fix them. Posts like this are needed though to give us all a kick in the ass and make things better.

mnazim 15y ago
I don't think the author is hinting at ditching rails altogether. IMO, he is just pointing out his disappointments, starting at the start and doing what he thinks is good for him.
Fluxx 15y ago
How are things harder with these technologies?
- railsjedi 15y ago
  Having to learn the ins and out of bundler `bundle exec, update, --without :darwin`.. just to use a package handler. I had growl_notify installed, and now we've forced our team to be mac only because we got tired of dealing with linux issues. Ruby Debug is impossible to get working in 1.9.3. The maintainer of ruby-debug has gone AWOL so we're forced to deal with solutions like this http://blog.wyeworks.com/2011/11/1/ruby-1-9-3-and-ruby-debug http://blog.wyeworks.com/2011/11/1/ruby-1-9-3-and-ruby-debug that don't work within bundler or a team environment. 1.9.2 + Rails 3.x is attrociously slow (30+sec). With falcon (a very unstable ruby hack) the startup speed goes to 10seconds. But 10sec is still way too slow Sorry, it sounds bad when I just rant. In the grand of scheme of things, Rails makes me more productive as a web dev than I ever thought possible. It's just easy to pull out the daily frustrations and complain. I've been trying to help fix these issues but they are so dependent on a web of gem authors, and core ruby fixes that it takes an extraordinary amount of time. I'm almost to the point where I think things need to be fixed top down. Matz needs to take control and try to make stuff not suck as soon as possible. Since he's working for Heroku now, it's in his best interest to push the platform and keep new users engaged.
  - rohitarondekar 15y ago
    You don't have to use Bundler. Just delete the Gemfile and manage the dependencies yourself.
    - subwindow 15y ago
      The problem is that there's no third option- something to manage dependencies that's not bundler. We all want and need dependency management, but bundler should not be the One True Solution.
      - rohitarondekar 15y ago
        Write your own? I'm sorry but if Bundler doesn't solve your problem (or introduces other problems) either try and fix those issues OR write your own dependency management lib.
        secoif 15y ago
        And discussions like this, raising awareness and exchanging ideas, are a part of getting the problem fixed.
        rohitarondekar 15y ago
        The correct place for these discussions is on the issue trackers & mailing lists of Bundler.
        sha90 15y ago
        The unfortunate reality about writing your own new Bundler is that you'll inevitably end up rewriting Bundler. Isolate is basically just a mini-Bundler with a different (arguably simpler) storage location, but the storage location is really not where the complaints about Bundler are coming from. Rewriting things just to shed complexity or "bloat" will often just put you in a position where your library just can't do things it will need to do, and then you end up rewriting those things and adding back the complexity. It's the circle of life. Lack of SCM support in Isolate is a good example-- I'm pretty confident that Bundler's support of git is heavily used and taken for granted, but if you were to rewrite or use a simpler dependency manager, you're throwing this out. This point feeds back into the larger issue of Rails vs. Node, I think. Rails ended up with all the complexity it has now because it was [mostly] necessary-- not all of it was, but much of it was. The idea that you're somehow liberating yourself by shedding complexity is often just the short-sighted pleasure of running faster test suites. And it's usually followed by a little bit of claustrophobia when you realize you can't do X, Y, or Z anymore. Wait until the claustrophobia kicks in, because it will. And the solution to this claustrophobia? More cowb-- complexity.
mtkd 15y ago
I'm not sure the community is self critical enough to fix the issues. The maintainers are highly opinionated and have shown very little concern about the bloat up to now - mitigating it by targeted optimisations not by removal of bloat itself. The community will just move on to something less bloaty - many Rails developers I know spend more (side project) time with JS now.

mtkd 15y ago

Rails is very suited to big API projects now - but there is no escaping the fact that all the action is moving clientside. The Rails learning curve is now very steep for new users and the accusation that it has become all it set out to solve is a fair one. For me it's a mature/stable framework and ripe for using commercially now, but I can understand the new kids gravitating to something more disruptive.

troyk 15y ago
agree plus add Rails is very well suited for the client side hotness with the asset pipeline in Rails 3. However I just tossed Rails after many years for 2 primary reasons: 1) Anything that might take a sec or more has to be moved out of the request cycle and into a background process. That just gets annoying after a bit. Node.js can serve requests, grab data from to world's slowest API's, send emails, etc, all from a single process. 2) Although I think Ruby's strong point is readability and succinct LOC, it's hard to beat using the same language for everything and not context switching. Maybe my brain is broken, but I used to drive myself nuts writing client js and using Ruby's nil instead of null and Object.new instead of new Object. For the project I'm working on now, I had to make my own asset pipeline. It uses less for css (and bootstrap), precompiles handlebar templates and concats all the js into a single file and uglifies it. Cost me 2-3 hours, about the same time it took me to learn Rails asset pipeline and was about 10x more fun. Last point I'll add is when Rails was a baby it made fun of all the xml configs etc that other frameworks bogged developers down with. Now it's grown up a little, and although sprocket and yaml files aren't xml, the concept is the same. If you've been around Rails for awhile and dive through the code of project like Spree, you just scratch your head and little simple things like node appear shimmering sexy!
- rimantas 15y ago
  > For the project I'm working on now, I had to make my own > asset pipeline. It uses less for css (and bootstrap), > precompiles handlebar templates and concats all the js > into a single file and uglifies it. Cost me 2-3 hours, > about the same time it took me to learn Rails asset > pipeline and was about 10x more fun. Sounds familiar: http://documentcloud.github.com/jammit/ http://documentcloud.github.com/jammit/

fullmoon 15y ago

You can't compare a web framework with an event reactor.

karterk 15y ago
Actually, node is also a web framework. It's just not a web framework to build CRUD apps like Rails is tailored for. So, it all depends on how you define what web is.
- fullmoon 15y ago
  Node is a web framework because it has a HTTP server built in? By this logic, EventMachine is also a web framework

karterk 15y ago

As far as Node goes, there is still no "holy grail" framework that can help one build a web app seamlessly across both client and server side. The momentum will definitely shift heavily towards Node if and when that happens. Right now, there is still a lot of manual glue work needed to set-up a client side MVC app using Node + Backbone while also taking care of graceful degradation etc.

jeswin 15y ago
Should we really worry about graceful degradation anymore? Personally, I don't waste much time on this like I did years back.

jamesu 15y ago

This came across to me as a long rambling rant which amongst other things interchangeably referred to ruby as both "ruby" and "rails", but i got the feeling it was more about bashing rails. Rebuilding something because the older stuff is is "bloated" and the new stuff is somehow superior always seems like a weak excuse to me. The new stuff quickly becomes the old "bloated" stuff and you're back to square 1. In fact I have no doubt that within 5 years something else new will come along and perhaps Giles will be writing another article about "Node Went Off The Script: Why I'm Rebuilding Clyde In TheNextBestThing". Personally I would rather concentrate on making something which is actually good in its own right.

batista 15y ago
In fact I have no doubt that within 5 years something else new will come along and perhaps Giles will be writing another article about "Node Went Off The Script: Why I'm Rebuilding Clyde In TheNextBestThing" Which possibillity he mentions in TFA. But this is what we call progress (or, to a more bitter viewpoint) change. It doesn't stop.
- hello_moto 15y ago
  Aside from async, I don't see a single drop of progress moving from Rails to Node.JS.
  - ascendant 15y ago
    Much smaller memory footprint, faster execution times, consistency of writing your server code and client code in the same language, etc. You could say all of these things are subjective, but so is the word "progress".

betageek 15y ago

tl/dr Rails is not the new hotness anymore, the Rails 3 rewrite was a waste of time and it's strayed far from its initial ease of use. Node & Coffeescript, the new hotness, are awesome, here's my new video series, the first one's free.

kristianp 15y ago
Thanks for the tl/dr, that post certainly needed one.
drostie 15y ago
You missed the most important part: And as for overly ceremonial code, let me tell you about my balls. I actually have a rake task to scratch my balls. Somebody told me a good entrepreneurial programmer writes code to scratch their own itch, and I took them literally. The code uses a serial port to power an Arduino board. The Arduino's got a servo with a backscratcher attached. I keep it on a shelf at scrotum height underneath my desk. I literally need to type bundle exec every single time I want to scratch my balls. I don't like having to type bundle exec every single time I scratch my balls. I named the task balls, so I can type rake balls, because it rakes my balls, and Bundler pisses all over my tidy syntax, but am I going to complain? Am I going to point out that asking me to type bundle exec every time I want to scratch my own balls shows incredible contempt for me as a user, particularly considering that the whole reason I'm a user of this particular thing is because I work in a language which was designed to optimize for programmer happiness? Of course not. It's not productive or helpful to say that, so I simply type bundle exec rake balls and scratch my balls in sullen silence. Typing bundle exec every single time I want to scratch my balls is the epitome of the overly ceremonial code which Rails defined itself against from 2005 to 2007. The problem with tl/dr is that it misses out on the funny. :-(
- zedshaw 15y ago
  Nope, the tl;dr didn't miss a thing.
  - functionform 15y ago

prosa 15y ago

I love Giles. His first Archaeopteryx talk was one of the best Ruby-related talks of all time. He's way too harsh on Rails though. The original "blog in 15 minutes" demos that catapulted Rails into the limelight are still possible with Rails 3. Things like 'gem install rails' still work. If you are determined to skip bundler, you can do that too. What's more, unlike 2005, in the 15 minutes it takes to build a Rails blog, you can deploy to Heroku and have a live site running. Node is fun. V8 smokes MRI. But Node's web framework ecosystem has a long, long, long way to go before one can reasonably say that Rails is a bad investment. If anything, we should be celebrating the number of options that are open to us. It's a great time to be developing for the web. Good things will come from Node's ascendancy, whether its frameworks dethrone Rails or not. The negativity is unnecessary.

fullmoon 15y ago
I'd go further and say, that it will be very hard to have a good MVC framework with Node before the async callback mess is brought under control. Maybe we'll even need something like Iced CoffeeScript for this.
- ypcx 15y ago
  The async callback mess is not really a problem, there is about zillion patterns and libraries to handle it. The problem is error handling in callbacks, capturing stack traces from the async parent callers, and generally not crashing Node if you forget to try/catch your async handler. However, this problem is known, and this is being worked on in the form of "domains". Btw. Iced CoffeeScript doesn't solve this a single bit.
  - stock_toaster 15y ago
    > The async callback mess is not really a problem, there is about zillion patterns and libraries to handle it. Doesn't that seem to imply that it is such a problem that people have come up with a myriad of disparate solutions to try to solve it?
    - 15y ago

bad_user 15y ago

Rails has always been bloated. That's what you get from frameworks that come with automation for common tasks. However, let me provide a counter-point ... I think that Rails 3 is finally a good framework that I want to use. Blogs written in 5 minutes (which you can still do in Rails 3) have never impressed me. What impresses me is code-reuse, modularity and readability. Which is why I preferred Django instead of Rails 2. The biggest reason was that I can read Django's source-code, but Rails (prior to 3) was really awful in that regard and cargo-culting is OK, but only when you're starting out. Node & Coffeescript are indeed cool and have their place. However I prefer mature frameworks that save me effort when building yet-another-admin or yet-another-facebook-login. Not pursuing hotness is the new hotness IMHO.

irahul 15y ago
> Blogs written in 5 minutes (which you can still do in Rails 3) have never impressed me. I don't know. I liked the rails 5 minutes blog demo. I wasn't into rails from the beginning - I followed the recent one http://guides.rubyonrails.org/getting_started.html http://guides.rubyonrails.org/getting_started.html I think it's the ideal example for demonstrating a web framework. 1. It gives basic introduction to the framework and installation notes. 2. It's simple enough to follow, yet large enough to show major aspects of development with rails. 3. It shows all major aspects of the web application development - db access layers, db creation and migration, models and validation, request routing, controllers, views, partials... > What impresses me is code-reuse, modularity and readability. Which is why I preferred Django instead of Rails 2. I use both Django and Rails. Rails has various stuff which I need for a basic app out of the box, which Django doesn't have - asset pipelines, coffeescript integration, swappable templates, bundler for dependencies, rvm(not exactly rails) for isolating ruby version and gemset, tested gems for basic tasks(kaminari, devise, paperclip) etc. I know I can do all of it in Django/Python(pip, virtualenv, coffee --watch, webassets etc etc), but rails sets up things for me and I can begin coding. Rails does require more peripheral knowledge, but it's optimized for people who know rails. Beginners will be more at home with Django, but you are a beginner for a very short period of time, and optimizing for beginners while forfeiting comfort for people who are on-board isn't a good compromise IMO. In an ideal world, we can have frameworks which is both beginner and power-user friendly, but I seldom see it happening it in the real world. As far as reading code goes, I have trouble following Rails code, and my only friend is the interactive debugger - I set breakpoints, read code in the editor, continue, break... I haven't read Django's code in a while, but it used to be quite heavy on magic - not sure about the current status.

DanielRibeiro 15y ago

As Smalltalk creator Alan Kay said: "Once you have something that grows faster than education grows, you’re always going to get a pop culture." This is so true in so many levels, that I feel I bit sad just thinking about it.

Jare 15y ago
Why? Exploration and evolution are in many ways the opposite of education, but that doesn't mean they are bad things.

ajsharp 15y ago

Glad you published this Giles. I really think you hit the nail on the head in your criticism of rails, and not necessarily ruby. I think some of the framework decisions in the 3.0 release were kind "abstraction for abstraction's sake" moves. In other areas, I think the framework has pushed beyond what the language is capable of handling in a reasonable manner, from a performance perspective (I'm talking about development efficiency performance, not production performance). No doubt, these features were implemented with good solid principles in mind. But, imo, at this point in Rails' lifecycle as a framework (something that has been in public release for 5+ years) performance (both production and in development) should have held more weight in the decision-making process than doing things for what appeared to be because they were the "right" things to do. For one, the startup time of the framework is just, atrocious. If it takes me 15-30 seconds to boot up the framework (and on my quad core dual processor 8gb ram MBP running a small-to-medium-sized project, it does) just to run one test, that is just plain ridiculous. A lot of that time is spent loading the large dependency graph of gems with which most new rails apps these days are packaged. I think this trend -- rigorous packaging open source library code as a first-class dependency, instead of writing it yourself, or snapshotting that actual code in your SCM -- is a good thing. But I think the performance characteristics of the ruby language, and of the ruby community, make trying to cram 150+ gems into the load path and then require all of them, serially, in a single thread, unacceptably slow for modern web development. I will say that I think the situation has improved quite a bit more recently, and the focus seems to be honing in more on development performance, but it might be a tad too late for me. I'm focused more on building api's than I am building "web apps". For that, sinatra is just a much simpler, faster and elegant stack IMHO.

jonathanwallace 15y ago
You'll get no argument from me that sinatra is simpler, faster and elegant. However, I've often found that sinatra APIs end up re-implementing rails features one by one over time. Have you not seen a similar trend?
- ajsharp 15y ago
  In some cases, definitely. However, I rarely find myself missing most of the features that you don't get.

mcantelon 15y ago

Tldr: Giles discovers 2011.

batista 15y ago
Too short, expanding: Giles BS reasoning of what 2012 should be resonates so well with you, that you not only consider it the truth, but also "so yesterday, dude". i.e another fad-chaser.
- deleted 15y ago
  [deleted]
- iamgilesbowkett 15y ago
  Yeah, but you have to give the guy credit, his was the only comment that made me laugh. And it's basically true. Not in the sense that this is new to me, I did a bunch with node and jasmine-node (etc.) in 2010, maybe earlier, but I went to a Ruby conf and was shocked how many people hadn't heard of it. even heard people saying you don't have to test JS because it's hard. so I decided the Ruby community needed to have a look at all the stuff that's already been going on for quite some time in JS-land.

ypcx 15y ago

Recently, I actually started to learn the Ruby spec because I was offered a well paid work in Ruby for many months to come, and I thought it would be cool to work in something new. Besides web dev, my past is C/C++, then many years of Java, and recently Node.js. I turned the Ruby project down because very early down the spec I realized that I don't want to work with technology belonging to 5 (or at least 2) years ago, language design-wise. I'm now on Node and I have great fun. The JS community is great, the Node.js subset even greater. The NPM repository is exploding with new libraries. You can see a new framework literally every week, but you also have tested ones to rely on. Good patterns are taken from anywhere, anytime, and new ones are being created. I'm not saying this to bash Ruby, it's just my personal story. I approached Ruby with optimism, but what I saw was a badly designed language. I can understand it being so popular compared to Java, I know I would be Ruby coder today had I discovered it during my Java days. But today I have Node.

rurounijones 15y ago
Sorry, one thing I do not get. You refused a ruby job because the language (Ruby) was "5 (or at least 2) years old language design wise" and instead you went for.... node.js? Technology based on a language designed...17 years ago!? (God that makes me feel old) I feel there is a flaw in your reasoning, or at least other reasons which you are not going into. EDIT: I know ruby has been around a long time. Just found it first appeared around the same time as JavaScript.
batista 15y ago
I turned the Ruby project down because very early down the spec I realized that I don't want to work with technology belonging to 5 (or at least 2) years ago, language design-wise. Ah, so you don't want to work with mature, proven technologies, language design-wise, that bring benefits to the company and the user base. Good thing that you don't WANT to work with this kind of technology, because I too don't think you SHOULD be working anywhere near client projects with that mentality.

Uchikoma 15y ago

tl/dr What I take from the post: Guy has no fun with underlying technology, rewrites from scratch with more fun framework, does not care about current users, thinks this is offset by future users who can more easily use coffeescript.

xinuc 15y ago
what zed said about him is not absolutely wrong http://oppugn.us/posts/1276150607.html http://oppugn.us/posts/1276150607.html
- mythrowaway2 15y ago
  I'm ranting about shit fucking loser pricks like Giles A litany of bilious libel as useful an indicator as asking Kim Jong Un for opinions on Dick Cheney.
- nathan_f77 15y ago
  Wow, that post was terribly offensive. ... as was the code that zed linked to - https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb91471fdb91b534b7e0d6632b2b6f4b98/lib/arkx.rb https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb9...

charlysisto 15y ago

That's called throwing the baby out with the bathwater. There might be a few issues when your newbie & want to kickstart a rails app, but they're easily overcome with a good template.rb (the later being as small as possible, many of them are bloated). Also I find the Rails 3.0 bashing cheap and unfair since it's a huge step forward in terms of robustness, modularity & coherence. But yes I agree the fine tuning you need to get your quicky rails app up & running with your special flavor (eg: rspec, haml, inherited_resources etc) should be better advertised & explained. I also spend more time on js nowadays but with backbone.js, throwing out the legacy of rails on the server seems a huge waste of time at this stage.

dgregd 15y ago

Now it is risky to bet on Node.js. Especially for bigger projects. I'll wait two years and see how Node.js evolves. For now I'll continue to use RoR. I really would like to see something like Google Dart to succeed. Node.js feels like PHP in early 2000s.

glenjamin 15y ago

While I agree with most of the points, you can just do require 'bundler' Bundler.setup In your Rakefile, and never have to type bundle exec. This is exactly what I use in my commandline Node.JS project which is BDD tested using cucumber and aruba.

gurkendoktor 15y ago
Does this help if you even bloody `rake` is not backwards compatible? 0.9.x has caused all sorts of trouble for me...

DiabloD3 15y ago

I'm going to preserve the best thing I've read in awhile in a HN comment: "And as for overly ceremonial code, let me tell you about my balls. I actually have a rake task to scratch my balls. Somebody told me a good entrepreneurial programmer writes code to scratch their own itch, and I took them literally. The code uses a serial port to power an Arduino board. The Arduino's got a servo with a backscratcher attached. I keep it on a shelf at scrotum height underneath my desk."

mrjd 15y ago

Can't Rails and Node play together (see: http://www.perfectline.ee/blog/optimizing-ruby-on-rails-application-with-nodejs http://www.perfectline.ee/blog/optimizing-ruby-on-rails-appl...)? To me it falls back to 'the best tool for the job'. Both Rails and Node have their strong points.

cageface 15y ago

If fashion is dictating your technology choices you're not choosing hard enough problems to solve.

iamgilesbowkett 15y ago
Upvoted! But here's the thing. How many technology choices does fashion dictate? I've seen fashion determine huge amounts of technology choices, and wheels get reinvented constantly in this industry as a result. In 2006ish I did a talk about MVC JavaScript at a tiny FooCamp in Albuquerque. At the time people were all excited about Rails MVC, and I was like, "hey, initially MVC was for GUIs, and Ajax is headed towards GUIs." Because of that, it was easy to see that this particular wheel was headed for imminent reinvention. It's easy to sneer at individuals for making technology choices based on fashion, but that's petty. Take a minute to look at communities making technology choices based on fashion. The periodic re-invention of wheels in programming mirrors the cyclical nature of fashion in terms of what people wear. Embarrassing fashion confession: I used to be a raver in the 90s. I wore big baggy jeans. In the disco era, people wore pants like that. They called them flares in the UK and bell-bottoms in the US. Clothing fashions cycle, and programmer fashions cycle too. If fashion is dictating an entire community's technology choices, you can learn something about the fundamental problem they're solving by asking yourself what wheel they're re-inventing, and looking into the history of computer science a little to see how programmers solved it last time.

Tichy 15y ago

"It's a bloated meta framework that requires enormous amounts of peripheral knowledge to understand." Unfortunately I think that might be because web development requires enormous amounts of peripheral knowledge to understand. It might be overkill for the first prototype of a new web app, but after a while that web app will probably acquire lots of peripheral hacks, too.

pjmlp 15y ago

Right on. Being old enough in this industry I have seen technologies come and go, while a few are able to stick around for a little longer. The Node.js hype will be gone in the next 5 years, being replaced by whatever is hype, while giving me and other consultants lots of money to port existing applications to more mature enterprise level technologies.

dasil003 15y ago

I agree Rails has evolved to become many of the things that DHH first complained about in so-called Enterprise frameworks. But that's because a wider audience has wider problems to solve than Basecamp 1.0. At the end of the day, Rails 3.2 for all its complexity still "gets" server-side web development better than the antiquated Java frameworks that it replaced ever did. What Rails really never got was client-side development. Even as it ushered in the era of easy AJAX support in 2005, it was based on a poor fundamental understanding of how to do good client-side development (to be fair, no one really had that understanding for javascript apps back then because we were lost in the weeds of browser compatibility). Over the years it's improved only in fits and starts, with bandaids and ancillary features like the asset pipeline and coffeescript (RJS was probably one of the worst ideas ever hyped). So to me what the new crop of frameworks bring to the table is rethinking things from a deep understanding of client-side development, in much the same way that Rails rethought things from a deep understanding of server-side web development. I don't hold much hope for Rails to get good at client-side development due to the fact that DHH doesn't really like client-side development (as indicated by some of his commentary in the Basecamp Next caching article). He likes coffeescript because it's more like ruby and thus less painful, but the fertile ground of client-side development techniques will never be tilled by someone with this attitude. Javascript may not be the prettiest language, but it is powerful and paradigm-shifting when embraced to its fullest. All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps. If Rails was fast I would happily stick it on the server as I explored client-side development independently. Unfortunately I'm really starting to feel like Ruby performance is holding me back and that it will be impossible to fix regardless of how seriously Ruby and Rails core get about performance. Who was it that said "everything can be fixed with another layer of indirection, except performance"?

MatthewPhillips 15y ago
> All that said, server-side ain't goin away, and Rails is still one of the best ways to develop server-side apps. I'm not sure. You only need a server-side if you have users, there are a lot of apps that don't need users. For those that do there's no reason why your server-side code needs to sit next to your web server as it does today. What you need is a good API framework, which Ruby does well today, but perhaps should be its primary focus in the future.

gudjon 15y ago

Rails is missing the V8-like phenomena Node.js has. Imagine if we would see something like V12 in the future, a JavaScript engine running on nVidia CUDA. That's where I would like to run my Node.js from ;-)

mistercow 15y ago
>Imagine if we would see something like V12 in the future, a JavaScript engine running on nVidia CUDA. For that concept even to make sense, we would have to have massive leaps forward beyond what is currently even believed possible in the realm of auto parallelization.

functionform 15y ago

The people who learned with Rails always make me chuckle. The only reason Rails got anywhere was because of scaffolding and the hype that surrounded it - which of course already existed in some form in other platforms. It's completely revisionist to think that platforms like Java or .NET didn't already have application creators and ORM. The genius of Rails and DHH was the marketing which isn't surprising seeing as how much he loves Apple for it. They can always try to say the other platforms were bloated, but this is coming from people who thought full Unicode support at launch wasn't necessary.

subwindow 15y ago
I don't know where you got that from. Struts was my first proper web framework- the kind where adding a column was an all-day affair. The simplicity of Rails, even now, is that you'd only need to put it in two places- the migration and the view. You don't need to mess around with Hibernate XML configurations all day. Just add the damned column and get on with your life.
- chromatic 15y ago
  Struts was hardly the be-all end-all of web development. Sure, Rails was a lot better than Struts--but so were a lot of other platforms.

jgeerts 15y ago

We are developers and we can learn and use any language if we just know the concepts of what we are doing. Same thing, different language... who cares. Hope it's the last "why I switched" blogpost because I never found them useful.

jamesbritt 15y ago

Dupe: http://news.ycombinator.com/item?id=3627368 http://news.ycombinator.com/item?id=3627368

ciparis 15y ago

I don't get the frequent comparisons (mostly by bloggers) between Rails and Node.js. The things you most want Node.js for you don't really want to be doing in Rails, and vice-versa.

f4stjack 15y ago

This is not a fashion show, or "my framework is leaner and executes faster than yours" competition. "Rails is old and busted; Node.js is the new hotness." Seriously? is this the mentality we should adhere to? What happened to the problem solving, or building stuff? Old is bad, eh? If that is our credo we should quit javascript altogether because it is oldness itself! Please don't get me wrong but I see a problem here. The attitude is quite problematic. You choose a programming language based on what do you want to achieve, and how that language helps you to achieve, not on buzzwords. If I want to build a weblog application, I won't try to learn c++ for example. Not because "it is old and bloaty and requires a peripheral knowledge", it won't help me to solve my problem. And I wonder, what kind of programming language does not require peripheral knowledge? I can go on and on about how hard is it to do such a shift in a corporate environment and maturity of a codebase is good, and code is not a thing that rusts but I think I made my point. tl;dr: you choose programming languages based on what you want to do and how that language makes your job easier; not because it is new or old or bloaty or "lean".

jpdoctor 15y ago

FTA > I literally need to type bundle exec every single time I want to scratch my balls. I don't like having to type bundle exec every single time I scratch my balls. I named the task balls, so I can type rake balls, because it rakes my balls, and Bundler pisses all over my tidy syntax, but am I going to complain? Am I going to point out that asking me to type bundle exec every time I want to scratch my own balls shows incredible contempt for me as a user Really? This what passes for A vs B discussion at the top of HN?

deleted 15y ago

[deleted]

enko 15y ago

I guess the first of many things I don't understand about this post is that Archaeopteryx is not built in Rails, has nothing to do with Rails, nor is it a web site nor has anything to do with http nor even requires active_support or similar. I know some people think Rails is going in the wrong direction - I disagree, but it's a topic on which reasonable minds can differ. This post may have something valuable to say on that subject, or not. Regardless, it's got nothing to do with the author's music library and I suspect the only reason Rails was mentioned at all was to stir controversy and bring attention to an otherwise unrelated announcement.

politician 15y ago

I can't say much about Rails, but I will say that after doing a CoffeeScript, Backbone, and require.js with clientside compilation project -- debugging is pain and tears. Even though Chrome supports source maps, CoffeeScript doesn't, and the error messages raised by require.js are of the "you fucking peon" variety referred to in the article. I like CoffeeScript and AMD, but they aren't ready to be in the same room together. Hopefully, jrburke's almond will let me build a serverside compilation strategy that isn't awful to debug. On the other hand, Backbone kicks ass, and I wrote a DOM-twiddling Knockout.js inspired data binder called _outback.js_ to make it better. It's up on github (politician/outback) if anyone's interested.

socratic 15y ago

Has anyone made a comprehensive comparison of the top web frameworks and how mature the libraries/plug-ins/services around them are? Frankly, Rails and Node.js seem to have much more in common than apart. Both are based around relatively inconsistent languages (though conforming to some BDD or Good Parts style can help), both have deeply flawed runtimes in terms of performance and especially parallelism, and they seem to have extremely high overlap in the people who program in both frameworks. What I care about is libraries, plug-ins, and services. Specifically, if I have some new web task, what I care about is that there is some library/plug-in/service that exists to perform that task (e.g., user auth, Facebook API, exception logging, Heroku, resque, state machines), that the library/plug-in/service is mature enough that I can pretend it works, and that it has enough of a community around it that it won't break in the future. Is there some comprehensive list of use cases, plug-ins/libraries/services, and relative maturity of those plug-ins/libraries/services across web frameworks? For example, the maturity of the various ORMs across frameworks, or the various testing tools, or the various Facebook libraries. It would be great to see it change over time, and to know when to jump ship to the next flawed language/runtime that has good plug-ins/libraries/services.

nwmcsween 15y ago

This is garbage, why is it being voted up? Rails is not bloated it's modular and quite simple if you understand ruby and can read - look at the source. That said his to address his _complaints_: * Rspec / Testing is slow as it has to reinitialize a whole rails stack every time it runs - run it async smartass it's what you're preaching, use inotify or fsevent with watchr or guard. * Bundle exec for Gemfile changes? This guy is inept.. async yet again with inotfiy / fsevent * HTML5 - It's a server side framework, if you want HTML5 you do it in the markup or the included coffeescript pipeline, why not pure coffeescript / javascript? because I value my time and sanity over the new hotness

ssmoot 15y ago
> Rails is not bloated it's modular and quite simple if you understand ruby and can read - look at the source. You've got to be kidding. The Routing has got to be the canonical example of bloated and confusing code. Is inotify/fsevent built into the "full stack" framework? No? "Hey guys, I wrote/found/whatever this code to solve a problem that another bit of code I chose to use caused for my development. Oh BTW you're a complete tool if you aren't already doing the same." You must be awful proud of that Yak.
- nwmcsween 15y ago
  Confusing? you map resources to URL's it's confusing if you are inept. Inotify / fsevent and such aren't built into rails just as they aren't in _EVERY OTHER FRAMEWORK_ because it's complete voodoo to make side effects of editing a file default.
  - ssmoot 15y ago
    > you map resources to URL's it's confusing if you are inept. Inept? Kids these days. Forking my code then calling me inept. It's precious is what it is. But you're moving the goal-posts. You said read the source. Since you're clearly unfamiliar with it, here's a couple handy links to the Routing code I mentioned. https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/routing/route_set.rb https://github.com/rails/rails/blob/master/actionpack/lib/ac... https://github.com/rails/journey https://github.com/rails/journey > it's complete voodoo to make side effects of editing a file default You seem to be under the impression Rails doesn't have any facilities to reload files after modification.

tmanderson 15y ago

Wait. Node is a framework now?