Comment by amw-zero | Hacker News Reader

Comment by amw-zero | Hacker News Reader

We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application.

Some applications really want to make use of a richer UX, one that doesn't need to re-render the entire page from scratch on every button click. Maybe Gmail is the best example of using the SPA experience to drive a rich UX. The web browser was not meant to build such applications, that's something we don't acknowledge enough. The web browser was designed, since day one, to render and link between text documents. We've been trying to play UX catch-up for 20 years at this point, and it's finally converged with lots of support for treating the web as an application platform as well (React, Angular, etc.)

So we've taken years to arrive at SPA's, but I think they're completely justified. They absolutely have tradeoffs, but they're not pointless tradeoffs. That doesn't mean that all applications should be SPA's, but I also think it's completely wrong to say that all applications should be simple documents too.

> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.

My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.

I'm skeptical of that. Have you timed it in Chrome DevTools? E.g. when I hit 'c' on the keyboard to compose an email, it's effectively instantaneous.

I use a regular mail client on my computers and phone, and don't touch webmail with a ten foot pole. Google did it best, but it's still junk.

That’s ok. You should have the option to use that UX.

I can tell you that any non-programmer on the planet would ever choose that UX over the “app-like” feel. I think we forget that most users are not programmers way too often.

> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.

Gmail is is the perfect example of an app that loses more functionality than it gains by being an SPA. Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free. This is more important functionality to me than saving a page refresh. Same goes for JIRA, middle click at least works but the the 30+ seconds to reload the SPA in it's own tab makes it unusable.

These are both document driven apps and the document viewer I'm using them in have some great features that they cripple.

> Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free

The fact that things like middle click and right click can be overridden in javascript is pretty much one of the biggest failings of modern browsers in my opinion. It's developers giving the middle finger to standards, and browsers accomodating those whims without considering the end user whatsoever. If your grand design doesn't include basic functionality that browsers provide then great, feel free to create a native application that fits that design. Otherwise, please leave the functionality that I rely on every day, and works in 99% of other sites, alone.

Well UX is of course subjective. I don’t agree with you at all. I use Gmail every day and I would call its user interface very successful.

New Twitter also broke the ability to middle-click embedded tweets to open in a new tab.

> We should create a better division in web standards between the "document web" and the "application web."

Why are those the only two options? By those terms do mean "document web" as HTML without any JavaScript and "application web" as HTML with any JavaScript, or something else?

"Why stop at two" is an excellent question, but the first cleave is the heaviest lift.

I think the first seam should be network requests. Unwind AJAX: produce the "content web" and the "interactive web." The content web should be HTML with JavaScript that can respond to events, but cannot fetch new code. This sterilizes the malware aspect of the web: JS can no longer track you (it can in crafty ways but ad blockers are a match for these).

The second seam should be aimed at the other direction: empowering the web. Factor out the "app web." This provides a native-level API which can dispense with the anti-fingerprinting, second-guessing nonsense. But the app web has higher barriers: revocable certs, user reviews, potentially frictive installs.

Eventually a document web might become interactive. For example you start with something basic, now you want to show some animations. For example in geometry visualization.

Sometimes you just need something dynamic. I need it in 99pc of my websites. Why would I start with plain js, and then move to react. Plus I already have a base in react that can be shared with all websites. Much easier to maintain all in react than a mix

Your conclusion is hard to disagree with. I don't think anyone's saying all apps should be SPA's or no apps should be SPA's

I think what a lot of us are saying here is that SPA's in general are overused in our industry when simpler solutions are more appropriate. And that's having a negative effect on productivity and developer happiness.

Reply on news.ycombinator.com