[dansiemens]

> I also really don't get the apparent hate for react, usually from people who haven't used it all that much

In defence of the haters, I think we’ve all seen our share of horrendously organized React SPAs. Dependency hell, (seemingly) infinite prop drilling, components thousands of lines long, the list goes on.

Some people think they hate React, when in reality they hate a specific implementation of it.

[lowercased]

I contracted on a few different projects over a few years, with React involved in all of them. Each team had their way of doing something, and goodness me... each team I joined was way different than the previous one with respect to approach, style, testing, etc. And anything I did that was "wrong" (meaning, not to their particular approach), I was ... belittled or talked down to as if I was some imbecile. In a couple cases, I used an approach with company B that they'd discarded a year before, but 6 months earlier, my work with company A's team led us down adopting that same approach, with decent results. But company B knew better, saying that approach was 'crap' (but... looking at their own internal docs, 2 years earlier, it was the hottest approach).

I was shocked at how much time some teams spent on reinventing wheels rather than using some off the shelf components. "We need everything to be done in house so we can document it and have full control". But... designing all your own widgets is going to take months. "React makes it easy though, so don't worry - we know what we're doing' Yet... they didn't - untestable components that couldn't support what the original requirements called for months earlier, etc.

You know how people crap on PHP because there's so much 'bad' PHP out there? But others say "it's just how you use it - frameworks XYZ are great!". I feel the same way about React. There's probably some great examples out there, but I somehow tend to see a lot of lesser quality stuff.

Most of the use cases I've seen up close... there wasn't any real magic or benefit to React vs something else, but everyone was jacked to get more React experience on their resume for their next gig. It didn't really matter if the resulting output was good or not, just that they used React.

I don't hate React - it's a library. I'm tired of much of the B-team players requiring it to be considered "professional" (while simultaneously) eschewing testing and documentation).

For people who have chosen it, and get to stay on the same project for several years, honing their skills on one codebase and iteratively improving, great. Enjoy.

[throwaway2k04]

I feel like the frontend community is suffering from the "eternal september" problem. Like PHP, it is very easy to get started so you get a lot of inexperienced developers writing very opinionated blogs that are shared with other inexperienced people who can't see the flaws. Interestingly it seems that the PHP community has matured and now consist of very reasonable and experienced "leaders", while the JS/TS community as a whole is still a long way from maturity. Don't get me wrong, there are many excellent JS/TS developers, but they face an endless stream of adversity.

In my previous startup the frontend developers decided to develop their own design library from scratch. My suggestion was to start with an established library and just adjust the style to match our look, but they wanted full control and ownership of the code. 3 years later, most of them left for new jobs and the library only contains a very basic set of components. Apparently accessibility and the rest of the "remaining 80%" part of the "80% completed" components were more difficult than they assumed. At least they had fun and could pad their resumes when they applied for new jobs, leaving others to maintain their m

This mindset was so different from the backend teams in the same startup. They preferred stable and known frameworks and libraries, and focused on the business logic. I had a feeling that the backend teams just got stuff down with little drama, while the frontend team was engaged in endless debates and rewrites. They had their own issues of course, but once they had fought the battle of choosing which language and stack to use, they stuck with it.

I worked with both and tried to stay away from most of the discussions, but it is clear to me that autonomy only works when you have a good balance of senior and junior developers that can have a discussion with the others without needing to "win" every time. As a senior developer myself, I have often learned new approaches from junior developers who have found a problem and dug in deep. Unfortunately I have seen too many senior developers and junior developers not listening to good advice from each other. The juniors think the seniors are outdated, while the seniors think the juniors are not capable.

[zenogantner]

Most of these sound like team/people problems, not technology problems.

Like most problems in IT in general :-)

[KronisLV]

> Most of these sound like team/people problems, not technology problems.

I wonder what are the frameworks or libraries that have exactly one widely accepted, idiomatic and correct way of doing most things, where the technology itself discourages anything else? Angular, maybe, at least with how batteries included it is?