Care
johan.hal.se
johan.hal.se
Right, because a description of the use of the response would constitute a DSL
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?
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
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>.
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.
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.
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...
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.
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.
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.
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 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.
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)
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.
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'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 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.
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.
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.
Enjoy your Lamborghini made of plastic with the app screen that nags you to renew the bundled satellite radio subscription! :D
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.
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 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.
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.
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.
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.
To me, caring means expecting work to be done to your standards instead of an independent standard.
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.
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 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.
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.
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.
Take away the dark patterns and incentive to eek every last dollar from the user and the entire web can be neal.fun.
I’ll ignore the clustering and trust structures that form naturally, but those are long-term dark patterns as well.
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).
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
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.
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 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'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.
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.
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.
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?
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.
> 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.
Generous, but almost certainly untrue.
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.
Craigslist could make a lot more money, especially in the short-term, with different design and monetization choices.
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.
> 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.
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”.
That said, I do get fatigued with the insufferable apps out in the wild :)
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.
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.
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.