Comment by marcus_holmes | Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

> These InteractionHandlers are just objects satisfying a specific TypeScript interface. They’re not coupled to React or hooks or anything like that, which feels quite freeing, honestly. There’s no worrying about stale closures or dependencies or hooks rules - it really is just TypeScript.

This is a great example of "fighting the framework". React + SVG got them from nothing to a working product. But then they had to rewrite completely to solve problems in the product because the framework no longer fit the product. I've seen this so many times.

But it's hard for people to believe when they start out and choose the "perfect" framework for their product:

"you will eventually have to rewrite your entire product because that's easier than fighting the framework to make it do what you need"

"no, we won't, this $framework is flexible enough to do whatever we need"

"OK, good luck"

2 years later:

"we're rewriting the product completely because $framework wouldn't let us do $thing"

Not that I'm advocating for not using frameworks, just for people to realise that eventually (almost) everyone fights the framework and rewrites. And the more the framework does, the earlier the fight begins.

I've also seen the other side where the argument is:

"we should be doing things correctly from the start"

2 years later:

"the maintenance of custom doesn't deliver business value and makes recruitment and on-boarding increasingly difficult. We should rewrite in $framework since it's well known, maintained and flexible enough to do whatever they need"

...

There have been a few occasions where this has led to (literally) years of extra maintenance work for me, as I patiently wait for a team of devs to replace my custom app with v2 using $wellKnownFramework. Sometimes that v2 is eventually abandoned and I'm contracted to build v3.

Also seen this where the $wellKnownFramework is dumped before v2 is completed, and the whole thing is rewritten in $newHotFramework for no other reason than the dev team wanted to work in $newHotFramework.

There are lots of anti-patterns around this ;)

This in a nutshell is why Visual Basic 6 eventually failed. It worked for your use case until it didn't. And of course a programmer could dive into COM and ActiveX to extend it, but avoiding that mess was why people chose VB6 to begin with.

I feel the same way about WordPress. If you stick to it's sweet-spot as a solution, it's ... good enough and cheap. But too many folks have this hammer called WordPress and see a world full of nails.

It's almost like there's no silver bullet, and neither management nor engineering are capable of sticking to one set of trade-offs. Instead, the product thrashes back and forth while trying to accommodate whatever the current feature demands happen to be, with no one applying enough higher order thinking to see that there is no end-state that satisfies everything. Just endless busy work, a few more paychecks, and actual value down the drain.

I would agree with you if it was t for the fact that we’ve seen a big increase in the number of complex maps being made since the change.

You give people a more powerful product and they’ll use the power.

Glad to hear it's working out! Hope it continues to prove to be an exception to the rule, then.

Anecdotal counter-argument from applying frameworks successfully over decades: the framework is there to help us get up and running .. we get up and running .. we build out the weaker parts of the ship while we're sailing, only when the work in framework no longer applies .. the app grows .. the user base grows .. the framework grows ..

> the framework grows ..

I've seen too many teams fight Rails (in particular) to implement new product features to agree with this. The framework never grows, it stays the same size and eventually becomes a straitjacket for the product.

Like I said, though, this isn't a reason to not use a framework at the start. As long as everyone realises that at some point it'll need to be rewritten.

Well, thats the case where too much responsibility is being off-loaded onto the framework providers and someone hasn't quite grok'ed TANSTAAFL. I never use a Framework I won't feel comfortable modifying ..

It's unfortunate that coevolution like this usually lands in a very suboptimal start. If we tore it all down and started from what we knew we'd have much better things. Occasionally stuff like that happens, but it's really hard to fight against the momentum of decades of shit

Or, your stuck doing version upgrades of the framework before even getting to the fight.

>And the more the framework does, the earlier the fight begins.

assuming that the more the framework does also means the less the framework allows you to do yourself. which is a pretty reasonable assumption of course.

Reply on news.ycombinator.com