16
10Dev
3y

I’ve come to the conclusion that developers who like react have never used it for anything even remotely complicated.

Because here’s reacts dirty little secret; it doesn’t scale. Not even a little. It’s flexible, but that leads to every developer writing their code in a different way.

It’s simple and easy for simple side projects, but as soon as you have to pass state to a child component, you’re fucked. And god help you if you’re modifying the state in said child component. You can try using redux, but that’s a bandaid solution to the real issue.

There are better alternatives, namely Vue. There’s no need to write unintelligible code that’s a mutated hybrid of html css and js. We as web developers realized mixing these technologies was a bad idea a long time ago.

React simply doesn’t scale. It’s flexibility, complexity, and the awful code quality it leads to makes it a nightmare for large projects with multiple developers

Some of its concepts are interesting and useful though. It’s functional concepts allow for easy code reuse, among the other benefits associated with functional programming

I sincerely hope that the hype around react dies out, and a new framework emerges that takes the best from react and fixes the glaring issues it currently has

Comments
  • 5
    Sounds like a organization / people problem.
  • 0
    I use it all the time, and I wouldn't disagree with anything you said. State management is the fucker with any big app though - hooks make it a little easier to throw state around in React but fuck are they ugly, and Redux has never seemed like it isn't using a subterranean tunnel borer to crack a nut.
  • 10
    Doesn't all that basically describe JavaScript in general? 🤔
  • 1
    I use it with no particular concerns on some medium to large sized projects with really no major impact.

    Heck, for my previous company I developed an MVP of a mobile app using React Native. My experience with it was enjoyable and easy to adapt, change and scale to different needs. State management to me was naturally using something like Mobx. Maybe it is the idea of using declarative programming for ui interfaces, or maybe lack of resources provided to you. I have seen enough rants from you to know that you are not a mediocre dev, so I am just gauging this as "i legit don't like it" which it is always fine.

    But everyone's mileage with it will vary. I still, to this day do not get when people say that it does not scale. I have charts concerning the structure and general architecture of everything I build, even if I am using server side rendering which I normally do through a highly intricate ioc architecture with PHP and Twig. So I legit don't get when people say it does not scale.
  • 1
    @iiii I wouldn't say that, no. I would say that it describes all technology that we are not used to or have not yet had that AHA moment. I personally never had a massive breakdown on a JS application, probably because high level JS was not given or provided by me until I was at the most senior stages of development.

    I also happen to really, really fucking like JavaScript
  • 3
    Why is passing state to child component a big deal? You can pass it and just add a useEffect in child component with that prop.

    It scales really well, but depends on developers.
  • 0
    @AleCx04 would you choose JavaScript for a large scale project or switch to typescript?
  • 1
    I used react for some pretty large scale projects and I do not agree.

    I have tried vue and fail to see that it would be much better, but also its quite similar.

    But I have seen some ver bad state management also so I do understand that if you where in a project designed by someone that never really understood how to structure the code you will have a state hell to deal with.

    Using mobx or hooks you can get very clean solutions where moving whole sub trees of components around is a simple cut and paste with almost no worry at all.

    And sure, scale is relative, bu in my case it was a full page multi view process in a web application with massive amounts of ajax,and massive amount of data as state and for display and very dynamic content.

    I really do believe the real difference between vue and react id how good you understand the design philosophy of them.

    If you grok one but not the other you will feel its much better.

    I know enough vue to know I probably could do as good a job in both but I also knew that three years of react experience will take time to match in vue ;)

    But what I liked with vue was the no compilation, so for some hobby project where I just need some dynamic components in an simple page I have used vue since its easy to just drop in the script link, code, and run. No need to create a project or anything.
  • 0
    @iiii because I REALLY know Javascript. I have been writing server side JS since before Node was a thing (classic ASP flashbacks) and the "You don't know JS" book series served to re-afirm what I do know about the language.

    Even tho, I still use TS for projects, AND if given the chance Clojurescript. JS has an extremely powerful ecosystem which at the end of the day is all just Javascript. There is no two ways about it realy.
  • 1
    @AleCx04 honestly, I never could understand why some insist on using JavaScript as a server-side language, while there are a plethora of other better languages for the task (including Perl)
  • 1
    Angular and RXJS for the win!
  • 0
    The whole "centralised state" concept is royally fucked from the start. 99% of the time some state is only needed within a single component while it's active, but react devs love to stick their fat, greasy hooks into it instead of using events and services to pass only the relevant updates through the app when they happen. Then the whole app moans and twitches like some hentai girl being molested by countless slimy tentacles trying to reach their way to the core...
  • 1
    Every framework produces an undebuggable pile of trash if the developers are not skilled at using it.

    For me, using TS or any kind of typed-preprocessor is a must have.

    The Lead developers have to set up the application structure and not rely on every developer to make their own design decisions. This is true for every single application to be built.
  • 3
    Here’s another dirtier secret. There’s nothing wrong with React or JavaScript. You just need to write better scalable software.
  • 0
    @hitko I do not really understand your point.

    Hooks are designed to keep state as local as you need, preferably within one component.

    If you need more global state that is used by multiple components in different parts of the page you use context where a top component keeps the state and the components that needs it subscribe to the context so that no intermediate components need to know about the state.

    Or you add a state library like mobx but I find that hooks it enough.

    Just because some developers write bad code does not mean that the framework is bad, I have seen monstrosities in most frameworks ;). But I have also seen very clean code in otherwise ridiculed frameworks.

    Its all about knowing how to use the tools.
  • 0
    I wouldn’t say JS is not the issue here. When it comes to handling state and propagating changes, language level capabilities like value types and immutability are crucial. Writing safe and sane code with what JS offers becomes a huge PITA then. It’s not impossible but it requires a lot ceremony and caution.
  • 1
    @Lensflare I have not had so much problems but I tend to write quite functional code and avoid changing anything but local variables.

    That is sort of ceremony I guess ;) but not to hard to remember.
  • 1
    @iiii as long as there is a lot of objective bias in you in terms of language preference then I guess you have your answer. I don't neckbeard about languages and will use anything as long as I get paid.

    Even perl, which I also do like a lot. Javascript quirks are easy to detect.
  • 1
    @iiii perl's a nice flexible language.

    used it for a couple years straight modernizing old perl server code.

    But damn there were some serious performance issues with popular libraries like "moose" which greatly expands oop capabilities in perl. Had to settle for "moo" or something like that because the startup time with moose was java spring level awful and it wasnt even doing dependency injection
  • 2
    @AleCx04 yes,I will use any tool for job as well. Does not mean I have to like the tool or think it is the best tool
  • 0
    @iiii i feel you bro. Same way, i might not necessarily like the tooling, but i really do like money.
  • 0
    @AleCx04 is that you, Mr. Crabs? 🤔
  • 1
    Redux toolkit solved all of this for our team
Add Comment