Radical Statements about the Mobile Web
I drafted a long post about the mobile web, but then Flipboard released their new mobile site with a detailed explanation of why they used canvas instead of the DOM to layout content. Subsequent blog posts ensued in response.
Since the topic of 60 FPS mobile apps has already been discussed greatly, my original post isn't relevant anymore (and I don't have time to polish it up). However, I would still like to point out some important issues.
A quick note (I added this after publishing): I have to give huge props to the recently formed Houdini project which is involving all parties of the web to figure out how to make css/layout/rendering extensible. They are talking about all of these problems in depth (see the wiki) and smarter people than me might be able to really solve this.
This was triggered by playing with React Native, but it stems from years of trying to make the web work well on mobile. These statements are intentionally bold to stir discussion. Some of my assertions may be wrong, but I believe there's at least some truth in most of them.
I'm going to try a new point-based format. The interesting thing about it that is it helps make my argument very clear, since all the colorful articulation (which I don't have time to do) is removed. The downside is that it's quite dense, and might be easy to misinterpret. Here we go:
- I work for Mozilla, and I want the web to win. However, this is a thought experiment and I'm going to try to take the role of an unbiased observer. Some of the statements are undoubtedly controversial. None of them reflect my employer — these are just my own thoughts.
- The web isn't close to competing with higher-end native apps. You may think the UX is getting close, but there's always more jank. Let's not even talk technical; even if it is getting close, when companies want to develop a beautiful, ground-breaking app, they choose native. I've talked to enough developers to see that we aren't close to changing this yet.
- Users don't care about the web. You may argue that the web brings all sorts of benefits over native apps, that they have URLs, are accessible, and you can zoom them. Sadly, most users don't care. By now it should be clear that too many users would choose a native app over a web app.
- We need to accept this. The longer we downplay the importance of performance of native app animations, the longer we fail. Animations that smoothly respond to gestures are not progressive enhancement on mobile, they are how users interact. Maybe not on very low-end devices, but I think it's wrong to bet the web on the low-end.
- The DOM is slow. I don't think you can argue against that. The only question is if it will get faster, which is what everyone seems to assume. "At some point, the DOM will be fast enough and the mobile web will start winning," they say. It's based on nothing. There's no indication the DOM will ever be fast enough, and if it does happen it's lightyears away on mobile. I've seen no technical description of a truly plausible way to make it significantly faster. This is like trying to optimize your rendering loop to render a model with a million polygons, when what you really need to do is reduce the number of polygons in your model.
which if the first thing I'd do if we really want to try to make the DOM work. (edit: this statement was too bold. Recently those involved with standards have been looking at other solutions which may actually work out much better.) We need to guarantee that the JS event loop will run at 60 FPS which is impossible right now.
- Maybe the DOM is not the answer. The web is not the DOM. If the DOM doesn't work out, we should look for other solutions. At this point, any advanced app has to work against the DOM (see the whole React movement, which Ember is now copying, and others). The industry is crying out for something faster and more controllable than the DOM. Don't be religious about this.
- Lower-level APIs are going to be exposed. Work has already started on controlling the layout and measurement systems of browsers, see here. This might finally allow us to start experimenting with custom DOM-like solutions. I believe this is the direction we should be going. The Box Tree API is especially of interest.
- Accessibility is important. Once we start circumventing the DOM, we need to think about how to make our content accessible. Nothing shows that this is impossible, and it's obviously important for the web, so don't freak out. This might be way simpler than you think.
Prediction #1: In the next few years, we see a significant amount of effort to run web apps in web workers. Asynchronous APIs are created to interact with anything that runs on the main thread, like layout, storage, etc. reapp.io is doing a lot of interesting research in this vein.
Prediction #2: React Native becomes so popular that a significant portion of web developers use it to write web/native apps. Attempts to mitigate the DOM by running apps in web workers fails to provide the experience of React Native because the DOM is still the bottleneck. By 2018, we see a big push for a collection of lower-level asynchronous APIs to do layout, rendering, and construct accessibility databases instead of using the DOM. Accessibility APIs allow the developer to apply roles to various parts of the layout.