LUKE FRANCL: Good afternoon. I'd like to get
started if, I
think, everybody's ready. Cool. Cool.
Thank, thank you for joining me this afternoon.
I'm
excited to be here. And thanks for, thanks
for
choosing this talk.
So it's been ten years since the first public
release on Rails, so I think that's a good
time to think back and reflect on where Rails
has come from, where it might be going, and
what the future has in store.
So, I've been thinking a lot about the early
days of Rails, lately, because the company
I work
for, Swiftype, makes site search software.
So I use
my own website for testing. So I index my
site and then have to do searches on it,
and I'll search for Rails. Just cause I'm
not
super creative and I need to search for something,
right.
And, in doing so, I found some old blog
posts that I wrote in early 2005, when I
first discovered Rails. And it was really
interesting for
me to read, because back then, I was, I
was working as a Java developer and I was
really interested in Python. And Rails was
neither of
those things. So I was pretty skeptical of
Rails.
Like, I was impressed with it, but I wasn't
sure it was worth learning Ruby over.
So I thought, I'll just sit back and let
the Python people catch up. And I waited and
I waited and I waited, and that never really
seemed to happen. And so after a few months,
I jumped into Rails and started learning it
and
I started learning Ruby so that I could use
Rails. And then that fall, I got wind of
a new group starting in my home town. The
Ruby Users of Minnesota. And so I was, I
was there at the first meeting when there
was
twelve people talk, who were just really excited
about
Ruby and really excited about Rails.
And at that point I joined the, the Ruby
community and became a part of that and really
have not, have not looked back since then.
And
I've been working with Rails professionally
now for about
eight years.
So this made me think about a book I
read once called Looking Backward by Edward
Bellamy. So
in this book, which was written in the late
1800s and takes place at that time, a rich,
upperclass man is hypnotized. And he falls
asleep for
over a hundred years. And when he wakes up,
everything has changed.
America is now a socialist utopia. And so,
you
know, he had it pretty good before, right.
He,
he was wealthy. He had servants. And now everyone
is equal. And so he's pretty skeptical of
this
new order.
So it takes him awhile, but as he's shown
the new way of doing things, he becomes convinced
that this is actually a better way. And that
made me think of, think of my situation, where
I was, I was skeptical of Rails, and, but
eventually won over.
So today, what I'd like to talk about is
the idea of what would a programmer from 2004
think if they could time travel forward to
today
and experience our web development utopia.
What would that
be like, for them, to see how we work
today?
So, what I'd like to do today is first
talk about what web development was like in
2004.
Then, I'd like to jump forward to the present
and think about what a programmer from 2004
would
think about our web development utopia of
today. And
finally I'd like to take a look at what
the future might have in store for Rails,
and
what the, what the legacy of Rails might be.
So first, let's talk a little bit about what
development was like in 2004.
So if I can set the stage for a
minute, I see a lot of Mac Books here
today. There were no Mac Books in 2004. The
top of the line Apple laptop was a Power
Mac G4. And, you know, Apple had not completely
penetrated the web development community like
it has now.
There were only, I, I used Linux at work
myself. And, a Windows at home, actually.
And the
most popular phone, like, maybe not the most
popular,
but the hottest phone in 2004 was a Motorrola
Razr. So, right?
So things were pretty different there. Things
were pretty
different then. And I was working as a Java
developer at the time. And I was pretty excited
about that, because I graduated in 2001, right
after
the dot com bust. And things were pretty sketchy
there for awhile. It was hard for me to
find a job. And so I was excited that
I was able to work as a Java developer,
in the hot language at the time. And I
was, I was glad that I was able to
work at a software development company, where
I could
work on software for sale instead of working
in
the cost center at a, at a big bank
or something like that, right.
So I was working as a Java developer, and
if you've ever done any Java web development,
you
know that it can be pretty painful, right.
At
the time, the, the best way to do Java
web development was struts and hibernate.
But we didn't
use either of those. We used raw Java servelettes
and hand coded J, JDBC queries to our database.
So the, the real problem with Java as a,
as a web development platform, at least in
those
days, was it, it has a really long edit,
compile, debug loop. Or, in the case of, of
Java web development, it's the edit, compile,
deploy, debug
loop. Because you have to restart your app
server,
and we used Web Sphere, so that took a
long time.
So if I needed to write a new page
for, for our app, it, it was a pretty
involved process. So we used raw servelettes,
so that's
sort of like using a raw CGI library, where
it's very low-level. And if, when you work
in
Java, it's very verbose and you have to read
from input streams and write to output streams.
And
it just doesn't have the conveniences of Ruby
or
a scripting language.
So I'd have to write my servelette, then I'd
have to write a bunch of XML files, or
XML code in the web dot xml file to
map it up. And then you'd compile everything
and
get it working and then restart your app server,
which would take several minutes. And then
browse to
the new page to, to see what it, what's
going on there.
And that's where the fun would start, because
that's
when the JSPs came into play. So JSP is
just like ERB, right. Instead of Ruby, it's
Java.
But Java a much more heavy-weight language,
and it
doesn't have, you know, friendly looping constructs
or mapping
constructs like Ruby does. So writing view
code in
Ruby, or in Java is not very much fun.
But worst of all, the way that JSPs work
is that it takes the Java, or the JSP
code that you write and it compiles it into
a Java class file. And then that Java class
file gets compiled into code. So when you
get
an error, when you're debugging, you'd get
this stack
trace, and it would be like, NullPointer exception
on
line 12,075 of line 20,082, and you'd sit
there
and you'd think, ah. What was I doing in
my JSP that could cause a NullPointer exception?
And you'd look at the JSP and you'd look
at the stack trace, and they had no correspondence
whatsoever, right. So it's really painful.
And if you
were smart, you would, there was a setting,
like
a secret setting you could use for Web Sphere
to keep around the compiled Java files. So
then
you could open that up in your web browser
and look at line 12,075 and be like, oh.
That's what I was doing in the JSP.
So, web development in Java, especially in
2004, not
very much fun. But there was, there was also
at that time a glimmer that something better
was
on the way, that the web could do more.
There was a new sense that the web was
a powerful platform for delivering software.
And I think
that the earliest glimmerings of this come
from Microsoft's
Outlook web app. This was the first application
to
use what we would call today Ajax, without
requiring
any kind of browser plugins.
So that, that came out in 2001. And people,
people didn't pay much attention to it because
it
was IE only and it, it wasn't clear how
it was working, right. And then Google launched
Google
Suggest. And people dissected that, and they
saw how
it was working. And they also launched Gmail,
which
gave people a new sense of what was possible
in a web app. That, that web apps could
automatically refresh as things were changing
on the server.
So there was a new sense of what was
possible. That, that, that maybe there was
a better
way of writing web apps. And in 2004 I
was also looking for something better. Because,
and I
attribute that to a book I read early in
my career. The Pragmatic Programmer by Dave
Thomas and
Andy Hunt. And in that book, which is, it's
a terrific book about becoming a better software
developer,
a better software crafts man. In that book,
they
talk about the importance of learning a scripting
language.
And that's because, if you were working in
a
language like Java, there's often things that
are too,
too small of a task to make it worth
writing a Java program to do. And, but a
scripting language you can, you know, knock
that off
really easily.
So things that you might do manually, you
can
instead write a script to do for you. And
so I took that to heart, and I went
to the book store. Remember, this was the
early
2000s. There were still bookstores. And I
looked at
all the books that they had about scripting
languages.
So there was a bunch of books about Perl.
There was a bunch of books about Python. And
there was this one book about Ruby by those
same guys, Dave Thomas and Andy Hunt.
So I immediately just started the books about
Perl,
because I'd worked with Perl before and I
thought
it was terrible. And I looked at the books
about Python, and I'm like, this looks OK.
I
can see myself using this. And then I looked
at the book about Ruby. And, unfortunately,
what I
saw in the book about Ruby was a lot
of dollar signs and dollar sign underscores
and at
signs and at at signs. And I thought, this
looks just like Perl. I don't, I don't want
to learn this. This, this is, this is, this
is crappy.
So I decided then to become a Python programmer.
And I was actually able to use Python for
a number of things in my job and my
personal programming. I wrote a script to
migrate from
one bug database to the other. I wrote a
script that tied our subversion check ins
to our
bug database so you could reference bug numbers
and
link up the commits and stuff.
And I, I wrote some personal scripts. But
what
I really wanted to do was write web apps.
Because that's, throughout my career, that's
always what I've
been most excited about. Because I've always
loved the
potential of the web as a platform for enabling
communication. It's, it's the most powerful
and widely distributed
way that you can connect people.
And so every time I would have an idea
for a web app in Python, I would start
thinking about how it, or, I would start thinking
about how it should work and what it should
do. And I'd get excited about it, and want
to build it. And then I'd start reading about
how to build web apps in Python. And get
really frustrated.
Because, then there was no clear way. There
was
no Jengo. There was CGI in the core library,
but, you know, who wants to write at that
low-level? There was, then, a myriad of templating
options
and different object relational mappers and
different ways of
publishing your objects to the web and different
database
drivers. And, there was no clear way of deploying
the software, either.
So I would have this idea for what I
thought would be the next great app, and then
I would start reading about Python, how to
implement
it in Python and get frustrated and give up.
But I didn't know it at the time, but
there was something better on the way.
So let's turn now to 2014, and think about
what would a programmer from 2004 think about
how
we work today.
And I think if you could take someone from
then and bring them forward to now, I think
they would be amazed. Because it's truly a
great
time to be a programmer. We're all walking
around
with a computer in our pockets that's more
powerful
than the desktop I had in 2004. And it
has a, a better web browser, too.
So think about what's different between now
and then.
In 2004, Ajax was in its infancy. The term
hadn't even been coined yet. Today, rich Ajax
frameworks
come with every web application framework.
So you can,
you can build rich, interactive applications
much easier.
And, you can even write your entire frontend
in
JavaScript if you want to. Web browsers are
immeasurably
more powerful now than they, than they were
then.
Deployment is much easier, too. In 2004, it
was
really hard to figure out how you should get
your app up on the web. You could colo,
but that was expensive. You could use shared
hosting,
like, DreamHost or something like that. But
those servers
were underpowered and kind of weak.
Today, you can spin up a server with the
click of a button. You can manage everything
yourself
if you want to use EC2, or you can
rely on platform services like Heroku or Google
App
Engine. And this is really great for programmers,
because
you don't have to be a great programmer and
a great sys admin now to launch a web
application. You can let other people handle
that part.
And that's terrific.
Another thing that I think is really powerful
about
how we work today is that in, today we
have access to all of these web service APIs,
with a simple HTTP request. You can extend
the
functionality of your app really easily by
leveraging these
services.
There's everything from search, like my, my
company provides,
to payments from companies like Stripe, and
even telephony
from companies like Twillio.
So with just an HTTP request, you can add
that kind of functionality into your application
super easily.
And best of all, you're us- they use JSON
instead of XML. So there's no XML setups like
there was back in the early 2000s.
But what about Rails? Like, what would a programmer
from 2004 think about Ruby on Rails? Well,
I
think if you could bring someone, or talk
to
somebody in 2004 and say, in ten years the
best way to make a web app is gonna
be this thing called Ruby on Rails. I think
what they would say is, what on Rails?
It's difficult to overstate how marginal the
Ruby community
was in 2004. When David publicly demo'd Rails
at
RubyConf 2004, there were probably less people
in the
room than there are right now. That, there
were
about sixty people at that conference.
Today, there's dozens of conferences around
the world, and
thousands of people make their livings using
Ruby and
Rails. The community has grown tremendously
since those days.
But what about the features? The features
were really
what made Rails succeed. And if I think back
on what I first thought about Rails when I
saw it, like, what impressed me. Things that,
that
really stand out in my mind are things like
live reloading.
Compared to how I was working in Java, where
it was like, a really long cycle to get
anything up on the screen, in Rails, you could
edit any file. You could edit your model,
you're,
you're views. Even your database schema. And
reload your
browser and it was right there. And that was
tremendously exciting.
And, if you had an exception in your, in
your view, you would see exactly which line
of
code caused it, and not have to wade through
these huge stack traces that had nothing to
do
with what you were working on. And that was
tremendous for developer productivity.
Another thing that was a real big win for
developer productivity, for me anyway, was
the development console.
Rails let you just type a single command and
get full access to all of the code that
you'd been writing. So, for me, I keep that
open all the time. And I am always constantly
trying out things and experimenting and trying
to figure
out how different APIs work by using the developer
console.
This is something that I'd been able to get
working in the Java world using a tool called
BeanShell, which is like a Java scripting
framework. But
it was nowhere near as good as the Rails
console, and, you know, it just was a lot
harder to, to get working.
Related to that is just the idea of having
separate development environments. Rails came
right out of the
box with development, production, and test,
and has separate
databases for all of those things. So you
didn't
have to worry about mixing your code together.
You could have separate configurations for
testing and production
and development. And that really helped with
the software
engineering side of Rails.
Finally, the, the, the last big feature that
I
think really stood out to me was ActiveRecord
and
migrations. ActiveRecord was super exciting,
because here, this, this,
this, this code is sort of magically intuiting
the,
the fields from the structure of your database.
You
didn't have to write any code at all. And
for someone who was writing SQL statements
by hand,
that was really exciting.
And migrations were awesome, too, because
you always need
to transition the state of your database in
your,
in your application.
And, again, this is something that we had
built
at my job. But ours was not as good.
It, it used raw SQL, so you would write
SQL statements to, to transition the database.
And it
was tied directly to the app version that,
that
we had. So, when you would release a new
version of the app, you would have to sync
that with the database. The database version
would have
to be synced with that.
So there was, there was no way to independently
migrate the database.
And there was no way to go down. So
you had to get it right. Rails was better
than that.
But why did Rails win? Why, why was Rails
exciting to people? Because all these features
were available
elsewhere. I think there's three reasons.
First of all, while each of these features
was
something that you could get in other web
programming
frameworks, Rails brought them all together.
Rails was the
whole package. So Rails took things that were
possible
and made them easy. It, even that, it made
them the default.
So Rails took a lot of best practices and
put them together in one thing that you could
use super simply. And that was really exciting
to
people. Even, even for me, because I was able
to, to do some of the things that Rails
had. Having it together in one package was
super
exciting.
The second reason I think Rails succeeded
is the
triumph of hype. If you go back and read
the early blog posts about Rails, it's really
interesting
because it really caused a furor in the Java
and the Python world. Because people were
like, well,
why can't we do this? And in the middle
of all that, you saw DHH. He was constantly
promoting Rails and getting into discussions
and arguments with
other people and blogging about it. And he,
he
was relentless in promoting Rails, and the
early Rails
community was relentless in sharing their
enthusiasm for this
new thing.
And I think that that matters a lot, because
it's not enough to have great code and just
put it up on the internet. That, that never
works. You need to tell people about what
you're
doing in order for them to know about it.
And you need to explain clearly and concisely
why
it's better than what they're doing now. And
Rails,
David and the Rails community really succeeded
at that.
Third. Another reason that Rails succeeded
is the triumph
of community. From really early days, Rails
had the
ability to be extended with plugins. And so
people
wrote plugins that would take care of default
areas,
or not, not default areas, but common areas
of
your application, like logging in or uploading
files.
These are the things that you needed in your
app, but they weren't core to your app. And
so knowing that you could take advantage of
these,
these plugins and later gems really made picking
Rails
an easier choice.
So ultimately, Rails was successful. But what
about the
future? What does the future have in store
for
Rails? I think that Rails does face challenges
in
the future, because, because the web is changing.
What
people want to do on the web is, is
becoming different. And indeed the, the future
of the
web I think is even in question.
So let's look at two challenges to Rails.
First
of all, now that browsers are more powerful,
people
are able to write more of their app on
the frontend. And so, when you do this, you
don't need the kind of classic web app that
Rails is. Rails is really good at generating
a
lot of HTML and shipping it down to the
client. Kind of the classic web app like base
camp.
But when you're writing your entire app in
JavaScript
in the client, what you need is the ability
to talk to the server with an API. And
when that's all you're doing, people can question,
why
do I need Rails? Why do I need all
of this extra stuff that Rails does? I'm,
maybe
I should just use node.js, and then I can
write, you know, the same language on the
client
and the server.
Similarly, mobile apps are becoming increasingly
popular, because you
can do so much more with a mobile app
than you can with a web app. The user
interaction is much richer and, and faster
and, and
just cleaner. And, again, these kind of apps
talk
to the server with an API. And so people
think, well, I don't need Rails, then.
And I think that this, this is a threat
to Rails. But there's two key things to remember
about this. One, Rails is great at this kind
of thing. In our application, we serve hundreds
of
millions of API requests a day, a month, using
Rails. And the way that we do that is
not using action Controller.
But Rails makes it easy to pick out only
the parts of Rails that you need to use.
And so you can, you can take Rails much
further than many people think, I believe.
Second, even if you are building an API heavy
app, not all of your app is going to
be API based. You are going to need a
management console to handle the backend of
your application.
Pretty much every app has this. You need a
way to look up your users and, you know,
change their account status and things like
that.
And, are you gonna build an iPad app for
that? I don't think so. Because it would be
too expensive and slow. The web is still the
best way and the easiest way to distribute
an
application.
So Rails has a real, I think, has a
place for that. Or, there's a place for Rails,
even in an API-driven application.
But even if the web, as a platform, and
Rails as a, as a framework, can't adapt and
fall by the wayside, I think the legacy of
Rails will really live on for a long time.
Because this idea of taking things that were
possible
and making them simple, making them easy to
do,
is really powerful. And it inspired programmers
in many
different programming languages to, to copy
Rails and to
try to get those benefits for themselves.
So I think no matter what the next platform
is, people will be inspired by that aspect
of
Rails, and they will want to write the Rails
of whatever.
I'd also like to look at the reaction against
Rails. Because that's part of Rails's legacy,
too. There's
two examples that I'd like to talk about here.
First of all, there's Jengo. So Jengo can't
be
considered to be inspired by Rails, because
it was
developed at the same time or even earlier
than
Rails.
But since, the, the two frameworks have been
really
similar and, and, and have learned a lot from
each other I think. But the way that Jengo
works, it is really driven by the Python philosophy
of explicit is better than implicit. So in,
in
Jengo, when you, when you like what to map
up a url on your server, you think really
hard about what that url is going to be.
It doesn't happen automatically. And your
database models tell
the database what its fields should be, instead
of
the other way around. In Rails, of course,
we
follow convention over configuration, right.
But if you've ever
tried to teach someone Rails, you know that
this
can be a double-edged sword.
Convention over configuration lets you write
less code, but
it also makes it less clear what's happening.
When
you're teaching somebody Rails, it can be
really confusing
that you edit a route in this file over
here and therefore your controller over here
needs to
be named this and it has these methods available
to it that respond to these HTTP requests.
Or
HTTP methods.
That is not at all obvious. And so it
takes time to learn all those conventions.
And, I
mean, I don't think one is better than the
other. They're just, you know, different sides
of the
same coin. Different ways of looking at how
programming
should work.
Kind of related to that is the second example,
which is microframeworks. Like Sinatra. These
have been incredibly
influential. And I love using Sinatra. It's
just, it's
like such a thing of beauty, when you can
have your whole web app in one file. And
the, the urls that are, that are in your
web app are just tightly connected to the
code
that's going to run when someone goes to that
url.
It, that is like a really wonderful feeling,
I
think. And Sinatra has been probably even
more influential
than Rails. There are copies of Sinatra, or
Sinatra-inspired
microframeworks anyway, in just about every
programming language you
can think of. Anything from Java to PHP to
Clojure, Go, JavaScript. Even Haskall.
All of these have a version of Sinatra.
And in some languages, these microframeworks,
the microframework inspired
by Sinatra is the default way people write
web
apps. It's the best way that they have. And
I think that that is kind of a problem,
because while I love using Sinatra, when an
app
gets above a certain size, I find myself pulling
in more and more of Rails.
And at some point I feel, well, I might
as well just switch to Rails. And so, in
these, I feel bad for these programmers in
these
other languages, because they don't have the
choice to
switch, necessarily, to something as good
as Rails.
So I think, I think Rails actually has a
bright future ahead of it, because it, it's
shown
the ability to adapt and respond to change.
Think
about Rails 1 point 2 and the addition of
REST and making that the default way that
we
think about controllers and resources on the
web.
So I think that if people want to use
Rails to back JavaScript-based applications,
Rails will get better
at that. And if people want to use it
to back mobile applications, it will get better
than,
at that. But you'll still have the ability
to
use Rails for what it's good at when you
need to.
All right. So we've talked about what programming
was
like in 2004. We've talked a little bit about
the features of Rails that made people want
to
use it and made it win. And we've talked
about what could happen in the future. What
is
the, what's the legacy of Rails and will it
be able to adapt?
So a hundred years ago, or, actually, more
than
a hundred years ago, when Edward Bellamy was
frustrated
with the way things were going, with how society
was working, he took up his pen and he
used his imagination to create a new world.
This,
this utopian novel, where he could explain
how he
thought things ought to work.
Now, that may seem kind of pointless. Because
it's
the twenty-first century. America is not a
socialist utopia.
But that book was incredibly influential.
In the years
after its publication, hundreds of Bellamy
clubs were started
across the country, and millions of people
were inspired
by the ideas written in the book.
And those people, and those clubs formed the
nucleus
of the progressive movement in the early twentieth
century,
that broke the trusts and monopolies, and
ultimately paved
the way for social security and the American
welfare
state.
So the book did have a huge influence on,
on the world.
Programming, on the other hand, is a little
more
concrete. So when DHH was frustrated by how
programming,
web programming worked in 2003 or whatever,
he was
able to do something about it. He cracked
open
his text editor and got to work and built
something that people found inspiring.
And when they saw it, they wanted to meet
other people who were interested in that.
And that
was the genesis of the Rails community. And
so
today, you know, we're all here today because
of
the Rails community and because of what, what
developed
over those, those last ten years. So I'm really,
really pleased to be a part of that community,
and really honored to be speaking to you today
about that.
And it, it's made a huge impact in the
direction of my career. And I just find it
inspiring. I find it inspiring that as programmers,
we
can see something that's broken and we can
fix
it. We can create a new reality for ourselves
with code. And I think that that's a really
powerful, really powerful notion.
And we also shouldn't forget the lessons of
Rails
as we did that. Because Rails didn't just
win
because it was, because it was better, though
I,
I do think it was. It won because of
the community around it and because of the,
their
passion for telling people about what was
so good
about Rails.
So most of us probably are not going to
write the next great framework. I, I, I don't
imagine that I will. But I think that this,
we can take to heart the lessons of Rails
in our own work and in the libraries that
we're writing.
Don't forget to, to, to try to make things
easy. To try to make it easy for your
fellow programmers. And don't forget to tell
people about
it and explain why they should use what you've
written. And I think if you do that, you
can help make the world a better place.
Thanks.