My experience with React has not been good. A gullible manager bought into "react everywhere" hype, flew in consultants for training and then proceeded to have a dozen pages on the website written in React. It's important to note that all but one was either completely static or a simple form with less than 5 fields.
This project did not go well. It took months to develop, has 0 test coverage, numerous bugs and doesn't work on edge or IE and isn't rendered on the server so it's a bad experience.
Everyone on the team was either fired or quit less than 6 months after it launched.
After evaluating the level of effort it would take to get the code base in a maintainable state, it was decided to migrate it over to a more traditional stack (plain js, static html, html forms) and that was completed in less than 2 weeks. Customer metrics across the board also improved.
The lesson here is to use the appropriate technology for the appropriate problem. Unless your application is very complex, requires real-time updates and you can afford the extra maintenance costs -- react is probably the wrong choice.
Don't mean to be rude, and it certainly seems like React was overkill for your project, but 6 months to generate a react site like you're describing seems like the problem might not have been react. Maybe it was engineering, or maybe it was management, but cranking out a react app that's "completely static or a simple form with less than 5 fields" is something one developer should be able to do in a day or two after reading a basic react tutorial (assuming there are design guidelines)...
Which is not to say I'm not sympathetic to bandwagoning having a negative impact on engineering teams. Just that in this case, I find it hard to believe that react specifically was the problem.
> cranking out a react app that's "completely static or a simple form with less than 5 fields" is something one developer should be able to do in a day or two after reading a basic react tutorial
I've only done very basic web development during my career, and absolutely no javascript. But, I've been learning React for a week or so and that's something I could do in a few minutes. 6 months is insane, hyperbolic, and probably untrue.
Yeah, or something other than react is seriously screwed up. I said a couple of days just to have time to do styling (assuming design is already done.)
> Everyone on the team was either fired or quit less than 6 months after it launched.
If that team took 6 months to develop such a simple site with a framework that basically does everything for you, I'd fire them all, too. I guarantee the problem was not with the framework.
Certainly from your story it sounds like you had a bad experience, but it seems to be in the "had a bad experience with a hammer, terrible for hammering in screws" type of experience.
I generally do what I can to avoid software snobbery, but it's examples like those that really cause me to scratch my head and exclaim "Why?"
React makes sense when you actually have a DOM to deal with, but as soon as you start trying to write something that goes beyond that model, well, I really don't get you. ("you" being rhetorical)
Generally, though, I think a lot of junior programmers or those new to React get very enthusiastic about it and try to solve whatever problem they can with a tool that works well for them, and that does speak quite a bit to how good React is. In general, I would avoid using React for things it was not designed for.
> It took months to develop, has 0 test coverage, numerous bugs and doesn't work on edge or IE and isn't rendered on the server
This has nothing to do with React and everything to do with implementation. It does not take months to develop a dozen pages in React. React makes test coverage easier to write, works cross platform and supports server side rendering.
While I agree that using React everywhere is a dumb choice, so is ruling out a technology because your company implemented it horribly.
I've see this go down before. React was the wrong choice but I'd put the blame right at the feet of the consulting firm. Let me guess, the budget was under $5M but the firm was one of the large ones probably being used elsewhere in the company right? I work for a very very large consulting firm, anything under $30M is not worth getting out of bed for them. Projects like this get staffed by nobodies and run by nobodies, unless you have a PM and one dev who actually care they will always go down in flames.
It reflects poorly on us that this is being downvoted. The parent shared a simple cautionary tale without baiting or flaming or anything like that. It is a good thing, to be aware of the worst case scenario; IME, projects that fail badly do so mainly for people-reasons / org-reasons, just like this.
It doesn't reflect poorly on anybody beyond said company that took six months to build a <form> with five <input>s which was clearly blighted by major issues regardless of which technology they chose for their <form>.
What's interesting is that, despite regurgitating the writing on the wall, OP still blames a JavaScript framework.
This project did not go well. It took months to develop, has 0 test coverage, numerous bugs and doesn't work on edge or IE and isn't rendered on the server so it's a bad experience.
Everyone on the team was either fired or quit less than 6 months after it launched.
After evaluating the level of effort it would take to get the code base in a maintainable state, it was decided to migrate it over to a more traditional stack (plain js, static html, html forms) and that was completed in less than 2 weeks. Customer metrics across the board also improved.
The lesson here is to use the appropriate technology for the appropriate problem. Unless your application is very complex, requires real-time updates and you can afford the extra maintenance costs -- react is probably the wrong choice.