With the rise of all these APIs and the browser race to implement them, you’d think that currently we can do pretty much everything in JavaScript and even if we currently can’t due to browser support issues, we will once the specs are implemented. Unfortunately, that’s not true. There are still things we can’t do, and there’s no specification to address them at the time of this writing and no way to do them with the APIs we already have (or if there is a way, it’s unreasonably complicated).

We can’t do templating across pages

Before rushing to tell me “no, we can”, keep reading. I mean have different files and re-use them accross different pages. For example, a header and a footer. If our project is entirely client-side, we have to repeat them manually on every page. Of course, we can always use (i)frames, but that solution is worse than the problem it solves. There should be a simple way to inject HTML from another file, like server-side includes, but client-side. without using JavaScript at all, this is a task that belongs to HTML (with JS we can always use XHR to do it but…). The browser would then be able to cache these static parts, with significant speed improvements on subsequent page loads.

Update: The Web Components family of specs sort of helps with this, but still requires a lot of DIY and Mozilla is against HTML imports and will not implement them, which is one main component of this.

We can’t do localization

At least not in a sane, standard way. Client-side localization is a big PITA. There should be an API for this. That would have the added advantage that browsers could pick it up and offer a UI for it. I can’t count the number of times I’ve thought a website didn’t have an English version just because their UI was so bad I couldn’t find the switcher. Google Chrome often detects a website language and offers to translate it, if such an API existed we could offer properly translated versions of the website in a manner detectable by the browser.

Update: We have the ECMAScript Globalization API, although it looks far from ideal at the moment.

We can’t do screen capture

And not just of the screen, but we can’t even capture an element on the page and draw it on a canvas unless we use huge libraries that basically try to emulate a browser or SVG foreignObject which has its own share of issues. We should have a Screen Capture API, or at the very least, a way to draw DOM nodes on canvas. Yes, there are privacy concerns that need to be taken care of, but this is so tremendously useful that it’s worth the time needed to go intro researching those.

We can’t get POST parameters and HTTP headers

There’s absolutely NO way to get the POST parameters or the HTTP response headers that the current page was sent with. You can get the GET parameters through the location object, but no way to get POST parameters. This makes it very hard to make client-side applications that accept input from 3rd party websites when that input is too long to be on the URL (as is the case of dabblet for example).

We can’t make peer to peer connections

There is absolutely no way to connect to another client running our web app (to play a game for example), without an intermediate server.

Update: There’s RTCPeerConnection in WebRTC, though the API is pretty horrible.

_________

Anything else we still can’t do and we still don’t have an API to do so in the future? Say it in the comments!

Or, if I’m mistaken about one of the above and there is actually an active spec to address it, please point me to it!

Why would you want to do these things client-side?!

Everything that helps take load away from the server is good. The client is always one machine, everything on the server may end up running thousands of times per second if the web app succeeds, making the app slow and/or costly to run. I strongly believe in lean servers. Servers should only do things that architecturally need a server (e.g. centralized data storage), everything else is the client’s job. Almost everything that we use native apps for, should (and eventually will) be doable by JavaScript.

Not sure if you noticed, but Dabblet now has a blog: blog.dabblet.com

I’ll post there about Dabblet updates and not flood my regular subscribers here who may not care. So, if you are interested on Dabblet’s progress, follow that blog or @dabblet on twitter.

That was also an excuse to finally try tumblr. So far, so good. I love how it gives you custom domains and full theme control for free (hosted Wordpress charges for those). Gorgeous, GORGEOUS interface too. Most of the themes have markup from the 2005-2007 era, but that was no surprise. I customized the theme I picked to make it more HTML5-ey and more on par with dabblet’s style and it was super easy (though my attempt is by no means finished). There are a few shortcomings (like no titles for picture posts), but nothing too bad.

Not sure if you noticed, but Dabblet now has a blog: blog.dabblet.com

I’ll post there about Dabblet updates and not flood my regular subscribers here who may not care. So, if you are interested on Dabblet’s progress, follow that blog or @dabblet on twitter.

That was also an excuse to finally try tumblr. So far, so good. I love how it gives you custom domains and full theme control for free (hosted Wordpress charges for those). Gorgeous, GORGEOUS interface too. Most of the themes have markup from the 2005-2007 era, but that was no surprise. I customized the theme I picked to make it more HTML5-ey and more on par with dabblet’s style and it was super easy (though my attempt is by no means finished). There are a few shortcomings (like no titles for picture posts), but nothing too bad.

Yesterday, I released dabblet. One of its aspects that I took extra care of, is it’s keyboard navigation. I used many of the commonly established application shortcuts to navigate and perform actions in it. Some of these naturally collided with the native browser shortcuts and I got a few bug reports about that. Actually, overriding the browser shortcuts was by design, and I’ll explain my point of view below.

Native apps use these shortcuts all the time. For example, I press Cmd+1,2,3 etc in Espresso to navigate through files in my project. People press F1 for help. And so on. These shortcuts are so ingrained in our (power users) minds and so useful that we thoroughly miss them when they’re not there. Every time I press Cmd+1 in an OSX app and I don’t go to the first tab, I’m distraught. However, in web apps, these shortcuts are taken by the browser. We either have to use different shortcuts or accept overriding the browser’s defaults.

Using different shortcuts seems to be considered best practice, but how useful are these shortcuts anyway? They have to be individually learned for every web app, and that’s hardly about memorizing the “keyboard shortcuts” list. Our muscles learn much more slowly than our minds. To be able to use these shortcuts as mindlessly as we use the regular application shortcuts, we need to spend a long time using the web app and those shortcuts. If we ever do get used to them that much, we’ll have trouble with the other shortcuts that most apps use, as our muscles will try to use the new ones.

