4 ms·

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

by lmm 3y ago

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

crq-yml 3y ago
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.
smaudet 3y ago
> 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.
- lmm 3y ago
  > 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.

by lmm 3y ago

crq-yml 3y ago

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.

smaudet 3y ago

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

lmm 3y ago
> 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.