We’re witnessing the exponential rise of a neglected little broken language. A language that obviously started with something very right and grew up even better.

A language that is finally gonna get A LOT of love.

P.S. Here are my talks:

But despite these wins, and numerous loyal fans, Wave has not seen the user adoption we would have liked. We don’t plan to continue developing Wave as a standalone product, but we will maintain the site at least through the end of the year and extend the technology for use in other Google projects.

That’s a great example of why “do one thing well” is better than “do it all”. Not only because, as Gall’s law implies, it’s easier to get a simple system straight, but also because once you get a complex system straight, you still have to make people get their mind around it. Wave made chat and e-mail play well together, with a great replay feature, bots and translation. Twitter gives short text updates. Adoption declared the winner, but we already knew it.

Here it is.

update: now i am linking to the extended version which i gave at phpday 2010

Having recently read RESTful Web Services, i wanted to write about the most interesting of my REST-induced epiphanies:

Form based authentication with its login/session/logout workflow, which is currently dominant on the web, is hopelessly broken.

To understand why, one has to grasp how the greatest living RESTful implementation, the web and its backbone protocol HTTP, was meant to work. In a nutshell, there’s a server that keeps the state of the web application, split into meaningful resources. Each resource has its own name (URI) and a set of available representations of itself. That’s all the server knows. Then there’s a client that acts as a finite state machine visiting resources, getting representations and then moving to other resources through links and forms. The state of the conversation, the session, where a client has been and where it is now, is something that belongs to the client. Server drives the client by feeding him a graph made of states and links to other states, but it’s the client who is in charge of following a path. That’s statelessness, the simplifying property that made the web triumph as a darwinian winner.

In this view, authentication should have been largely a client-side business.
The client visits resources anonymously. If it wants to be authenticated, it just starts sending authentication data with each further request. If it wants to be anonymous again, it just stops. It could as well send a mix of authenticated and anonymous requests.
The server doesn’t care of what happens between requests. If a single request carries authentication data, it checks the data and possibly replies as if the client were authenticated. If a request has no authentication data, a generic response is returned. There’s no server-side login through a form, there’s no server-side logout, and above all, there’s no temporal ordering between those two and hence no server tracked session. All of a sudden, the beauty of this comes with great force. By delegating authentication to the browser using the standard HTTP mechanism we can greatly simplify application code.

Unfortunately, in reality this is not the case. During its race to the top, HTTP lost part of its original vision, mainly due to implementation mistakes.

1. The specs failed to hit the sweet spot of authentication security. They standardized Basic Authentication which, by sending user and password in plain text, scared people to death and Digest which, due to its complexity and required server cooperation, never really caught on. A client-side mechanism with cheap yet reasonable security such as WSSE UsernameToken, later adopted by atom, would have been optimal.
2. Browsers took away login from client’s hands by showing the popup dialog to input user/password only after a 401 http error code from server. There should have been an always visible “login” button since the specs said “A user agent that wishes to authenticate itself with an origin server–usually, but not necessarily, after receiving a 401…”.
3. Browsers practically took away logout from client’s hands by requiring to close the browser in order to clean the passwords cache. There should have been an always visible “logout” button.
4. Browsers gave no chance to customize the ugly and annoyingly modal login dialog. HTML and/or CSS could have been used.
5. Browsers gave no client-side storage needed to keep session data but again turned back to server with cookies. They should have given something like upcoming HTML5 localStorage and sessionStorage.

Now there’s not much that can be done short of a collaborative effort by all browser vendors. Meanwhile we can keep dealing with authentication in application code on the server, in a never ending pile of custom solutions, each one slightly different, for yet another pretty standard problem. A problem solved 15 years ago.

• Avoid for-in and forEach in favor of optimized while loops
• Before making modifications to a DOM node remove it and then re-insert it
• To insert multiple DOM nodes, first insert them into a Document Fragment and then add it to the DOM
• Join all scripts into a single file
• Load javascript files on demand

Let’s make it clear for once, execution speed is not a human problem, that’s what computers are for, they execute our commands fast. The human problem is programming speed and writing down clear, readable, maintainable commands aka programs. forEach loops make sense to me, they say “i want to do something on each item”, optimized while loops make sense to computers. If i want to add DOM nodes or modify one, i don’t care of removing it or document fragments, browsers care. To me it’s just noise. Almost all of the problems addressed by those techniques stem from lack of smartness in the browser, and that’s where fixes belong to, on the machine side. The fact that there are inept browser makers is no excuse. Fixes still belong to the machine, they’re repeatable and can be made automatic. We have a long history of programs automatically converting human friendly code to machine friendly code. They’re called compilers and the output either machine code or optimized javascript doesn’t matter.

So, learn about javascript performance since knowledge is always the way, but don’t turn yourself into a machine, you’d be an awful one. Use the tools and wait for browsers to catch up.

• Aptimize
• Closure Compiler
• YUI 3 use