None of that is the fault of Javascript, it's on the people building them. I'm pretty sure in an alternate universe of no JS, we would see the same articles but about the horrible user experiences of full HTML or native apps.
None of that is the fault of Javascript, it's on the people building them. I'm pretty sure in an alternate universe of no JS, we would see the same articles but about the horrible user experiences of full HTML or native apps.
This is logically correct, but I don't think it's true in the spirit of the argument. Browsers makes it very easy to deploy a broken website. They're incredibly tolerant of faults. Consequently there's no accountability for problems.
If browsers didn't try to display broken apps in a sort-of-working-but-not-really way there'd be a lot fewer broken apps.
It seems if we want to have single page application that act like desktop apps, maybe we need a new language/technology that browsers can handle that is designed for this.
Maybe WASM is supposed to be the answer there, but it doesn’t feel like it (I haven’t really looked into it much). These JS frameworks have had way too much time to get out of hand without something coming in to fundamentally change things to make them obsolete. I worry this whole generation was raised on complexity, with nearly unlimited compute, and they lack the limitations which led to some of the more elegant solutions of the past. Though I could just be wearing rose colored glasses.
While a lot of pages would be well served by going back to a more traditional style, there are web apps that require more, and in lieu of a better alternative, people are going to keep hacking more frameworks around JS to make it happen.
> al_borland
Borland had a nice and not complex solution. Which made for very fast, low latency interfaces. Everyone starts crying when you don't have the react, downward reactive (well, for some definition of this leaky abstraction thing they call reactive because javascript doesn't support anything to help), but with simple events, getters and setters it was much much clearer what was happening every tick and you could optimise, even as junior, accordingly because everyone gets it all after 10 minutes of tutorial of how it works. I have seniors asking me (every few days) why something doesn't or does update in react or why it's so slow to input something in a field in react (we fix or patch horrible software for a living, so we see 100s of different companies over the months / years; these are not the same seniors asking me this; there are very very few people actually understanding how it works and how not to crash and burn because it LOOKS like you can do something in 'this way' (even on the official react site), but when you do it, you machine gun yourself in your legs).
Not to mention that you would end up with a consistent UI with shortcuts that every user could use immediately instead of the shitshow of 'designer' choices.
- No native back and forward button implementation. Now you must listen to an API and emulate the legacy behaviour.
- The concept of links, its also emulated via onClick events. This means that anything can be a link, so in many cases rows become links and their content is not really selectable as text. Legacy HTML has clear limitations for this not to happen.
- Same with buttons. There are no native buttons anymore. Anything can be a button, including any DIV with an event listener. Good luck tabbing through every DIV to get you to a button, that's also another difficult implementation.
Links in Vue Router at least are just regular <a> tags. Yes the framework handles navigation when clicking these, but nothing prevents anyone from wrapping anything they want in an <a> tag even with no JS. You could make an entire table be clickable as a link if you wanted to, framework or not. "Legacy" HTML will render these just fine and browsers will make it a regular link, even though HTML validators will fail it.
Literally the first element anyone makes in frameworks will be a generic Button element that is simply a <button> with some styling. People abuse divs as buttons with or without frameworks because again, nothing prevents you from making any arbitrary element in your DOM have an onclick handler and act as a button. Tabbing through can even work with the correct ARIA attributes, and can even be broken on regular plain <button>s if abused hard enough.
I would seriously suggest people try out Vue or especially Svelte, they're about as simple as you can possibly get (especially Svelte 4) while giving you a lot of power and flexibility. I've worked with plenty of server-rendered apps in the past, and trust me, people would butcher things just as badly and easily there.
Having the proper tool and using the tool properly are two different things - and the web is a place where people forgot to do things the proper way.
All the SPA frameworks handle browser history and links correctly.
Way too many very basic UI affordances cannot be made accessible without JS if they can be implemented at all.
In my opinion there is NO problem. We have powerful tools that give you freedom and the possibility of tinkering. Some people will use it in ways one doesn't like, but as long as you have some possibility to use other products I think it is great.
I wouldn't trust anybody (including myself) to decide for all others what are the powers that should be given or not. The web architecture is amazing exactly because it allows everybody to build without some large body/organization/company imposing most rules.