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

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



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.


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.


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.


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.


> 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've never seen this before, but I'm stealing it!


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 :)


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


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


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"


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 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's not a joke. It's reality. It gets mentioned repeatedly because of how true it is.


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.


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


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)


this is how everything echos through time, no joke




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: