6 ms·

Why I hate your classic HTML app: - Every click is a full page load, and you still didn't manage to get caching right, so it takes 2 seconds to load. - When I

Why I hate your classic HTML app: - Every click is a full page load, and you still didn't manage to get caching right, so it takes 2 seconds to load. - When I have multiple tabs open, your badges and notifications fall out of date, because you never poll for updates. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. - You forgot to update the styles on that rarely-used page, and now it's got half the new CSS and half the old CSS and the point is the header runs halfway down the goddamn content in Times New Roman. I get it, there are problems with SPAs. But this perfect land of one-page-per-link has real usability problems if it's not implemented properly, and there's a lot of maintenance overhead associated with a sprawling mass of transcluded templates. If we're going to criticize an architecture because it's easy to poorly implement, I don't think "ROCA" or whatever we're calling it has any meaningful benefits over SPAs in the general case.

lscharen 9y ago
"If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it." This. I have a very short list of architectural must-haves that I use when evaluating junior dev's code at the start of a project, and not having robust error handling that preserves submitted form information is right up near the top. It's an annoying design mistake with two input elements, unworkable with five, and just plain cruel beyond that.
- ruleabidinguser 9y ago
  You're not evaluating them based on requirements you didn't share, are you? That seems a little unfair
  - Xoros 9y ago
    Is'nt that the point of an evaluation ? "Hey, here is your test and here are the answers. You've got one hour" :)
    - deleted 9y ago
      [deleted]
    - ruleabidinguser 9y ago
      Not really no
  - lscharen 9y ago
    Not evaluating them; evaluating code. Just handing someone an expanded version of "implement good error handling" is not likely to result in a good product. Every project has nuance and subtle trade-offs -- the code review is an opportunity to teach juniors how to map abstract design principles onto concrete implementations without falling back to "cookbook / cargo cult" programming. I want them to take ownership of their own code, and advance down the path of craftsmanship because I believe this results in long-term value -- both to them personally and to the project at hand.
darkstar999 9y ago
Most of your criticisms are solved with basic javascript, not necessarily single page applications. > You forgot to update the styles on that rarely-used page That's solved with proper css, not SPA.
- jfaat 9y ago
  Also a sane build/deployment process will solve this.
- trjordan 9y ago
  You're right! If we just implemented everything correctly, there wouldn't be problems! Anecdotally, every team I've worked with has converted to a SPA, and the main ergonomic upgrade is that updates to the signup page or the "not found" widget quit getting forgotten whenever we change tweak our design. There always seems to be one page that's out-of-date for 2 months before anybody notices, then it quietly gets fixed up because we forgot that the design tweak was a CSS+HTML change, not pure CSS. Not that that's perfect -- once you have a SPA, nobody remembers the 404 page, because it's a different HTML base...
Pigo 9y ago
I only scanned towards the end, but I was waiting to here what his proper architectural would be. I don't like complaining unless you have alternative you're ready to support.
- mikestew 9y ago
  From TFA: "What is this alternative, then? It is to build a classic web application, including rendering server-side HTML, and use JavaScript only sparingly, to enhance browser functionality where possible."
amelius 9y ago
> When I have multiple tabs open, your badges and notifications fall out of date, because you never poll for updates. How bad is that really if users are aware of it and they can simply reload the page?
- williamdclt 9y ago
  Not very bad for Hackernews. Terrible for Facebook, Twitter or any website that claims to be interactive
  - amelius 9y ago
    Personally, I'm not eagerly waiting for updates on Facebook all the time. They might as well appear after a reload. Of course, chat/messenger is something else, but I consider that an exception. (It's easy to build a chat service on top of a static website).
