Care

I agree with the author, but they don't seem to get into what we can do to get it back to a more delightful experience.

I don't think the solution is to have more passionate builders in existing organizations that have overly short-term priorities (increase revenue this week vs. re-imagine a market).

I only see things changing through better competing products. Similar to how LLMs have enabled products that completely circumvent crap in search results (e.g. low quality listicles), we will see the same happen for most products and services.

Some products are going to be tough to displace, and it might take a new airplane startup that owns the entire ticket purchasing to inflight entertainment and last mile transportation (airport to destination) to show the world what an incredible flying experience could look like, that will force other airlines to at least try and catch up.

I hope more people with these sort of frustrations (which I share!) try to re-imagine experiences from the ground up and not shy away from tackling problems in big ways. We need more of it.

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.

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...

Likely because the element authors didn't want to overload the existing input semantics. You are talking about not . Its the same semantic issue that lead to and , with different functionality/support in different browser(s), and why we have auto-fill libraries that eventually became javascript component libraries, got rolled into development frameworks and turned into hyper-adware...

Its "hilarious" but an "input" that does nothing but show an input calendar is arguably better. Otherwise, you're not writing (semantic) html, you're writing .

The real problem isn’t the page load, it’s that it’s visible. If only one picture and a bit of text update, why does the whole screen have to blink?