Hacker News Reader

Comment by crooked-v | Hacker News Reader

I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc. Then there's the endless layers of fiddly work needed to make accessibility work cross-platform (check out all the work Adobe puts into the react-aria project for an example), and that there's still fundamentally no browser-native no-JS way to submit a form and use the response without loading the whole page again...

View on HN

Agreed. I remember in 2012 we joked that if you used enough Javascript you could get the Web in 2012 up to the level that VisualBasic 1.0 offered back in 1991. But we were certain that in 10 years, by 2022, we'd up to the level offered by VisualBasic 6.0, which would have been amazing, because VisualBasic 6.0 had been amazing.

I've been stunned by the lack of progress. The major browser companies/projects have largely stopped innovating. The period from 1993 to maybe 2010 or 2015 was very fluid, and HTML and CSS expanded quickly, but after a certain point the attitude seemed to be "We don't need to fix HTML because we can fix it with Javascript." Which is sort of true, but it is clunky. It would be much better to simply add more to HTML. At a minimum, every form element offered by VisualBasic should have eventually been added to HTML. What is the hold up? Why isn't this happening?

It's shocking, but there are still no calendars in HTML. Every calendar has to be custom built with CSS and Javascript. You'd think in the year 2024 we'd have every possible time element added to HTML, with easy customization options. I'm baffled this hasn't happened yet.

What will it take to get the major browser companies/projects to start adding more to HTML?

Input type=“date” was added and is supported in HTML5, no js required. Same with time!

...which is great as long as you don't need a calendar on the page itself, or a calendar that shows two months instead of one, or a calendar where you can display information on dates or block selection of certain dates, or a calendar you can add any CSS styling to, or... you get the idea.

What browser do you use? You can test `input type="date"` here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... -- I've tested every up-to-date browser I have on my laptop and phone and they all display a proper calendar-style date picker.

_date picker_, yes. Calendar display? No native options.

The person you're replying to is talking about displaying event data to users which always requires building custom components or pulling in libraries which do

Which is hilarious because it can display a calendar for date picking; but cannot display a calendar.

Likely because the element authors didn't want to overload the existing input semantics. You are talking about <calendar /> not <input type="date" />. Its the same semantic issue that lead to <button /> and <input type="button" />, 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 <insert ui framework>.

> What is the hold up? Why isn't this happening?

One of the problems, and arguably one of its strengths, with the modern web is that there's no single "entity" that owns everything.

A large part of why this isn't happening is that there are too many parties involved in the web - browser implementers, standards maintainers, and web developers. If you want to introduce a new feature to the web standard, it's not enough to convince one browser implementer to add it - web devs can't use a feature that only one browser supports! You need to convince the standards body to adopt it, and to convince browser implementers (plural) to support it, and this takes a lot of time and coordination effort.

In the case of Visual Basic, you just need to get some PM in Microsoft to add it, and it'll be added.

Is it Apple and Google?

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

> no browser-native no-JS way to submit a form and use the response without loading the whole page again

I think a lot of badness comes out of the desire to avoid loading the whole page again. Sure, there are lots of more desktop-like webapps where that's definitely undesirable, but a whole lot of interactions are just fine as a page load, as long as the page load itself doesn't suck.

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?

The view transitions API addresses this: https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

And seems to require JS and doesn't support (yet) cross-document transitions (i.e. anything that causes a reload)

I question whether that's a real problem in a web form. Even unsophisticated users have probably seen it more than a few times and know that it's normal.

“And use the response”

Right, because a description of the use of the response would constitute a DSL

Regarding a form submission without a reload I got this idea years ago:

If the page that is loading has the same origin as the page before it the browser would do the equivalent of DOM diffing and replacement.

Basically doing what those new batch of JS libraries did in browser.

> I feel like a lot of the problems with web UX come from browsers never natively implementing even basic functionality needed for many web apps, like comboboxes, menus, tab panels, etc.

This is completely backwards IMO. The problems come from browsers natively implementing all of these things, in ways that are almost, but not quite, good enough for those web apps. The browser has the Python standard library problem of being "where modules go to die", but even worse since browsers can never deprecate anything; as a result we have all these 80% implementations that don't quite solve the problem but are enough to suck all the oxygen away from any good solutions. And then we just pile hacks on hacks to improve these things without ever fixing the underlying stuff. I mean FFS, Chrome will save and sync passwords that I enter in some web form flow based on heuristics, but it won't save actual username/passwords that I enter via the built-in username/password functionality that the browser has; how screwed up is that?