ojosilva 9y ago
Exactly. - The author is describing hypertext, which is perfectly fine for textual static content, one of the key goals for which the World Wide Web was conceived. - Server-side generation of HTML seems totally out of place for other use cases: HTML/JS are now the assembly languages of the web and they belong in the browser. Besides a more distributed architecture is just perfect: server and client focus on what they do best. - Fixing web-apps with broken history buttons and unlinkable urls is important, but to be honest there are fewer and fewer SPAs that are mono-url these days. And it's perfectly fine to have a unlinkable "Delete this Invoice" app button. If it's not real content it should not be a link.
smhenderson 9y ago
- If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. Even when I was coding web pages in Perl in the 90's I wouldn't do that to a user, that's just mean. You don't need a SPA to provide proper error handling that also rebuilds previous state.
- sireat 9y ago
  Sadly there is a major e-commerce provider in my niche which does exactly that - routinely forgets all my information. In fact sometimes their web form just forgets things for no reason. There is no competitor in sight because of the huge huge SEO juice they have built over 15 years.
  - smhenderson 9y ago
    Oh, I know, I have a few examples as well, mostly regarding paying bills. Hate those sites but what can I do? I guess I could go back to mailing a check :-) But it's not THAT inconvenient!
mnarayan01 9y ago
> If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.
tjoff 9y ago
You probably have never tried a classic HTML "app": 1. Every click is fetched and rendered faster than your javascript code has had a chance to execute, let alone fetch or render. 2. True, minor headache though compared to the vast improvements in usability. 3. Nope. 4. Nope, this is a bug - something javascript pages most certainly are not immune against.
- philosopherlawr 9y ago
  You're basing a lot of this viewpoint on fast internet connections. Javascript code rendering will be faster if you have a slow internet connection and are using an updated browser with a fast javascript engine
  - tjoff 9y ago
    In theory you have a point. In practice though the initial loading of the first page is so slow that it completely negates the benefits entirely. It also doesn't work well when opening lots of tabs (which is a popular technique that helps immensely when browsing on a slow connection as pages are loaded in the background). And if you have a really slow or spotty connection the javascript page would barely load at all.
    - philosopherlawr 9y ago
      I think you're basing this off of old technology. With webpack 2 and HTTP/2, this is less of an issue. But, the top comment's statement I think is the most valid: if you're loading static text, then simple html pages are the best. Notice the rise in popularity of static site generators for this purpose. A SPA will win out when you have lots of interactions and you only experience the initial loading of the first page once - and then the majority of your user experience is around interacting with the app.
  - e12e 9y ago
    Eh, I've yet to experience an spa that feels or is faster than the equivalent simple html, no matter what network I'm on - with the exception of being off-line (and I've seen few enough spas that actually work better offline than static pages, ie not broken navigation/functionality). Note that I've of course seen countless slow, bloated static pages - but that's pretty much never because of the tech stack - but because of bloated css, silly large images, and often horrible convoluted html. Hn is of course a typical example of a web page that on paper would be great as an spa, but works fine as a static page with minor js (broken up/down links notwithstanding..). D-lang forums is another : https://forum.dlang.org/ https://forum.dlang.org/ Assuming a 64 kbps connection, and a 50%+ gzip compression, downloading a couple of pages of text is done in about half a second. If the user has such a terrible connection, they've hopefully turned off image loading. I don't think adding 40-400 kbs of gzipped js is going to help with the speed... https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d
cpburns2009 9y ago
Since we're talking about poorly implemented features. Why I hate your SPA: - If I click on a link, I receive no indication that I actually clicked a link, then 2-10 seconds later the page abruptly loads. Sometimes the page doesn't load at all. - I cannot tap and hold a link, wait a second for the pop-up menu, and open the link in a new tab because the link isn't actually a link. It's implemented in JavaScript. - The back and forward buttons don't work as expected because either history isn't maintained or it's shoddy (scrolling should not be a history event). - The refresh page button don't work as expected because it resets you to the beginning.
- aaron-lebo 9y ago
  Just to be clear, that is a poorly designed SPA, none of that should be happening and is easy to avoid.
  - cpburns2009 9y ago
    That is absolutely true, but I've seen it enough times to be annoyed. Also, the grand parent post was about classic HTML apps which were poorly designed with issues that should be easily avoidable.
  - tarboreus 9y ago
    A normal web page doesn't have to be well-designed in these ways, though. And SPAs often are not designed in this way. The author addresses this pretty well in the first paragraph.
- imglorp 9y ago
  I think the prime directive of all UI should be, "Ack UI inputs immediately, no matter what else is going on." Throw up a spinner, make something throb, change a status to "loading", anything. Don't just go off and attempt to do it and hope for timely response.
  - chiefalchemist 9y ago
    Why can't the browser do this? I mean, it's a universal function / feature, right? And ultimately, it's the browsers that's waiting, not to application per se. (Yeah, I okay. But you know what I mean). I can't think of any good reason why the browsers can't help out with this UI / UX. Am I crazy?
yellowapple 9y ago
"[each click] takes 2 seconds to load" In about 95% of the SPAs I've tried, each click takes even longer than that. "you never poll for updates" Yes, because apparently AJAX/AJAJ is completely nonexistent and there's absolutely zero ground between "pure-HTML like it's 1991" and "VueWangulaReact.js single-page monstrosity". Hell, even a meta-refresh will fix that if you really do want "pure-HTML like it's 1991", though that's certainly inelegant.
romaniv 9y ago
. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. This was fixed in browsers years ago when they started keeping form state along with page history. I can refresh this page, go back and forth in history, and this text box will keep my comment. Ironically, websites that tried to be clever about form state management and faked page transfers (like ASP.NET WebForms) didn't benefit from the fixes and currently are significantly worse off in terms of usability than websites that used vanilla forms. I think there is a lesson here.
romaniv 9y ago
. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. Funny that you mention it. Loosing form data on page refresh or clicking "back" button was a problem on the Web until browsers started keeping form state along with page history. Suddenly millions of websites got this new feature without actually doing anything differently. But that was only possible because page transfers were semantic. Frameworks of that time that tried to manage their own form state (like ASP.NET WebForms) didn't have real page transfers, so they didn't get this "upgrade" and currently are significantly worse off in terms of usability. I think there is a lesson here.
s17n 9y ago
The last bullet is just a straight up error on the part of the developer. The third... isn't real? What browser doesn't save form state? The first two are fair criticism but they aren't nearly as detrimental to the user experience as the typical single page app antipatterns (no history, no indication of page loading, refresh button is broken, etc). While it is of course possible to execute any design well or poorly, the observation that a typical single page app is worse than a typical multipage app is certainly valid.
deleted 9y ago
[deleted]

lscharen 9y ago

"If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it." This. I have a very short list of architectural must-haves that I use when evaluating junior dev's code at the start of a project, and not having robust error handling that preserves submitted form information is right up near the top. It's an annoying design mistake with two input elements, unworkable with five, and just plain cruel beyond that.

ruleabidinguser 9y ago
You're not evaluating them based on requirements you didn't share, are you? That seems a little unfair
- Xoros 9y ago
  Is'nt that the point of an evaluation ? "Hey, here is your test and here are the answers. You've got one hour" :)
  - deleted 9y ago
    [deleted]
  - ruleabidinguser 9y ago
    Not really no
- lscharen 9y ago
  Not evaluating them; evaluating code. Just handing someone an expanded version of "implement good error handling" is not likely to result in a good product. Every project has nuance and subtle trade-offs -- the code review is an opportunity to teach juniors how to map abstract design principles onto concrete implementations without falling back to "cookbook / cargo cult" programming. I want them to take ownership of their own code, and advance down the path of craftsmanship because I believe this results in long-term value -- both to them personally and to the project at hand.

darkstar999 9y ago

Most of your criticisms are solved with basic javascript, not necessarily single page applications. > You forgot to update the styles on that rarely-used page That's solved with proper css, not SPA.

jfaat 9y ago
Also a sane build/deployment process will solve this.
trjordan 9y ago
You're right! If we just implemented everything correctly, there wouldn't be problems! Anecdotally, every team I've worked with has converted to a SPA, and the main ergonomic upgrade is that updates to the signup page or the "not found" widget quit getting forgotten whenever we change tweak our design. There always seems to be one page that's out-of-date for 2 months before anybody notices, then it quietly gets fixed up because we forgot that the design tweak was a CSS+HTML change, not pure CSS. Not that that's perfect -- once you have a SPA, nobody remembers the 404 page, because it's a different HTML base...

Pigo 9y ago

I only scanned towards the end, but I was waiting to here what his proper architectural would be. I don't like complaining unless you have alternative you're ready to support.

mikestew 9y ago
From TFA: "What is this alternative, then? It is to build a classic web application, including rendering server-side HTML, and use JavaScript only sparingly, to enhance browser functionality where possible."

amelius 9y ago

> When I have multiple tabs open, your badges and notifications fall out of date, because you never poll for updates. How bad is that really if users are aware of it and they can simply reload the page?

williamdclt 9y ago
Not very bad for Hackernews. Terrible for Facebook, Twitter or any website that claims to be interactive
- amelius 9y ago
  Personally, I'm not eagerly waiting for updates on Facebook all the time. They might as well appear after a reload. Of course, chat/messenger is something else, but I consider that an exception. (It's easy to build a chat service on top of a static website).

