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

61–70 of 237 posts

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

#61

Post by ehnto »

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…

To be fair to "the system", it was developed over decades, much of it before design was even a consideration, and almost all of it from a time when modern designs would have been a pipe dream on given device resources.

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

#62

Post by mattmanser »

soperj wrote: post #46
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.

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

You and the parent are totally missing the point.

Use the system tools. But make the look of the system tools customizable.

System tool. Customizable look.

That's what should be available. But even today you can't consistently change something as simple as a scroll bar or a checkbox.

Which, even worse, are by default styled differently on different browsers.

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

#63

Post by martpie »

tarboreus wrote: post #35
vbo wrote: post #32

Earlier quoted context omitted.

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.

While I understand the concern, I'm not really sure I buy the argument "JS makes accessibility bad".

It is for sure easier to do things wrong, but if you check at most of the major libraries for front-end (drag-and-drop, routing, dropdowns...), accessibility is built-in, and a critical selling point (e.g react-router, downshift...).

I think the proportion of front-end developers knowing about accessibility is just low, and the result is more visible for JS-heavy websites/webapps, but this is imho an education problem, not an ecosystem issue.

Having worked in agencies, accessibility was always treated as a second-class citizen (by clients or managers, not by developers, trying to push for it), and clients would often say "let's go live without it", then would come back to us asking to finish the job once they saw their competitors got sued for having an inaccessible website.

So JS may be a catalyst, but not the root of the problem. It's our job to push for the importance of it, as we pushed for responsive websites a while ago.

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

#64

Post by LarrySellers »

nullandvoid wrote: post #23
durnygbur wrote: post #3

Quoted post unavailable.

I'm sure you already know this (although I've had conversations with people that hate on TS in the past, that didn't, hence my post), but Typescript is JavaScript at runtime, there are no performance hits by using it in production (and negligible build times on save during development).

Shame it's so easy to get comments flagged and killed on HN. The parent comment wasn't inflammatory and (as we can see) contributed to relevant conversation.

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

#66

Post by [deleted] »

nullandvoid wrote: post #23
durnygbur wrote: post #3

Quoted post unavailable.

I'm sure you already know this (although I've had conversations with people that hate on TS in the past, that didn't, hence my post), but Typescript is JavaScript at runtime, there are no performance hits by using it in production (and negligible build times on save during development).

[deleted]

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

#67

Post by Spivak »

Shacklz wrote: post #51
jonahx wrote: post #49

Earlier quoted context omitted.

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

This is my approach. To me the ask for custom components from designers is extremely reasonable. The fact that it’s so hard to get all the edge cases right on the web is a failing of the tooling not the ask.

At some point we have to climb out of the trenches and introspect why the most treaded path in web design is the one with the rickety bridge and spike pits when we the software engineers are the ones who lay the bricks.

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

#68

Post by root_axis »

throw10920 wrote: post #20
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…

The author already addresses this in the article: > I think the Web is great, I think interactive dynamic stuff is great, and I think the progress we’ve made in the last decade is great. I also think it’s great that the Web is and always has been inherently customizable by users, and that I can use an extension that lets me decide ahead of time what an arbitrary site can run on my computer. > What’s less great is a t…

Doesn't seem to be a JS specific criticism, testing application performance on typical user hardware is a key responsibility of QA regardless of the language or platform.

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

#70

Post by Arthanos »

Surprised to see the top comments here so doom-and-gloom: "ah it was posted in 2016, I don't think anyone (but do wish) cares about limiting their JS usage anymore "

The tools we have available today to optimize JS and build for progressive enhancement are light years ahead of 2016 because the smartest minds in the industry have optimized for it. The rise of batteries-included server-side-rendered React apps like Remix and Next massively cut down on time-to-first-paint and React 18 makes it easier than ever to defer rendering of async or interactive portions of the page (e.g. the Like count, the reply form) in favor of getting static content on the screen as fast as possible.

Post reply on HN