Hacker News Reader

Comment by BilalBudhani | Hacker News Reader

I ditched React soon after they released hooks, mainly because I couldn't relate to the tradeoff React roadmap was taking from there. They went in a different direction from that point onwards, it seem like whatever code you write will become obsolete with the new set of best practices in the next release cycle.

More importantly, I realized React is trying to tame Facebook level of problems and hence their design decision steams from those data points. I develop small/medium type of frontend apps which doesn't need to apply solutions developed for such a scale.

These days I'm using Hotwire[1] (Turbo + Stimulus) with fair amount of vanilla javascript libraries in my apps. Occasionally, when I need to develop a reactive piece of UI I reach out for Svelte[2]

I'm quite happy after making the move. My apps complexity has reduced drastically and there is huge boost in my overall productivity.

[1] https://hotwired.dev

[2] https://svelte.dev

View on HN

Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things.

Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity"

Step 3: People start loving the new tool because it is so much easier to work with.

Step 4: People start to do things the tool wasn't designed to do. They start making "minor feature enhancements" to the tool so that it can fit more use cases.

Alternative Step 4: Tool becomes "industry standard" so everyone starts using it because it is "the right way", regardless of whether or not it is a good fit.

Step 5: The new tool becomes massive and bloated and overwhelmed with too many features, configurations, and options.

Step 6: Return to step 1.

> The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time. But it was a beginning.”

This tired argument has been trotted out repeatedly, and isn't really funny anymore. It's just old and boring.

For people like me who are new to JS and use these sorts of discussion to determine which technologies I should adopt first, it's really just pointless noise in the channel.

The little I know about JS so far, I definitely know this joke is tired and played out.

Step 2: Get a better joke please?

It's not a joke. It's reality. It gets mentioned repeatedly because of how true it is.

It's not a joke, it's intended to convey the wisdom of not thinking "the next big thing" will solve all your problems, it is intended to focus on the importance of fundamentals, and of relying on using engineering skill to solve problems rather than fancy gadgets, it is to point out the value of developing technical acumen rather than becoming a tool bound technician.

If you define yourself by the technology you work with you aren't an engineer you're a technician.

It is because its true and once you get through the endless cycles of your newly chosen framework you will adapt a similar mind.

this is how everything echos through time, no joke

adopt better methodologies, languages (TS, ReasonML, etc), find what works for you, automate the hard part, find reusable patterns, don't settle for the popular but mediocre new stuff (eg. React)

I understand your frustration, but I think you’re missing what is actually meant to be a helpful takeaway from this.

Essentially, all these frameworks ARE part of a cycle that repeat, and in time we all start to see it. Most of them just iterate on previous concepts, with some core concepts going way back to the late 60s, 70s and 80s.

What remains the same is the underlying Javascript language itself, and more importantly, fundamental software engineering and computer science principles.

Learn the fundamentals, and they will help you learn every new framework and language more easily, and in more depth.

If you really just want to get a job using JavaScript, then you might be best off browsing job postings to see what kinds of companies are hiring for which frameworks, and go from there.

But if your goal is literally to learn JS and find the right tech stack for you, unfortunately there is no replacement for learning the basics, and then picking a framework that looks interesting, and building something in it to see if it clicks with you.

> The new tool becomes massive and bloated and overwhelmed with too many features, configurations, and options.

It is almost as if people are not breaking their problems over the correct dimensions.

I don't agree with you.

I have been doing Rails development for past 10 years now and I never faced a dilemma where the framework took a direction which isn't aligned with its core vision.

I have been just trying to find a similar tool for frontend where I don't have to keep rewriting the entire codebase.

I think Rails was able to avoid this because of its modular structure and ease to write gems that extend the framework in a way that fits your project's circumstances and needed tradeoffs. As DHH famously said Rails is omakase, but you can also make reasonable substitutions.

It partly became modular because it merged with Merb, which was an alternative modular web framework that competed with Rails for a little while.

You are correct, Rails and Ruby are one of the few places I haven't felt like there's been constant and unedning churn, I attribute it to the incredible flexibility and power of the Ruby programming language, which incidentally is my favorite language to work in.

What about the webpack rails7 situation? I feel like rails has guessed wrong too many times about FE (coffeescript, asset pipeline, websockets) that I don't trust them to deliver their own stack.

I'm not sure this is a fair representation. Rails didn't "guess wrong" too many times. They chose the best option available at the time. Remember, CoffeeScript was used in Rails in 2010! Brendan Eich even borrowed many ideas from CoffeeScript in subsequent versions of JavaScript. Ditto, the asset pipeline solved a great number of problems for many years. With recent advances in web browsers, many of these problems aren't really problems, so it's less relevant, and Rails has to take advantage of import maps as an alternative.

This is kind of a great example because Django did the opposite: insist on having no frontend opinions.

As a result, Django left its users completely on their own, while Rails made choices that wouldn't last the test of time.

Given how chaotic the frontend ecosystems have been over the past decade, I'm not sure there was a "right" answer in hindsight.

I've never seen this before, but I'm stealing it!

Nah.. That's some Ba'alzamon stuff...

In case you don't know. This is a variation of the first paragraph of the Wheel of Time book series by Robert Jordan. Each book opens with a variation of this same paragraph

I’m well aware of the origins of the quote :)

Just wanted to make sure, it wasn't clear to me if you just liked their modifications or you weren't familiar with the quote at all :)

After a few trips around the wheel you'd think that people would realize "hey, we rewrote our entire react app, we were good little developers, we did the right thing,.. but that path led nowhere"

