Hacker News new | ask | show | jobs
by nullpoint420 462 days ago
> mostly with web standards

IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great.

At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain.

Especially because we haven't finished any of these migrations:

* ExtJS -> JQuery

* JQuery -> React class components

* React class components -> MobX-observed components

* Observable MobX components -> functional React components with context

* Functional React Components with context -> React Router v6

* React Router v6 -> Remix w/ GraphQL federation

I understand my situation is unique - I'm just bitter from needing to know ~6 different frontend technologies at once. Let alone all the Not-Invented-Here-Syndrome abominations in our codebase.

3 comments

It's not that unique. The one enterprise app I worked on (that was started with Rails 1) had all of: Prototype, jQuery, Backbone, Angular, React, Handlebars AND mustache, vanilla CSS, SASS, CSS in JS (or whatever it's called). I wouldn't be surprised if they've introduced Tailwind at this point.
This is also a project started w/ Rails 1, so I feel our experiences may be similar.

To be fair to both code bases - it's very impressive that they're still running, right?

Definitely!

It actually wasn't even THAT bad considering how huge it is. People still complained (admittedly myself included), but it had been TDD'd from the start so had very good test coverage, at least. Also, some people who had worked on really massive Java applications called it "really good!" so it's all about perspective, I suppose :)

Remix already has data loading, why add GraphQL? It's a pain in the ass to work with from my brief experience.
That's my point exactly. I have the same questions from leadership.
your last note that adds not-invented-here abominations… if chasing endless frameworks of the month is bad, and building stuff in house is bad, then what do you propose to avoid making this mess?
I would propose that if you want to change frameworks, actually complete the migration from one technology to the other.

My problem is having all of them existing at once.

Skip a couple framework versions and indeed entire frameworks. Maybe go a couple years before you "upgrade" to something else. It is entirely possible you could go as much as 5 or 10 years on something. You'll still have to evaluate and potentially mitigate some CVE's. But that could actually be less work and less aggravating.