If I was somehow king of the web, what I'd be looking to do is: standardise one of the various "web components" proposals that lets people implement custom tags as libraries. Reimplement almost all of the things that are currently implemented as browser builtins as web components instead, move them out of the core rendering engine and into what are effectively polyfills-in-reverse; make the actual "browser" piece only implement div/span/canvas or something. Normalise pages loading components from libraries, where they can be iterated on and improved more quickly.

But for some reason web folks and especially HN seem to hate the few parts of the web technology stack that actually work well (Javascript, NPM) and love implementing as much as possible in the parts that are awful and unfixable (CSS). So I don't see things ever improving.

The elephant in the room is that the majority of the standards we end up with are the same thing done three or more different ways in a great rush by a bunch of industry players, with the most popular one being sufficient for a demo app, and the rest being unknown and NIH'd out of parlance.

What we've managed to seriously agree on:

* 8-bit bytes

* IEEE 754

* Unicode

Still up for grabs to a motivated dissenter:

* Endianness

* Line endings

* 3D coordinate systems

* Structured data encoding

* Networking protocols

* Calendars

* Everything else

The browser does work and do some useful things. At the same time, it is mostly a defacto-standard in the post-Chromium era. Specifications like Web Audio did not appear through a lengthy process like, e.g., what created MIDI 2.0. A team at Google appointed themselves a rubber stamp for the thing they wanted to do. But if you actually want to implement it, you look at what Chromium did.

These days I go with the assumption that most of our interfaces are not seriously standardized, and starting over is correct once you have an application that really needs control.

> But for some reason web folks and especially HN seem to hate the few parts of the web technology stack that actually work well (Javascript, NPM)

Actually, the parts that are "awful" and "unfixable" work great. You still need a DOM to render anything whether its CSS or JS. Without all the parts that make a browser, well, a browser (that you seem to hate), you have a glorified JS engine.

But maybe you are a guy who likes doing everything in their own custom graphics engine, you can have your canvas and javascript-based UI (ew, hard pass) and render everything like molasses except on 24 core monster desktops...

> Reimplement almost all of the things that are currently implemented as browser builtins as web components instead, move them out of the core rendering engine and into what are effectively polyfills-in-reverse; make the actual "browser" piece only implement div/span/canvas or something

There's no reason to do that last part, and in fact its really terrible news for not just compatibility but also any sort of accessibility. I guess you don't care about blind, disabled people, or people in different markets, 24 core video game guy... or maybe you do and you'll re-implement the browser...in your browser! What a great idea...

Now, as far as web components go, we should have default impls of nearly everything. You can, and probably should, have some ability to customize the render of individual elements (what web components brings to the table). But you don't get to change default behavior _because you feel like it_. There's no point to writing web-apps otherwise. You are far better off just writing in a "native" language where you have full control anyways.

> But maybe you are a guy who likes doing everything in their own custom graphics engine, you can have your canvas and javascript-based UI (ew, hard pass) and render everything like molasses except on 24 core monster desktops...

Doing e.g. UI transformations in Javascript generally outperforms the CSS version. But HN doesn't really care about performance, it's just an excuse for their prejudices.

> There's no reason to do that last part, and in fact its really terrible news for not just compatibility but also any sort of accessibility. I guess you don't care about blind, disabled people, or people in different markets, 24 core video game guy... or maybe you do and you'll re-implement the browser...in your browser! What a great idea...

Again, just like performance, the HN crowd doesn't actually care about accessibility, they just use it as an excuse to push their own prejudices. If you actually take the time to e.g. test your pages in a screenreader, you'll find that most of the dogma is false; a JS-heavy component library will often do better than using the browser builtins (and this has been true since the days of YUI if not earlier), and a table-based layout will often do better than a CSS one.

> Now, as far as web components go, we should have default impls of nearly everything. You can, and probably should, have some ability to customize the render of individual elements (what web components brings to the table). But you don't get to change default behavior _because you feel like it_. There's no point to writing web-apps otherwise. You are far better off just writing in a "native" language where you have full control anyways.

