jQuery has become obsolete these days because the problems it solves have largely been solved by additions to JS, but the interactivity of websites has continued to increase and browsers have yet to catch up to that. Frameworks like React actively fight against the browser rather than work with it by maintaining its own DOM state and constantly creating copies of state for every re-render of a component, along with a bunch of other magic. That's a lot of unnecessary loopholes just to make up for JS's lack of features when it comes to writing reactive UI.

I am genuinely afraid for the future of CSS as it is becoming increasingly more complex, meanwhile most people haven't been able to properly utilize or understand it for the last decade even without all of that additional complexity.

> Engineering is the practice of using natural science, mathematics, and the engineering design process to solve technical problems, increase efficiency and productivity, and improve systems.

We don't increase efficiency or improve systems, we just build garbage on top of garbage. Imagine if a structural engineer did the same and built new floors on top of shaky floors. Our buildings would be collapsing on a daily basis.

Maybe I'm just at the wrong place at the wrong time, but as a software engineer I don't feel like I'm doing any actual engineering and solving meaningful problems, just spaghetti gluing random frameworks, packages and services together. The only problems I get to solve are those caused by the quirks of all these incompatible things being forced to work together. It's draining.

It's a blessing and a curse. Look at package managers, they more or less all do the same thing, with one primary job of "go download some binary so I can run it", yet there's so many to choose from. Every time you read some Linux guide they have to list 7 different ways of installing the same package. It's stupid, probably even more so for the maintainers of those packages because they have to distribute their package 7 different ways. At least I'm glad systemd has mostly become the standard, so you don't have to also see 7 different ways of creating a service.

On a similar note, this is also why I highly dislike struct tags. They're string magic that should be used sparingly, yet we've integrated them into data parsing, validation, type definitions and who knows what else just to avoid a bit of verbosity.

It goes over more advanced gotchas and tips in detail such as flex-basis, auto margins, min-width, etc.

> Also, anecdotally, I’ve never had a sonicare toothbrush battery die. They still last weeks after many many years of use.

Sure, these exist too, though it doesn't reflect the majority of items which cheap out on all components, including batteries.

Because almost none of the electronics you buy come with a replaceable battery, the second you buy something and use it on a regular basis it's destined to die and be thrown out within the next 4-8ish years due to the battery degrading and becoming increasingly more dangerous to keep around. Something that might be in perfect working condition and could be used for another 10 years has to be thrown out because of one single component.

I understand that batteries come in all shapes, sizes, capacities, yada yada, but imagine if we had standard rechargeable batteries like we have standard non-rechargeable batteries and things were built in a way where you could easily replace batteries like we could on phones a decade ago. You would double or triple the lifespan of a ton of things.

And what used to be relatively simple static layouts designed for a 4:3 screen are now layouts that must accommodate a screen of any arbitrary aspect ratio and physical size. This means that most of your components will now have at least 2 layout states, one for desktop and one for mobile, usually horizontal and vertical respectively, accomplished by switching random layout related properties on and off. Arguably anything related to CSS layout comes with a ton of quirks and flex/grid are no exception. It's those quirks that put most people off CSS, because they're sometimes far from intuitive, hard to debug, and are just things you have to know.

Comments URL: https://news.ycombinator.com/item?id=40954255

Points: 9

# Comments: 18

"that's it" does not paint the full picture. Yes, UI = function(state) is very convenient but the way React implements it inverts the problem. Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.

This is actually something I hate about multiplayer games with matchmaking nowadays. I made the majority of my childhood friends only because we stayed on the same server and played together for hours on end. I don't think it's a stretch to say that a key reason for why we play multiplayer rather than single player games is to socialize. This has become increasingly more difficult when you just get a new set of people every 10-30 minutes.

I now leave a bunch of TODOs in my code as a reminder to myself that yes, this isn't the best it can be, I'll come back and make it better when it becomes a bottleneck, but for the time being 80% of something is better than 100% of nothing. This way I'm able to move on and continue doing meaningful work rather than wasting time obsessing over minute details that almost nobody else would care about.