[MzHN]

> As far as I know, there’s no way to set a dynamic width for an HTML input with pure CSS (please lmk if that’s not the case). Setting max-content doesn’t work, for example, because inputs are replaced elements that have intrinsic dimensions and behaviors that are not fully governed by CSS.

This is the case currently, but when field-sizing: content; lands, you can do it with a single property.

Also I get a weird feeling when something like React makes simple things hard and low performance. The solution of pouring a lot of time into debugging and optimizing (in context of React) feels even weirder to me. Sure, you might not need React here, but what if you do? What's the next best solution? Integrate the React "frame" with an "island" of vanilla?

I don't know, something about having this issue puts me off in a major way.

[jokethrowaway]

I did a small project recently (a form to edit N instances of an object, each containing N instances of other objects, so standard input, add / delete buttons, saving to server) and I decided to not use React or any form of templating, just DOM. It reminded me of when I used to ship jQuery projects.

It was refreshingly simple and, despite being more verbose, it was clear what everything would happen once a certain event would happen. With a bit of clever refactoring dealing with elements factories wasn't too bad, even without a templating engine.

Not having to think "How is this going to be rendered by React, is it going to be efficient or trash performance" was great and I think it's intrinsic of picking a certain abstraction and we'll always have that.

Sure, the better the abstraction the less this problem happens eg. Solid is calling the component function once, which makes things easy to reason about

[petemilly]

Oh cool, I didn't know about field-sizing. Thanks.

And yeah, this definitely set off my alarm bells like "maybe I shouldn't be using React here." I guess the initial goal was just getting something that works out there using the thing I know best (React), and the second phase could be a rewrite using a better tool for the job-open to any thoughts and suggestions on that.

[MzHN]

I'm in the same boat with vanilla instead. I start with no dependencies and add some vanilla compatible libraries when needed. But when project size grows the friction makes me less motivated to continue. That's just what I know best and where I'm most comfortable since I control everything.

Unfortunately I don't have more specific suggestions, but just in case the verbosity of vanilla is a turn-off, I will namedrop Bliss.js.

[petemilly]

Oh nice, I hadn't heard of Bliss.js, but the creator (https://lea.verou.me/) is great.