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

81–90 of 237 posts

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

#81

Post by pjc50 »

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…

The problem is, as always when talking about cross-platform development, is that you can have consistent widgets OR native widgets, because the native platforms have different look, feel, and interaction standards.

Would it be great if everyone on the frontend could get together and agree what the native-to-browser widgets should look like and how they might be customized? Yes. Would the three warring browser manufacturers change their platforms to make web development easier and lighter for everyone, at the cost of platform uniqueness? No.

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

#82

Post by root_axis »

bcrosby95 wrote: post #74
root_axis wrote: post #68

Earlier quoted context omitted.

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.

What is this QA you speak of? This is a really common problem in tech. Smaller companies adopt large company strategies that require more resources than the small company has to do correctly.

If the software development process lacks QA, performance is likely to be the least of their concerns.

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

#83

Post by throwaway19937 »

LarrySellers wrote: post #64
nullandvoid wrote: post #23

Earlier quoted context omitted.

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.

I flagged it because it's a Well, Actually (https://tirania.org/blog/archive/2011/Feb-17.html) that makes an unsupported claim.

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

#84

Post by hotz »

martpie wrote: post #63
tarboreus wrote: post #35

Earlier quoted context omitted.

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 lo…

I think sites that fail the accessibility test should be shamed into compliance. Possibly like how they handle sites that aren't https. I can just imagine how frustrating it must be to have an impairment that hinders usage of a website. Especially if it might be something essential.

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

#85

Post by timeon »

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?"

"a good rule of thumb to follow when designing your own controls:

Don't."

-- https://web.archive.org/web/20021009021738/http://www.iarchi...

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

#87

Post by duxup »

root_axis wrote: post #79

This blog loads 2mb of scripts, and if you disable JS you can't leave a comment or even read any comments. Personally, I don't have a problem with this, but I'd have expected a blog hosting an anti-js essay to be less dependent on JS. The author notes in the noscript block that using disqus is part of hosting a static blog, but that definition of "static" is an implementation detail - i.e. a convenience for the devel…

I feel like I sympathize with a lot of the various JavaScript rants in a way … but I’m not convinced that many of the blogs about it (that now feel like years old spam) are actually practicing what they preach or have ever waved the magic wand they want to exist.

I’ve yet to see a real guide from someone building an even moderately complex site and moving away from these terrible frameworks and “unnecessary JS”.

In the end most of these boil down to “I wish other people would build their sites the way I want them to” without much consideration of how / why a site is the way it is in the first place.

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

#88

Post by inasmuch »

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?"

As a product designer, I am and have long been looking for a company that will enable—hell, allow—me to design software that employs system standards. I can’t imagine I’m the only one.

Problem is, most leadership doesn’t care about usability unless it affects marketability, which is less and less likely as people (users) become more comfortable with and accustomed to hopping between needlessly proprietary workflows and abstraction of crucial processes.* Often (usually?) designers also don’t, to be sure, but those like myself who do care are, like devs, up against unreasonable speed demands and interruptions that make it difficult to do our best, most thoughtful work. And though it may seem like design is higher up the totem pole, perhaps because it’s usually upriver from dev, in my experience, most companies see designers as whiny graphics monkeys, just as they may see devs as whiny code monkeys.+

It’s significantly more difficult and time-consuming to design novel functions and flows that conform to or complement existing standards than it is to draft a new system that need only make internal sense and may wantonly disregard the environment around it. This is why people like Electron, right? This is why people liked the internal combustion engine.

* I’d like to see a study on how this kind of acontextualization of work tasks might exacerbate burnout.

+ How many companies are actually defined by great design these days (versus, say, great functionality)? Not even Apple seems to care about that anymore, as they seem eager outpace their software with their hardware, rather than creating any iconic or lasting designs. As “product design” has evolved to include software products, the discipline and its output have become just as mutable, and therefor disposable, and therefor ‘not worth’ the effort necessary to make good things, let alone great things.

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

#89

Post by tarboreus »

martpie wrote: post #63
tarboreus wrote: post #35

Earlier quoted context omitted.

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 lo…

The reality is that the education you're talking about is never going to happen. By the time you had 80% of devs knowing how to do a11y on JS framework #271, a whole new paradigm would have come in. It's because accessibility is not a priority that accessible defaults, which almost definitionally need to be system- or browser-based, are so important.

If you make a form with HTML and style it with CSS, then you're 85% of the way there with accessibility, and chances are it will be usable if you screw the rest up. With JS, even if you're working from a checklist, you're much more likely to get somethign wrong. And then there are regressions. I kind of believe that you know what you're doing, because the kinds of people that hang out on HN often do. But will your second-generation successor, four years from now, know how to update your work without breaking accessibility? Empirically, based on the low level of accessibility on the web (improving, but still pretty tough going), I'd say "no."

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

#90

Post by radicalbyte »

mattmanser wrote: post #62
soperj wrote: post #46

Earlier quoted context omitted.

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.

This was the entire selling point behind Windows Presentation Foundation:

https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio...

Post reply on HN