3 ms·

I think Web Components was seen as the fix for this; that (in the same way VB4 did) we'd have packages of standard components as building blocks for UIs. So rat

I think Web Components was seen as the fix for this; that (in the same way VB4 did) we'd have packages of standard components as building blocks for UIs. So rather than each browser implementing a calendar defined in HTML, you'd use a third-party library Web Component that implemented a calendar. Which is happening. You can get a Web Component calendar, and they mostly work. I just don't think it's taking off as "the way" for doing web UI (yet). This might change, I guess. But probably not. I think the big difference from the VB days is design. In the old days, we dev monkeys would design UIs by slapping together controls in a form. Which is why they all looked the same, and while they worked well they didn't exactly inspire. Now in Web Dev we have designers as the first step, and every designer designs their UI differently. You can't slap together a UI and call it done. Well, you can, and I do, but everyone thinks the result is ugly and needs a designer to make it usable - we've moved the bar of acceptable aesthetics to the point where this VB way of creating UIs doesn't work any more.

smaudet 3y ago
You hit the nail on the head (well, half) - design is an incredibly tricky problem. Mostly because it at its core is the process of adding constraints, and once you've added those its far harder to un-add them. That's why CSS was so janky for so long - there were design paradigms (tables, box model, flex box, etc) and once they were there, you hoped they worked and you hoped that your specific design didn't break one of its core assumptions, leading to large amounts of work-around code that was either slow or exhibited constant random bugs in different versions of browsers... The other half of the nail was backwards compatibility. Unfortunately you can't have web components and your stuff working on 20 year old devices. So any new design/paradigm etc. served to splinter the ecosystem (your stuff only works on this browser, that device, our operating system). Graceful degradation sort-of would have provided a work around, but it would have done so by shifting the workload onto the provider (please make sure your calendar works, in these browser, and also has fallback implementations as a clock that doesn't break your back-end code because they entered hours as farsi, test on on these 40 browsers and also target moving backends). So instead we invented polyfills as a way of "automatically" back-filling for a lot of stuff. Unfortunately, you can't do much about the Web Component calendar. The design paradigm that once existed doesn't support it without a lot of busy work, even if newer browsers could natively implement one and never load a line of javascript or any of your shitty thousand line long html layout code... I don't think its a completely lost cause, HTMX + Web Components seems like our best path forward so far. Right now, a lot of people who've written millions of lines in non-html frameworks like React and the like are very reluctant to give up their codebase(s), however terrible they might be. It is unfortunately, the result of someone somewhere making a design decision that added constraints, now causing headaches and difficulties un-adding those constraints...

smaudet 3y ago

You hit the nail on the head (well, half) - design is an incredibly tricky problem. Mostly because it at its core is the process of adding constraints, and once you've added those its far harder to un-add them. That's why CSS was so janky for so long - there were design paradigms (tables, box model, flex box, etc) and once they were there, you hoped they worked and you hoped that your specific design didn't break one of its core assumptions, leading to large amounts of work-around code that was either slow or exhibited constant random bugs in different versions of browsers... The other half of the nail was backwards compatibility. Unfortunately you can't have web components and your stuff working on 20 year old devices. So any new design/paradigm etc. served to splinter the ecosystem (your stuff only works on this browser, that device, our operating system). Graceful degradation sort-of would have provided a work around, but it would have done so by shifting the workload onto the provider (please make sure your calendar works, in these browser, and also has fallback implementations as a clock that doesn't break your back-end code because they entered hours as farsi, test on on these 40 browsers and also target moving backends). So instead we invented polyfills as a way of "automatically" back-filling for a lot of stuff. Unfortunately, you can't do much about the Web Component calendar. The design paradigm that once existed doesn't support it without a lot of busy work, even if newer browsers could natively implement one and never load a line of javascript or any of your shitty thousand line long html layout code... I don't think its a completely lost cause, HTMX + Web Components seems like our best path forward so far. Right now, a lot of people who've written millions of lines in non-html frameworks like React and the like are very reluctant to give up their codebase(s), however terrible they might be. It is unfortunately, the result of someone somewhere making a design decision that added constraints, now causing headaches and difficulties un-adding those constraints...