Care(johan.hal.se)
johan.hal.se
Care
https://johan.hal.se/wrote/2024/02/28/care/
91 comments
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...
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?
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?
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.
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...
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...
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
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>.
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>.
[deleted]
> 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.
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?
> 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.
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.
[deleted]
“And use the response”
Right, because a description of the use of the response would constitute a DSL
Right, because a description of the use of the response would constitute a DSL
[deleted]
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
I think part of the problem is that there seems to be a widespread sentiment among software developers to prioritize our time above the user's. Ease of development trumps ease of use and features are made to be easy, or rather fast, to build rather than easy to use and performant.
As a young developer I was taught to take the extra time to make things better for the user. Even if it might mean spending two days on a feature rather than a few hours, the cumulative time saved would end up much more than the extra time I spent since users use your software more often than you write it and there are many users. Unfortunately this view is not widespread enough.
As a young developer I was taught to take the extra time to make things better for the user. Even if it might mean spending two days on a feature rather than a few hours, the cumulative time saved would end up much more than the extra time I spent since users use your software more often than you write it and there are many users. Unfortunately this view is not widespread enough.
„it‘s not economical to build good software“
Physical products suffer the same fate. It makes no (capitalist) sense for a business to make a product that never needs to be replaced. In the US, it means we've seen brands like Levi's and L.L. Bean quality and guarantees decline greatly compared to the products that earned them their reputation.
"Of a quality too high for the market to rationally produce"
Enjoy your Lamborghini made of plastic with the app screen that nags you to renew the bundled satellite radio subscription! :D
Enjoy your Lamborghini made of plastic with the app screen that nags you to renew the bundled satellite radio subscription! :D
I try to be positive. People still choose to interpret my writing as negative, but that’s very much on them. I’m not a negative person, despite the circus that is Life in the Twenty-First Century.
I was a troll. A fairly nasty one, and I feel the need to atone. No excuses. I just don’t do that, anymore.
My formula tends to be specific, in praise (and as much of that, as possible), and vague, in criticism (and as little of that, as possible). It does earn me some sneers, from this crowd, but I’m really too long in the tooth, to be ruled by personal insecurities. I continue to do it, and the occasional insult won’t stop me, or provoke me into retaliating.
I’m a pretty good coder. I write code every day, and just about everything I write, ships. I open a significant part of it[0]. I feel that I do it well, and would rather lead by example, than complain about others. Just feels better, to me.
Kindness and empathy almost seem like lost arts, these days, and that really is a shame. I know that I played a small part in establishing that culture, and hope to play a small part in reversing it.
Personally, I hold myself to excruciatingly high standards, but I really only worry about others, if I use their work. Life’s too short, to be obsessed with the motes in the eyes.
[0] https://github.com/ChrisMarshallNY#browse-away
I was a troll. A fairly nasty one, and I feel the need to atone. No excuses. I just don’t do that, anymore.
My formula tends to be specific, in praise (and as much of that, as possible), and vague, in criticism (and as little of that, as possible). It does earn me some sneers, from this crowd, but I’m really too long in the tooth, to be ruled by personal insecurities. I continue to do it, and the occasional insult won’t stop me, or provoke me into retaliating.
I’m a pretty good coder. I write code every day, and just about everything I write, ships. I open a significant part of it[0]. I feel that I do it well, and would rather lead by example, than complain about others. Just feels better, to me.
Kindness and empathy almost seem like lost arts, these days, and that really is a shame. I know that I played a small part in establishing that culture, and hope to play a small part in reversing it.
Personally, I hold myself to excruciatingly high standards, but I really only worry about others, if I use their work. Life’s too short, to be obsessed with the motes in the eyes.
[0] https://github.com/ChrisMarshallNY#browse-away
I debated internally whether I should leave this comment or not, but I have a principle to always try to give constructive criticism where I can, so here it is:
I don't know if it's that people interpret your writing as negative per se, I tried to realize what your writing makes me feel and why, and I realized that your comments always have a very high percentage of "I" and "me". I can see how that might rub a few people the wrong way, but obviously there's nothing inherently wrong with that.
I don't know if it's that people interpret your writing as negative per se, I tried to realize what your writing makes me feel and why, and I realized that your comments always have a very high percentage of "I" and "me". I can see how that might rub a few people the wrong way, but obviously there's nothing inherently wrong with that.
That’s deliberate.
I have spent most of my adult life in a community that is extremely sensitive to dictatorial language, and I have learned to keep it to “me,” or (preferably), to “we.”
A big part of my editorial review, is replacing instances of “you,” with “we.”
I state stuff as it applies to me, my opinions as personal points of view, as opposed to absolutes, etc.
In fact, when I diverge from this, it tends to immediately draw (often justified) criticism.
I am also quite prepared to back up what I say, but it has been my experience that folks refuse to follow up on it; instead, insisting on continuing to state easily disproven opinions. They don’t want facts to interfere with the narrative.
I have spent most of my adult life in a community that is extremely sensitive to dictatorial language, and I have learned to keep it to “me,” or (preferably), to “we.”
A big part of my editorial review, is replacing instances of “you,” with “we.”
I state stuff as it applies to me, my opinions as personal points of view, as opposed to absolutes, etc.
In fact, when I diverge from this, it tends to immediately draw (often justified) criticism.
I am also quite prepared to back up what I say, but it has been my experience that folks refuse to follow up on it; instead, insisting on continuing to state easily disproven opinions. They don’t want facts to interfere with the narrative.
One of the top things that I want in a job is coworkers who care obsessively.
it's a double-edged sword. I want balance rather than obsession.
Yes. Balance.
It is okay to care, but nobody is always right, and noone has a monopoly on good ideas.
It follows then that the person who just 'cares too much' will be on the wrong side of a decision. At that point the best outcome is for them to either change their mind, or let go.
It is okay to care, but nobody is always right, and noone has a monopoly on good ideas.
It follows then that the person who just 'cares too much' will be on the wrong side of a decision. At that point the best outcome is for them to either change their mind, or let go.
Ppl tend to care for things that enable bonuses
Especially if you're working as team.
Caring obsessively can be a negative in some competitive environments, e.g., a very insular/non-collaborative university department. But I suppose I might not call those other professors coworkers.
Caring obsessively can be a negative in some competitive environments, e.g., a very insular/non-collaborative university department. But I suppose I might not call those other professors coworkers.
This works if people also have very clear boundaries for where their responsibilities end and where their teammates responsibilities begin.
Someone who cares obsessively about things that are closer to their coworkers area of responsibility are a liability to a team IMO.
Caring obsessively about your own responsibilities is great. It is a pain in the ass from time to time, but that pain is worth it.
Someone who cares obsessively about things that are closer to their coworkers area of responsibility are a liability to a team IMO.
Caring obsessively about your own responsibilities is great. It is a pain in the ass from time to time, but that pain is worth it.
> One of the top things that I want in a job is coworkers who care obsessively.
While I agree with the premise, the "downstream" really matters though.
There's a lot of different ways to care obsessively and many are quite toxic if you've ever worked with them. One example comes to mind is I've been there were PR comments are way overbearing. There's definitely good points/notes, but nitpicking, snide comments, holier-than-art attitude easily comes along with the boat.
"With love" is such a blase statement, but it really has to be the starting point. That caring combined with respect has to be present to be a healthy, long term working environment.
Like with many things, there's a balance.
While I agree with the premise, the "downstream" really matters though.
There's a lot of different ways to care obsessively and many are quite toxic if you've ever worked with them. One example comes to mind is I've been there were PR comments are way overbearing. There's definitely good points/notes, but nitpicking, snide comments, holier-than-art attitude easily comes along with the boat.
"With love" is such a blase statement, but it really has to be the starting point. That caring combined with respect has to be present to be a healthy, long term working environment.
Like with many things, there's a balance.
I'm going to plug my PR log level policy here: I add a tag to my PRs asking for "error level" or "debug level" or whatever in between. Then the reviewer can tune their feedback. I started doing this when I was working with a diverse group of folks with different backgrounds. I'd like it to be a standard thing.
I find that I want different kinds of feedback through the process of developing a PR, and whether it's over a day or a month matters a lot too.
That way, I can safely be obsessive about things when giving PR feedback, in the knowledge they're asking for "debug level" feedback, or give it just-the-facts review if they're just trying to get something merged that has been reviewed to hell and back.
I find that I want different kinds of feedback through the process of developing a PR, and whether it's over a day or a month matters a lot too.
That way, I can safely be obsessive about things when giving PR feedback, in the knowledge they're asking for "debug level" feedback, or give it just-the-facts review if they're just trying to get something merged that has been reviewed to hell and back.
s/obsessively/pragmatically/
That’s such a great observation
Well, y'know. You're likely to be better off if you put that desire to one side and focus within.
Consider a soup kitchen vs a supermarket checkout. The people working at the soup kitchen arguably care a lot more. The person at the supermarket checkout can be as glassy eyed as they feel and still be part of feeding more people in absolute terms.
Humans seem to have some sort of emotional heuristic to focus on care (really, focus on motivation of others I think). That works in small groups but it is highly misleading in large ones. In large groups, the only factors that matter are incentives and competence. If the incentives are good and the people are competent, good results will happen. If the reverse, corruption. The motivation heuristic actually does a lot of harm because it causes a huge amount of noise in the discourse where people whinge about this person or that having bad character to no avail. It is often true that people have impure motivations, but at scale that is true of effectively everyone. There are the devils you know and the devils waiting to become known. We can get great outcomes regardless; our politicians are cut from the same cloth as the Nazi and Communist parties but look at the difference in outcomes.
One of the most peaceful insights I ever stumbled across was that of the people in the workplace who cared less than me, there were a significant and productive subset who were just doing more good than me through competence and being thoughtful about what work to pick up.
Consider a soup kitchen vs a supermarket checkout. The people working at the soup kitchen arguably care a lot more. The person at the supermarket checkout can be as glassy eyed as they feel and still be part of feeding more people in absolute terms.
Humans seem to have some sort of emotional heuristic to focus on care (really, focus on motivation of others I think). That works in small groups but it is highly misleading in large ones. In large groups, the only factors that matter are incentives and competence. If the incentives are good and the people are competent, good results will happen. If the reverse, corruption. The motivation heuristic actually does a lot of harm because it causes a huge amount of noise in the discourse where people whinge about this person or that having bad character to no avail. It is often true that people have impure motivations, but at scale that is true of effectively everyone. There are the devils you know and the devils waiting to become known. We can get great outcomes regardless; our politicians are cut from the same cloth as the Nazi and Communist parties but look at the difference in outcomes.
One of the most peaceful insights I ever stumbled across was that of the people in the workplace who cared less than me, there were a significant and productive subset who were just doing more good than me through competence and being thoughtful about what work to pick up.
I've been on large and small teams of people that cared and didn't care. It feels noble and reasonable and right to tie it to a greater purpose; like your soup kitchen vs supermarket example. It's not that type of care the OP is getting at.
It's closer to a craftmanship kind of care. Being proud of what you're putting into the world. Caring that it works well, not because the purpose is important, but because it's something you're doing and you want to do it well.
It's closer to a craftmanship kind of care. Being proud of what you're putting into the world. Caring that it works well, not because the purpose is important, but because it's something you're doing and you want to do it well.
If someone wants high personal standards then ok, that'll be good for them in the long term. But if we're talking about colleagues that care then that is just a cover for bad management. And fair enough bad management is endemic in the software industry so teams pick up the slack.
But it is management's job to decide on software quality standards and provide feedback to devs. Expecting the developers to be responsible for quality as a baseline is just a path to burnout for those devs; because then they are going to go mad because everyone on the team has different personal standards. The person with the highest standards on the team will never be satisfied.
You can't reasonably expect teammates to cover for bad managers, it is much cleverer to learn to identify good managers and try to work for them. Or become one.
But it is management's job to decide on software quality standards and provide feedback to devs. Expecting the developers to be responsible for quality as a baseline is just a path to burnout for those devs; because then they are going to go mad because everyone on the team has different personal standards. The person with the highest standards on the team will never be satisfied.
You can't reasonably expect teammates to cover for bad managers, it is much cleverer to learn to identify good managers and try to work for them. Or become one.
How would you describe the difference between thoughtful and caring?
Maybe I'd pick on an auditor as an example. They need to think about whether people are doing what they say they do. They don't need to care about what they are doing.
To me, caring means expecting work to be done to your standards instead of an independent standard.
To me, caring means expecting work to be done to your standards instead of an independent standard.
Web and modern tech can be fantastic if you take away the dark patterns. The UX for booking a flight isn't complex because reserving a seat or taking your card is difficult. It's complex because low margin businesses like airlines can make more money up-selling extra legroom or travel insurance.
Take away the dark patterns and incentive to eek every last dollar from the user and the entire web can be neal.fun.
Take away the dark patterns and incentive to eek every last dollar from the user and the entire web can be neal.fun.
Yes. It’s slightly amusing seeing hacker news bringing the magnifying glass trying to look for which JavaScript framework to blame when the boogeyman is standing right in front of them: it was meant to be this way, largely. It’s a pure function of the parameters given to the developers by their employers and clients. JS hell is just collateral damage.
I mean… try to turn off the adblocker for a bit. And don’t look at the address bar. Now this is hard: but pretend you can’t tell ads and clickbait apart from the content. Also, pretend you don’t know that websites are sandboxed and that they can helpfully warn you about “problems with your computer”. Now you’re somewhat close to the experience of an average user. This is the stage at which the dance between providers and consumers take place.
I mean… try to turn off the adblocker for a bit. And don’t look at the address bar. Now this is hard: but pretend you can’t tell ads and clickbait apart from the content. Also, pretend you don’t know that websites are sandboxed and that they can helpfully warn you about “problems with your computer”. Now you’re somewhat close to the experience of an average user. This is the stage at which the dance between providers and consumers take place.
Take away enough dark patterns and you eventually kill Capitalism. :)
I know you’re being mildly facetious, but profit doesn’t come from thin air (or does it?). If you spend $.30 to grow and ship bananas and charge $1, that $.70 difference is just a made up number by what you hope is a fair market. A dark pattern is just a way of maximizing that difference unethically.
I’ll ignore the clustering and trust structures that form naturally, but those are long-term dark patterns as well.
I’ll ignore the clustering and trust structures that form naturally, but those are long-term dark patterns as well.
> profit doesn’t come from thin air (or does it?)
It doesn't. Its supposed to come from your operating costs (cost of living + insurance costs). That is supposed to be where the prices come from, the problem is the insurance...if the cost of insurance approaches infinity due to infinite uncertainty, then "dark patterns" become "coping mechanisms". Not that I'm saying airline booking websites are in the moral right here, or anything - but someone thought they needed a raise, or to provide stock holders with a quarterly increase, because of rising cost(s) (or greed, but that's just another way insurance costs increase).
It doesn't. Its supposed to come from your operating costs (cost of living + insurance costs). That is supposed to be where the prices come from, the problem is the insurance...if the cost of insurance approaches infinity due to infinite uncertainty, then "dark patterns" become "coping mechanisms". Not that I'm saying airline booking websites are in the moral right here, or anything - but someone thought they needed a raise, or to provide stock holders with a quarterly increase, because of rising cost(s) (or greed, but that's just another way insurance costs increase).
> operating costs (cost of living + insurance costs). That is supposed to be where the prices come from
That isn’t the only way to set price.
Common methods are:
- Value-Based Pricing
- Cost-Plus Pricing (your example)
- Competitive Pricing
- Psychological Pricing
- Dynamic Pricing
- Bundle Pricing
- Promotional Pricing
That isn’t the only way to set price.
Common methods are:
- Value-Based Pricing
- Cost-Plus Pricing (your example)
- Competitive Pricing
- Psychological Pricing
- Dynamic Pricing
- Bundle Pricing
- Promotional Pricing
Shh you can't say that on Hacker News.
Not a fan of the ”I care therefore I get to throw tantrums” rhetoric. But yes, I also care and expect my colleagues to do so as well. But being mad doesn't strike me as a good way of facilitating change.
One successful formula I've found is to generate only positive or dilligent content but freely contribute and reply to any content. For example, I'd refrain from complaining on Mastodon about some app update being broken but I'd reply to relevant news posts with criticism if required.
This dichotomy allows to separate contribution and self expression more clearly for my own well being. I don't want to create more whining but if there's something already going on maybe there's something constructive I can add or empower a worthy voice.
This dichotomy allows to separate contribution and self expression more clearly for my own well being. I don't want to create more whining but if there's something already going on maybe there's something constructive I can add or empower a worthy voice.
I agree with the author, but they don't seem to get into what we can do to get it back to a more delightful experience.
I don't think the solution is to have more passionate builders in existing organizations that have overly short-term priorities (increase revenue this week vs. re-imagine a market).
I only see things changing through better competing products. Similar to how LLMs have enabled products that completely circumvent crap in search results (e.g. low quality listicles), we will see the same happen for most products and services.
Some products are going to be tough to displace, and it might take a new airplane startup that owns the entire ticket purchasing to inflight entertainment and last mile transportation (airport to destination) to show the world what an incredible flying experience could look like, that will force other airlines to at least try and catch up.
I hope more people with these sort of frustrations (which I share!) try to re-imagine experiences from the ground up and not shy away from tackling problems in big ways. We need more of it.
I don't think the solution is to have more passionate builders in existing organizations that have overly short-term priorities (increase revenue this week vs. re-imagine a market).
I only see things changing through better competing products. Similar to how LLMs have enabled products that completely circumvent crap in search results (e.g. low quality listicles), we will see the same happen for most products and services.
Some products are going to be tough to displace, and it might take a new airplane startup that owns the entire ticket purchasing to inflight entertainment and last mile transportation (airport to destination) to show the world what an incredible flying experience could look like, that will force other airlines to at least try and catch up.
I hope more people with these sort of frustrations (which I share!) try to re-imagine experiences from the ground up and not shy away from tackling problems in big ways. We need more of it.
Honestly urge most people, especially in tech to read something like Nonviolent Communication. There is a way to communicate your care that doesn't have you come off as an angry asshole. I'm guilty of it, I'm an asshole even when I don't mean to be and even when I mean to be I probably shouldn't. But everyone can do better.
This is everywhere, with everything. I watch a house inspector youtube channel, and there's a ton of horrible hacks and stuff that doesn't work in house construction. If you're not the person to invent a new technology to make it better, then it's better to just not complain publicly about it, because you're just adding to the noise.
> My father called me in exasperation last night after trying and failing to book a plane ticket
I've been going through really infuriating experiences with airlines' software too. Web apps, totems for luggage dispatching, everything. I know it's hard to pinpoint a single cause, but I believe that the current trend of overemphasizing aesthetics plays a major role on the current deplorable state of affairs: applications get too hard to design and build and at the end of the day there's simply not enough time to properly test things and fix its bugs.
I've been going through really infuriating experiences with airlines' software too. Web apps, totems for luggage dispatching, everything. I know it's hard to pinpoint a single cause, but I believe that the current trend of overemphasizing aesthetics plays a major role on the current deplorable state of affairs: applications get too hard to design and build and at the end of the day there's simply not enough time to properly test things and fix its bugs.
> And it would! If you would just let the browser do what it wants to do!
Ok, so it's an incentives/management problem. The people doing the work have no reason to care.
Also, I suspect some of it might be caused by misuse of frameworks.
Ok, so it's an incentives/management problem. The people doing the work have no reason to care.
Also, I suspect some of it might be caused by misuse of frameworks.
> My father called me in exasperation last night after trying and failing to book a plane ticket. I find myself having to go over to their house and do things like switch browsers, open private windows, occasionally even open up the Web Inspector to fiddle with the markup, and I hate every second of it.
What an unusual case! I have been booking plane tickets online for a very very long time and very often and I have never had to resort to these gymnastics.
What an unusual case! I have been booking plane tickets online for a very very long time and very often and I have never had to resort to these gymnastics.
> I feel like the web used to work better. Not in the sense of features or flagship sites—web-based email clients and word processors and image editors are all waaay better than they used to be and I would say the high-quality stuff is of higher quality than ever. I’m not pining for the HTML-only version of GMail, I promise. But if I were to estimate some rough median of “how well do websites work” I would also say that there’s an incredible amount of jank out there.
Nah. I remember that era. It all sucked, except Flash, which was the only way to have interactive sites that weren't awful. The main reason websites work even less well now is that they got rid of Flash so you have to use an informally-specified bug-ridden implementation of half of Flash instead.
> They expect the Back button to work, and they expect that the stuff they filled out on the previous page will be there when they click it. And it would! If you would just let the browser do what it wants to do!
That's a very recent change, and only after a literal decade of people using javascript to do this put enough pressure on browser makers to fix such basic functionality. I'm not sure it's even implemented in all common browsers yet.
> Every broken contact form or booking site is a truly spectacular own-goal. If your calendar was a bunch of progressively enhanced checkboxes and a submit button, you could be riding off into the sunset and counting money instead of taking support calls from frustrated octogenarians.
Nah. If you did that progressive enhancement nonsense it would take 3x as long and would still work less well. Frankly the biggest thing holding back the web is the opposite, people keep trying to use the broken and awful browser widgets and technologies instead of declaring bankruptcy and just rendering their system via one big canvas element like you would if you were writing a program in a real programming language. We've been trying progressive enhancement for 30 years and it still sucks; how bad does it have to get before we start trying something different?
Nah. I remember that era. It all sucked, except Flash, which was the only way to have interactive sites that weren't awful. The main reason websites work even less well now is that they got rid of Flash so you have to use an informally-specified bug-ridden implementation of half of Flash instead.
> They expect the Back button to work, and they expect that the stuff they filled out on the previous page will be there when they click it. And it would! If you would just let the browser do what it wants to do!
That's a very recent change, and only after a literal decade of people using javascript to do this put enough pressure on browser makers to fix such basic functionality. I'm not sure it's even implemented in all common browsers yet.
> Every broken contact form or booking site is a truly spectacular own-goal. If your calendar was a bunch of progressively enhanced checkboxes and a submit button, you could be riding off into the sunset and counting money instead of taking support calls from frustrated octogenarians.
Nah. If you did that progressive enhancement nonsense it would take 3x as long and would still work less well. Frankly the biggest thing holding back the web is the opposite, people keep trying to use the broken and awful browser widgets and technologies instead of declaring bankruptcy and just rendering their system via one big canvas element like you would if you were writing a program in a real programming language. We've been trying progressive enhancement for 30 years and it still sucks; how bad does it have to get before we start trying something different?
> and just rendering their system via one big canvas element
Interesting perspective, but I'm not sure if this would really solve the problem. You'd have to implement so much functionality that we take for granted (selecting text, copy & paste, accessibility, keyboard shortcuts, etc.). If you don't want to do it yourself, you have to use a widget library or some kind of UI kit. Maybe like Flutter. The web-version of a Flutter app renders everything to canvas (with a lot of caveats).
Since people bring their own UI libs for their JS-CSS-HTML web apps all the time, they will probably do the same with a pure canvas implementation and the result would be even shittier, because half of them will forget basic functionality.
Interesting perspective, but I'm not sure if this would really solve the problem. You'd have to implement so much functionality that we take for granted (selecting text, copy & paste, accessibility, keyboard shortcuts, etc.). If you don't want to do it yourself, you have to use a widget library or some kind of UI kit. Maybe like Flutter. The web-version of a Flutter app renders everything to canvas (with a lot of caveats).
Since people bring their own UI libs for their JS-CSS-HTML web apps all the time, they will probably do the same with a pure canvas implementation and the result would be even shittier, because half of them will forget basic functionality.
> You'd have to implement so much functionality that we take for granted (selecting text, copy & paste, accessibility, keyboard shortcuts, etc.). If you don't want to do it yourself, you have to use a widget library or some kind of UI kit. Maybe like Flutter. The web-version of a Flutter app renders everything to canvas (with a lot of caveats).
> Since people bring their own UI libs for their JS-CSS-HTML web apps all the time, they will probably do the same with a pure canvas implementation and the result would be even shittier, because half of them will forget basic functionality.
The thing is that it's much easier for a UI lib to fix missing functionality than a browser. And when the fix is ready, the webdev can bump the dependency and then it's fixed for all their users, rather than having to hope that it somehow makes it through their vendor's update process. So even if the UI libs are initially worse, I'd expect them to overtake the browser builtins pretty quickly.
> Since people bring their own UI libs for their JS-CSS-HTML web apps all the time, they will probably do the same with a pure canvas implementation and the result would be even shittier, because half of them will forget basic functionality.
The thing is that it's much easier for a UI lib to fix missing functionality than a browser. And when the fix is ready, the webdev can bump the dependency and then it's fixed for all their users, rather than having to hope that it somehow makes it through their vendor's update process. So even if the UI libs are initially worse, I'd expect them to overtake the browser builtins pretty quickly.
[deleted]
> everyone is doing their best given the conditions they’re in
Generous, but almost certainly untrue.
Generous, but almost certainly untrue.
Sure -- but lets be clear about what this is a function of; this is misplaced incentives.
There's nothing (yet) incentivizing a clean, efficient, pleasant web, owing to the fact that scale of the stuff the web connects to/makes available doesn't have any meaningful "competition" whatsoever.
There's nothing (yet) incentivizing a clean, efficient, pleasant web, owing to the fact that scale of the stuff the web connects to/makes available doesn't have any meaningful "competition" whatsoever.
Clean and efficient web (for consumers) isn't terribly profitable.
Craigslist could make a lot more money, especially in the short-term, with different design and monetization choices.
Craigslist could make a lot more money, especially in the short-term, with different design and monetization choices.
Ugh, did y'all downvoters get triggered when I said "no competition?"
Sorry, your downvotes don't make this not true.
Look, why does google no longer have the title of "simple, no frills search?"
It's very very difficult, pretty much impossible for any new competitor that provides a useful, good, quality web-related service, to not be crowded out by incumbents and anti-competitive behavior.
It's technically trivially easy to make a new/better Uber, Doordash, Google, whatever. But they're going to throw everything at you to make you not happen.
Sorry, your downvotes don't make this not true.
Look, why does google no longer have the title of "simple, no frills search?"
It's very very difficult, pretty much impossible for any new competitor that provides a useful, good, quality web-related service, to not be crowded out by incumbents and anti-competitive behavior.
It's technically trivially easy to make a new/better Uber, Doordash, Google, whatever. But they're going to throw everything at you to make you not happen.
> I’m not pining for the HTML-only version of GMail, I promise.
> If your calendar was a bunch of progressively enhanced checkboxes and a submit button, you could be riding off into the sunset and counting money instead of taking support calls from frustrated octogenarians.
> If your calendar was a bunch of progressively enhanced checkboxes and a submit button, you could be riding off into the sunset and counting money instead of taking support calls from frustrated octogenarians.
I get very mad at UX issues because I know how easy they are to avoid.
This is utter bullshit. Cgi forms have always been clunky AF.
The back button used to work? Come on! Websites used to tell you not to click the back button!
“Please do not refresh while we proceed with your payment”. Does that ring a bell?
Oh and do you remember when your credit card was voided every 6 months because some website kept your info in clear text?
You’d always have to update macromedia flash and Java for some reason. And then you’d see “this website is optimized for IE6”.
The back button used to work? Come on! Websites used to tell you not to click the back button!
“Please do not refresh while we proceed with your payment”. Does that ring a bell?
Oh and do you remember when your credit card was voided every 6 months because some website kept your info in clear text?
You’d always have to update macromedia flash and Java for some reason. And then you’d see “this website is optimized for IE6”.
There is probably a segment of devs who "care" but lack the perception to understand how what they are doing may be problematic or counter-productive. Software is complicated and it's hard to avoid all the pitfalls. Not everyone is a hacker-news 1%-er nerd. I have to practice empathy in this regard.
That said, I do get fatigued with the insufferable apps out in the wild :)
That said, I do get fatigued with the insufferable apps out in the wild :)
This is so spot on.
Everyone can see that today's UX experience is needlessly slow and buggy. I don't think that's a surprise to people who care about UX. And most people (your average joe) don't care about UX. This article is only being read by people who care about UX, and they already know how bad everything is. It reads just a bit like a rant and it's a bit like doomscrolling news. What would be interesting is a take on fixing this.
[deleted]
Structure determines behavior. If a technology structurally encourages shooting oneself in the foot, people will shoot themselves in the feet.
The author seems to be arguing the the core problem is behavior — if only developers would stop building flimsy things! But what about a structural view? Is there a certain structure that lends HTML, CSS, and JS to creating frustrating experiences?
The structural heart of this problem is so big it's hard to see — it's the ground we stand on. The designed-by-committee dissonance between "the Web should be a simple document engine" and "the Web should be a game-engine-like interactive graphical runtime" leaves us with a bloated tech stack that doesn't excel at either.
WebAssembly and WebGPU give us a way out. Fork HTML. Employ a better language for authoring documents; employ a better language for authoring apps & games. It is a matter of time.
The author seems to be arguing the the core problem is behavior — if only developers would stop building flimsy things! But what about a structural view? Is there a certain structure that lends HTML, CSS, and JS to creating frustrating experiences?
The structural heart of this problem is so big it's hard to see — it's the ground we stand on. The designed-by-committee dissonance between "the Web should be a simple document engine" and "the Web should be a game-engine-like interactive graphical runtime" leaves us with a bloated tech stack that doesn't excel at either.
WebAssembly and WebGPU give us a way out. Fork HTML. Employ a better language for authoring documents; employ a better language for authoring apps & games. It is a matter of time.
I think the fact that "structure determines behavior" is true is exactly what it is he is lamenting about. The fact that a tool enables you to shoot yourself in the foot is never an excuse to shoot yourself in the foot. Knowing how not to shoot yourself in the foot with a powerful tool is one thing that separates amateurs from professionals, and you get to be a professional by caring.
That is not to say that work shouldn't be done on making tools which require less cognitive load to use professionally, but until that happens I feel there are too many opinions blaming the tools instead of taking on the responsibility required to use them correctly.
That is not to say that work shouldn't be done on making tools which require less cognitive load to use professionally, but until that happens I feel there are too many opinions blaming the tools instead of taking on the responsibility required to use them correctly.
The problem is: you shouldn't have to be a professional to author Web software. Certainly I was not when I started tinkering with HTML & CSS in the 90s. The trend line is moving — in 10 years, it's likely that billions of people will be able to create apps & websites. Should we hold all of those billions to a high bar of professional diligence? Not practical.
If a four-way stop intersection were missing one of its stop signs, a diligent driver would infer the missing stop sign and pass cautiously. We all agree that drivers should be diligent. In aggregate, anthropologically speaking, there would be accidents at that intersection. Rather than "scream into the wind" at every passing driver, a systemic solution is necessary.
Not that I would call most people to action to create a solution themselves — this particular problem is hard tech and a tremendous amount of work — but I do challenge people to be open to a better future. With such future in mind, "screaming at passing cars" feels like a battle against the wrong enemy.
If a four-way stop intersection were missing one of its stop signs, a diligent driver would infer the missing stop sign and pass cautiously. We all agree that drivers should be diligent. In aggregate, anthropologically speaking, there would be accidents at that intersection. Rather than "scream into the wind" at every passing driver, a systemic solution is necessary.
Not that I would call most people to action to create a solution themselves — this particular problem is hard tech and a tremendous amount of work — but I do challenge people to be open to a better future. With such future in mind, "screaming at passing cars" feels like a battle against the wrong enemy.