A major contributor to both jQuery and Rails, Yehuda Katz wants to change the way we develop websites once again with Ember.js.

Interview: Yehuda Katz
Keine Kommentare

Besides being a core team member of two of the most influential web frameworks of the past decade, Yehuda Katz has another reason to brag: he was GitHub’s fourth ever user.

It was a matter of being in the right place at the right time. When Katz moved to San Francisco, he begun hanging out with Chris Wanstrath, who happened working on a social Git hosting service that would become GitHub.

Back then, Katz was a Subversion user – reluctantly, since “nobody could figure out how to reliably host a Git server”. When he heard about GitHub, Katz “begged” Wanstrath for an account – and, when the service finally launched, was given the first non-founder account.

“I think the interesting part of me being there at the time was just that I am aware that the social coding thing was part of their idea from day one,” he tells me, sitting in a cafe in London. “The idea that they were really building a social network and not a Git hosting service was part of their vision for what they were doing from the beginning of their process.”

Katz, who began his career as a print designer and fell into web development by a “happy mistake”, has a knack for spotting projects that go on to be hugely successful. Becoming involved in jQuery “super early”, he became best known for Visual jQuery, an interactive cheatsheet for its API.

While helping jQuery grow in popularity, Katz also served as lead developer on Ruby web framework Merb, which later merged with Rails. “I did a lot of work getting jQuery to work with Rails,” he says of the symbiosis between the two projects. “I think me being on both avoided some disastrous mistakes that could have happened.”

Almost a decade on, jQuery is now near-ubiquitous, and Katz’s relationship with the framework has changed accordingly. “I don’t need to evangelise it anymore,” he admits. “I don’t even want the code to be very different from what it is now.”

Instead, he now considers the jQuery Foundation’s primary role to be a “mechanism for getting developer voices into places they aren’t, or weren’t”. That is – putting the right people in the right places, at the right time. But more on that in a bit.

Building Ember

Katz’s new venture is Ember.js, a framework for building single-page web applications (though he prefers the term “long-lived apps”). It’s already being used in Discourse, the new forum software being developed by Stack Overflow founder Jeff Atwood, and by the time this article is published, the first stable release should be available – the culmination of three years of work, with a history stretching back even further.

When Rails 3 was released in 2010, Katz had been working on the framework full-time for 18 months and wanted a change. “I sort of picked my head out of the sand, and thought, right, what problems exist right now that aren’t being well-serviced?”

He settled on writing a new JavaScript framework, finding the existing market leaders lacking. The first stage in this process was the creation of Handlebars.js, an extension to the Mustache templating language that has since taken “a life of its own”.

Katz then planned to begin work on a project called “Momentum.js”, but ended up partnering with SproutCore creator Charles Jolley instead. It was only then that their new framework, originally called SproutCore2 but later renamed Ember, began to take shape. (Development has since shifted to Katz’s consulting company, Tilde).

While designing Ember, Katz says he and “partner in crime” Tom Dale had major two priorities. Both felt “extremely strongly” about using an HTML-based templating system, and so integrated Handlebars – despite controversy among the existing SproutCore community.

“People writing web stuff want to use HTML,” says Katz, defending the decision. “They know HTML and CSS, they have designers, they have other frameworks like Bootstrap and they really want to just be able to use the ecosystem and their existing knowledge.”

Less contentious, but even more important to the pair, was that Ember provided URLs when interacting with a web app. Dale recently claimed that “if your app doesn’t have URLs, you are not a web developer”, and Katz agrees, describing URLs as “the web’s UI” and a key advantage over native apps.

“The reason the web is so viral is because anybody could take what they’re looking at and give it to somebody else,” he argues. “If you break people’s ability to share what they’re looking at effectively, it will stop being as effective.”

As such, URLs are so integral to Ember that “the only way you get new UI onto the screen is by thinking about a new URL, and adding a new route to your router and putting a piece of template on the screen,” says Katz. “The idea is that it’s very hard in Ember to write an application that doesn’t have good URL support, because we’ve basically baked in URLs as the central architectural tenant.”

Long live the server

Perhaps surprisingly, Katz doesn’t believe that all sites would necessarily benefit from being a JavaScript-heavy “long-lived” app, nor that servers will be killed off as a result of frameworks such as Ember.

“Basically I think there’s three types of developers,” he explains. “There’s two on the extreme end. There’s developers who 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.”

Developers in the middle whose apps use “a sprinkle” of JavaScript are “deluding themselves”, claims Katz. “If you look at any of these applications, before long they end up with a monstrous megabyte of JavaScript – of little ‘sprinkles’ here and there. I think in my keynote at RailsConf I said [it ends up as] a megabyte of sprinkles – or a whole cup of sprinkles.”

But when much of your application logic is being handled client-side, won’t the role of the server become increasingly smaller? Katz disagrees, arguing that “every single application that is worth its salt has some interaction with the real world” – be that sending emails or dealing with financial transactions. This, of course, isn’t possible in a sandboxed browser.

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

Extending the web

With Ember, Katz is attempting to shape the next generation of the web from the bottom up. But he’s also recently become active among web standards committees to drive progress from the top down, aiming to introduce a “developer on the ground” perspective which is, he says, “sorely needed”.

Through the jQuery Foundation, he has become a member of TC39, the cross-industry group developing new JavaScript features, and claims to have been the only person actively working on JavaScript web applications at the time of joining.“

More recently, in February he was voted into the W3C’s Technical Architecture Group (TAG), which determines a wide range of web standards and is chaired by Tim Berners-Lee, with the explicit aim of making the two standards bodies work closer together.

“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, basically.”

Ultimately, what Katz says he wants to see is a more organic evolution of the web, driven by practical implementations rather than commitee-driven specs. He calls this “the extensible web”, and uses the notorious AppCache as his case in point.

AppCache was a much-hyped feature of the HTML5 spec designed to allow offline storage and access of web apps. However, few would disagree with Katz’s judgement that AppCache is “broken” for many (if not most) use cases.

“Because [of] the way AppCache is delivered – just as a bit feature, a manifest string – web developers have no way of fixing it. What that means is that AppCache shipped several years ago now, and in that time the only thing that web developers could do was beg, borrow and steal – try to get it fixed – to no avail.”

Katz’s argument is that, had AppCache been a library – easily replaced by developers unhappy with its standard implementation – it would have been possible to fix with a homegrown solution. The most popular of these might go on to influence future standards, providing a much a tighter feedback loop than the current system.

“I think we as web developers need to push for this – for our own ability to fix the mistakes in the platform.”

If this approach sounds familiar, it’s because jQuery set out to fix JavaScript’s problems in a similar way, simplifying the way developers interact with the DOM and send AJAX requests, and providing fixes for fiddly browser bugs. With an “extensible” web, everything becomes a library to an optional, lower-level API.

A fortnight after the interview took place, Katz and a number of influential web developers signed an ‘Extensible Web Manifesto’, urging for an “evolutionary model of standardization, driven by the vast army of web developers”. With creator of JavaScript Brendan Eich and many other TAG and TC39 members on board, it’s possible that Katz may finally get the community-driven standards that he’s being crying out for.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Benachrichtige mich bei
Inline Feedbacks
View all comments
- Gib Deinen Standort ein -
- or -