Yehuda Katz on the future of the client-side web

Elliot Bentley

The JAXConf keynote speaker and jQuery standards lead on single page applications, the role of the server and the “extensible web”.

Ahead of JAXConf next week, we spoke to
keynote speaker Yehuda Katz about his thoughts on front-end
development and the diminishing role of the server. Make sure to
check out Katz’s latest project Ember.js, a new JavaScript MVC


JAX: Why does a developer need a complex
JavaScript framework like Ember.js when building their

Katz: I don’t think a developer needs a complex
JavaScript application, and I think if you’re thinking that you
don’t need JavaScript in general, you should not necessarily use
Ember. Basically I think there’s three types of developers.

There’s two on the extreme ends. There’s developers that really
don’t need JavaScript, they’re building, like, an HR system and
they can just use Struts or something, and they’re really in no
need of JavaScript.

And then there’s developers that are building applications like
Rdio or Google Music, which are for sure going to be doing things
with JavaScript, because it doesn’t make sense to not use
JavaScript. I think the guy who doesn’t need JavaScript at all
should go ahead and do the thing they’ve been doing, and the guy
who needs JavaScript should use a framework like Ember.

There’s somebody in the middle who I think is deluding
themselves. Somebody who knows they need “a little” bit of
JavaScript, or a “a sprinkle” of JavaScript, because they want a
fast, interactive app, but they think they’re going to get away
with, y’know, a little bit of JavaScript. But if you look at any of
these applications, before long they end up with a monstrous
megabyte of JavaScript – of little sprinkles here and these. I
think in my keynote at RailsConf I said, a megabyte of sprinkles –
or a whole cup of sprinkles.

I think if you know you’re going to use JavaScript, you should
be honest with yourself about how much JavaScript you’re really
going to use, and if you’re going to use a bunch of JavaScript, you
may as well do it in a way that’s coherent, that’s using a
framework. Otherwise you’re going to end up doing it yourself, and
it’s not going to be pretty.

And I think more and more people are going to be in that camp.
They think they can get away with a little bit of jQuery, but in
practice they’re going to need a lot more.


JAX: Are single-page web apps – where an
entire site is generated dynamically using JavaScript – the

Katz: I don’t tend to call them single-page apps, or
JavaScript-heavy apps. I tend to call them long-lived apps, is the
terminology I use. I don’t want to speak about the future, it’s
hard to know, I don’t have a crystal ball.

But, I think increasingly, for a few reasons, users are
demanding applications that are persistent – the reloading time is
unpleasant. Basically, the main reason people are drawn to
long-lived applications is – imagine you’re using Rdio, and every
time you hit the play button it caused a refresh. It would be
extremely annoying.

You could make it work, but it would be annoying… [or] every
time you hit the forward button it would cause a refresh. So, I
think people are drawn to long-lived applications because they want
to control what happens when the user clicks on something more
effectively than going back to server all the time.

Another reason is that people have other applications, like iOS
or Android apps, that already need to have a JSON API, and so they
want to make use of that JSON API in the browser.

I think probably the biggest problem facing the single-page /
long-lived apps universe is, many, many people are building
applications that do not support URLs well. So if I’m using Rdio,
Rdio actually does a good job [of supporting URLs] – if I’m
listening to a song that I find interesting, I can easily IM it to
you, I can tweet it, I can bookmark it… all that works.

But many, many people who start new with apps, they’re mostly
thinking about what I said before, which is fast, responsive,
performant applications. And they just don’t think about URLs until
it’s too late. And that really breaks the web’s UI. In my opinion,
the web’s UI is URLs. The reason the web is so viral is because
anybody could take what they’re looking at and give it to somebody
else. And there’s many, many mechanisms that people use – email,
IM, Twitter, Facebook, Google+ – to share. And if you break
people’s ability to share what they’re looking at effectively, it
will stop being as effective.

I think people feel this way when they look at content on their
mobile phones, that it’s hard to share what they’re looking at.
And, you may have to do a lot of extra work to make it shareable,
but the web is already a thing that has a solution for this, that
everyone knows how to use.

And this is probably the main technical priority we have with
Ember – continuing to make it easier and easier and easier to have
URLs. The main way that we do this is by making the architecture of
your application based around URLs.

It’s actually very hard to build a good Ember app without URLs,
just because when you go from – let’s say you’re on Rdio, if you go
from a list of songs to an individual song, and you’re replacing
some UI. The happy path to building that is to have a path for
songs, and a URL for songs, and you have a link that goes into a

And what we’ve done [in Ember] is we’ve made it [that] the
amount of code necessary to say all those things [is] very small –
a line of code in the router, there’s a few lines of code that say
what model you’re trying to use, we automatically the template
that’s the same name as the route that you’ve generated, with the
model that you’ve specified in your route. So, a lot of things – we
basically end up with a package of concepts that work really
nicely, that are centered around the route that you’re in.

I honestly think this is the number one thing that is facing
people building this type of application, because of the fact that
it’s so easy to get into it because you want fast, and forget that
this is an important thing. And then get stuck, y’know, later on –
“aah, my users are asking for URLs, what now?”


JAX: Do you see the role of the server diminishing
further as they become even “thinner”?

Katz: So, no. Here’s what I usually tell people who ask me this
question from Rails – but I think it’s applicable. You’re a server
developer, think about the application that you have built and
think about what percentage of the application is dedicated to
generating HTML, and what percentage is dedicated to something
else. Most applications have a lot of code – that is more code –
that is dedicated to something else than generating HTML.

