Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Here we are in 2023 still battling with forms (see comments about datalist and color picker) and general UX for users entering data. It blows my mind. Why this isn't a solved space is beyond me.

It is. You throw it in React and get on with your life. It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives.



Uggh, as a full time React developer I cringe at the thought that React has actually solved anything. It has undoubtably advanced the front-end ecosystem considerably but by god does it feel like a brittle foundation in which to advance further. After 10 years it seems like the only things React really has going for it is that it does forms pretty well, that JSX is a great templating language, and that it is popular. I find myself on a daily basis wishing for more vanilla approaches to the problems React smoothes over.


> It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives.

This isn't some "bizarre fetish," it's an issue with implications from performance to code organization to legal compliance. (No, seriously -- Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.)

This is a core component of a lot of problems with modern webdev.

Framework fatigue? Yeah, because UI toolkits frequently reimplement basic structural elements, in their own specific dialects.

Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.

Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.

I'm not saying that it's without its own problems -- obviously different orgs will require different levels of support for older browsers, for one thing -- but there's a reasonable argument to be made that the current ecosystem overcomplicates this a lot, and that relative to using the platform, sometimes all the extraneous dependencies are the half-baked alternatives.


> Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.

Use of JavaScript has approximately zero correlation with website accessibility. If anything, sticking with a mainstream framework makes you more likely to meet accessibility requirements, not less.

> Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.

If your concern is dev time then third-party libs are a great thing, and trusting the library generally means less test burden than trying to figure out what each browser supports at the moment and whether that fits with your support matrix. If your concern is performance, you have to actually measure it - often JavaScript performs better than the native browser implementation of a feature.

> Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.

CSS selectors are far more messy than using a CSS class for every element. CSS is a tarpit where everything almost but not quite works, minimising your interaction with it is the only way to stay sane and keep your codebase maintainable.


Forms aren't even a react feature. They are part of some meta frameworks and there are hundreds of packages you can pick from... Doesn't sound like it was solved to me


JavaScript is the main attack vector on browsers. Why are you surprised that people don't want to run it?


JavaScript is the main way of delivering attacks because it's the main way of getting a browser to do anything. Actual vulnerabilities tend to be anywhere (image decoding in particular) and you can trigger them from anything, it's just easier to trigger them from JavaScript rather than some absurd spaghetti CSS.


As the OP says, many things can be done without it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: