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
I don’t mean have an HTML structure and repeat it with different data like many libraries do. 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…).
Eli Grey suggested <iframe seamless> but this doesn’t really help: It’s just an iframe with seamless borders and such. An iframe is NOT what I’m saying and multiple iframes are a performance nightmare. I’m talking about *injecting* HTML from another file and end up with one document, the same way server-side templating works.
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.
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 and I’ll add it to the list!
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!
Source : http://lea.verou.me/2012/01/what-we-still-can%E2%80%99t-do-client-side/
