

Moving on from Rails - michaelty
http://broadcastingadam.com/2011/11/moving_on_from_rails

======
peteforde
As an early Rails adopter who rarely gets to code directly on projects anymore
(I'm a victim of my own success) I find it really curious when developers feel
the need to post expository essays about framework switches. Things move fast
and it would be bad for tech evolution to stop, so there's nothing to be loyal
to unless you've placed awkward bets on the future of any given tool.

DHH said at the first RailsConf that he was tired of people asking if Rails
would "hit critical mass" or become "ready for the enterprise" because Rails
as a tool hit critical mass the moment it was useful to him and the core team
that built Basecamp and Shopify. If anyone else found it useful then awesome,
but everyone else can pretty much go fuck themselves.

Cocky? Sure. A lot of fun to be part of? Hell yeah.

I've never been on core but I can arrogantly speak for the early Rails
community when I say that we excitedly encourage all Rails fans to try out
Node, Django, SC and Backbone. Anything which captures your imagination and
makes you see coding in a more whimsical, _why?-like way.

I recommend anyone that hasn't seen it check out Foy Savas' amazing talk from
FutureRuby in 2009, Polyglots, Unite!

<http://www.infoq.com/presentations/savas-polyglots>

~~~
Addict
This should be top comment!

I'm still waiting for my crack through...

<https://github.com/crack>

:D

------
rickmb
The author seems to consistently confuse architecture, languages and
frameworks. None of his arguments have anything to do with Rails, Ruby, PHP or
whatever else he mentions, except partly Javascript.

This seems to be a recurring pattern with developers who have "discovered"
design and architecture through frameworks and can not seem to separate that
from the tools used.

~~~
kayoone
thought the same, like he says PHP was shit and still is (which is partly
true) but then delivers CRUD Tasks, ORMs etc as the reason for Rails which
also are very popular in all other frameworks for other languages nowadays.

~~~
dextorious
"""but then delivers CRUD Tasks, ORMs etc as the reason for Rails which also
are very popular in all other frameworks for other languages nowadays."""

The might be popular for "other languages nowadays", but he delivers those as
a reason of Rails success BACK IN THE DAY.

And indeed it was. Not many PHP ORMS and scaffolding frameworks existed or
where successful back then.

------
fosk
I think the whole point here is: build APIs first, wrap all the client code
around them. If I have an API written in Ruby/PHP/node.js/Java/whatever, and a
standard format (or protocol) to exchange data, I can then build the clients
in Ruby/PHP/node.js/Java/whatever, clearly separating the backend and the
frontend which can now be built in completely different ways using different
technologies.

This is not new. There are lots of system out there built on top of
private/public RESTful (XML/JSON/whatever)/SOAP APIs. There are both huge and
small applications on top of distributed, stateless, components that clients
can easily consume and that makes the whole architecture highly scalable
(again: stateless). People can do this on HTTP, TCP, UDP or on
TheirCoolProtocol.

------
xd
"I was coming from PHP. PHP was shit then and is still shit now."

I find it embarrassing that the community would vote up a story with comments
like this. There is simply no need for it, and it shows nothing but a lack of
articulation and outright immaturity.

If you don't like PHP, fine, but slamming it with one word insults does
nothing but insult the tens of thousands of developers out there that use PHP
to solve real world problems for a living.

~~~
jwblackwell
In defence of PHP:

Firstly, every time I see it getting slammed its nearly ALWAYS PHP in
comparison to a framework whether it's rails, django, web2py or whatever. As
soon as I see this I can't help but feel the author is just jumping on the
"PHP isn't cool bandwagon". PHP isn't a framework, so don't compare it to
other frameworks.

Secondly, it is possible to write good code using PHP - and many people do. It
powers some of the largest sites in the world and there are more PHP web devs
out there than any other working on millions of PHP sites. There are also some
excellent frameworks for PHP that are quick to learn, fast and powerful.
Codegintier, Yii or Symphony(2) all spring to mind.

Finally, for most web developers who actually need to earn a living writing
code to solve problems, PHP is still the most popular choice for good reason.
It's easy to earn, easy to deploy, cheap to host and widely used. There are
also more PHP jobs (especially in the U.K.) than any other and it isn't
changing anytime soon. For the busy developer trying to make a living these
type of posts aren't really helpful at best and at worst quite insulting.

~~~
hello_moto
I'm not sure you should put "write good code using PHP" in the same paragraph
with "some of the largest site in the world". Because they're the exact
opposite.

Facebook, Wikipedia, Wordpress, all of them don't have a good PHP codebase. In
fact, people despise them.

PS: for the downvoters, why the hate? it's the fact though. I'm not saying you
cannot write good code in PHP. What I'm trying to say is that "big sites out
there" are not a good example of "writing good PHP code".

~~~
dextorious
"""Facebook, Wikipedia, Wordpress, all of them don't have a good PHP codebase.
In fact, people despise them."""

You've seen Facebook's codebase? I doubt it.

And when you show me a blogging platform more successful than Wordpress, then
we will talk.

Who exactly despises FB, Wikipedia or Wordpress? Not the users.

And while I can't talk about Wikipedia and FB (haven't seen the source),
neither do Wordpress developers (including the tens of thousands of plugin
authors) despise Wordpress's codebase.

