Hacker News Reader

Comment by Flimm | Hacker News Reader

I wish I could agree with you, but in my experience the built-in controls have many flaws and have remained stagnant for years or decades.

View on HN

Btw that's largely our (web devs) fault.

https://extensiblewebmanifesto.org/

Good intentions and some good ideas. But ultimately lead to a fractured, overly complicated and bloated web.

I say yes to lower level, more general capabilities. But why does that have to mean we get bad APIs (web components, indexeddb, service workers...) and lack fundamental and well established UI components (combobox, toggles, tabs, tooltips, data grids...) and incomplete implementations (lacking HTTP verbs for forms)?

(Also why we're at it, I'm going to sneak in a complaint about half baked and broken language features like `const` and `import`. Also we shouldn't have abandoned Do-Not-Track...)

DNT wasn't abandoned, it was killed.

How are `const` and `import` half-baked or broken? They work great, and do what they are supposed to do. Browser support is great today for both.

"Const" is half baked as it implies that you declare an immutable value, but it only prevents redeclaration and direct reassignment.

"Import" breaks the browser REPL and the dynamic nature of JS. You can't redeclare, look or move into a module. Now JS is already broken in that you can't redeclare variables declared with let/const. But not being able to move into modules an extra crime.

`const` works that way in most of the C family that uses it as a keyword or is restricted only to "primitive" types. To be fair, I agree that JS isn't really a C-style language under the hood and as a functional programming enthusiast I wish `const` was called `let` and `let` called something like `mut` or `let mut`, but JS likes its pretend-to-be-C-family surface level so I'm not upset about it.

`import` works great in the REPL, the various REPLs I use have caught up. Most of them in REPL mode let you redeclare imports and reimport modules as needed. They also all support top-level await so it's just as easy to use `let { thing } = await import('some-module.js')` if you want more of a safety net to redeclare as you wish.

Just some blatantly obvious examples: Select Multiple was some Windows 3 garbage, and HTML didn't have a 'combobox', much less a 'multi-combobox'. (MDN says datalist is not supported on Firefox, so maybe it still doesn't.) So write it yourself, or use a library. The form validation stuff is still bad, and idk if modern desktop browsers have a good date control.

I can agree that it is bad. And there might be some examples where <select multiple> is the "best" way, but I cannot ever remember a real-world use case where it was not better solved using a list of <input type=checkbox> anyway.

Yeah sure, the 'right' way was checkboxes in an iframe. Just that the weblords care alot more about adding syntax to javascript than whatever multi-select-searchable-accessible-box you might want. The form stuff still mostly sucks.

I must be confused because the use case I'm thinking of is a list of 5,000 somethings that are filtered down through user-input text in the combobox, that they can then select, and selected items are then displayed as bubbles within the input field or elsewhere. Certainly can't just display 5,000 checkboxes instead :P

Firefox got partial support in 2011. All that's missing, today, is support for date and time fields.

For most usecases, it'll work. Not so much for meeting scheduling, or calendar management, but everything else.

Second that and from my experience they are just not feasible for any modern web app.

Those controls work fine maybe for a static form on a website as parent wrote - but web applications are not websites...

To you and OP, as the movie goes: "Yeah, well, that's just like, your opinion, man."

My opinion is that we could use fewer "web applications" and more web pages that simply provide structured semantic data and then get out of the way and let the User Agent (and user himself) control the presentation of that data. Sure, some things have to be a web application. I'll grit my teeth and admit that. But many, many sites we visit could easily be raw HTML and maybe some CSS (which the User Agent is free to cherry-pick through or ignore). They would be fast, functional, accessible, (probably) more secure, (probably) more private, free of telemetry, and would better serve the user's interests over the web company's interests.

Instead we get JavaScript "instructions" from the web site, which require the User Agent to faithfully execute, often removing the user's direct access to the actual content and enforcing the web developer's opinion on how it should be presented.

If we had more use of standard controls and light markup, and less JavaSludge, maybe browsers would devote more time towards fixing and improving their standard controls.

Just another random person's opinion, but this has been a terrible direction for the web.

The whole reason we need web "applications" when a simple web site will do all boils down to the demands of marketing and advertising. If you were to go to a major news organization's web site, the bulk of the javascript isn't for frontend UI frameworks, but advertising. Go to a video streaming platform, and they do Weird Things not to prevent scraping, but to inject marketing analytics for advertisers even when you're on an ad-free plan.

Marketing and advertising makes the world a worse place. When you look at the real numbers, it rarely achieves whatever business goals it's supposed to achieve, though for some reason they keep throwing money at the crap because maybe this time it will be different.

What kind of flaws did you have in mind?

<input type="number"> is famously really flawed and not worth using even if what you want is semantically a number and not just numeric:

https://stackoverflow.blog/2022/12/26/why-the-number-input-i...

Tables have a whole bunch of flaws, like not letting you turn an entire row or cell into a link. (Some things are semantically tabular data!)

<button disabled> doesn't trigger various DOM events, forcing you to use <button aria-disabled="true"> if you need them.

These are the ones that come to mind immediately. I wouldn't be surprised if there are others.

Reply on news.ycombinator.com