3 ms·

> 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, th

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

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.

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