Yehuda Katz on the future of the client-side web
The JAXConf keynote speaker and jQuery standards lead on single page applications, the role of the server and the extensible web.
Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is the co-author of best-selling jQuery in Action and Rails 3 in Action. He spends most of his time hacking on open source—his main projects, along with others, like Thor, Handlebars and Janus—or traveling the world doing evangelism work.
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.
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 song.
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 custom.
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’ time?
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.
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.
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.
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.