Hacker News Reader

I have a less charitable view, when it comes to business. It's not about the misunderstanding of what the web is. It's about misalignment of values.

Most of website design today is not done with the interest of the user in mind, no matter what the popular UX posts will say. The companies only care about users insomuch as it leads them to closing a sale. Which means trying to give away as little value as possible for as much money as possible in return.

You can see it in contemporary design trends, and you can see it in the language used. Say, for example, "user engagement". Translated to plain English, it means making sure the user doesn't get what he came for too quickly. He'd then leave. You need to distract him with random stuff so that he stays "engaged" with your page.

Most of the JS on the web is either gratuitous or simply user-hostile. It hampers productivity, it destroys readability, and it does it on purpose.

And yeah, I'm fine with some of that; that's how dealing with businesses look like. I just wish people were honest about what they're doing. And then maybe little less user-hostile too.

I respect Do Not Track on my site. If you enable that the Mixpanel code will not be loaded. On the other hand, nearly all my network interactions are AJAX. I just tested it and you can't even login with NoScript running (because I hash your password client side before sending it). My site was actually pretty laughable without JS, I'll have to make something that warns people.

I'm a programmer though. When I wanted to build a site I threw in some basic HTML, grabbed a CSS framework, and then I wrote a ton of lines of JS. That's just how building webpages makes sense to me.

> warns people

That can be an acceptable solution (or at least a workaround). It is always important to provide usable error messages when writing software. It is reasonable for some things to not work without JS.

That's the whole point behind progressive enhancement, which is really just defensive programming. You never assume things worked, for the same reason you should always be checking return values for errors. How you respond to an error is something the programmer has to decide because sometimes you can simply continue without some feature, while other times making sure the user sees an error message is important.

> This point of view is based on a fundamental misunderstanding of what the web is. HTML is more concerned with semantic abstractions than the specifics of how a page renders (use a pdf if you want to control the layout). This was an important design choice because it recognizes that the client is responsible for the rendering, which is free to completely ignore the suggestions made by the page.

You are describing the web as it was 25 years ago. No modern browser works this way.

That's the fundamental misunderstanding I was talking about. You don't know what browser is being used. Ever. You only know what the user agent decided to describe itself as and the requests it made to your servers. None of that tells you anything about what happened on the remote computer.

Besides, "modern browser" is a complete undefined term that is obviously subject to a lot of interpretation and opinion. Usually this term is used as either a euphemism for "I really want to put spyware on my website" or "I only use badly-designed tools".

Are you including, for example, screen readers in that assessment? Because you’re wrong if you are.