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.