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

Maybe we could tone down the JavaScript (2016)

eev.ee

Post reply on HN
Print view View original

51–60 of 237 posts

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

#51

Post by Shacklz »

jonahx wrote: post #49
Spivak wrote: post #14

Earlier quoted context omitted.

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…

Not a downvoter but... > Pontificating about how they should just change their notion of right misses it completely. The ask isn't to change their notion of right, but to understand that (yes, sadly) there is a tradeoff between "usable but ugly system components" and "pretty but janky" bespoke components, and they're making the wrong choice.

> they're making the wrong choice.

If what feels like the vast majority of them are making the same "wrong" choice, we should probably think about ways to make that choice more "right", because clearly, the current approach isn't working

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

#52

Post by Spivak »

coffeefirst wrote: post #38
Spivak wrote: post #14

Earlier quoted context omitted.

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.

We’re saying the same thing. The web right now today requires that you reimplement all that functionality from scratch when it should be just inheriting all the behavior from the native control in your custom thing and tweaking the styles or adding some additional functionality.

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

#53

Post by scelerat »

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…

It's not just appearance but also behavior. There are differences across browsers, OSes, and devices in how UI widgets work and inevitably the "custom" approach is a compromise in favor of the PM's personal workstation.

And lest it be overlooked, the appearance of those widgets themselves, is a feature. They are easily identifiable by users of that platform as being something they can interact with and expect a predictable set of outcomes.

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

#54

Post by eitland »

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…

Good points.

I'm still not convinced it is worth everything we lost:

- Instant loading

- Sane page sizes

- Cross browser compatibility by default, including text based browsers

- Every page is reasonably safe by default

- CPU is idle after initial page load

- Battery life is great by default

and probably a few more.

I guess a good middle road might exist but I wonder if the current situation doesn't mostly serve ad pushers and bored developers ;-)

Edits: yes, a number to clarify my points and to make it clear that I am open to change my views, at least slightly.

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

#55

Post by durnygbur »

jenscow wrote: post #39
newshorts wrote: post #24

Earlier quoted context omitted.

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.

But they how how to connect the Angular injector into the service directive.

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

#56

Post by Nextgrid »

Spivak wrote: post #47
Nextgrid wrote: post #40

Earlier quoted context omitted.

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.

We’re saying the same thing. The web’s current tools requires devs to reimplement all that functionality from scratch, which isn’t gonna happen, when the ideal solution would be to start with the battle tested native control and then tweak from there to fit the design.

My point is that by tweaking the looks of the existing thing you are breaking standards users are used to or might be causing issues you're not even aware of (bad color choices for colorblind people for example) even if the behavior/functionality of the control is unchanged.

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

#57

Post by ryandrake »

Spivak wrote: post #47
Nextgrid wrote: post #40

Earlier quoted context omitted.

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.

We’re saying the same thing. The web’s current tools requires devs to reimplement all that functionality from scratch, which isn’t gonna happen, when the ideal solution would be to start with the battle tested native control and then tweak from there to fit the design.

But, once you tweak it, it is no longer the same "battle tested" thing. Even little tweaks. App developers should do themselves a favor and just stick to the standard controls that have decades, maybe centuries of tester-time working out the kinks and edge cases. A medium-size company's UX expert's "restyling tweaks" are unlikely to make the control better.

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

#58

Post by easrng »

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…

Modals can be done with CSS pretty easily (with either :checked and a label to activate the modal or :target and a link to activate it or with details/summary etc.), so can form validation (the required and pattern attributes), and lazy loading (add the loading="lazy" attribute for images and iframes). Infinite scroll can't really be implemented easily but in theory it's possible with server support (I'll make a demo and get back to you).

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

#59

Post by eitland »

jakub_g wrote: post #33
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?

Side note: basic autocomplete can be done fully without JS using https://blog.teamtreehouse.com/creating-autocomplete-dropdow...

Emphasis on basic I think: once you go past what could easily be done earlier you still have to use JS to configure a datasource to load from?
Post reply on HN