[systemvoltage]

Please write more about this because I feel the exact same.

Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today?

What should have happened is the following:

- Develop web-to-native-UI mapper, call that thing a browser.

- Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.

- Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.

The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper!

I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste".

/Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.

[userbinator]

Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static

Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS.

I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link.

That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.

[int_19h]

It's not even the ability to bookmark it. It's basic stuff like the ability to restart my computer (e.g. because Windows demands that for updates), and go back to the same exact spot I've been at. For desktop apps, this works. For web pages that are just web pages, it works. But with something like Facebook, if you close a tab in which you've been scrolling through the feed, that state is forever lost.

[amw-zero]

“Let the page refresh” translates to a terrible UX. It devalues the application. It’s equivalent to buying a physical product, say a car, but the car jerks up and down whenever you hit the gas, and you hit your head on the roof every time.

Yea, the web page _works_ but it’s ugly, and in poor taste. Users do not care about browser purity, they want an app that seems polished. You can’t get that experience by using semantic HTML at all.

[slfnflctd]

I'm pretty sure blind people don't even notice this 'terrible UX' problem you describe, and that sighted folks aren't quite as jarred by it as you think.

This 'taste' issue probably matters more in some organizations than others. Hopefully they don't involve blind people in their business, because SPAs are notorious for being unusable to them. You can design an SPA with accessibility in mind (https://www.deque.com/blog/accessibility-tips-in-single-page...) but most devs either can't be bothered or aren't even aware of the issue.

[amw-zero]

Yes, people who don't have the ability to see won't care about flickering on the screen and the better user experience that a single page app affords to users who can see. Not even sure why you're making that point other than to try and imply that people who write single page apps automatically don't care about blind people, which is self-righteous and rude.

We have a single page app and we regularly run it through screen readers to see what the experience is like. Since an SPA is not some magical entity and it does produce a real DOM tree, we can achieve a great degree of accessibility (not perfect) by simply focusing on the markup that's produced. That doesn't help with things like loading screens, but again, since we actually check applications on screen readers, the experience for pages that take a long time to render is not much better with pure HTML either.

I read the link you posted and it's a good resource. The #1 takeaway I got from it is:

> Make sure that client-side view changes are known to screen reader users by announcing the change in page title, using ARIA live regions and/or focus management.

That's a good idea and one we'll incorporate into our application.

Some other comments in the article are not helpful, such as:

> Consider whether a single-page app is really necessary, and if you even need to use a JavaScript framework at all.

This is a moot point. Using a JavaScript framework to create an application is not only acceptable, but extremely popular. So instead of trying to politically smash the idea of building an application using JavaScript, we should be focusing on how to improve accessibility in that landscape. We can and should figure things out.

[slfnflctd]

I appreciate you taking the time to look at that.

I'm glad there are people out there taking the accessibility issue seriously, what you said does make me more inclined to evaluate framework-based solutions. Nice to know at least parts of the most popular JS platforms are maturing enough for this to be easier for devs to implement.

[mnming]

Can't agree more. It's a very simple point but I am surprised that people couldn't realize it and even downvoted your view.

IMO, discussing this further will just yield a negative returns as I think there are some fundamental issues/gap between two parties in this thread.

No matter how much ppl kick and scream, the SPA is gonna make the web a much more user friendly place in general. When we fade away and the next generation of us come, they will take this as the new norm easily and happily.

[robertoandred]

Not sure why you think SPAs can't have unique URLs or real links.

[userbinator]

They can, but it requires additional work on the part of the developers, which in my experience is almost never done. Also, that's kind of what the SPA acronym stands for, no?

[robertoandred]

It does not require much work, and basically none of you use any standard libraries or frameworks, which handle it all for you.

And SPA doesn’t mean you can’t use real links or pages.

[noahtallen]

> Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static.

To be completely honest, this is one of my least favorite things about HN. As I write this comment and click reply, if I wish to navigate “back” after I post this comment, the first back button click with take me to this still-filled comment form. (Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into.) The second back will take me back to the post comments. Which is weird, because this is where I was taken after posting the comment. The third back will take me back to HN homepage. I expect to go back to the homepage on the first back click.

And this nav stack works as it does because HN uses plain HTML forms without any “overkill” JS. But the reality is that the default back behavior doesn’t really fit most user expectations, because most people don’t understand that clicking each of these buttons added more and more to the stack. Most people don’t know what a stack is! :) I think this is a great example of why the default document behavior of the web doesn’t really match most people’s user expectations, and the normal form behavior on the web makes it way to easy to do the wrong thing, like re-submit information.

[int_19h]

> Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into

Have you tried clicking "Reply" once more after going back? If not, do try.

[mmis1000]

> Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order

Designer hate it

[tsimionescu]

> Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.

> Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.

I'm not sure if this was supposed to be a case of 'how it once was' or 'how it should be', but this was never a reality, at least after the 90s. Native apps have always tried to style themselves just so (my company has a C# B2B GUI that has a little bit of assembly somewhere calling a Windows interrupt directly because they couldn't figure out another way to change the color of some window element). Even the earliest web pages were often trying to look as different as possible.

[commandlinefan]

How is it that there are so many of us, but I never seem to work with any of you?

[theonething]

haha, I ask myself the same question.

Someone should make a job board called noSPAjobs.com