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.”

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.

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!

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

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?

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

Did you rewrite your entire app?