Most webapps would be better if they were native apps. The web is a terrible application platform. But since it's mostly used for apps nowadays, it would be better to accept that and implement the things that are needed to make the browser a non-awful application runtime, rather than the continued masochism of pretending it's a document viewer and contorting everything to fit that.

> it would be better to accept that and implement the things that are needed to make the browser a non-awful application runtime

It absolutely would not. Everything doesn't need to (and should not) be an app. Most interactions online can and should be handled (for a human at least) as document exchange. App != better, app == worse (more random non-necessary complexity).

I'm inclined to dis-believe your other claims, as well. Those are pretty broad strokes for a litany of devices, runtimes, etc. "Screenreader"? Ha, which version, what OS, which device, etc. Just because you haven't seen the plethora of devices and use cases you support, doesn't mean they don't exist, at any rate your claims are baseless without more evidence.

> Everything doesn't need to (and should not) be an app. Most interactions online can and should be handled (for a human at least) as document exchange. App != better, app == worse (more random non-necessary complexity).

I don't like it any more than you do, but the fact is that the web as a document platform has failed. The overwhelming majority of web use is app style, even for things that "should" fit into the document paradigm. Facebook or Twitter posts? Loaded via AJAX and rendered by an engine they've written in JavaScript. Article on any major news site? Ditto. Webmail? Ditto. Blog? Editor pages definitely, unless it's an old WordPress that hasn't updated, and there's a decent chance even the posts work that way too. Even web forums are moving there.

> I'm inclined to dis-believe your other claims, as well. Those are pretty broad strokes for a litany of devices, runtimes, etc. "Screenreader"? Ha, which version, what OS, which device, etc. Just because you haven't seen the plethora of devices and use cases you support, doesn't mean they don't exist, at any rate your claims are baseless without more evidence.

Right back at you. If you really cared about performance, or accessibility, you'd have benchmarks and test cases. If you don't have any, you don't have any real basis for thinking that using more CSS and less JavaScript makes your site better.

(If you have actually found cases where CSS etc. help, I am interested, FWIW - it doesn't match my experience, but it's always good to learn more)

> Facebook or Twitter posts? Loaded via AJAX and rendered by an engine they've written in JavaScript. Article on any major news site? Ditto. Webmail? Ditto. Blog? Editor pages definitely, unless it's an old WordPress that hasn't updated, and there's a decent chance even the posts work that way too. Even web forums are moving there.

Don't use, don't use, don't use, don't use, don't use. Actually I did use media-wiki, that was quite refreshingly simple. Worked on a phone that is going on 10 years old.

In comparison, big-name web-app stuff like Expedia, Discourse, Discord, Teams, News that uses lots of JS like you claim works like utter trash.

> If you have actually found cases where CSS etc. help, I am interested, FWIW

The off-the-cuff example was AMP pages (which has different issues), but basically worked by heavily, heavily restricting what pages could do at all. Like, e.g. Javascript.

I'm sure I could find more, and even get benchmarks.

Your turn.

> Don't use, don't use, don't use, don't use, don't use. Actually I did use media-wiki, that was quite refreshingly simple. Worked on a phone that is going on 10 years old.

Well good for you, but approximately no-one's using that. So evidently it's not working out great.

> In comparison, big-name web-app stuff like Expedia, Discourse, Discord, Teams, News that uses lots of JS like you claim works like utter trash.

And yet that stuff is a lot more popular. So even with the issues, JS-heavy sites are inevitable.

Which sites manage to be both popular and usable? The very sites that dive all the way into an application approach: Google Maps, Twitch, Trello before Atlassian ruined it. Half-assing it with progressive enhancement etc. is doing more harm than good.

> The off-the-cuff example was AMP pages (which has different issues), but basically worked by heavily, heavily restricting what pages could do at all. Like, e.g. Javascript.

They also severely restricted CSS. And, even with all that, they didn't work very well; one might even say they were a lot more effective at blocking non-Google ad tracking than they were at making web pages faster.

> I'm sure I could find more, and even get benchmarks.

> Your turn.

Uh huh. I'm also sure I could find examples and get benchmarks. Right back at you.

> I'm also sure I could find examples and get benchmarks. Right back at you.

I've provided examples. Your "examples" are to say that yes, it sucks, no JS isn't better, but you won't provide any examples to support your claim that JS is better.

I can't take you seriously at this point.

Reply on news.ycombinator.com