Using the de facto standard keyboard shortcuts carries no such issues. They take advantage of muscle memory from day one. If we advocate that web is the new native, it means our web apps should be entitled to everything native apps are. If native editors can use Cmd+1 to go to the first tab and F1 for help, so should a web editor. When you’re running a web app, the browser environment is merely a host, like your OS. The focus is the web app. When you’re working in a web app and you press a keyboard shortcut, chances are you’re looking to interact with that app, not with the browser Chrome.

For example, I’m currently writing in Wordpress’ editor. When I press Cmd+S, I expect my draft to be saved, not the browser to attempt to save the current HTML page. Would it make sense if they wanted to be polite and chose a different shortcut, like Alt+S? I would have to learn the Save shortcut all over again and I’d forever confuse the two.

Of course, it depends on how you define a web app. If we’re talking about a magazine website for example, you’re using the browser as a kind of reader. The app you’re using is still the browser, and overriding its keyboard shortcuts is bad. It’s a sometimes fine distinction, and many disagreements about this issue are basically disagreements about what constitutes a web app and how much of an application web apps are.

So, what are your thoughts? Play it safe and be polite to the host or take advantage of muscle memory?

Edit: Johnathan Snook posted these thoughts in the comments, and I thought his suggested approach is pure genius and every web UX person should read it:

On Yahoo! Mail, we have this same problem. It’s an application with many of the same affordances of a desktop application. As a result, we want to have the same usability of a desktop application—including with keyboard shortcuts. In some cases, like Cmd-P for printing, we’ll override the browser default because the browser will not have the correct output.

For something like tab selection/editing, we don’t override the defaults and instead, create alternate shortcuts for doing so.

One thing I suggest you could try is to behave somewhat like overflow areas in a web page. When you scroll with a scroll mouse or trackpad in the area, the browser will scroll that area until it reaches it’s scroll limit and then will switch to scrolling the entire page. It would be interesting to experiment with this same approach with other in-page mechanisms. For example, with tabs, I often use Cmd-Shift-[ and Cmd-Shift-] to change tabs (versus Cmd-1/2/3, etc). You could have it do so within the page until it hits its limit (first tab/last tab) and then after that, let the event fall back to the browser. For Cmd-1, have it select the first tab. If the user is already on the first tab, have it fall back to the browser.

Yesterday, I released dabblet. One of its aspects that I took extra care of, is it’s keyboard navigation. I used many of the commonly established application shortcuts to navigate and perform actions in it. Some of these naturally collided with the native browser shortcuts and I got a few bug reports about that. Actually, overriding the browser shortcuts was by design, and I’ll explain my point of view below.

Native apps use these shortcuts all the time. For example, I press Cmd+1,2,3 etc in Espresso to navigate through files in my project. People press F1 for help. And so on. These shortcuts are so ingrained in our (power users) minds and so useful that we thoroughly miss them when they’re not there. Every time I press Cmd+1 in an OSX app and I don’t go to the first tab, I’m distraught. However, in web apps, these shortcuts are taken by the browser. We either have to use different shortcuts or accept overriding the browser’s defaults.

Using different shortcuts seems to be considered best practice, but how useful are these shortcuts anyway? They have to be individually learned for every web app, and that’s hardly about memorizing the “keyboard shortcuts” list. Our muscles learn much more slowly than our minds. To be able to use these shortcuts as mindlessly as we use the regular application shortcuts, we need to spend a long time using the web app and those shortcuts. If we ever do get used to them that much, we’ll have trouble with the other shortcuts that most apps use, as our muscles will try to use the new ones.

Using the de facto standard keyboard shortcuts carries no such issues. They take advantage of muscle memory from day one. If we advocate that web is the new native, it means our web apps should be entitled to everything native apps are. If native editors can use Cmd+1 to go to the first tab and F1 for help, so should a web editor. When you’re running a web app, the browser environment is merely a host, like your OS. The focus is the web app. When you’re working in a web app and you press a keyboard shortcut, chances are you’re looking to interact with that app, not with the browser Chrome.

For example, I’m currently writing in Wordpress’ editor. When I press Cmd+S, I expect my draft to be saved, not the browser to attempt to save the current HTML page. Would it make sense if they wanted to be polite and chose a different shortcut, like Alt+S? I would have to learn the Save shortcut all over again and I’d forever confuse the two.

Of course, it depends on how you define a web app. If we’re talking about a magazine website for example, you’re using the browser as a kind of reader. The app you’re using is still the browser, and overriding its keyboard shortcuts is bad. It’s a sometimes fine distinction, and many disagreements about this issue are basically disagreements about what constitutes a web app and how much of an application web apps are.

So, what are your thoughts? Play it safe and be polite to the host or take advantage of muscle memory?

Edit: Johnathan Snook posted these thoughts in the comments, and I thought his suggested approach is pure genius and every web UX person should read it:

On Yahoo! Mail, we have this same problem. It’s an application with many of the same affordances of a desktop application. As a result, we want to have the same usability of a desktop application—including with keyboard shortcuts. In some cases, like Cmd-P for printing, we’ll override the browser default because the browser will not have the correct output.

For something like tab selection/editing, we don’t override the defaults and instead, create alternate shortcuts for doing so.

One thing I suggest you could try is to behave somewhat like overflow areas in a web page. When you scroll with a scroll mouse or trackpad in the area, the browser will scroll that area until it reaches it’s scroll limit and then will switch to scrolling the entire page. It would be interesting to experiment with this same approach with other in-page mechanisms. For example, with tabs, I often use Cmd-Shift-[ and Cmd-Shift-] to change tabs (versus Cmd-1/2/3, etc). You could have it do so within the page until it hits its limit (first tab/last tab) and then after that, let the event fall back to the browser. For Cmd-1, have it select the first tab. If the user is already on the first tab, have it fall back to the browser.