The way I usually describe it is: every single application that
is worth its salt has some interaction with the real world. And
that might be things like sending emails, but might might be
something like sending packages, it might be things like sending,
dealing with money.

There’s some interaction, some seam between your application and
the real world, and in general – because of the security model of
browsers, which is a good thing – browsers cannot interact with the
real world, they’re sandboxed, they’re isolated, they need a server
to talk to real world. And typically if your application is very
interesting, it’s doing a lot of work.

If you’re a medical records company, the seam with the real
world is large. It’s doing a lot of things. And yes, if you’re
building a game with a leaderboard, you can probably get away with
having a simple server. But you could always have got away with a
simple server, right? I think the apps that are interesting are
doing much more complex interactions with the real world, and those
applications will always need complicated servers.

Now, I think an interesting thing is, there are companies like
Parse [a mobile-backend-as-a-service startup
recently acquired by Facebook
] that are trying to figure out
some 80% of things that are common, like money, email, database
[connectivity]: things that are common, that you need a from a
server, and try to patch them up. I think that’s a tough story,
because there is typically some other thing that is the point of
your app existing in the first place that does really need to be

So, you’re not going to be able to build a medical record
company using Parse. But I think there’s a lot of applications at
least starting out that could benefit from a system like that – but
Parse is itself just a complicated server, right? Parse is a
complicated server on its own, it’s just packaging up a couple of
common cases.

I think when people say things like, the server is just going to
be a dumb JSON pipe, and they imagine it’s just going to be, like,
connecting a database to the client, they’re missing what these
things tend to do. I would just say, for people who doubt it – just
think about your own application. Think about how much code in your
application is dealing with something that is not just piping some
database directly into your client. Usually, there’s more code in
that part than the code that generates the HTML.


JAX: Your keynote is on “The Future of the
Client-Side Web”. How do you see the area in five years’

Katz: Five years is hard. I’ll say a few trends that I hope
continue, that will make me happy if they continue. And if they
happen, I can do a little bit of prognostication.

One is evergreen browsers – the idea that browsers increasingly
automatically update themselves. Tom Dale just recently wrote
a post
about this – my partner in crime – and basically his position is
that evergreen browsers are a singularity. I don’t think he uses
those words exactly, but he did quote Kurzweil. It’s hard to
predict the pace of progress when we get to a place where most
users are on browsers that are evergreen.

Today, if you’re an iOS developer, and Apple releases some new
features, you get to use them right away. Which means that the pace
of progress is relatively steady, although it’s all driven by
Apple. The web is actually a different place, in the sense that a
lot of innovation on the web is driven by users. There’s a much,
much more vibrant open-source community, a much more vibrant
JavaScript ecosystem than there is an Objective-C ecosystem, but
we’re stymied by the fact that the platform itself is not
introducing the features at a fast clip, because of older

When new browsers are actually increasing features – WebRTC is a
good example, I can open a connection between Chrome and Firefox,
and have a kind of Google Hangout in theory, using just the web.
Big deal. But it doesn’t work on old browsers, which are still
making up a big chunk of the market share, so we can’t do anything
with them. You could imagine evergreen browsers finally winning – I
think Safari is a problem with this, but let’s cross our fingers
and hope – you could imagine evergreen browsers become the thing,
which then means as platform features roll out, they can be used
immediately, which then feeds in on the big open-source community
and the innovation of web developers.

I hope five years from now, we haven’t got into another IE6
situation with Safari, or some other browser that decides to stop
caring. I think the real singularity point, and what’s hard to
prognosticate about, is, the fact that the open ecosystem of the
web actually is very powerful, and people have done things like,
build compilers for the next version of JavaScript in the old
version of JavaScript. These are things that, if we just increase
the capabilities of the web just a little bit, if we move the
capabilities forward so that the open ecosystem can do more things,
I think we’ll see more.

So that’s the high level, evergreen browsers. I think the
low-level is things like web components, Google’s MDVs –
Model-Driven Views – which is basically a built-in platform support
for data-bound templates, I think are coming. There’s new CSS stuff
– some stuff to call out is layout finally being solved with CSS,
with flexbox and grid support. So, that’s been around for a long
time, it’s just finally making it into browsers. CSS Object Model
stuff, there’s a bunch of work on making it easier for developers
to add stuff…

So, all that said, I think my high-level on that, the thing that
brings together all those things, is what I and other have been
calling “the extensible web”, which is essentially filling gaps
where you can’t easily extend things as a web developer.

An example of that would be, you can’t add new properties to
CSS, as a rule. From the web developer’s perspective, the main API
in CSS is a string. So if you want to add another property, you
can’t provide a hook that the browser calls into JavaScript and
says, what shall I do with this property? You have to wait for the
browser to add it.

Now, as always, there are ingenious people that have written CSS
parsers and [do all kinds of their own CSS layouts. But in my view,
whenever web developers are required to rebuild the entire stack –
like for scrolling on mobile – that puts a massive drag on
innovation, on what people can actually do. Things don’t compose
well anymore… [so] developers are really sad, many developers
aren’t willing to use that solution – again, like scrolling,
because it just doesn’t work right.

I have a blog post that I put up recently, called ‘Extend
the web forward’
, where I talk about this in more detail. But I
think – what I hope – my personal mission on standards bodies these
days is to make it so that the web focuses on providing
capabilities in a reasonably factored way, so that web developers
can fix mistakes.


Don’t miss Yehuda Katz’s
at JAXConf next week – get your free ticket

comments powered by Disqus