[aserafini]

Ironically the site itself breaks the 3rd listed law, Jakob's law that states "Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know." because it breaks the back button. When navigating to a law and then hitting back the site sends you to the top of the list again. -

[Lxr]

My vote for law 11 is “don’t use JavaScript unless it’s absolutely necessary”. That way the browser actually behaves the way you expect.

[metafunctor]

Maybe more like “use JavaScript to enhance the experience, not define it”. At least unless you're prepared to actually get it right, which still in 2018, seems to be tricky given the amount of weird sites like this.

This site breaks so many conventions of the web and normal navigation I don't even want to start listing them.

Bad SPA sites are the full page Flash sites of today.

[CaptSpify]

To me, JS is like salt: It can definitly make the experience better when used sparingly, but that doesnt mean I want my meal made out of it.

[rovek]

Seems a broad law considering

* Expectation is subjective and this forum are the minority

* History-jacking done badly is not a reason to throw out a technology

Random JavaScript hate is so last year

[reitanqild]

> Random JavaScript hate is so last year

It isn't random.

Firstly I think it is mostly directed at the abuse of JS that we see.

Secondly while there has always been good reasons to avoid running code in the browser unless there is a good reason.

This year added one more with the CPU level bugs that could be exploited through client side JS.

[reaperducer]

> there has always been good reasons to avoid running code in the browser unless there is a good reason

From what I hear from the junior devs, what they're teaching in school these days is that as much of the site as possible should be offloaded to the client device in order to free up server resources.

The mindset is that everyone in the world has unlimited massive bandwidth at all times, along with the latest gear; and if you don't, you're an "edge case" and should be ridiculed.

[Lxr]

Honestly, I believe the exact opposite is true. Why should you make your users and their batteries work harder to get what they want? Somebody comes to our website with a task in their head, and fundamentally our goal is to help them complete that task as quickly as possible. "Offload as much work to the client as possible" does not help our users complete their tasks faster. It makes life easier for dev teams by having servers that focus on APIs, reusing js code to create native apps, etc. But in the vast majority of cases it does not help the user, even if done perfectly. No, it's not faster because "no whole page reload" and yes, it does break expected browser behaviour unless you are extremely, unreasonably careful. The only exception is if you're building Google Maps or something extremely "appy" and need to have an alternative to the app store, for some reason.

[TeMPOraL]

I'm saddened by the possibility that this is what they teach juniors these days. This approach is, IMO, borderline unethical.

Offloading to the client device in order to free up server resources quite often means taking the load your server could handle once and multiplying it millionfold, once per each of your million visitors. In other words, your product just started to burn a million time more electricity than necessary. We should call it by its true name - externalizing costs - with all the negative baggage associated with that phrase.

[hexane360]

as much of the site as possible should be offloaded to the client device in order to ~~free up server resources~~ decrease latency.

Network is much slower than CPU. It's ironic you deride the assumption that everyone has unlimited bandwidth and then suggest that the solution is to send every user interaction through the network.

[iapx88]

> Random JavaScript hate is so last year

It may well be, and with good reason. However, I still encounter people who think that JavaScript is only used for things like onMouseOver and find it difficult to accept that actually, their favourite app or site is entirely powered by JavaScript.

[throwanem]

Part of that may result from the fact that, when it's done properly, the fact that it contravenes no expectations makes it easy to overlook. Like the first rule of systems administration - when you do your job right, nobody notices; it's only when you screw something up that anyone remembers you exist.

[paulryanrogers]

Using Noscript or an equivalent can be very enlightening. IME many major sites do work without JS. My guess is for accessibility.

[rovek]

That sounds like the vast majority of users expect more functionality from browsers than can be achieved without javascript. Do you think they would be willing to part with that functionality to achieve engineering perfection?

[iapx88]

> Do you think they would be willing to part with that functionality to achieve engineering perfection?

I think that the question would be entirely lost on most users. Perhaps there needs to be a push to educate on the benefits.

[alkonaut]

Also why use “sites” in the wording if the laws are about UX in general and not web app UX in particular? Why not say “applications”?