Also, it's not about how well you like it, it's about what you can do with it,
and especially what you users can do with it.

Yeah, Wordpress could have been written in, say, elegant Haskell. And then it
would have gotten nowhere, because very few people could have got it working
on their webserver or on a shared server platform. And it would have lacked
tons of extensions that PHP gives it, from Imagemagick to LDAP to DB2 client
libraries --or it would have to use some less battle tested, less popular and
less mature Haskell equivalents.

~~~
hello_moto
Facebook, Aditya Agarwal, presentation:
<http://www.infoq.com/presentations/Facebook-Software-Stack>

Judge for yourself (you probably have to interpret what he said there since
obviously he doesn't say up-front "it sucks" but the words he chose describe
the situation).

Maybe despise is a strong word.

But what's your point? successful project so they must have good codebase or
something?

My original post was that "those projects don't necessarily have a good code
base" (thus you may want to choose other examples to show a better written PHP
code base).

You're off by miles.

~~~
dextorious
"""But what's your point? successful project so they must have good codebase
or something?"""

I never implied that "because they are successful, they must have a good
codebase". I actually made a different point, essentially asking in return:

What's a "good code base"?

Wordpress's, for example, is good at what it does, not in some idealistic
theoretical way. Not only it resulted in a successful product (actually two:
wordpress + wordpress.com), but it also has been proven stable (heard often of
WP crashing mysteriously for any other reason that too much load and no
caching which is totally reasonable?) and flexible to build upon (wordpress
constantly adds features to its core and tons of developers add third-party
add-ons).

I'd argue that "good" code base = flexible, extensible, successful, liked by
IT'S developers. WP has had all of those. So, for THEIR PURPOSES and to THEIR
DEVS, it is a good codebase.

On the other hand you implied that FB, WP, Wiki's code is bad. I tried to show
that WP's at least is far from bad by MANY metrics. What are your metrics?
Besides, say, proof by rigorous handwaving?

As for the FB presentation, he never says despise or sucks, as you mention.
It's a classic presentation of some trade-offs. You'd have a selection of
those even if you coded in Haskell or whatever.

------
bphogan
This is less about moving on from Rails and more about moving on from building
static pages from a database. Lots of web folks have been predicting this.
I've been saying for about two years now that the days of serving entire HTML
pages from the serverside are numbered. With things like Backbone, I can bring
up a Rails app without views and do something pretty awesome. And then it
becomes a question as to what Rails offers.

I love Rails. It got me back into web app development in 2005 after nearly
burning out. But Rails isn't exactly keeping up and people who need to move on
are going to do that.

~~~
bad_user

        I've been saying for about two years now that
        the days of serving entire HTML pages from the
        serverside are numbered.
    

You'll keep saying that for another two or three years at least.

    
    
        With things like Backbone, I can bring up a Rails
        app without views
    

Backbone-style development sucked when people did it with Microsoft's MFC, it
sucked when people did it with Java's Swing and it sucks right now. At least
for native graphical interfaces, you have IDEs to help you out with bindings
and all that crap.

Rails gives you the possibility of doing progressive enhancements, when you
need them. You don't have to build an entire Backbone layer, just for updating
a small rectangle on your page, when you can just render a partial in a good
old-fashioned way.

    
    
        But Rails isn't exactly keeping up
    

It's just a tool and not all of us need to build GMail. People treat Rails
like it's their girlfriend or something.

~~~
hello_moto
It's about time to keep up with Zed Shaw tradition: the prediction that Alpha
nerds will leave what was hot a few years ago with a lot of crappy code for
the next generation.