> I realized React is trying to tame Facebook level of problems and hence their design decision steams from those data points.

Strong agreement!

There's a saying in community organizing and activist circles that goes something like:

"Don't apply the solutions of the butterfly to the problems of the caterpillar."

Imho it's a really important consideration when thinking about scale of movements (and nonprofits... and any community initiative...). This is especially true when "professional" people are always coming in and confidently over-applying their learnings in corporations to thinking about activism (which often, though not always, has very different incentive structures and lifecycles).

I think about this parable often in regards how all these scaled tech companies end up stewarding the developer tools and therefore practices for everyone. And they tend to out-pace and out-broadcast other wonderful tools that could better serve the majority of developer niches.

I don't have a strong opinion either way but if you left React because you are frustrated with code becoming obsolete and picked up Hotwire, a significantly smaller framework, arnt you likely to run into the same problem if Hotwire doesnt end up being the next big framework?

In 5 years if no one else is using Hotwire then your code is obsolete, no?

I liked working in next.js in the past but my company was already talking about Nuxt.js when we hadnt even fully converted to next. Feels like jumping ships from a ship with some major flaws, but will continue to float for x+ years, onto a lifeboat that may or may not make it another 500 feet before sinking.

In 5 years if no one else is using Hotwire

I think that's the opposite of what he is saying. Because React is updated and changes frequently, your code becomes obsolete unless you update to follow the latest changes. In theory, if everyone abandoned Hotwire, your code would never be obsolete or need changes, because Hotwire would never change. In reality, as browsers and web standards change, frameworks need updating.

React doesn't change frequently though, that's the point. And it has always had excellent backwards compatibility. Class components are still fully supported, for example.

React changes best practices every few years prompting many rewrites.

One has to question the sanity of a rewrite launched for the sake of notional orthodoxy. If it ain't broke...

Right but you dont actually have to rewrite it, correct? The updates dont break the old code. It's just not best practice anymore.

React changing best practices every few years is a good thing! It means it keeps getting better.

That would be a bad thing if it meant that earlier best practices were no longer maintained. But that’s not true. Class components are still around. All official documentation continues to have class component examples and explanations (where it makes sense obviously…there isn’t any class component documentation under hooks, of course). And class components will likely still be around 5 years from now.

All the class components people wrote still work and can be maintained. React doesn't overhaul everything like Angular did. You can have function components with hooks and also have your old class components in the same app.

No ones learning class components for react anymore, and I'm not implying that class components are bad or ancient.

I liked classes to-- their lifecycle methods were so clear to work with.

That said, learning how useEffect replaces lifecycle methods is pretty quick to pickup. As is useState.

The lesser known hooks are what are difficult for me to understand. useRef is pretty clear. useMemo? I'm not quite sure what it's for, but I imagine it's not too tough to figure out if I spend a bit of time learning & experimenting with it.

So, although I liked the simplicity of class components, functional ones aren't too bad. They bring in some additional complications, but with a bit of effort it seems to all be learnable to me.

> when I need to develop a reactive piece of UI I reach out for Svelte

I never used Svelte, but I feel that "develop a reactive piece of UI" is basically Stimulus' job description. Can you explain a scenario/task where Stimulus does so poorly, that you flip the switch and use Svelte instead?

Stimulus was made by people who hate JavaScript and deliberately and pointlessly avoids JavaScript conventions. If you hate JS, you might like it, but I like JS, so I hate Stimulus. My preference is for Alpine.js, but Svelete is cool too.

Howard Lewis Ship kept changing the paradigm for Tapestry every major release or two. He could have had something to take the spot that Spring eventually filled, but these big gear shifts I think left people with a lot of rework and at some point it seems like porting your code to something more architecturally stable is a better bet.

It’s challenging though to keep supporting an API contract that you don’t believe in anymore. Or especially that you are causing you and others pain. I think sometimes maybe the thing to do is pass the baton and work on something else, but we also punish people for abandoning things. Like the author of Groovy, who hopped around from project to project and lost people.

I haven't got the ideas why many frontend jobs require experience in React whether it's for a new or existing projects, maybe I need enlightenment.

Probably because a large portion of their app is built in React?

Because HR (and IT strategy) nowadays is a farce, managers, decision-makers and the actual organizational units that do hiring rarely have the necessary systemic big-picture knowledge/information, foresight, experience, longitudinal thinking that would allow them to venture out of their preset suboptimal ways.

Are you suggesting that requiring React experience for a job where you will use React is not a reasonable ask?

It's usually perfectly reasonable, but not really optimal. In this job market requiring React seems worse than hiring someone that is a good frontend developer and has the wits and eagerness to pick up React and whatever tools the team uses, and the job requires.

This has the advantage that when - inevitably - tool1 gets deprecated and tool2 arrives you'll have someone that can adapt and learn, and likely you'll also have someone who can teach.

Talking with recruiters again and can agree.

The worst experience so far was for a general full stack role. They sent me a 3 page long PDF of job "requirements" which was a lot of fluff and implicit stuff. I get it... but I think that can be reserved for later. Not the best offer, seemed like they were disorganized in general, etc.

The best experience was for the best TC offer _and_ most relevant position for me... they sent over half a page that didn't waste a single character. Named a few frameworks but they had a crystal clear idea of what they needed. It was amazing, lol.

> I ditched React

Did you rewrite your entire app?

my front end is 50k loc, is that medium or small or what?

Amen

Reply on news.ycombinator.com