ojosilva 9y ago

Exactly. - The author is describing hypertext, which is perfectly fine for textual static content, one of the key goals for which the World Wide Web was conceived. - Server-side generation of HTML seems totally out of place for other use cases: HTML/JS are now the assembly languages of the web and they belong in the browser. Besides a more distributed architecture is just perfect: server and client focus on what they do best. - Fixing web-apps with broken history buttons and unlinkable urls is important, but to be honest there are fewer and fewer SPAs that are mono-url these days. And it's perfectly fine to have a unlinkable "Delete this Invoice" app button. If it's not real content it should not be a link.

smhenderson 9y ago

- If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. Even when I was coding web pages in Perl in the 90's I wouldn't do that to a user, that's just mean. You don't need a SPA to provide proper error handling that also rebuilds previous state.

sireat 9y ago
Sadly there is a major e-commerce provider in my niche which does exactly that - routinely forgets all my information. In fact sometimes their web form just forgets things for no reason. There is no competitor in sight because of the huge huge SEO juice they have built over 15 years.
- smhenderson 9y ago
  Oh, I know, I have a few examples as well, mostly regarding paying bills. Hate those sites but what can I do? I guess I could go back to mailing a check :-) But it's not THAT inconvenient!

mnarayan01 9y ago

> If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.