Here's a prediction: 6 years from now, there will be more crappy heavy
JavaScript based web-application out there and the biggest money making is to
maintain and fix these apps.

~~~
bphogan
That's not far off. I've made good money fixing Rails apps that have no tests
:)

------
hello_moto
I did a single-page app before with GWT. I guess the GWT crowds beat y'all by
miles since 2007.

The problem with this kind of web-app is that it's so much harder, so much
more difficult, so much effort is required. And you need to be very very
discipline and build automation testing from ground up (and I know many
developers are just lazy to write automation testing, don't give me the start-
up/iterate faster excuse, lazy is lazy).

At least with GWT, there are patterns and good practices to support unit-
testing and modularizing your app properly.

In JavaScript? the fight just goes uphill straight away. In 2011, we still
don't have automation test framework that is headless (console based) without
requiring investment to infrastructure. And this is largely because the
mentality of JS developers is to test in real-browser. Which is fine. Except
the extra effort required to setup automation-test will cause a lot of people
to find more excuse not to write automation test.

I get that developers are optimist people. But time through time, developers
get burned so bad. Most people don't even know how to write JavaScript code
properly but they're so ambitious. These people bite more than what they can
chew.

So... good luck doing that while some of us will stick with
Rails/Django/PHP/JEE6. Get ready, you're in for a lot of pain.

------
mceachen
I don't understand why this article is remarkable.

It shouldn't be a grand revelation that there is more to web development than
what runs on the server.

~~~
dmix
Or a developer getting disinterested in the framework he has been using for a
while, for that matter. It's pretty common.

------
thomasfl
TL;DR When web applications is written mainly in javascript and communicates
with the server over json, what language is beeing used on the server becomes
less important. As long as it's not php. ;-)

------
choxi
great summary of architecture trends. i think there's a room out there for
someone to build a framework with the server-side simpleness of Rails and the
client-side elegance of Backbone/SproutCore

------
div
It seems like the title is a bit poorly chosen.

The author talks about the importance of having a platform to cater to the
multitude of devices and other apps out there, and that this means rails isn't
the center of the universe anymore.

To me, this does not necessarily mean moving on from rails.

It does mean moving on from writing all code in rails.

There could be a fullfledged backbone.js app powering a responsive ui, and a
distributed clojure jobqueue making sure messages are fanned out to their
destined networks in the backend. However, there is still room in this picture
for Rails as a router of sorts.

Rails still makes it easy to quickly build a solid REST api, and easy to
delegate long-running jobs to a separate system, in this type of architecture,
Rails would have roughly a third of the responsibility / code that it has in a
Rails only architecture, but it's still a vital component.

------
j_col
I stopped reading at:

> PHP was shit then and is still shit now.

Way to go shitting all over so many peoples work.

------
hmans
tl;dr - web development is changing, the frontend side of things is gaining
significance, while the backend is moving to, well, the background.

No reason to be surprised there, right?

------
cvshepherd
"From my experience, generating a good UI (V) takes orders of magnitude more
than implementing M and C."

yeah, because picking the right font has always been way more of a task than
domain modeling.. (yes, i know that ui / ux isn't a breeze, but this depiction
is just insane.)

------
verroq
So what web framework are we supposed to use now?

~~~
fuzzix
"So what web framework are we supposed to use now?"

Flippant answer: Whatever works

Pointed answer: I am paid to write RoR apps. When I need to get stuff done at
home I use Perl, if it's for the web I recommend Dancer[1], which was inspired
by (i.e. nicked from[2]) Sinatra[3].

I've found MVC to be a little bit too much architecture and scaffolding for
many tasks.

 _edit_ : Not to say I don't want an architecture, but the routes and
templating of Dancer are the essentials. Occasionally I will find myself
missing the bloody lovely validations in Rails' ActiveRecord, but I am usually
grateful for the light weight of the finished product and the fact that the
entirety of it fits in my head when building with Dancer.

[1] <http://perldancer.org/>

[2] ;)

[3] <http://www.sinatrarb.com/>

------
ksetyadi
"Think back to when Rails first came out. There was no iPhone. There was no
Android. People still owned Nokias and actually bought stock in the damn
company. Windows XP was still massively popular and we were fighting to get a
decent version of IE (but that will never end). There was no such thing as a
mobile web. No one was thinking about tablets. How old is the iPad? Not very
old".

OK, no iPhone and the iPad is not very old. Wikipedia should change their
contents, especially on the dates when the iPhone and iPad were launched.

