> This seems ludicrous to me.
Why?
UI is hard dude. UI on the web is especially hard because the technology has been growing progressively for over two decades.
Why?
UI is hard dude. UI on the web is especially hard because the technology has been growing progressively for over two decades.
I've seen devs complain about how coupled some small jQuery one-liner is and then replace it with some muli-hundred line monstrosity of a module that's buggy, incredibly hard to understand and impossible to actually reuse...then when you call them out on it, they just say "fuck you, we're writing ES6 now".
The code they replaced was simple, just worked and didn't have side-effects. And they're still using jQuery elsewhere in their project anyway...
Probably because it's one line in Vanilla.js:
confirm("Message")* With the vanilla solution, the user can check a box that says 'Prevent this page from creating additional dialogs' (which can break the site). With a non-vanilla solution, the user cannot check that box
* The vanilla solution can't be themed in tune with the rest of the site or webapp
* The only options you have are 'OK' and 'Cancel' - you may wish to have other buttons/labels for your modal. Never mind if you want three buttons, or a list or the like
It's been a solved (and re-solved) problem for decades.
If Javascript and jQuery truly are bad (though I would claim they are not, they are mediocre but workable), it's because their creators didn't know history, not because the problem is unsolvable.
- clients that range from tiny phone screens to full desktop screens
- incompatibility when it comes to what features clients support, and even how they support it
- a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers)
- serious limitations in payload file size for the entire UI codebase
- much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'.
- backend systems that are not optimized for these kinds of things
I am a relatively 'young' programmer, so maybe I'm utterly wrong about thinking that, considering the above, we're in kind of uncharted territory. By all means correct me!
All that said, I do get the feeling 'we' in the javascript world reinvent the wheel more than necessary. But perhaps that's because none of the historical solutions are 'complete' enough to get enough mindshare in the way that, say, Ruby On Rails was, or jQuery.
Also, personally I'm becoming more convinced that until all this stabilized, many of use (or at least I personally) might benefit from just not aiming that high when it comes to UI. If I'm honest with myself, an 'old-fashioned' backend that produces HTML with perhaps a few dynamically loaded components (as just HTML fragments, even) is perfectly fine and I truly doubt it would have a negative impact.
(hey carsongross, this is where you bring up intercooler.js!)
It does your checklist for 2 decades.
For example, I can't really think of a desktop app where most of the crucial app/UI logic is reliant on async communication with a server. Most data is stored locally and permanently.
I'd actually really like to hear because I have been eying native development lately!
clients that range from tiny phone screens to full desktop screens -- Desktop UI could support this if developers wanted to its just resizing a window. You just don't see it because devs assume the existence of a mouse which allows easing panning in a scroll bar window.
- incompatibility when it comes to what features clients support, and even how they support it - Desktop UI has or had solutions: Swing, JavaFX, QT, Adobe's Flex.
- serious limitations in payload file size for the entire UI codebase: There have been desktop XML UI for so long. The oldest I can recall would be Adobe's that went along with ActionScript to build Flex apps.
- much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'. -- The desktop analogy here is some long running process. Whether that is a slow disk, long computation, or some network access, desktop UI solved this a long long time ago with a rendering thread and worker threads.
- backend systems that are not optimized for these kinds of things - not sure what you mean here.
Rather, disregarding how we got here, the situation we're in now provides challenges that sort of justify the complexity and confusion we're in now. Maybe this comment better expresses what I'm saying: https://news.ycombinator.com/item?id=14218425
On the bright side, I will never forget a manager of that era who was very good with buzzwords but not so good with the technologies behind them. We had some existing software built using COM, Microsoft had just announced the first version of .NET (though no-one quite knew what .NET actually meant yet) and the Internet was taking off as a mainstream technology for the general public. The manager in question would wander around the department asking us if we were using this new .COM framework to build our new software...
This is the problem, right? It's not that the other problems are unsolved, it's that we're buiding on a lousy foundation. But even that is just an annoyance, something we know how to overcome, it's not a fundamental impossibility.