Principal Evangelist at Mozilla Christian Heilmann has written a feature outlining problems with local storage for websites. Within, he says web developers often encounter things that seem too good to be true, and that we only find out after a while that we’re “doing it wrong”.
He argues localStorage is one such case; while it’s well-supported and simple, it offers poor performance. The problem: alternatives are either more complex or poorly supported.
We asked Heilmann (CH) about localStorage and how its problems might affect the future of web app development. We also quizzed him on whether differences in browser implementation point to further fragmentation and if that's a concern.
.net: Why do you think localStorage got so much traction if it's so poor? Simplicity? Support?
CH: Both. It's dead simple and it works across browsers. Almost every HTML5 tutorial covered it in the past. We want cookies to die and this was a great option.
.net: Does the continued use of localStorage threaten a shift to web apps, in terms of them appearing to be second-class citizens from a performance standpoint?
CH: Most likely not. The main argument is localStorage is bad for performance, but mainly when used excessively and on pages/apps that don't get visited often. Real web application development always favoured a database solution instead of having a simple key/value store. The main performance hits are actually visible on the desktop and less so on mobile devices.
.net: Do you think users notice such performance hits?
CH: Yes. If an app locks up for a few seconds, it is hard to not show it. To a degree, the switch to IndexedDB would be a good thing. Whilst it is handy to store content for the user locally, it can also be creepy if you don't tell them about it. Almost all other APIs ask the user to say yes to them – for example, geolocation and fullscreen – and so this shouldn't be any different. A lot of tracking of users happens as we're not asked if it's okay to store content. Tracking should be more transparent.
.net: You say in your article that the localStorage situation is reminiscent of the HTML5 video debate …
CH: It's comparable in terms of annoyance to the implementer but it's not the same. The video debate is about codecs and intellectual property. Using MP4 doesn't mean it will be free for you to do so in the long run. WebM/OGG does.
.net: But in terms of the fragmentation aspect – is this inevitable at the cutting-edge of web standards and technologies?
CH: Fragmentation will always happen and it has gotten worse lately as some browsers are pushing to run operating systems on them (IE with Windows 8 and Chrome with Chromebooks). Browsers are more than an app running in the operating system to show web content – they are advancing to be the main OS interface layer (boot to gecko is a great example).
This means it can take too long for some to agree on a standard and get it implemented across the board, which is why experimental implementations get thrown out as spec proposals. And without waiting for feedback or helping others to implement, the marketing machine advertises them as the ‘new cool in browser X’ that others need to keep up with.
.net: How can such fragmentation be fought and dealt with?
CH: With Mozilla, the main arguments are security, privacy and openness. If something new and cool comes out that's just the work of one company and is hard to implement in other browsers, or is connected with APIs and content that are not open, we are not happy to support it.
A lot of what we have right now is not ready and needs agreement amongst browser makers, but we need people to try the things out to see how they break.
.net: And how can developers help with this?
CH: We need to stop being fanboys using technologies because they work in the browser we like the most and claiming others are behind because they do not support their features. Past success is not a guarantee for innovation.
Chrome, for example, had it much easier than any other browser out there – they were the second implementer and could learn from the mistakes of others. Now, it’s easy to predict this browser will come up with failures that need discussion and iteration rather than blind followers. Fragmentation is good, it allows for a few approaches and to see which works best. We just need to find the time to come to a consensus.
This can be frustrating for developers, but if you're honest with yourself, web development has always been a moving target and you've always had to keep up with what is going on!
