An attempt was made to tackle this once and for all with XForms, but it never got implemented in browsers. Instead we have virtually all CSS/JS component frameworks provide their own limited set of form elements with different semantics.
I'm too young to know what happened or why. By the time I got my first engineering job, JSON was the standard choice for "stuff you need to serialize."
I feel like YAML has also become the default choice in several areas where XML would be flat-out better.
The benefits mentioned above are due to schemas, and not the serialization format or tool scope, all of which could be improved independently.
But even if an excellent combo dropped from the sky getting everyone to use it would be very hard due to inertia.
That said, some folks with demanding needs use protocol buffers or thrift, etc. And have for a while.
I'm not advocating for universal XML use, nor am I advocating for universal JSON use. I'm advocating for standing back and asking yourself "what am I trying to accomplish?" then choosing the right tool for the job.
As for protobuf: I've seen entire companies built on it. It's amazing what your engineers can do when they don't spend half their time twiddling bits or arguing about data formats. It's a godsend for embedded developers (like me), because JSON, XML, et al are non-starters in that space.
Others won’t even try to edit xml/json and constitute the great majority of humans.
json is better but the lack of trailing commas dooms it as a more general format.
XSLT is powerful but harder to get right than just reshaping JSON.
It is. You throw it in React and get on with your life. It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives.
This isn't some "bizarre fetish," it's an issue with implications from performance to code organization to legal compliance. (No, seriously -- Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.)
This is a core component of a lot of problems with modern webdev.
Framework fatigue? Yeah, because UI toolkits frequently reimplement basic structural elements, in their own specific dialects.
Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.
Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.
I'm not saying that it's without its own problems -- obviously different orgs will require different levels of support for older browsers, for one thing -- but there's a reasonable argument to be made that the current ecosystem overcomplicates this a lot, and that relative to using the platform, sometimes all the extraneous dependencies are the half-baked alternatives.
Use of JavaScript has approximately zero correlation with website accessibility. If anything, sticking with a mainstream framework makes you more likely to meet accessibility requirements, not less.
> Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.
If your concern is dev time then third-party libs are a great thing, and trusting the library generally means less test burden than trying to figure out what each browser supports at the moment and whether that fits with your support matrix. If your concern is performance, you have to actually measure it - often JavaScript performs better than the native browser implementation of a feature.
> Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.
CSS selectors are far more messy than using a CSS class for every element. CSS is a tarpit where everything almost but not quite works, minimising your interaction with it is the only way to stay sane and keep your codebase maintainable.
Intent is not something you can work out programmatically, so we can’t have nice things in some situations.
The last fancy form I worked on, I had to make sure the click event fired the form submit fairly directly so the browser would allow it.
Having a multitude of “solutions” is a feature, not a bug.