3 ms·

> If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, eve

> If you have a simple website built on boring technologies like HTML, CSS, and vanilla JS, then nearly anyone can read, understand, and make changes to it, even backend developers Ehhhh, or it could be a pile of shit and be unmaintainable. The upside of the ubiquity of react is that once you learn it well, dropping into a react based project is much simpler. How simple of a website are you talking about? Something so simple not to need a framework could also be equally simple in React, maybe more so because of the ecosystem, dev tools, testing, etc.

umvi 4y ago
To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with some extra features we wanted. Swagger UI 3.0+ was completely rewritten in React, and I had a super hard time navigating the new source code and trying to figure out how to achieve the same basic things I did with 2.0 with some minor JS tweaks. I'm sure if I invested a few days/weeks becoming a React expert I would be able to do it. But I wasn't willing to do that, so as a result, we are still on Swagger UI 2.0. Judge for yourself: Swagger UI 2.0: https://github.com/swagger-api/swagger-ui/tree/2.x https://github.com/swagger-api/swagger-ui/tree/2.x vs Swagger UI 4.0 https://github.com/swagger-api/swagger-ui https://github.com/swagger-api/swagger-ui
- schwartzworld 4y ago
  I finally got to look at the source code. There's a lot going on, and it's pretty well organized into components and small files. The worst thing is the flat file structure. Diving into a React codebase definitely requires some process and familiarity with dev tools, common patterns and React in general, but the upside is that the process is repeatable. Doesn't do you a lot of good for diving into a random codebase, but as a pro React dev, I can hit the ground running much faster than with a project of similar complexity.

umvi 4y ago

To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with some extra features we wanted. Swagger UI 3.0+ was completely rewritten in React, and I had a super hard time navigating the new source code and trying to figure out how to achieve the same basic things I did with 2.0 with some minor JS tweaks. I'm sure if I invested a few days/weeks becoming a React expert I would be able to do it. But I wasn't willing to do that, so as a result, we are still on Swagger UI 2.0. Judge for yourself: Swagger UI 2.0: https://github.com/swagger-api/swagger-ui/tree/2.x https://github.com/swagger-api/swagger-ui/tree/2.x vs Swagger UI 4.0 https://github.com/swagger-api/swagger-ui https://github.com/swagger-api/swagger-ui

schwartzworld 4y ago
I finally got to look at the source code. There's a lot going on, and it's pretty well organized into components and small files. The worst thing is the flat file structure. Diving into a React codebase definitely requires some process and familiarity with dev tools, common patterns and React in general, but the upside is that the process is repeatable. Doesn't do you a lot of good for diving into a random codebase, but as a pro React dev, I can hit the ground running much faster than with a project of similar complexity.