
Went Off The Rails: Why I'm Rebuilding Archaeopteryx In CoffeeScript - mnazim
http://gilesbowkett.blogspot.in/2012/02/rails-went-off-rails-why-im-rebuilding.html
======
bad_user
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.

~~~
functionform
After everyone saw how it easy it was to write your own blog in Rails,
everyone ... used Wordpress anyway.

The Rails use case was always truly limited. I still don't know any
application that achieved maturity and stayed coded in Rails. For a while that
was Twitter, but then they started moving stuff over the jvm.

Node will probably end up in a similar way, because at the end of the day no
one wants to manage thousands of lines of Javascript (or any other language
that doesn't enjoy the benefits of a statically typed ide).

~~~
nathan_f77
In my experience with Ruby development (2 years), I have never, ever
experienced a single issue caused by duck typing. Static typing is great for
performance, but it has nothing to do with being able to maintain a project.

~~~
etrain
Have you worked with more than 5 developers on a rails project? I ask because
all the problems I've had with dick typing appear around interfaces between
code from 2 programmers, and 5 seems to be the threshold where communication
starts to break down.

~~~
phillmv
What kind of problems do you genuinely have with a dynamic language/duck
typing?

Like, that you've actually experienced and said "You know, I'm not saying this
just because I'm not used to it. _This bit right here_ is a design flaw".

This is such a tired and boring argument by this point, but I'm willing to
entertain it because duck typing is at the bottom of my list of worries.

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

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

~~~
weixiyen
I'd caution against any "I'd go further to say" statements. Either you know
because you've tried, or you don't and are simply guessing.

As someone who has made an MVC framework in Node.js and launched a production
site using that framework, I can assure you that it's not hard to avoid async
callback mess. I can also assure you that many others have had success doing
this.

It's really not difficult to write beautiful, modular, and readable code in
node.js without going past 80 columns and without using Iced CoffeeScript.

I suspect that comments like this only further reinstate the theory that most
people are dismissing Node primarily due to the annoying amount of hype. There
are better reasons to not use Node, but imo, this isn't a very strong
argument.

~~~
bphogan
All the examples, github repos, books, and tutorials I'm seeing with my dive
into node say exactly the opposite - the code becomes a mess of callbacks. It
looks like enormous work goes into avoiding callbacks, similar to the amount
of work that went into Rails in 2005 so that server-side folks could avoid
writing JavaScript.

I'd love to see this framework you wrote. Is it open-source? or is it
something you're unable to share?

~~~
MatthewPhillips
You have to think about async code differently than you think about
synchronous code. In PHP you might write:

    
    
      $data = getData();
    

And people want to substitute the return for a callback in js.

    
    
      getData(function(data) {
        // Do something with data.
      });
    

That indeed does lead to callback mess. But when you are coding in js you
rarely should use anonymous functions. I mostly just use them when I might
want to perform recursion. Going back to my example, I would write the
operation as an object like so:

    
    
      var SomeObject = {
        start: function() {
          getData(dataGot);
        },
    
        dataGot: function(data) {
          
        }
      };
    

JavaScript is an object-oriented languages; use objects! They make async
painless.

~~~
bphogan
Wrapping things in objects doesn't seem to help me.

I'd still end up with this, thanks to callbacks.

    
    
        app.get('/documents', function(req, res) {
          Document.find().all(function(documents) {
            // 'documents' will contain all of the documents returned by the query
            res.send(documents.map(function(d) {
              // Return a useful representation of the object that res.send() can send as JSON
              return d.__doc;
            }));
          });
        });
    

Seems to me that what's missing is something that lets me write it in a more
simple way. What I have here looks like an absolute nightmare of coupling. So
if you have some suggestions you could point me to that show a little more
detail, I'd be really grateful.

~~~
MatthewPhillips
I would create a DocumentRequest object that takes your req and res, then
break apart your callbacks to separate functions on the DocumentRequest
prototype. Then you would simply consume it with:

    
    
      app.get('/documents', new DocumentRequest);

~~~
bphogan
Thanks for this. Been thinking about this. Could you recommend a book on
patterns like these?

------
jamesu
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
_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
Aside from async, I don't see a single drop of progress moving from Rails to
Node.JS.

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

~~~
mgkimsal
Funny, I've mentioned "ease of use" and "rails" to a few rails friends, and
most have said something along the lines of "Rails was _never_ pitched as
_easy to use_ \- I've no idea where people get the idea that Rails was
intended to be easy to use!". It may be just them, but I've heard it from more
than a few Rails people (though not universally).

Personally, it feels a bit revisionist, because I distinctly remember the
Rails fans in 2006/2007 talking about how easy Rails made web development.
But... perhaps my mind is playing tricks on me as I get older.

~~~
mattmcknight
Rails _was_ easy to use/learn in 2006/2007, and, coming from a background of 5
years of writing Java web apps, it was vastly easier than doing that mess.

~~~
bad_user
Easy to use and easy to learn are too very distinct things.

~~~
mattmcknight
And it was both...

------
ajsharp
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
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
In some cases, definitely. However, I rarely find myself missing most of the
features that you don't get.

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

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

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

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

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

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

~~~
Fluxx
How are things harder with these technologies?

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

~~~
judofyr
> Ruby Debug is impossible to get working in 1.9.3.

Ruby 1.9 ships with a debugger:

    
    
        require 'debug'
    

Besides, I've often find Pry way more useful: <https://github.com/pry/pry>

~~~
railsjedi
Thanks for the heads up. I've searched far and wide to find any sort of docs
for the built in debugger. ruby-debug was incredibly easy to use. require
'debug' sets a breakpoint, but I cant figure out any way to interact with it.

I use pry, however I've found it's very unreliable for stepping into shoulda
tests, and often it errors out. I haven't been able to find stable
alternatives to the most common ruby-debug commands 'l', 'e', 'n' and 'c'.

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

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

~~~
mnutt
Jammit is great, but I think he meant he built one for node.js.

------
DanielRibeiro
_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
Why? Exploration and evolution are in many ways the opposite of education, but
that doesn't mean they are bad things.

------
glenjamin
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
Does this help if you even bloody `rake` is not backwards compatible? 0.9.x
has caused all sorts of trouble for me...

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

~~~
awj
> * 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

I like Rails, but these two points right here are bullshit. Rspec and Bundler
being ridiculously slow are valid problems with those projects. Papering over
the problem is not solving it, and I'd rather be polite than state what I
think of calling people idiots for _not_ papering over the problem.

~~~
nwmcsween
You're not _papering_ over anything, rspec is slow because it _has to_
initialize a whole rails stack if you want speed make it happen in the
background - you don't stare at compiler output while compiling a large
program do you? Again bundler isn't slow due to bundler being slow, it's slow
due to IO.

------
jpdoctor
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?

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

~~~
karterk
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
Node is a web framework because it has a HTTP server built in? By this logic,
EventMachine is also a web framework

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

------
karterk
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
Should we really worry about graceful degradation anymore? Personally, I don't
waste much time on this like I did years back.

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

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

------
Uchikoma
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
what zed said about him is not absolutely wrong
<http://oppugn.us/posts/1276150607.html>

~~~
nathan_f77
Wow, that post was terribly offensive.

... as was the code that zed linked to -
[https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb9...](https://github.com/gilesbowkett/archaeopteryx/blob/0b08ebdb91471fdb91b534b7e0d6632b2b6f4b98/lib/arkx.rb)

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

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

------
mcantelon
Tldr: Giles discovers 2011.

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

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

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

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

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

------
jgeerts
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
Dupe: <http://news.ycombinator.com/item?id=3627368>

------
tmanderson
Wait. Node is a framework now?

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

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

