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

> Well, bummer. I have a mature product using React Components which are now legacy. It looks like in the future, I'll slowly migrate these over to functional components, as is standard in the documentation.

The writing has been on the wall for 4 years that hooks are the future. You _can still_ use class components. Function component with hooks is the simplest API you can get to React itself—classes are more of an abstraction.

> I'm disappointed by the fanatical adoption of hooks, but I saw it coming and I can't say their legacy documentation didn't warn me.

We all adopted hooks because it makes things easier to reason about. If you’re still having trouble understanding them, I’d urge you to dig deeper into how they and React works.

> I might finally invest some time into what it looks like to create front ends independent of any of the existing frameworks that exist today, which I think is probably controversial, but I want the decisions I make to last longer than the whimsy of engineering teams who don't care that they might change their mind in 10 years.

I can’t think of a better way to develop an appreciation of UI frameworks that to go without.

> I want the decisions I make to last decades, not just a few years. I don't think that's a sentiment appreciated by most, though.

Barely any software runs untouched for decades (documents don’t count). So it’s not that the sentiment isn’t appreciated, I think most of us would agree—it’s that it’s an impractical expectation.



When you maintain your own software for periods of time that outlast front-end engineering trends or IC's entire career tracks, your opinions might change.

Plenty of software runs untouched for decades. A lot of it powers your interactions with people on HN right now, from drivers, to font rasterization and backing layer UI composition. There are bugs in codebases that have taken 20 years for people to even notice. It happens.

When people don't have to worry about trivial details, they can focus greater efforts.


At once I sympathize with your viewpoint and also have to say that React is the longest I've ever seen a Javascript thing stay in the notoriously fickle good graces of the frontend world – short of perhaps jQuery.

Railing against it is railing against the best-in-class example of what you want... even if it still falls short of what you want. A decade is nothing to sneeze at.


But it hasn't really lasted has it?

We've had React 1 (components) and now React 2 (hooks), they just managed the transition better than angular and so gobbled that market share.

jQuery stayed mostly stable, there was only one version that I can remember where it was a bit of a hassle to upgrade it. But it's quite a while ago now, so could be mis-remembering.


It has lasted as a project. Are you saying that no library should try to improve their performance, internals or API?

There was many versions of jQuery. I remember the days of hacking Drupal to load multiple versions because it shipped with an older version, but we needed a newer one for other dependencies.


Right, exactly. Had Angular.JS slowly implemented what is now just Angular, they wouldn't have displaced so many people so fast.

I think it still would have happened, but it's a shortsighted read into competitive analysis to not understand how this happened.


I’ve been around this space for over a decade. Software that’s easy to change, tends to outlive the rest.

React has more staying power than almost any other JS library I’ve seen. And they’ve maintained backwards compatibility on par with Windows.

The other day dang was mentioning how HN struggling under the popularity of the GPT4 thread[0]. But even then, surely HN has seen some code updates. If you look at HN as a product (and not a codebase), the unofficial/official algolia search engine is an addition.

What runs untouched for decades?

[0] https://news.ycombinator.com/item?id=35157344


And yet, I‘ve said no to projects that would‘ve earned me a nice sum because they were started at a nice pace with a dev that intended to build his own frontend framework, and it slowly grew into an eldritch horror.


I feel that. I have even done that myself.

Typically written by folks who aren't even aware of the problems they are trying to solve, no tests, and event and timer leaks.


I've got a multi-gigabyte folder of portable windows programs and utilities, where parts have been untouched for 15+ years. For the most part, everything still runs.

Winamp? Check.

Spacemonger? Check.

FLAC encoder? MP3 encoder? Notepad++? Savihost? TheGodfather? Flash Player? MS XML Notepad? ConEmu? Some really old build of CockroachDB? CPU-Z? Doom Builder 2? HexChat? Hell, even mIRC? Check check check check check checkity check.

None of those have been updated in years, many untouched (but not unused) since the day I installed them. This is why the web is so effing stupid. (And a hat tip towards Microsoft for keeping promises, unlike web developers)

And in many cases they STILL work better than the crappy little my-first-webapps that everyone uses instead nowadays.

Software is and should be eternal. It's these damn platforms that nobody wants to hold still with.


I used to use a few of those programs you mentioned. I moved on to other programs that solved my needs in better ways.

They could have stopped changing React. And people would have moved on to other things.


> They could have stopped changing React. And people would have moved on to other things.

God I wish!


I strongly disagree. It was way easier to reason about things pre hooks.


I think you’re probably referring to the lifecycle methods, which have relatively clear and unambiguous names in class components. The thing is, those names may make you feel comfortable that they do what their respective names imply, but in reality they’re an abstraction away from how React really works under the hood. Hooks, for better or worse, get you a little “closer to the metal,” so to speak.

Also custom hooks are vastly more readable IMHO than HOCs.




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

Search: