Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Care

johan.hal.se

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Care

#81

Post by shrimp_emoji »

BowBun wrote: post #78
ersamsa wrote: post #70

Earlier quoted context omitted.

„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

Re: Care

#82

Post by Zak »

_factor wrote: post #50
Zak wrote: post #45

Earlier quoted context omitted.

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

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?

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.

Re: Care

#83

Post by zackbrown »

placebo wrote: post #40
zackbrown wrote: post #31

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…

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 sho…

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.

Re: Care

#84

Post by tegiddrone »

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 :)

Re: Care

#85

Post by lmm »

WA wrote: post #60
lmm wrote: post #39

> 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 t…

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

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

Re: Care

#86

Post by lmm »

smaudet wrote: post #55
lmm wrote: post #38

Earlier quoted context omitted.

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

> 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 l…

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

Re: Care

#87

Post by smaudet »

lmm wrote: post #86
smaudet wrote: post #55

Earlier quoted context omitted.

> 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 l…

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

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

Re: Care

#88

Post by lmm »

smaudet wrote: post #87
lmm wrote: post #86

Earlier quoted context omitted.

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

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

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

Re: Care

#89

Post by smaudet »

lmm wrote: post #88
smaudet wrote: post #87

Earlier quoted context omitted.

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

> 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 doc…

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

Re: Care

#90

Post by lmm »

smaudet wrote: post #89
lmm wrote: post #88

Earlier quoted context omitted.

> 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 doc…

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

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

Post reply on HN