tjoff 9y ago

You probably have never tried a classic HTML "app": 1. Every click is fetched and rendered faster than your javascript code has had a chance to execute, let alone fetch or render. 2. True, minor headache though compared to the vast improvements in usability. 3. Nope. 4. Nope, this is a bug - something javascript pages most certainly are not immune against.

philosopherlawr 9y ago
You're basing a lot of this viewpoint on fast internet connections. Javascript code rendering will be faster if you have a slow internet connection and are using an updated browser with a fast javascript engine
- tjoff 9y ago
  In theory you have a point. In practice though the initial loading of the first page is so slow that it completely negates the benefits entirely. It also doesn't work well when opening lots of tabs (which is a popular technique that helps immensely when browsing on a slow connection as pages are loaded in the background). And if you have a really slow or spotty connection the javascript page would barely load at all.
  - philosopherlawr 9y ago
    I think you're basing this off of old technology. With webpack 2 and HTTP/2, this is less of an issue. But, the top comment's statement I think is the most valid: if you're loading static text, then simple html pages are the best. Notice the rise in popularity of static site generators for this purpose. A SPA will win out when you have lots of interactions and you only experience the initial loading of the first page once - and then the majority of your user experience is around interacting with the app.
- e12e 9y ago
  Eh, I've yet to experience an spa that feels or is faster than the equivalent simple html, no matter what network I'm on - with the exception of being off-line (and I've seen few enough spas that actually work better offline than static pages, ie not broken navigation/functionality). Note that I've of course seen countless slow, bloated static pages - but that's pretty much never because of the tech stack - but because of bloated css, silly large images, and often horrible convoluted html. Hn is of course a typical example of a web page that on paper would be great as an spa, but works fine as a static page with minor js (broken up/down links notwithstanding..). D-lang forums is another : https://forum.dlang.org/ https://forum.dlang.org/ Assuming a 64 kbps connection, and a 50%+ gzip compression, downloading a couple of pages of text is done in about half a second. If the user has such a terrible connection, they've hopefully turned off image loading. I don't think adding 40-400 kbs of gzipped js is going to help with the speed... https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d

cpburns2009 9y ago

Since we're talking about poorly implemented features. Why I hate your SPA: - If I click on a link, I receive no indication that I actually clicked a link, then 2-10 seconds later the page abruptly loads. Sometimes the page doesn't load at all. - I cannot tap and hold a link, wait a second for the pop-up menu, and open the link in a new tab because the link isn't actually a link. It's implemented in JavaScript. - The back and forward buttons don't work as expected because either history isn't maintained or it's shoddy (scrolling should not be a history event). - The refresh page button don't work as expected because it resets you to the beginning.

aaron-lebo 9y ago
Just to be clear, that is a poorly designed SPA, none of that should be happening and is easy to avoid.
- cpburns2009 9y ago
  That is absolutely true, but I've seen it enough times to be annoyed. Also, the grand parent post was about classic HTML apps which were poorly designed with issues that should be easily avoidable.
- tarboreus 9y ago
  A normal web page doesn't have to be well-designed in these ways, though. And SPAs often are not designed in this way. The author addresses this pretty well in the first paragraph.
imglorp 9y ago
I think the prime directive of all UI should be, "Ack UI inputs immediately, no matter what else is going on." Throw up a spinner, make something throb, change a status to "loading", anything. Don't just go off and attempt to do it and hope for timely response.
- chiefalchemist 9y ago
  Why can't the browser do this? I mean, it's a universal function / feature, right? And ultimately, it's the browsers that's waiting, not to application per se. (Yeah, I okay. But you know what I mean). I can't think of any good reason why the browsers can't help out with this UI / UX. Am I crazy?

yellowapple 9y ago

"[each click] takes 2 seconds to load" In about 95% of the SPAs I've tried, each click takes even longer than that. "you never poll for updates" Yes, because apparently AJAX/AJAJ is completely nonexistent and there's absolutely zero ground between "pure-HTML like it's 1991" and "VueWangulaReact.js single-page monstrosity". Hell, even a meta-refresh will fix that if you really do want "pure-HTML like it's 1991", though that's certainly inelegant.

romaniv 9y ago

. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. This was fixed in browsers years ago when they started keeping form state along with page history. I can refresh this page, go back and forth in history, and this text box will keep my comment. Ironically, websites that tried to be clever about form state management and faked page transfers (like ASP.NET WebForms) didn't benefit from the fixes and currently are significantly worse off in terms of usability than websites that used vanilla forms. I think there is a lesson here.

romaniv 9y ago

. - If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it. Funny that you mention it. Loosing form data on page refresh or clicking "back" button was a problem on the Web until browsers started keeping form state along with page history. Suddenly millions of websites got this new feature without actually doing anything differently. But that was only possible because page transfers were semantic. Frameworks of that time that tried to manage their own form state (like ASP.NET WebForms) didn't have real page transfers, so they didn't get this "upgrade" and currently are significantly worse off in terms of usability. I think there is a lesson here.

s17n 9y ago

The last bullet is just a straight up error on the part of the developer. The third... isn't real? What browser doesn't save form state? The first two are fair criticism but they aren't nearly as detrimental to the user experience as the typical single page app antipatterns (no history, no indication of page loading, refresh button is broken, etc). While it is of course possible to execute any design well or poorly, the observation that a typical single page app is worse than a typical multipage app is certainly valid.

deleted 9y ago

[deleted]