Hacker News Reader

Comment by cosmic_cheese | Hacker News Reader

Much of this complexity comes down to primitives being too primitive for the use case of web apps. They’re fine for documents, but for web apps it’s like trying to build a building from grains of sand instead of concrete blocks. Rube Goldberg machines are unavoidable when you’re doing that.

The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.

View on HN

> The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.

Well, I'd prefer if it provided widgets that can't be skinned. :-) The theming should be the user's choice, not the app designer's.

> That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.

I don't really care so much about the web dev experience as the web user experience. My experience as a user is greatly degraded by a bunch of web devs full of bright ideas about how to make their apps look, rather than using predefined widgets whose look is determined by me.

> Much of this complexity comes down to primitives being too primitive for the use case of web apps.

I totally agree with this, although I disagree about what the better alternative is. In my view it is partly this issue that's led to the disappointing profusion of "skinning". In desktop app toolkits you use a tree view, or a button, or a dropdown, or whatever. That widget's "identity" is based around functionality and its look and feel are not controllable by you as the app author. Instead, they're determined by the user's platform (color/font settings, window manager, etc.). That's a better model for users.

For the record, I’d prefer native unstyled widgets in sites too, but that ship has already sailed so I figure it’s best if web devs can do things like have a custom styled popup menu with proper keyboard navigation, accessibility, etc without having to pull in a mountain of wheel reinventing JS.

When look and feel of a widget are not controllable by designer, what ends up being is that people by whom it is controllable—who developed the widget, or the end user—become the de-facto designers. This is further complicated by the fact that “look and feel” can hardly be perfectly decoupled from how it works and its semantic content model (which in an ideal world the data to be skinned would be described in).

Though I can see both sides, there is a belief system in which this type of work is best delegated to professionals.

I recall making that point with Eich here on HN. His counter was that no one could know where it was going. And even today I think it's hard to get agreement on what the fundamentals should be. Web Components are slowly getting there I suppose.

Still, it's quite sad how long we had to wait for stylable checkboxes.

Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again.

The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.

> ...if it doesn’t go back to drawing board and try again.

My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there.

Native app developers seem to be burning resources trying to stay in stores and working on modern devices.

The new APIs wouldn’t be for everybody in the early stages and that’s fine. It’s impossible to build something that everybody can get on board with from day one. There will be early adopters who are willing to pay the price of admission.

Staying in app stores in my experience has not been particularly difficult or resource intensive. If you stick to first party toolkits and don’t go nuts with custom widgets, maintenance is minimal and often you only need to compile against a newer SDK every few years. The horror stories are generally coming from projects with severe NIH syndrome and sometimes of users of cross platform frameworks.

I mean, experimental APIs do get built this way, and some get adopted and some do not.

As it is, the vast majority of consumers want platform parity because nobody wants to feel left out of features on a second-class platform missing an API.

you have put into words a feeling that has been burning in my chest for 20+ years :-)

I cry at the ways we are doing and defining column tables.

> a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS.

It already does literally that. Have you heard about <form>? These common widget libraries seldom last, and that's because people want to differentiate on style in ways that go beyond a CSS skin.

There’s still large gaps that need to be filled.

> people want to differentiate on style in ways that go beyond a CSS skin.

And the reason this is a problem is due to shortcomings in current widgets, which is part of what I was getting at. There’s no technical reason why everything can’t be skinned with CSS, as we’ve seen with modern versions of GTK+ which rely on it entirely for styling. It’s fixable, but there’s little work being done to actually fix it.

Reply on news.ycombinator.com