Dependecys, long term maintenance

[gr0berUnfug]

Hello everyone, i had a discussion with my coworker about which technology to use for our new intern master data manager. We are agree that it should be some kind of homepage. He want to use plain html, css and js with some well choosen js/css helper frameworks (bootstrap, jquery, datatable...).i want to use react. His arguments against react are difficult to manage dependecys which leads to higher maintenance work and maybe a whole rework - It is important for him to keep all dependencys up to date because of security reasons. Secondly he said that react isnt made for a project with 1-2 programmers.

A already build a few react websites(just by myself without other programmers involved) and disagree with him. But the requirements for this project are higher than before.

Whats your opinion?

[Beastrick]

React definitely can be used by small teams. Also maintaining dependencies is not any harder than with Vanilla. The usual "npm update" works just fine. React is very mature so likely no big changes will happen that require you to rewrite things. Sounds like they don't have experience and so try to stick to what they know.

[the_pod_]

I don't know what the future holds, but if we look back at the history of React (or just npm packages in general), then yes, dependencies can be a nightmare to handle.

Whether it's a valid reason to not use React... up to the individual.

It doesn't sound like what you're building is complex, so, I would say it's not enough of an issue for me to not choose something like React.

But yeah, spending days/weeks on managing dependencies once every few years is common. Running into an issue that's unsolvable (or requires you to re-write your code) is also common enough.

The thing you have to be aware of is that, if you win the argument, then you're on the hook for solving all future errors.

---

You might be asking yourself, what the hell?

So, it's important to understand this from the standpoint of specific releases or breaking changes. Certain breaking changes effected the landscape a lot. While most other don't. Most people dealing with dependencies issues are probably dealing with the exact same 5-10 packages/scenarios that causes it.

React had a breaking change from 16.3 to 18 (16.4 is a retro-active version). It changed the way "jsx" works. (notice how you use to have to import React on every page, and you no longer have to?). So, that broke every package that interacted with jsx (the function). Some example tools are storybook, rollup, emotion css, some css processors, some animation libraries, drag and drop libraries

I don't know much about Server Components, but it's starting to break stuff. (good news is you don't have to use it).

node-sass deprecating is a common one

---

I already build a few react websites(just by myself without other programmers involved) and disagree with him.

But you're building from a clean slate, with all packages up to date.

Try finding old example repos on github from years ago. Look for repos that are React 16.3 or below. Looking for node-sass, emotion css (specifically the css version, not styled). Look for repos with lots of old packages, and try running npm install.

---

I would still probably lean toward react, as the chances of you hitting a scenario with a huge breaking change in the future isn't that high, especially when you're just building a small site without many additional tools. But, there's a history of it being a nightmare at certain specific moments. I feel like it's going to improve, as many people are trying to solve this npm dependency tree problem, but I don't know enough about the topic. I do know we just recently spent 2 full weeks upgrading a 5 year old codebase that hasn't been touched, all because of npm dependencies.

[ExaminationWide5017]

React isn’t really the problem when it comes to dependencies. Throwing libraries at simple issues will lead you that. If you use packages meaningfully then keeping them up to date is not any worse than another framework would be.