In my personal experience, the real problem is when there's an impedance mismatch in the web platform. Here's an example. Let's say you have some tabulated data. So, being a good developer, you use a <table>. Done. Then, you want to make the rows clickable.
Oops. You can't nest table row <tr>s within anchors <a>, so you have a few options:
1. Each column has a link, and the link extends to the width of the containing cell.
Pros: It's easy to implement. It doesn't break browser behaviors.
Cons: There's unintended holes in the click targets. It's ugly as sin in code. It is quite confusing for screen reader users. It may be hard to get this right if your cells contain more layout than pure text. All in all, it's not an elegant solution.
2. Instead of making it a link, override the behavior of clicking on a row by registering a click event handler.
Pros: It does what you want. It's easy to generalize. It's a little bit of a kludge but certainly less hacky than 1.
Cons: It requires extra work to make it work well with screen readers. It requires extra work to make it work well with ctrl clicking and other behaviors - in fact, many webapps that apply this approach actually emulate the browser behavior, which, imo, is horrifying. Right clicking no longer gives contextual options for links, since there is no real link.
3. Restructure the DOM to not use a <table>. Perhaps use `display: table` with plain divs.
Pros: Now you can use a proper anchor tag link. It's also fairly easy to generalize. It shouldn't require too much work to get working well with screen readers.
Cons: Although it's less of a kludge in the end, it has one annoying flaw: just to get this behavior, you have to completely restructure your document. Which leaves you with choices: Should all tables be structured using other HTML elements instead of <table>?
Ultimately, some applications end up with trouble where anchor links are pretty hard for one reason or another. I don't think PWA or JS developers generally strive to break things or needlessly reimplement them; everything from client-side routing to custom link event handling has a reason to exist, and usually the intent is to make things work as well as possible.
That having been said, I've noticed a great deal of issues even with mature frameworks. For example, if you go to a really heavy PWA that has proper anchor links for fallback, try ctrl+clicking the anchor links and see what happens. You might find that it navigates in the current tab and spawns a new window!
(Note: I'm not suggesting this example is perfect; you could probably argue about whether the tabulated data should ever have clickable rows, or something like that. Still, it is a real thing that I've come across a few times now, and there's some pretty similar siblings to this problem.)
edit: Oh, and on a historical note... some of you who also were early adopters on XHTML will remember that in XHTML, you could actually put an href attribute on more elements, allowing you to get the behavior on list items, spans, etc. Sadly, it was never widely implemented.
In our in-house apps we went for the progressive-enhancement, almost-2 option.
When we're presenting data, one of our columns is nearly always a 'primary identifier' of some kind - a name, an id, etc. We make this column a hyper-link and then we also add a click handler to the row. This means it's still fully accessible to screen readers and tab navigators, but users who expect a more 'app'y experience are happy too.
The click handler has to be a little smart to ensure it's not receiving the mouse-up of a selection event, but it's not bad.
Oops. You can't nest table row <tr>s within anchors <a>, so you have a few options:
1. Each column has a link, and the link extends to the width of the containing cell.
Pros: It's easy to implement. It doesn't break browser behaviors.
Cons: There's unintended holes in the click targets. It's ugly as sin in code. It is quite confusing for screen reader users. It may be hard to get this right if your cells contain more layout than pure text. All in all, it's not an elegant solution.
2. Instead of making it a link, override the behavior of clicking on a row by registering a click event handler.
Pros: It does what you want. It's easy to generalize. It's a little bit of a kludge but certainly less hacky than 1.
Cons: It requires extra work to make it work well with screen readers. It requires extra work to make it work well with ctrl clicking and other behaviors - in fact, many webapps that apply this approach actually emulate the browser behavior, which, imo, is horrifying. Right clicking no longer gives contextual options for links, since there is no real link.
3. Restructure the DOM to not use a <table>. Perhaps use `display: table` with plain divs.
Pros: Now you can use a proper anchor tag link. It's also fairly easy to generalize. It shouldn't require too much work to get working well with screen readers.
Cons: Although it's less of a kludge in the end, it has one annoying flaw: just to get this behavior, you have to completely restructure your document. Which leaves you with choices: Should all tables be structured using other HTML elements instead of <table>?
Ultimately, some applications end up with trouble where anchor links are pretty hard for one reason or another. I don't think PWA or JS developers generally strive to break things or needlessly reimplement them; everything from client-side routing to custom link event handling has a reason to exist, and usually the intent is to make things work as well as possible.
That having been said, I've noticed a great deal of issues even with mature frameworks. For example, if you go to a really heavy PWA that has proper anchor links for fallback, try ctrl+clicking the anchor links and see what happens. You might find that it navigates in the current tab and spawns a new window!
(Note: I'm not suggesting this example is perfect; you could probably argue about whether the tabulated data should ever have clickable rows, or something like that. Still, it is a real thing that I've come across a few times now, and there's some pretty similar siblings to this problem.)
edit: Oh, and on a historical note... some of you who also were early adopters on XHTML will remember that in XHTML, you could actually put an href attribute on more elements, allowing you to get the behavior on list items, spans, etc. Sadly, it was never widely implemented.