JAX London 2014: A retrospective
Noteworthy

Yehuda Katz on the future of the client-side web

ElliotBentley
yehuda-katz-teaser

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

  • Yehuda Katz

    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.

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 framework.

 

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

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 future?

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 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.

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 browsers.

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 keynote at JAXConf next week – get your free ticket now!

Author
Comments
comments powered by Disqus