Two Faces of Web Apps
There are many fantastic webpages use the single-page architecture, such as Macaw Scarlet, YAY, and the Sounds of Mumbai project.. Sounds of Mumbai really blurs the line between site and app with it’s engaging media content.
The real difference between a webpage and a web app is its complexity. A web app includes additional workflows, CRUD operations, and state management around tasks. Web apps have a rather strange dichotomy. As Mikito Takada puts it,,
“Single page applications have a schizophrenic relationship with URLs. On the one hand, single page apps exist so that the users can have richer interactions with the application. Richer activities mean that there is more view state than can reasonably fit inside a URL. On the other hand, we’d also like to be able to bookmark a URL and jump back to the same activity.”
The Web is becoming more powerful
There’s a prevalent opinion that native is for interaction and the web is just for documents. However, the web can excel at just-in-time notifications as well. Server-side javascript via Node and WebSockets combine to make communication on the web seamless and powerful. Socket.io even has a P2P client that allows a bidirectional events channel between two peers with a server fallback to provide maximum reliability. I shouldn’t be required to installed a specific app to read a news article; now, I don’t even have to install an app for IMing either. New browser features currently in development, such as push notifications via Service Workers, will help make engagement with websites more seamless.
Some Perspective on JS Support
Creating a single-page web application using JavaScript is still relatively controversial.JavaScript support across browsers is not yet homogenous, with some browsers handling JS drastically from others (I’m looking at you IE). JavaScript is frequently criticized for its inability to degrade gracefully. Ross Penman wrote an article on AListApart criticizing JavaScript for its fragility. He cites a report from the UK’s gov site that “out of every 500 visitors to GOV.UK, five did not receive JavaScript.”
Although this number can be troubling with a large traffic site, we have to put this 1% failure to load JS into perspective by looking at another fringe case - legacy IE support. It’s generally accepted that support for older versions of IE best left off the table as it dramatically increases the amount of time and effort needed to ship.
Many big players are dropping support for older IE as well. Google Analytics no longer supports ay IE less than IE9. SalesForce is dropping IE 7/8 support the summer of 2015. It’s worth noting IE9 has a 3% usage in the US. Combined IE6/7/8 is still has roughly 4% usage. [Sitepoint] However, we are not clamoring for wider IE support or lampooning companies that reject IE support.
As a community, we share contempt with legacy browsers and celebrate tales denouncing IE.
Avoid broad strokes
The best advice for development, whether it is JS or IE, is “it depends on your audience.” Solutions should be tailored to specific cases. That’s why UX design is so tricky- you have to learn a broad range of disciplines in order to understand the why behind a problem. It is not enough to look at the technology alone; we have to examine how the solution will be used by the intended audience.
Reliance on JavaScript is not going to be an unsurmountable obstacle for most users. If your particular audience does not have JS support, then it might be best find another way. But again, it’s not an absolute. There is no percentage that will work for all web apps; just like there isn’t one design that will work in all situations. We should take the same wisdom when approaching web applications and JS frameworks: Make sure it works for your audience.
Let’s not subjugate JS as a tool only to enhance websites in all situations when it could be used for so much more.