Live data from Hacker News

Maybe we could tone down the JavaScript (2016)

eev.ee

41–50 of 237 posts

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

#41
post #4

I honestly thought this attitude had died out with everything being Vue and React and all that I used Huel's site earlier and it even had a splash overlay saying what it was loading, it was one reticulating splines away from being The Sims Edit: ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore

I care! As in the article - I really appreciate the benefits of JS when it's used in useful, tactful ways. But re-implementing a LINK, or a TEXTBOX, or a SCROLLBAR? That's super-duper irritating, and a horrible UX. I hate it. And I hate loading 1GB of JS just so websites can monitor what I'm doing and serve me targeted ads. It really sucks.

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

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

well it's historically been because 'extend the native widget' isn't possible with css. WebComponents change that a little bit with well-scoped css, but that's still a very javascripty solution.

Of course, I’m not at all advocating that the solution is to just do it but that web really hasn’t kept up with the needs of the kinda of apps people want to build with it. It’s easy to build something that works but annoying to impossible to build something robust so we’re left with every single website being functional enough to work but broken.

I don’t think telling developers “just do it right” is a scalable solution, the platform has to make the least effort path the one that works best.

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

#43
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?

How about rich text editors in webmail?

HTML mail is a mess that's impossible to get right; better to avoid it. Misleading users with a rich-text editor that looks like a word processor is bad because it'll pretty much never look as intended in anything but the same HTML editor that created it originally.

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

#44
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?

How about rich text editors in webmail?

Annoying when pasting formatted text. Annoying when you try to delete a newline but it deletes an inline image. Sometimes tricky to add unformatted text after a formatted section (the editor assumes I want to continue the formatted section).

Inline images and hyperlinks are neat though.

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

#45

It's not really JavaScript that's the problem but the way it's used, right? No one says JS has to be used for weird and creepy tracking purposes.

Correct. And the article doesn't say so either. It just says that using it in pointless, negative-value ways is bad - and there's all too much of that. If you need a link, use , for example, not a custom JS handler.

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

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

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.

Literally stepping off the shoulders of giants and wondering why you're less capable.

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

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

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.

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

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

yes, and no.

You could have used the same argument with flash. It looked and ran the same everywhere, offered features totally unavailable with HTML/CSS and Js.

The point being is that it might work fine on your machine, but its not fine for the rest of us. I am lucky that I have a 2013 retina with a GPU, but even still, there are more and more websites that are slow as shit, for no real reason.

when I'm out and about, small website mean faster loading. this means that more people can use them without tearing their hair out.

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

#49
post #14
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…

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.

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

#50
Now that it's 2021, most of the concessions the author makes are possible with CSS. You can change the styling of an element using hyperlinks with the `target` pseudo selector:

    
      #dropdown {
        display: none;
      }
      
      #dropdown:target {
        display: block;
      }
    
    Show dropdown
    
      Dropped down!
      Close
    
This works for dropdowns, tooltips, modals, even navigation if you're navigating to known places (or if you use JS to pre-insert the destination into the DOM). And of course, you can animate the changes with pure CSS.
Post reply on HN