Maybe we could tone down the JavaScript (2016) • Hacker News Board

Re: Maybe we could tone down the JavaScript (2016)

#31

Post by MaxBarraclough » Mon, Dec 27, 2021, 5:53 PM UTC

eitland wrote: post #21

vbo wrote: post #17

I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll…

> but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?

How about rich text editors in webmail?

Re: Maybe we could tone down the JavaScript (2016)

#32

Post by vbo » Mon, Dec 27, 2021, 5:56 PM UTC

eitland wrote: post #21

vbo wrote: post #17

I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll…

> but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?

Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as well as server side, of course) and getting instant feedback. Modals. Having slower things being loaded after the intial page load resulting in the page loading faster (moreso with session info being loaded less often in SPAs). Infinite scroll for search pages (not the Instagram variety). Basically all "modern" web UI.

Re: Maybe we could tone down the JavaScript (2016)

#33

Post by jakub_g » Mon, Dec 27, 2021, 5:56 PM UTC

eitland wrote: post #21

vbo wrote: post #17

I know this is likely to be controversial, but JS improves the user experience a lot, both in terms of interaction and speed, as well as making development more manageable (if used correctly), alas at the expense of annoying purists who would prefer to enagage in all sorts of CSS/HTML gymnastics just to avoid using JS (and other kinds that would prefer vanilla JS to frameworks). Do that in a large project and you'll…

> but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?

Side note: basic autocomplete can be done fully without JS using

https://blog.teamtreehouse.com/creating-autocomplete-dropdow...

Re: Maybe we could tone down the JavaScript (2016)

#34

Post by Rd6n6 » Mon, Dec 27, 2021, 5:59 PM UTC

Off topic, but eev.ve has some outstanding articles on game design and is the author of one of my favourite custom doom levels

Specifically, the articles of how graphical fidelity is ruining video games and the ones about doom and doom mapping

Re: Maybe we could tone down the JavaScript (2016)

#35

Post by tarboreus » Mon, Dec 27, 2021, 6:02 PM UTC

vbo wrote: post #32

eitland wrote: post #21

Earlier quoted context omitted.

> but JS improves the user experience a lot, both in terms of interaction and speed, Except for autocomplete, do you have any examples where user experience is increased a lot?

Since you mention autocomplete, dealing with forms is a lot better from both a development perspective and UX, ie complex forms being validated client side (as well as server side, of course) and getting instant feedback. Modals. Having slower things being loaded after the intial page load resulting in the page loading faster (moreso with session info being loaded less often in SPAs). Infinite scroll for search pages…

Maybe it's a niche perspective, but as a blind person the obsession with JS forms is what makes the web borderline unusable for us. While it's not impossible to make an accessible experience with JS, people mess it up so often that it may as well be.

I honestly think the problem with JS reimplementations is that develoeprs assume that they are their audience, or that people like them are the only people that matter.

Re: Maybe we could tone down the JavaScript (2016)

#36

Post by exdsq » Mon, Dec 27, 2021, 6:02 PM UTC

newshorts wrote: post #24

durnygbur wrote: post #3

Quoted post unavailable.

Vanilla JS is more rare these days. I interview 2-3 devs per week and always ask basic vanilla JS questions since it’s vital for our workflow that you don’t rely on frameworks we may or may not be using. Knowing react/vue is a bonus, but knowing how to do basic tasks like adding event listeners and manipulating the DOM in vanilla JS is required. It’s anecdotal but I just wanted to say there are a few places that stil…

Not going to lie, I’d need to googled that nowadays if I wanted to do those things! Issue with polyglot development. Can’t you ask more fundamental questions like when to use an event listener instead, or best practices?

Re: Maybe we could tone down the JavaScript (2016)

#37

Post by bee_rider » Mon, Dec 27, 2021, 6:04 PM UTC

corobo wrote: post #11

alphabet9000 wrote: post #9

Earlier quoted context omitted.

i care, plenty of other people care.

Well then I dunno where they hang out cause it doesn't appear to be on HN anymore

Huh, I'd given up on disabling JS because reddit required it to reply to posts, and I'd assumed HN does too. Turns out HN doesn't. Thanks for providing the impetus to check (I'd expected to say something like "well the site doesn't work without JS, so I guess they didn't stick around" but wanted to check first), I deleted my reddit account a while ago and it turns out that was the only thing keeping me tied to JS.

I really am not a fan of JS for all of the reasons that have been retread a million times over the years, but honestly the war is long lost and I don't really see the need to annoy people about it anymore.

Re: Maybe we could tone down the JavaScript (2016)

#38

Post by coffeefirst » Mon, Dec 27, 2021, 6:05 PM UTC

Spivak wrote: post #14

scelerat wrote: post #7

It's been thus, nigh on two decades now. Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"

I mean the product manager isn’t wrong, there is no good reason we shouldn’t be able to make custom components with the behavior of “native” widgets. The fact that the dev story is “build a widget from scratch out of divs” and not “extend the fully functional component with new styling and hooks and slight behavior modifications.” We created this problem ourselves by not having the tools to meet designer needs while…

No, it’s because it’s stupid difficult to replicate the native functionality exactly, retain accessibility traits, and if you get it perfect, then you have to deal with the fact that different browsers and devices interpret these controls totally differently.

Re: Maybe we could tone down the JavaScript (2016)

#39

Post by jenscow » Mon, Dec 27, 2021, 6:05 PM UTC

newshorts wrote: post #24

durnygbur wrote: post #3

Quoted post unavailable.

Vanilla JS is more rare these days. I interview 2-3 devs per week and always ask basic vanilla JS questions since it’s vital for our workflow that you don’t rely on frameworks we may or may not be using. Knowing react/vue is a bonus, but knowing how to do basic tasks like adding event listeners and manipulating the DOM in vanilla JS is required. It’s anecdotal but I just wanted to say there are a few places that stil…

And this is why we need technical tests during interviews. There are people who call themselves "web developers", apparently been writing websites for 5+ years, but don't know about addEventListener.

Re: Maybe we could tone down the JavaScript (2016)

#40

Post by Nextgrid » Mon, Dec 27, 2021, 6:05 PM UTC

Spivak wrote: post #14

scelerat wrote: post #7

It's been thus, nigh on two decades now. Product Designer: "No system controls; we want our users to have the Full Brand Experience, therefore, custom controls." Also Product Designer: "Why don't our custom controls work as well as system controls?"

I mean the product manager isn’t wrong, there is no good reason we shouldn’t be able to make custom components with the behavior of “native” widgets. The fact that the dev story is “build a widget from scratch out of divs” and not “extend the fully functional component with new styling and hooks and slight behavior modifications.” We created this problem ourselves by not having the tools to meet designer needs while…

Lack of technical solutions isn't the only issue. System controls (well most of them - recent Windows and macOS seem to be regressing) have decades of refinement and battle-testing behind them and users are familiar with them. You're not replicating all of this alone regardless of how much money or years of experience you have.