Agree. More importantly, I see this nasty trend where people bag on jQuery code just because it's jQuery code.
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...
The vanilla solution doesn't offer as many features:
* 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
Of course there isn't perfect feature parity, but considering how much more complex a custom solution is, you should definitely think twice about what that complexity actually gets you
UIs on the web suffer much more than UIs elsewhere from the disease of people designing their own UI elements in order to achieve a novel, unique style. Perhaps, some day, this will be considered pointless and unprofessional like on the desktop...
But web design philosophy has been creeping on to the desktop for quite a while now. Apps like Skype and Slack are ludicrously overstyled these days. Flash and chrome have always played teeter-totter with utility and functionality, in every field.
But has it been solved if you take into account the various constraints/issues:
- 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!)
I've done stuff with Delphi back in the day, but I'm not too experienced. Would you mind explaining point by point how desktop UI 'does' this?
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!
Young developer here too, but I started about a decade ago with robotics/desktop development. Thus, I can sympathize with the comment earlier that desktop UI has done all this:
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.
I think we're talking cross purposes. I'm not saying that there we never came up with better things; far from it!
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
Oh, you're an evil person for bringing those up. Now I'm going to have COM and CORBA nightmares for days! It still blows my mind that we managed to write half a screenful of code, essentially just to call a function.
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...
a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers)
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.
With the way callbacks work in Javascript and jQuery, you lose some flexibility in organizing your code. It is true the types in Javascript make it difficult to build large projects. These drawbacks can be overcome, of course, but this is all orthogonal to the main point......
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.
Eich wasn't ignorant of history, he just had marching orders to deliver something that resembled Java for marketing reasons, and only a week to finish or be displaced by something worse. The trouble is nobody ever got to fix it until ECMA.
Why?
UI is hard dude. UI on the web is especially hard because the technology has been growing progressively for over two decades.