Ahahahahahaha At least it’s entertaining. But yeah this is why you need a cap on standup meeting time. Worst thing is when they have teams of 10 with 4 non-devs on the team, standup becomes hell
That's why front-end needs to be designed, planned and standardized (set the guidelines) by Engineers specialized in this field. We are no longer in the 2000s. This is not a React problem. It's a problem of software development factories.
Semi-disagree and semi-agree, it's not going to be standardized. all the user frontends, web suffers the most (except the game UI that is so consistent that also requires user to have specific device otherwise they're f**k), are currently facing the same issues. The requirement from users are so dynamic, so random and so subtle that even you can have user group A and user group B have opposite and conflict interests, every single frontend tools/standard can't satisfy all. It's not a technical issue. It's a human issue. All the established "standard" requires you to train people to have that habit, and can be quickly wiped out when the new trend or device hits. Then all of your technical standard optimized for that particular behavior will be completely useless. All of our mature standardized design for backend works because it's for developers, and developers adjust their frontend for the backend standard. Where the same thing can't happen on the human side, human wouldn't adjust for you, you have to adjust for them, otherwise your product will die, hence Frontend is always dumpster fire.
it's not technically hard, it's just human is so random, just like you at certain point you want to call customer service, no matter how "good" the current automate system (react/angular) is.
@@doc8527 You have a point, maybe I didn't use the right word. Rather it would be something like "Generate the initial guidelines, the conventions". Anyway, A good front-end engineer will take into account the points you indicate.
@@yojou3695, it's not. I have the same problems with Vue and Svelte. Requirements from users and businesses can be different. Only one redesign is enough to make your team suffer when almost half of your logic now works completely different
The guy is right. Many companies hire tons of react developers for cheap and think that they can create more because of all those developers, while all they do is turn any high quality code that the company might have had, to shit and then they leave so that guys like this author can come to fix the shit. It's bad management by non engineers that don't understand how software development works.
Many people in leadership think that hiring more devs will make it easier to develop apps, when in reality, it’s actually doing the opposite, 9/10 times in my experience.
This is why opinionated frameworks like Rails, Django, Ember.js are so much nicer to work with. 95% of projects fundamentally follow the same patterns. Why should you reinvent the wheel every time when years of experience and research has established a particular way that scales well?
Because something like Rails invented a structure in 2004, which based on nothing, and never rethink it. Most Rails-like frameworks are not even modular monoliths. Its just big ball of mud. All controllers in one directory? Really?
React has had a problem with creating a "pit of success" since hooks. By far most react devs I've met don't use dependency arrays correctly. The eslint plugin is usually not installed when I inherit a project and empty dependency arrays are flagrantly abused to achieve componentDidMount. While the hooks model is worlds apart from lifecycle hooks in terms of the granularity of reactivity you can achieve, the setup can be taxing. Also, the move away from using useEffect for data fetching with no clear non-library way to achieve it was kind of rough. I'd bet most React apps use useEffect with an incorrectly empty dependency array for data fetching. When the library lends itself to doing the wrong thing, there's a design problem. With the move to server side React, the setup has become simpler for those that use it. But when you really don't need SSR you're pretty much on your own. The React docs push server side React pretty heavily. But regarding the video, I think most medium to large code bases are shit. Partially due to time pressure, partly due to new-shiny-object syndrome and of course good old laziness.
IMHO, The problem is not that react sucks, it's that it requires so much framework knowledge to be good at it. As a developer I just want to write code and let the framework do the heavy lifting, but when using react it's like you constantly need to think about performance and what hook is appropriate to use. It's really easy to fuck things up in React in comparison to other frameworks.
I see this perspective a lot from developers with strictly OOP backgrounds. It's hard for them to get into the functional mindset. I think that's why Angular has remained so popular in Enterprise environments, as a lot of the developers have a background in Java/C#. I think most would benefit from reading a few books on functional/declarative programming.
Yeah, React is more associated with functional programming and was initially written in Standard ML, so it's true that using an OOP approach to react is causing many of these issues. I think most controversy and confusion around React stems from attempting to view React through the lens of the MVC paradigm, which is deeply ingrained in many developers due to its prevalence in university and traditional web development. React, however, was mostly inspired by XHP, a server component-oriented framework used at Facebook as an alternative to MVC. This fundamental difference in approach has led to many misunderstandings and controversies, such as the initial backlash against JSX for seemingly violating "separation of concerns". In reality, React's primary concern is the component itself. Many developers struggle to adapt to this component-based mindset, often trying to force React into an MVC context, which is like trying to fit a square peg into a round hole.
a few thoughts as a senior engineer who has also worked at "6-7" companies working with react, including as a contractor and as a FTE. 1) the author isn't comparing "class component react" with modern react, they're comparing angularJS with react. Theo is kind of setting up a straw man here by taking class component react and using that as the comparison point against modern react and saying "This is so much better!" Yes, modern react may be better than class component react, but there is a case for both of them being worse than angularJS (by which I assume the poster means angular 1). 2) there is a key difference between "this is technically better" and "this leads to better outcomes". I also think there is a significant issue with saying "engineers bad" as a way to hand-wave mistakes made with a framework. software engineering has been around a fairly long time now, the tools we use to produce high level code should make it easier to produce good code, not harder. react makes it harder. a lot of the stuff that react ultimately accomplishes isn't that complicated. updating some html on a web page usually isn't a hard problem - overengineering is rampant in the web dev space. from my perspective, react introduces too many imperfect and overly complex abstractions - aka footguns - relative to the utility it provides. 3) we need to get better at listening when people offer critical perspectives about the web dev ecosystem. half the battle is understanding the right problems to solve. we spend so much time solving the wrong problems. hand-waving things or dismissing thoughtful critiques should be a last resort, not a quick-draw pistol. I don't disagree that developers can be bad or trying to fit a square peg into a round hole, but you are way too quick to jump to that conclusion and dismiss a critical perspective. at the end of the day, the sum of average developer experiences is what defines the utility of the tool, and investing effort into improving the lower end of that average is how things get better for everyone.
"updating some html on a web page usually isn't a hard problem" is only true on a small scale. I work at a massive company in a 14 year old, behemoth of a codebase written by c# devs in vanilla js using oop principles, being able to use document.querySelector is not as fun as you think.
For personal projects I find using something like HTMX and web components is good enough. Even for complicated pages with a lot of interaction. I think something like React and Angular might shine on complicated pages with lots of devs. But a lot of times, maybe we just need to take a step back and think, "Is there a simpler way we can build this page?" The HTMX-like pages I build are offline first PWAs. Easy peasy and not complicated at all with web componenets and HTMX-like lib.
React provides fantastic abstractions. Rooted in maths even. Love them. What makes programming complicated is side-effects, and your average frontend is just a massive ball of them. UI is all about wrangling side effects by definition really. And programmers suck at dealing with side-effects which is why every frontend codebase is horrible. That's my take on the issue.. React is not a part of the problem and it really does a lot of things right imo. It gives you standardized and flexible ways for handling side effects and moves presentation away from them. The dev hypecycle is all about realizing that some established practice is wrong and then doing the extreme opposite until the community comes to the conclusion that the initial solution wasn't so bad after all (monolith v. microservice, BDUF v. XP, GraphQL, DevOps. The js trend atm is going for big everything-frameworks like next/astro, but the pendulum will swing in the other direction in a few years.). React hit that abstraction sweet spot in the middle pretty well from the get go which is why it has become a mainstay. Never do I want to go back to the days of jQuery plugins and manipulating the DOM by hand. That being said I'm sure HTMX has it's niche.
@@Schindlabua Most web pages aren't that complicated. React encourages developers to make the pages more complicated than they really need to be. If you push your state to the back end as much as possible and then on the front end you keep your state to only local state then developing web pages becomes really simple. When state is very localized then you really don't need a framework like React. Having said that. I do agree that sometimes your front end is truly complicated with a lot of interconnecting state and something like React might be useful. But most websites aren't like that.
@@dovh49 But localized state and basic websites are also easy in React so I personally don't feel the need to switch. I agree that we moved too much into the frontend in recent years but also writing razor pages and codeigniter SUCKED and sending JSON to the frontend was so much easier. "Pushing stuff to the backend" is the design space the react meta-frameworks are exploring at the moment and I have mixed feelings currently since a lot of stuff feels needlessly complicated but the community will get there I'm sure. Maybe there is a future in vanilla web components and signals and some effects library and then HTMX and serverside react if you really feel like it. (that would be the pendulum swinging in the other direction). But truth be told I'm not that bleeding edge anymore and when the big players tell me to change my stack I'll do so :p
This is not a shot against theo, but the fact that the useEffect at 26:40 has a bug, while ranting about the ease of use of useEffect compared to class components was so funny really shows you that nobody is good enough to use useEffect first try
@@ShivGamer The useEffect is dependant on fullName, which as you can see is calculated on every render, and because the comparison is based on reference not value the useEffect will run on every single render regardless of whether fullName actually changed. The correct way would be to change the dependency array to [firstName, lastName]
The useEffect is fine. Not all values in JS are compared by reference. React uses Object.is in the background(IIRC). This is what mdn has to say about comparing two strings: > Two values are the same if one of the following holds: > both strings of the same length with the same characters in the same order So this effect will only rerun if the resulting string is different. Though this is still possibly the wrong use of useEffect. It will run on mount, which might not be what's needed. It should happen in the setter, but at that point the last of the advantages over class components disappear 😂
Started web development in vue, spent couple of years with it, switched to react for couple of years and then again switched to vue. And all I can say....i am not going back to react ever again. I won't explain my self in depth. I think it's meaningless. Take it for a spin and under 15 minutes and I bet you will feel like either Vue has some hidden flaw (like bad perf or doesn't scale) or you were totally misguided.
I have a similar story too, started with react it is not bad but when I needed SSR I started working with next and hated it, it just forces you to write your code in their way (vercel's way) like I could not implement proper Authentication using standalone express API without using the "useAuth" or whatever it was called because in starting in next 13, they removed the ability to read the cookies in server side except in "server action" which is useless for me. long story short, by the first 30 mins reading vue docs I already felt it is way better, like way more better than react (talking about vue 3 here with the scipt setup composition API), and it got even better when I started working with nuxt. I never seeing myself working with react / next again except in a job or legacy code. finishing of with a question I ask my self every day, why people still choose (react / next) over (vue / nuxt) every day?, am I missing something?
I like Vue better as well. I feel it strikes a better balance of solving everything with JS vs staying true to how the web standards are conceptualized in terms of separation of concerns. I will say though that it does suffer a bit from its open sources nature, there's a larger community with a larger pool of libraries and tools that go along with React/Next that there is for Vue/Nuxt which may or may not make your life harder while debugging or trying to use third party tools depending on what you're trying to do.
I wouldnt really blame average react-developers for being "shit" or "stupid" when React team has a hands-off approach to architectural patterns. Codebases dont turn shit (necessarily) because of incompetency but rather because there's no source of truth in regards to best practices... Even the useEffect article you link is an anecdotal opinion on architecture and not official documents. If the react guys would just grow a spine and make some opinions about their framework, youd see codebase quality sky rocket
I would. When the framework does not impose an architecture on you, it's not a sign that you don't need one. It's a sign that you're free to choose one of your own. You gotta organize though.
@@MadsterV right, but then people shouldn't be surprised when there's suddenly 1000s of differentl architectures... It's a problem for older projects because usually the original architect is no longer on the project, leaving it to new developers, with their own opinions on architecture, to expand the project. *That's* why react feels like it's not scalable
As a newbie I began to understand learning MERN I really was not learning HOW to code using React. Your right I started learning ELM it's heaven. Also Go is great too
@@Joshua.Developer Haven't tried Elm yet. Syntax always scared me away :D For me the best framework for front-end is SvelteKit. It was hands down the easiest to work with and very flexible in ways you can extend it. It feels close to vanilla JS.
Basically he's saying that OP sees a lot of bad code and that it isn't representative of what React can do. Just because you're allowed to write bad code doesn't make it bad
@@BryanLu0 Thats not even the argument, the argument is that React encourages bad code. There are other languages/frameworks that put up much better guide rails for inexperienced developers while maintaining the flexibility required for advanced developers. Theos counter argument was literally just bring in a React PhD - that's what the OP is complaining about
@@PlebsSauce No, React does not "encourage bad code." What are some of those other frameworks, and why would frameworks need to cater to "inexperienced developers"? And yes, if you're going to use React, learn about best practices first. The issues with contexes and hooks are day 1 type of problems.
@@PlebsSauce Um, that's not what OP wrote. People frequently misuse features. I guess you can say that misuse of features should cause errors, but I don't think you should cause errors for optimization problems. Actually OP's biggest issue is everything shoved inside render()
The fact that useEffect runs on on change AND ON FIRST RENDER, seems to confuse Theo. It is actually quite strange to hear somebody, constantly praising React for just doing what you expect, while at the same time writing a useEffect that will spam full name change in Posthog every time somebody opens the app.
I don't understand why someone would log from useEffect and not in backend. Not related to what you are saying, just in general what would be the case to do this?
Theo's point about useEffect is valid, despite the potential misuse of PostHog in this context. The useEffect hook functions correctly here, running on the initial render and subsequently only when the fullName value changes, as strings are compared by value. This behavior is intentional and beneficial, aligning with useEffect's primary purpose of synchronizing components with external systems. It makes more sense to use posthog to check if full name gets changed on the server, but the fundamental operation of useEffect in this scenario is fine. Theo effectively communicated his point. Not every example needs to be flawless.
@@tvujtatata yeah, it's possible you would want to log every time full name gets set in the client, including the first time. I don't know why you would want to do that but I am sure there are reasons.
There is difference between “being able to read the code from top down” and “do business logic at the top”. PHP is the latter, yes all the code is at the top but it is a tangled mess. To understand what’s going on you have to keep going back and forth to understand what is going on between the JS and HTML.
If you are a mechanic and you keep get called in to fix BMWs you might conclude at some point, and rightfully so, that BMWs break easily. Thats their point.
@@hugmoretreez Maybe if too many people were frequently using said hypothetical BMWs incorrectly, then it may be time to admit that the BMWs might have or be the problem.
The biggest problem in working with react is lack of recommended folders structure in the docs which could be standardized. Right now I’m working on nextjs 14 and it takes me more time thinking about what to put where than actually coding. It really slows me down. Like… fore example components should be inside app folder, or outside? It’s just a basic thing and there’s no strict answer. I’m kinda autistic and I need some strict guides, I suck at making decisions, it takes me a lot of time :D
Yup, they have some "prints" of folder structures throught the docs, but I also have the same problem. About the components, what I normally do and from what I've seen in these "prints", is shared components like Button, Input etc, belongs outside of the app folder (in a components folder), and more specific page components inside a _components folder inside the folder where that same page resides.
"The biggest problem in working with react is lack of recommended folders structure in the docs which could be standardized. [...] it takes me more time thinking about what to put where than actually coding." Sounds like a big skill issue. It's things like this that make other devs laugh at web devs... I mean, I know that you're exaggerating but com'on, stuck on folder structure? How many files do you have to create on a daily basis? Don't get me wrong, I've been there too, wondering where to put something. All I had to do is elaborate a structure that I'm comfortable with and that's it. It takes 15 minutes max and you're done. As someone said above, usually you have a folder for things used without specific context. Like a "component" folder right under "app/src" to hold things like or that are used all over the place. And for contextual things, just put them in their context's folder. Let's say you have a component that's used only on 'xyz' page: put it in a "_components" or "_ui" folder in your 'xyz' page folder... Need a file to hold some functions specific to that page? Add a "_helpers" or "_utils" folder to that page. I really don't see where is the struggle there.
In theory React would be great! But there are so many many pitfalls in React. Example: at the very end you state that „with hooks…“ … „you choose what updates happen“ (in contrast to class-based lifecycle stuff..). And that statement is just wrong: hooks MUST be called in an order which must never change over the whole lifetime of any component, which often leads to similar or even more restrict rules on „embedding“ components… this does not allow much room for choice, right… WTF?
I think the argument of the article is more on how it is easier to write bad react code then an argument against react itself. You can absolutely write dogshit angular or laravel code as well but it doesn't happen that often, at least personally that's what I've seen so I actually agree with the author. We know that react is a great tool and devs are usually the one to blame but this doesn't change the fact that most problems I've seen they've been with react. It might also be because the job market in europe is completely different and most frontend here are made with angular (and are huge crm like apps).
9:00 “There are more good React codebases that need help than there are good React engineers.” Been applying for React jobs for months. If anyone has any suggestions I’m all ears!
How is react not a framework though. It literally isn't a library. You don't write generic code that you can then just call functions in. You write very, very specific code for it to work properly and if you don't follow it, it breaks.
@@roccociccone597 frameworks have CLI console if react was a framework it would have custom code, but it tries to be vanilla javascript, which is why states use functions and not like svelte with custom syntax
Whether you have a well-structured code isn't linked to whether you use a framework or a library. I would dare to say that most likely the very best code structure you'll ever see will be made in the plain language, without either.
I noticed you tend these polls often in your videos. I feel like these polls will always be biased because directly before asking the poll you'll say the answer, (not the biased you mentioned) For example, if you ask "did you know that x + y = z" but directly before asking, you tell everyone "x + y = z", you're gonna get a lot of people who were on the fence say "yeah i did know". Even if its unintentional. I'm sure there's a term for this kind of bias, buts its VERY apparent in all types of media. The viewers want to agree with you. I understand there will be viewers who will answer truthfully, but there is a non-negligible amount who will straight up lie (even to themselves unknowingly) and side with you. Basically, I'd love for you to poll your viewers before telling (or hinting) the answer.
@@MrEnsiferum77 initial problems will occur when you switch to any other technology, no matter how good the technology is or how skilled you are as a dev
a lot of companies have migrated away from react for performance reasons. meta literally made react. it's no surprise they're using it. also, there's a reason why other frameworks exist that focus on performance and there's a reason why most of the frameworks now have adopted signals.
It actually doesn’t. The code is messy and very adhock even though the best are working on it. Compare to RUclips (angular) which is very easy to jump into as a new joiner.
@@armanrozika can't be worse than vanilla js, or am i mistaken? i'm strictly vanilla, considering going deep in React because I always thought React *would* encourage a certain way of doing things compared to plain js
31:36 Components and state are NOT separate concerns. He always seem to miss the point. But at 35:54 his useName() example IS a separate concern, for the exact reasons he is giving.
At 4:00 you seem to be pointing out why those 40-45 engineers had trouble scaling a react codebase, implying it isn't a problem with react. The whole point is that the issue is so widespread over 6+ companies the poster worked at.
Love your content. You mentioned @18:19 that using Laravel is expensive on the server side. After giving up on looking for a great framework to build desktop apps, I decided to transition to web dev to build web apps instead (my main focus is the BACKEND). I was planning to learn PHP then Laravel because everyone on the internet says JS/React sucks. Do you recommend learning Laravel (or Symphony) to build backends (or websites in general) ?
I think the article's take is right ironically for the reasons you point out that it isn't a big deal Theo. Specifically if using react "correctly" requires deep react knowledge, but it's very easy to use incorrectly, there is something a miss. You mentioned people should know the react docs very well, it hasn't been my experience that every dev will RTFM. With a large enough team and unrealistic rapidly approaching deadlines from bad management, bad code will always slip through the cracks. I've been on a lot of teams and used a bunch of different technologies, including react, knockout, angular, svelte, blazor, and flutter. The only one that has been in anyway decent to contain the mess of less than perfect developers is, in my opinion, svelte (and maybe Vue with the composition api). React and flutter suffer from similar issues, which is they both require some deep knowledge of how the framework works for how to not make the app incredibly janky. You really dislike flutter though, but it is very close in design to react except using dart instead of JSX / JS / TSX / TS. While I think all codebases can become unruly messes at scale, I think the significantly reduced surface area of svelte makes it substantially harder to use incorrectly. That isn't to say it's impossible to use wrong just I think the author's issue has to do with the surface area of react.
You are so deep into code review! Your love for React comes from upgrading Twitch from Ember to React and seeing easy to understand git diffs, even more so when React hooks came out :D It is interesting perspective and experience to have!
50:01 an alternative would be to use a context in this scenario, but instead of having the component 'Something' subscribing to the context, it would be the Parent 'ReallyReallyTinyThing' that would, and provide it via props. Assuming, of course, that 'Something' should be a context-agnostic component while the parent wouldn't.
For large projects with many developers Angular provides really good projects structure and guidelines how to structure your code to manage complexity! If such guidelines exist for React then yes React will be a winner! With great flexibility of technology comes great responsibility which means developers should be much better but they don’t. Majority of average developers need strong guidance to avoid creating mess which will be very difficult to support in the future!
@@tumpperi3891 Unfortunately, no. They just introduce new features without providing guidance or structure. I’m using Next.js 14, and I can do whatever I want, which increases entropy and chaos because anyone can do anything.
@@tumpperi3891 Unfortunately, no. They just introduce new features without providing guidance or structure. I’m using Next.js 14, and I can do whatever I want, which increases entropy and chaos because anyone can do anything.
@@tumpperi3891 Unfortunately, no. They just introduce new features without providing guidance or structure. I’m using Next.js 14, and I can do whatever I want, which increases entropy and chaos because anyone can do anything.
I disagree with the react team not having a preferred/recommended way of writing apps. They do and do in fact enforce it quite strongly at times. The problem is that they don't ever tell you what that is publicly. I strongly suspect that the relay+flow+internal facebook stack is the only comfortable and correct way to write react apps. Though the rest of us are out of luck as most of it is internal/not publicly documented.
I really enjoy watching your longer videos because it gives me a better sense of how good I am at doing code-related things. - "A good engineer will weigh the pros/cons of what thing to use. A bad engineer just picks what's on Twitter or RUclips." I'm a bad engineer. - "If you approach things by writing the most minimal thing possible, and only making changes if it doesn't work, awesome." I'm a good coder. Since you say separation of concerns is so mis-used, do you have any good examples of the phrase being applied correctly? I definitely don't understand it, but I'd like to.
How is it a separation of Concern if removing the function to custom hook, is just create new state for each and every time it is called, and if you are saying that, maintaining state is the job of the state management library or prop driling then it's just syntax difference right ??
React allows more bad code to be written. Other libraries have better guards to prevent bad code to be written. Separation of concerns in a frontend application whether it's with React, Vue, or Svelte isn't a bad thing by itself. The UI should be a representation of state, but they are inherently two different things. Hell one of our frontend apps at work was a mess. State being mutated all over the place (in pages, layouts, components and the BFF), and it took us close to 3 months to separate the responsibilities of each thing: - state should be initialized, mutated and fetched via the store - components should have minimal side-effects and should just render what is passed in - layouts should only compose a specific way of rendering components - pages should render a single layout Is this not separation of concerns? I think it is and I'm open to hearing others' thoughts. This separation is what allowed us to find issues much quicker, and ship faster since then too. When someone wants to update how a component looks or behaves, there are no changes in anything but that component and it's tests (if needed). If someone wants to fetch something extra from the backend and add it to the state, only the actions and the structure of the state changes. Code review is so much easier and faster since then. Unless I misunderstood what Theo was saying completely
The OG "separation of concerns" freak out in React was JSX. Mixing JS with HTML was the thing that was violating separation of concerns according to everyone complaining. What people didn't understand was that React is not based on MVC, it was inspired by XHP which was a server component-oriented architecture used at FB as an alternative to MVC. In react, the concern is the component. This fundamental difference in approach has led to numerous misunderstandings and controversies. Many developers struggle to adapt to this component-based mindset, often trying to force React into an MVC context. This cognitive dissonance between the familiar MVC pattern and React's component-oriented architecture continues to be a source of confusion and debate. Maybe you meant something else by "mutating state", but mutating state directly in React is generally considered a bad practice. Also, now that we have RSCs, the formula is closer to UI = f(data, state).
25:01 useEffect for analytics is not the right solution. Actions should be triggered from user events, not from state transitions. state might change based on transient thing like remount, or async data loading. Analytics (and other actions) are properly done at the point where the user event occurs. useEffect docs cover this topic. So yeah, React is complicated. And React state, as people typically learn it, does not scale well on vast majority of projects.
I see this a lot in my companies legacy code. They'd take some redux state (API state), and then on mount or component did update, would take the things they need (or often times just all of it) and put it in local storage. Then you'd end up with duplicated state instead of derived state and it's a big mess. You'd refetch APi data, but it wouldn't update because the component only synced state on mount, or if you mounted the component too early, it wouldn't have any state. It's not reacts fault, you seriously have issues if you think duplicating state and then keeping it in sync is logical, even as a caching tactic (which is the only argument that I think you might be able to make, even though it's a horrible one). To me, the most important thing about writing code, is considering how others in the team will read it 6 months down the line. If you can't close your eyes and picture that, then your code is bad and try again. I'm not a perfect developer, I'd consider myself quite fresh, but I think having that mentality helps realise why some of these patterns are not good, and helps avoid them
43:00 this was slightly before your time, if you watch React documentary they always talked about backbone+React, that's the architecture for which React was initially created, it was before Redux and stuff like that
my 2ct on the first 4 : more likely the stanford guy was trained in high level math and most of the time was tought to think abstract , so his code --- note that it does not discuss the quallity only the readabillity --- will prolly reflect that , if your doing math with symbols and single letters and have no problem keeping track of whats what , you prolly also will do this for your function names and variables , making the code unreadable for someone who's breain is not trained in such a way , i personally have problems keeping track of what exactly a long variable name or function is , especially if there are multiple similar ones , so my vars functions mostly are 3 and 4 letters with an effor to have similar ones with the same with ... (even go back and ad a letter to all of them if required , it makes spotting bugs and typo's allot easier for me)
As someone with no React experience but I've been programming since before the "Internet" was a thing, my first thought was that you can write bad code in any language/framework. I know, I've done it on occasion before having an adequate understanding. Glad to see that that was largely the issue.
The failure of CSS, JS, markup as web's "separation of concerns" poisoned so many frontend brains. Sometimes you just need to do stuff that doesn't impact other stuff. Jamming everything into one giant inlined render function makes that hard. Tanstack/react query calls for example - its easy to pepper them all over your render tree, have a network call trigger a render call which triggers another network call. Suddenly because you've coupled data to component rendering the page takes 10 seconds to finish loading and you have a cumulative layout shift score of a million. I've worked in that codebase and it sucked. It's fine if you want to bring YAGNI to separation of concerns debates, but at some point there will be concerns in your code, they will be things that sound orthogonal (why can't the button be blue when the service is down?), and making it so one thing doesn't affect the other will require codebase design decisions.
I once facepalmed so hard that I knocked myself out. I inherited a project where the team used Vue but assumed EVERY component needs to have its own correlated Vuex store. Was that Vue's fault? Nope. The team just didn't take a moment to understand what is _actually_ necessary vs. what is the right tool for the job. I love React's context and provider feature for this reason btw. Such a nice middle ground between having a store and just making certain types of data available to any component that cares about it.
The biggest problem with the JavaScript community in general is that the rate of change is too rapid. It’s why you don’t as much of these problems with C#, Perl, Python, Php; because those languages and the most popular frameworks among them are changing much more slowly. Even within JavaScript, vue and angular have been changing much less rapidly than the rats nest of technologies orbiting react. With react there is a million ways to do things by how many options there are around using it, and expecting all the developers to get on board and do it “the right way” is a much bigger ask than what we’ve given it credit for. Its herding cats. Even if there was a uniform way of doing things, the rate of change makes it much more difficult for the general body of developers to keep up with. Some developers stay on the bleeding edge and others are actually getting things done at their job. That’s about the gist of it.
That form example for functional vs class components is the worst example I've ever seen anyone give on any topic related to anything. it's so far off and missing the point I actually lost most of the brain cells just watching it. thanks
Double standards shilling. React is great because reasons, everything else is bad because of reasons. Bottom line React is not aging well, it has layers and layers of abstraction which can catch you out as an application grows and the fact it is so open means that those abstractions can easily become unmanageable. One of reacts features, its easy to adopt, and get started without really understanding what react is doing under the hood. The constant upgrade of react libraries and meta frameworks, makes react hell to upgrade sometimes. Im not sure whats hes on about with regards to Angular. Sure AngularJS to Angular2 was... well a disaster, but Angular4 is pretty backward compatible, and was debeloped with that in mind. I imagine that Angular being quite prescriptive in its project structure made this easier JQuery, i can see it have the same issue as react, it can be solved with code reviews in much the same way as theo is claiming can fix knowledge transfer in react. I really uncharitable rant from Mr React
I'm came here to say the exact same thing. When you're incentivized to do everything in the browser and not have any backend logic, you will push all data to the front end and process it there.
@@JamesWendel agree but only semi incentivized. React not incentivized , just allow all. People just like to explore and do lot of stuff because they can.....Probably their AI that allow server side, is more easier than dom... React's wrapped dom is another standard.....I don't even fully understand pure javascript dom yet react had another layer. it is pain in the ass, if you want to do interaction / local only experimental web interaction
MVVM exemplifies state driven UI (as in various desktop and mobile app frameworks). If we can make that mindset shift, life becomes so much easier. That is how I approach React. I build VERY PERFORMANT ERPs with React. And those things are LARGE. Once you enable code-splitting and divvy up your app properly, and use Redux the way it should be used, you are good. By the way, I don't use the ReduxJS toolkit. I go barebones that allows me re-use a lot of pieces in a somewhat unconventional manner...
I'd love seeing some experienced React dev evaluating Feature Sliced Design architecture. It really feels to me it solves this issue while still being very comprehensive
I'm with you on this one, most of the problems described are a skill issue. No wonder you end up with shit code if devs can't be bothered to at least read the relevant doc for the framework/feature they're trying to use
theres a standard angular folder structure (module based)which every dev follow whereas depending on the devs experience they create different folder structure fox react
There is a difference between "separation of concerns" and "single responsibility", I feel like people think that you achieve the latter by doing the former, when this is fundamentally just being unable to perceive the benefits of a new approach.
08:45 I think the person who wrote this did not have a chance to get familiar with enterprise code but I see his point. All codebases turn ugly at some point. Most enterprises are driven by their "time to market/customer" so you have to cut some scope, have a partial release, or do some a/b testing because you have hypotheses that may or may not hold. Then when a change is required, we tend to patch things rather than doing a major overhaul. It has been proven that by committing small incremental well tested changes, you minimize your exposure as a company. It is our job as seniors to identify these emergent "black holes" and ticket them never to be heard of again :)
I 100% agree with the article's author. I’ve been working with React for the last 5 years, and the feeling is the same: every project I've worked on was/is a freaking mess, and no one seems to understand React at all. Sometimes I have the feeling that most RUclipsrs/Twitter influencers have no idea what most codebases out there look like.
I think if you asked most people writing they would say it scales really well. A medium sized project in go is more manageable than the same in some other language usually.
I never thought I'd say that but Theo kinda sold me on react with this one. I don't have any UIs to make yet which probably makes me a happier man. But still.
28:45 Agreed that ad-hoc useEffect should be banned. And that all the docs should be read. I don't like that the conversation becomes about React-isms, not about software principles. This is a sign that the framework is part of the problem. I would be much happier if React team told everyone that react state is only for actual UI state, and all domain data should be loaded and held outside of component tree. React should be for DOM handling, not as the full application.
React had it's day it's no longer the best choice for EVERY SINGLE PROJECT. And at 5:40 bro this is a libary/framework it should act nothing like a language, that is just silly.
The one thing that always comes up when I see this stuff. Just because JS and TS don't have the fundamental language features that are used in other frameworks, does not mean that all those frameworks and patterns like (gasp) MVC are bad. Chromium code? Yep, models, views and controllers everywhere. And yea, a React codebase will require a lot more care and feeding to not become unusable as it grows, because you have zero of the features most other languages use to manage that growth. Not to mention that Reach uses MVC terms in a completely different manner. A React Component is much more of a View and ViewModel (with a bit of validation logic?) stuffed into a JavaScript closure. There really isn't any business logic there (because that can screw things up). In the MVC, components are where most of the business logic lives. It's too late to change, but call the difference out in the documentation at least for those from that background.
React is the C or C++ of web development. Sure, you _can_ build performant and good applications with it but you are getting skill checked every step of the way. There are no enforced rules and a lot of opportunities to make mistakes. Saying things like "get good" and "you are doing it wrong" is not helping. It's just shifting the responsibility away from the horrible API design. By not enforcing or encouraging the correct way to do things on an API level or at least prevent or discourage the bad way we will sooner or later end up with tangled messes. Every code base tends to get messier the bigger it gets and the less structure the language and tooling enforces the quicker this happens. This is why a bigger go code base tends to be easier to work in than a C code base of the same size. Go forces you to write things a certain way, C doesn't. Code reviews can help against this but they will not catch 100% of the errors. Especially not in teams with inexperienced react developers where you have too few experienced devs to to double and triple check every line (which is most teams). "react as default" is a mistake and a project should only use it after careful consideration and if they can provide the necessary knowledge and structure (e.g. enough senior react devs and enough time for reviews).
Maybe I'm just pampered with skilled colleagues, but I don't like your mindset at all. Languages are there to give you an expressive toolset, not to protect you from your own foolishness. I like the motto "Provide sharp knives". Give people powerful tools, but educate them how to use these tools responsibly. Everything else is not a language/framework, but a prison.
10:31 is there anyone who can explain to a person such as myself, with a very small brain, how to interact with a canvas element with react and without useEffect? Like “render” to a canvas?
Another problem that I see all the time that wasn't even mentioned in the original reddit post is having teams not know how or when to use custom hooks. Without moving any state management logic to custom hooks or abstracting away parts of your render to another component, you can end up with these massive God components that are thousands of lines long and really hard to reason about. Again, not necessarily the fault of the framework, but it's another way to shoot yourself in the foot with React.
having engineers either A) wrapping everything in memo/useCallback B) reaching for memo/useCallback too early, has been something I've had to deal with. In general every time I've seen it in a PR its never been necessary. If it is a performance issue , then spending the extra time to deal with the core of the state management issue results in a better outcome that's not a absolute pain in the ass to look after. Having class based mix-in sucks. It was terrible in vue2 - having methods just magically get injected and super jank TS support. It was slightly better in React but yeah (agree) it still wasn't grate. The only thing I miss was the ability to wait for setState to update and now people usually try to do that with changing multiple useEffects (many unnecessary re-renders) together instead of picking a better pattern.
I have also had to deal with the over use of memoization. Doing this means you never really get to write idiomatic react and at that point, you might as well use solid. I can't wait for the react compiler.
I can 100% agree with the original author. With one exception all projects I had the "pleasure"to work on were a mess. And oh gosh the discussions I had as a mainly Angular developer about code structures, code consistency, abstractions and so on. This article speaks from my heart
I have to agree with the reddit post. Every react code base I've worked in that is even remotely large, is an utter mess and it's not because the project wasn't structured. The code itself is awful and that's largely due to how React wants you to do things to achieve acceptable performance.
It might be more of a project lifecycle issue than a technical one. React shines for products in constant development, with frequent updates and iterations. More rigid frameworks could be better suited for projects with a clear endpoint and infrequent post-release changes.
hooks are still better, but the class code is outdated. You can do: state = { firstName: '', lastName: '' }; handleFirstNameChange = (e) => this.setState({ firstName: e.target.value }); handleLastNameChange = (e) => this.setState({ lastName: e.target.value }); render() { return ... the rest ... } So sure, functions as components and hooks I also agree are better, but you can still do clean class based code on react
yep, I was a contractor, and man, I haven't worked with react for such a long time, but I remember my last project I made it more maintenable with a npm package coffee-react-class (but man how has Coffeescript evolved and Javascript post ES6+ made that package kinda obsolete...)
In regards to the ex-PayPal / ex-Twitter engineer comment - I didn't read it as you did. I read it that those places did not hire the best people - far from a free pass, more like a... 'yeah typical' type comment. My theory on those places during the big firing was if you were good to stayed - and those that were gone probably needed to go in the main, and probably should be not hired anywhere else, at least not at the level they were previously at as they clearly either were not experienced enough, or just can't hack it.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
1hr video is crazy, imagine this guy during standup
LMAOOOOOOOOOO FUNNIEST SHIT EVER
Far as I can tell this guy is just making videos for those who haven't set up screen readers
Bogus, I fw listening to dude talk about this stuff while I work sometimes.
Hmmm why do you say that
Ahahahahahaha
At least it’s entertaining. But yeah this is why you need a cap on standup meeting time.
Worst thing is when they have teams of 10 with 4 non-devs on the team, standup becomes hell
"The fact that they used to work there means absolutely nothing"
**Primeagen sweating profusely**
they're the same person
Theo used to work at Twitch too xD.
@@brangja4815Theo also has no idea what he’s talking about 95% of the time.
"netflix btw" (just kidding prime, i love ya)
That's why front-end needs to be designed, planned and standardized (set the guidelines) by Engineers specialized in this field. We are no longer in the 2000s. This is not a React problem. It's a problem of software development factories.
Semi-disagree and semi-agree, it's not going to be standardized. all the user frontends, web suffers the most (except the game UI that is so consistent that also requires user to have specific device otherwise they're f**k), are currently facing the same issues.
The requirement from users are so dynamic, so random and so subtle that even you can have user group A and user group B have opposite and conflict interests, every single frontend tools/standard can't satisfy all. It's not a technical issue. It's a human issue.
All the established "standard" requires you to train people to have that habit, and can be quickly wiped out when the new trend or device hits. Then all of your technical standard optimized for that particular behavior will be completely useless.
All of our mature standardized design for backend works because it's for developers, and developers adjust their frontend for the backend standard. Where the same thing can't happen on the human side, human wouldn't adjust for you, you have to adjust for them, otherwise your product will die, hence Frontend is always dumpster fire.
it's not technically hard, it's just human is so random, just like you at certain point you want to call customer service, no matter how "good" the current automate system (react/angular) is.
@@doc8527 You have a point, maybe I didn't use the right word. Rather it would be something like "Generate the initial guidelines, the conventions". Anyway, A good front-end engineer will take into account the points you indicate.
it is definitely a react problem
@@yojou3695, it's not. I have the same problems with Vue and Svelte. Requirements from users and businesses can be different. Only one redesign is enough to make your team suffer when almost half of your logic now works completely different
The guy is right. Many companies hire tons of react developers for cheap and think that they can create more because of all those developers, while all they do is turn any high quality code that the company might have had, to shit and then they leave so that guys like this author can come to fix the shit. It's bad management by non engineers that don't understand how software development works.
Many people in leadership think that hiring more devs will make it easier to develop apps, when in reality, it’s actually doing the opposite, 9/10 times in my experience.
This is why opinionated frameworks like Rails, Django, Ember.js are so much nicer to work with. 95% of projects fundamentally follow the same patterns. Why should you reinvent the wheel every time when years of experience and research has established a particular way that scales well?
Because something like Rails invented a structure in 2004, which based on nothing, and never rethink it. Most Rails-like frameworks are not even modular monoliths. Its just big ball of mud. All controllers in one directory? Really?
Tldr: not a react specific issue. Lear how to organize your code. Any code.
Thx 4 saving me the hour 👍
@@HolyMacaroni-i8ereminding myself to come back to this comment again to note this diwn
Framework users are not software engineers though.
They are 1990s style HTML authors.
React has had a problem with creating a "pit of success" since hooks.
By far most react devs I've met don't use dependency arrays correctly. The eslint plugin is usually not installed when I inherit a project and empty dependency arrays are flagrantly abused to achieve componentDidMount.
While the hooks model is worlds apart from lifecycle hooks in terms of the granularity of reactivity you can achieve, the setup can be taxing. Also, the move away from using useEffect for data fetching with no clear non-library way to achieve it was kind of rough. I'd bet most React apps use useEffect with an incorrectly empty dependency array for data fetching. When the library lends itself to doing the wrong thing, there's a design problem.
With the move to server side React, the setup has become simpler for those that use it. But when you really don't need SSR you're pretty much on your own. The React docs push server side React pretty heavily.
But regarding the video, I think most medium to large code bases are shit. Partially due to time pressure, partly due to new-shiny-object syndrome and of course good old laziness.
The problem is exacerbated by react.
Vue's onMount and onUnmount can be pulled into a hook/composable. It doesn't just need to be in a particular component.
Oh, that's cool
True! Don't take it personaly, Theo needs to learn not to make comments about things he does not know.
IMHO, The problem is not that react sucks, it's that it requires so much framework knowledge to be good at it. As a developer I just want to write code and let the framework do the heavy lifting, but when using react it's like you constantly need to think about performance and what hook is appropriate to use. It's really easy to fuck things up in React in comparison to other frameworks.
I've yet to see any language/framework that _does_ scale without a lot of care
I see this perspective a lot from developers with strictly OOP backgrounds. It's hard for them to get into the functional mindset.
I think that's why Angular has remained so popular in Enterprise environments, as a lot of the developers have a background in Java/C#.
I think most would benefit from reading a few books on functional/declarative programming.
Yeah, React is more associated with functional programming and was initially written in Standard ML, so it's true that using an OOP approach to react is causing many of these issues.
I think most controversy and confusion around React stems from attempting to view React through the lens of the MVC paradigm, which is deeply ingrained in many developers due to its prevalence in university and traditional web development. React, however, was mostly inspired by XHP, a server component-oriented framework used at Facebook as an alternative to MVC. This fundamental difference in approach has led to many misunderstandings and controversies, such as the initial backlash against JSX for seemingly violating "separation of concerns". In reality, React's primary concern is the component itself. Many developers struggle to adapt to this component-based mindset, often trying to force React into an MVC context, which is like trying to fit a square peg into a round hole.
a few thoughts as a senior engineer who has also worked at "6-7" companies working with react, including as a contractor and as a FTE.
1) the author isn't comparing "class component react" with modern react, they're comparing angularJS with react. Theo is kind of setting up a straw man here by taking class component react and using that as the comparison point against modern react and saying "This is so much better!" Yes, modern react may be better than class component react, but there is a case for both of them being worse than angularJS (by which I assume the poster means angular 1).
2) there is a key difference between "this is technically better" and "this leads to better outcomes". I also think there is a significant issue with saying "engineers bad" as a way to hand-wave mistakes made with a framework. software engineering has been around a fairly long time now, the tools we use to produce high level code should make it easier to produce good code, not harder. react makes it harder. a lot of the stuff that react ultimately accomplishes isn't that complicated. updating some html on a web page usually isn't a hard problem - overengineering is rampant in the web dev space. from my perspective, react introduces too many imperfect and overly complex abstractions - aka footguns - relative to the utility it provides.
3) we need to get better at listening when people offer critical perspectives about the web dev ecosystem. half the battle is understanding the right problems to solve. we spend so much time solving the wrong problems. hand-waving things or dismissing thoughtful critiques should be a last resort, not a quick-draw pistol. I don't disagree that developers can be bad or trying to fit a square peg into a round hole, but you are way too quick to jump to that conclusion and dismiss a critical perspective.
at the end of the day, the sum of average developer experiences is what defines the utility of the tool, and investing effort into improving the lower end of that average is how things get better for everyone.
"updating some html on a web page usually isn't a hard problem" is only true on a small scale. I work at a massive company in a 14 year old, behemoth of a codebase written by c# devs in vanilla js using oop principles, being able to use document.querySelector is not as fun as you think.
For personal projects I find using something like HTMX and web components is good enough. Even for complicated pages with a lot of interaction. I think something like React and Angular might shine on complicated pages with lots of devs. But a lot of times, maybe we just need to take a step back and think, "Is there a simpler way we can build this page?"
The HTMX-like pages I build are offline first PWAs. Easy peasy and not complicated at all with web componenets and HTMX-like lib.
React provides fantastic abstractions. Rooted in maths even. Love them.
What makes programming complicated is side-effects, and your average frontend is just a massive ball of them. UI is all about wrangling side effects by definition really. And programmers suck at dealing with side-effects which is why every frontend codebase is horrible. That's my take on the issue.. React is not a part of the problem and it really does a lot of things right imo. It gives you standardized and flexible ways for handling side effects and moves presentation away from them.
The dev hypecycle is all about realizing that some established practice is wrong and then doing the extreme opposite until the community comes to the conclusion that the initial solution wasn't so bad after all (monolith v. microservice, BDUF v. XP, GraphQL, DevOps. The js trend atm is going for big everything-frameworks like next/astro, but the pendulum will swing in the other direction in a few years.). React hit that abstraction sweet spot in the middle pretty well from the get go which is why it has become a mainstay. Never do I want to go back to the days of jQuery plugins and manipulating the DOM by hand.
That being said I'm sure HTMX has it's niche.
@@Schindlabua Most web pages aren't that complicated. React encourages developers to make the pages more complicated than they really need to be. If you push your state to the back end as much as possible and then on the front end you keep your state to only local state then developing web pages becomes really simple.
When state is very localized then you really don't need a framework like React.
Having said that. I do agree that sometimes your front end is truly complicated with a lot of interconnecting state and something like React might be useful. But most websites aren't like that.
@@dovh49 But localized state and basic websites are also easy in React so I personally don't feel the need to switch. I agree that we moved too much into the frontend in recent years but also writing razor pages and codeigniter SUCKED and sending JSON to the frontend was so much easier.
"Pushing stuff to the backend" is the design space the react meta-frameworks are exploring at the moment and I have mixed feelings currently since a lot of stuff feels needlessly complicated but the community will get there I'm sure.
Maybe there is a future in vanilla web components and signals and some effects library and then HTMX and serverside react if you really feel like it. (that would be the pendulum swinging in the other direction). But truth be told I'm not that bleeding edge anymore and when the big players tell me to change my stack I'll do so :p
This is not a shot against theo, but the fact that the useEffect at 26:40 has a bug, while ranting about the ease of use of useEffect compared to class components was so funny
really shows you that nobody is good enough to use useEffect first try
What is the bug here? I'm new to react so pls don't roast me :)
useEffect is one of the biggest foot guns in a JS centric framework I have ever seen
@@ShivGamer The useEffect is dependant on fullName, which as you can see is calculated on every render, and because the comparison is based on reference not value the useEffect will run on every single render regardless of whether fullName actually changed. The correct way would be to change the dependency array to [firstName, lastName]
@@Tekapeel you're wrong bc strings are primitives in javascript, they are compared based on value, not reference
The useEffect is fine. Not all values in JS are compared by reference.
React uses Object.is in the background(IIRC). This is what mdn has to say about comparing two strings:
> Two values are the same if one of the following holds:
> both strings of the same length with the same characters in the same order
So this effect will only rerun if the resulting string is different. Though this is still possibly the wrong use of useEffect. It will run on mount, which might not be what's needed. It should happen in the setter, but at that point the last of the advantages over class components disappear 😂
Started web development in vue, spent couple of years with it, switched to react for couple of years and then again switched to vue. And all I can say....i am not going back to react ever again. I won't explain my self in depth. I think it's meaningless. Take it for a spin and under 15 minutes and I bet you will feel like either Vue has some hidden flaw (like bad perf or doesn't scale) or you were totally misguided.
I have a similar story too, started with react it is not bad but when I needed SSR I started working with next and hated it, it just forces you to write your code in their way (vercel's way) like I could not implement proper Authentication using standalone express API without using the "useAuth" or whatever it was called because in starting in next 13, they removed the ability to read the cookies in server side except in "server action" which is useless for me.
long story short, by the first 30 mins reading vue docs I already felt it is way better, like way more better than react (talking about vue 3 here with the scipt setup composition API), and it got even better when I started working with nuxt.
I never seeing myself working with react / next again except in a job or legacy code.
finishing of with a question I ask my self every day, why people still choose (react / next) over (vue / nuxt) every day?, am I missing something?
I like Vue better as well. I feel it strikes a better balance of solving everything with JS vs staying true to how the web standards are conceptualized in terms of separation of concerns. I will say though that it does suffer a bit from its open sources nature, there's a larger community with a larger pool of libraries and tools that go along with React/Next that there is for Vue/Nuxt which may or may not make your life harder while debugging or trying to use third party tools depending on what you're trying to do.
I wouldnt really blame average react-developers for being "shit" or "stupid" when React team has a hands-off approach to architectural patterns. Codebases dont turn shit (necessarily) because of incompetency but rather because there's no source of truth in regards to best practices... Even the useEffect article you link is an anecdotal opinion on architecture and not official documents. If the react guys would just grow a spine and make some opinions about their framework, youd see codebase quality sky rocket
I would. When the framework does not impose an architecture on you, it's not a sign that you don't need one. It's a sign that you're free to choose one of your own. You gotta organize though.
@@MadsterV right, but then people shouldn't be surprised when there's suddenly 1000s of differentl architectures... It's a problem for older projects because usually the original architect is no longer on the project, leaving it to new developers, with their own opinions on architecture, to expand the project. *That's* why react feels like it's not scalable
@@MadsterV Right but sorry that is too idealistic, real world companies don't work that way. That's what the author is pointing out.
House Stark: "Winter is Coming"
House Targaryen: "Fire and Blood"
House Theo: "I obviously have a lot of thoughts"
You can't really rewrite this article talking about Go. Go is simple and forces developers to code in Go way. It's exact opposite of React..
As a newbie I began to understand learning MERN I really was not learning HOW to code using React. Your right I started learning ELM it's heaven. Also Go is great too
@@Joshua.Developer Haven't tried Elm yet. Syntax always scared me away :D
For me the best framework for front-end is SvelteKit. It was hands down the easiest to work with and very flexible in ways you can extend it. It feels close to vanilla JS.
This feels like Theo just ranting from a very pro-react perspective and isn't really hearing him out
He is hearing him out, it's just that what he is saying is mostly nonsense.
Basically he's saying that OP sees a lot of bad code and that it isn't representative of what React can do. Just because you're allowed to write bad code doesn't make it bad
@@BryanLu0 Thats not even the argument, the argument is that React encourages bad code.
There are other languages/frameworks that put up much better guide rails for inexperienced developers while maintaining the flexibility required for advanced developers.
Theos counter argument was literally just bring in a React PhD - that's what the OP is complaining about
@@PlebsSauce No, React does not "encourage bad code." What are some of those other frameworks, and why would frameworks need to cater to "inexperienced developers"? And yes, if you're going to use React, learn about best practices first. The issues with contexes and hooks are day 1 type of problems.
@@PlebsSauce Um, that's not what OP wrote. People frequently misuse features. I guess you can say that misuse of features should cause errors, but I don't think you should cause errors for optimization problems.
Actually OP's biggest issue is everything shoved inside render()
The fact that useEffect runs on on change AND ON FIRST RENDER, seems to confuse Theo. It is actually quite strange to hear somebody, constantly praising React for just doing what you expect, while at the same time writing a useEffect that will spam full name change in Posthog every time somebody opens the app.
I don't understand why someone would log from useEffect and not in backend. Not related to what you are saying, just in general what would be the case to do this?
Theo's point about useEffect is valid, despite the potential misuse of PostHog in this context. The useEffect hook functions correctly here, running on the initial render and subsequently only when the fullName value changes, as strings are compared by value. This behavior is intentional and beneficial, aligning with useEffect's primary purpose of synchronizing components with external systems. It makes more sense to use posthog to check if full name gets changed on the server, but the fundamental operation of useEffect in this scenario is fine.
Theo effectively communicated his point. Not every example needs to be flawless.
@@lukivan8 log user interaction?
@@tvujtatata yeah, it's possible you would want to log every time full name gets set in the client, including the first time. I don't know why you would want to do that but I am sure there are reasons.
@@tvujtatata for example?
PHP is the OG at "Do business logic on the top, rendering at the bottom".
There is difference between “being able to read the code from top down” and “do business logic at the top”. PHP is the latter, yes all the code is at the top but it is a tangled mess. To understand what’s going on you have to keep going back and forth to understand what is going on between the JS and HTML.
If you are a mechanic and you keep get called in to fix BMWs you might conclude at some point, and rightfully so, that BMWs break easily. Thats their point.
This would be a better analogy if BMW’s broke frequently because people were using them incorrectly instead of just being shitty cars
@@hugmoretreez Maybe if too many people were frequently using said hypothetical BMWs incorrectly, then it may be time to admit that the BMWs might have or be the problem.
The biggest problem in working with react is lack of recommended folders structure in the docs which could be standardized. Right now I’m working on nextjs 14 and it takes me more time thinking about what to put where than actually coding. It really slows me down. Like… fore example components should be inside app folder, or outside? It’s just a basic thing and there’s no strict answer. I’m kinda autistic and I need some strict guides, I suck at making decisions, it takes me a lot of time :D
Yup, they have some "prints" of folder structures throught the docs, but I also have the same problem. About the components, what I normally do and from what I've seen in these "prints", is shared components like Button, Input etc, belongs outside of the app folder (in a components folder), and more specific page components inside a _components folder inside the folder where that same page resides.
i've generally seen the src folder being the one holding components, libs, stores, etc. since i see the app folder as the pages folder
Good frameworks have standard and folder structure, and since react not a framework you know why is become problems.
"The biggest problem in working with react is lack of recommended folders structure in the docs which could be standardized. [...] it takes me more time thinking about what to put where than actually coding." Sounds like a big skill issue. It's things like this that make other devs laugh at web devs...
I mean, I know that you're exaggerating but com'on, stuck on folder structure? How many files do you have to create on a daily basis? Don't get me wrong, I've been there too, wondering where to put something. All I had to do is elaborate a structure that I'm comfortable with and that's it. It takes 15 minutes max and you're done.
As someone said above, usually you have a folder for things used without specific context. Like a "component" folder right under "app/src" to hold things like or that are used all over the place. And for contextual things, just put them in their context's folder. Let's say you have a component that's used only on 'xyz' page: put it in a "_components" or "_ui" folder in your 'xyz' page folder... Need a file to hold some functions specific to that page? Add a "_helpers" or "_utils" folder to that page. I really don't see where is the struggle there.
Thats a next thing. Not React.
In theory React would be great! But there are so many many pitfalls in React. Example: at the very end you state that „with hooks…“ … „you choose what updates happen“ (in contrast to class-based lifecycle stuff..). And that statement is just wrong: hooks MUST be called in an order which must never change over the whole lifetime of any component, which often leads to similar or even more restrict rules on „embedding“ components… this does not allow much room for choice, right… WTF?
I think the argument of the article is more on how it is easier to write bad react code then an argument against react itself.
You can absolutely write dogshit angular or laravel code as well but it doesn't happen that often, at least personally that's what I've seen so I actually agree with the author.
We know that react is a great tool and devs are usually the one to blame but this doesn't change the fact that most problems I've seen they've been with react.
It might also be because the job market in europe is completely different and most frontend here are made with angular (and are huge crm like apps).
9:00 “There are more good React codebases that need help than there are good React engineers.”
Been applying for React jobs for months. If anyone has any suggestions I’m all ears!
Don't apply for react jobs
if you need a well structured code, you need a framework not a library
How is react not a framework though. It literally isn't a library. You don't write generic code that you can then just call functions in. You write very, very specific code for it to work properly and if you don't follow it, it breaks.
@@roccociccone597 frameworks have CLI console
if react was a framework it would have custom code, but it tries to be vanilla javascript, which is why states use functions and not like svelte with custom syntax
Whether you have a well-structured code isn't linked to whether you use a framework or a library. I would dare to say that most likely the very best code structure you'll ever see will be made in the plain language, without either.
@@roccociccone597 react is a library not a framework, nextjs is a framework. Read the docs mate for once in your life
@@roccociccone597 search for react, first line says "react is a library..."
“If it’s your job to unfuck things, everything starts to look a little more fucked in your life.”
Truly the quote of all time.
I noticed you tend these polls often in your videos. I feel like these polls will always be biased because directly before asking the poll you'll say the answer, (not the biased you mentioned)
For example, if you ask "did you know that x + y = z" but directly before asking, you tell everyone "x + y = z", you're gonna get a lot of people who were on the fence say "yeah i did know". Even if its unintentional. I'm sure there's a term for this kind of bias, buts its VERY apparent in all types of media. The viewers want to agree with you. I understand there will be viewers who will answer truthfully, but there is a non-negligible amount who will straight up lie (even to themselves unknowingly) and side with you.
Basically, I'd love for you to poll your viewers before telling (or hinting) the answer.
Sooo Facebook doesn't scale?
All problem how facebook is lagish started when they switch to react.
Facebook isnt your average company react codebase lol
@@MrEnsiferum77 initial problems will occur when you switch to any other technology, no matter how good the technology is or how skilled you are as a dev
a lot of companies have migrated away from react for performance reasons. meta literally made react. it's no surprise they're using it. also, there's a reason why other frameworks exist that focus on performance and there's a reason why most of the frameworks now have adopted signals.
It actually doesn’t. The code is messy and very adhock even though the best are working on it. Compare to RUclips (angular) which is very easy to jump into as a new joiner.
I’ll just say from my experience, at the companies I work for the frontend react code is a mess
100%, everyone got their own way to do something, and that because react dont really encourage certain way of doing things, hence the mess lmaooo
@@armanrozika can't be worse than vanilla js, or am i mistaken? i'm strictly vanilla, considering going deep in React because I always thought React *would* encourage a certain way of doing things compared to plain js
31:36 Components and state are NOT separate concerns. He always seem to miss the point. But at 35:54 his useName() example IS a separate concern, for the exact reasons he is giving.
At 4:00 you seem to be pointing out why those 40-45 engineers had trouble scaling a react codebase, implying it isn't a problem with react. The whole point is that the issue is so widespread over 6+ companies the poster worked at.
Hey, man! Your ad transitions are smooth and flawless :D
Love your content. You mentioned @18:19 that using Laravel is expensive on the server side. After giving up on looking for a great framework to build desktop apps, I decided to transition to web dev to build web apps instead (my main focus is the BACKEND). I was planning to learn PHP then Laravel because everyone on the internet says JS/React sucks. Do you recommend learning Laravel (or Symphony) to build backends (or websites in general) ?
I think the article's take is right ironically for the reasons you point out that it isn't a big deal Theo. Specifically if using react "correctly" requires deep react knowledge, but it's very easy to use incorrectly, there is something a miss. You mentioned people should know the react docs very well, it hasn't been my experience that every dev will RTFM. With a large enough team and unrealistic rapidly approaching deadlines from bad management, bad code will always slip through the cracks.
I've been on a lot of teams and used a bunch of different technologies, including react, knockout, angular, svelte, blazor, and flutter. The only one that has been in anyway decent to contain the mess of less than perfect developers is, in my opinion, svelte (and maybe Vue with the composition api). React and flutter suffer from similar issues, which is they both require some deep knowledge of how the framework works for how to not make the app incredibly janky. You really dislike flutter though, but it is very close in design to react except using dart instead of JSX / JS / TSX / TS.
While I think all codebases can become unruly messes at scale, I think the significantly reduced surface area of svelte makes it substantially harder to use incorrectly. That isn't to say it's impossible to use wrong just I think the author's issue has to do with the surface area of react.
It's not React's problem. It's just that the whole universe is broken.
You are so deep into code review! Your love for React comes from upgrading Twitch from Ember to React and seeing easy to understand git diffs, even more so when React hooks came out :D
It is interesting perspective and experience to have!
50:01 an alternative would be to use a context in this scenario, but instead of having the component 'Something' subscribing to the context, it would be the Parent 'ReallyReallyTinyThing' that would, and provide it via props. Assuming, of course, that 'Something' should be a context-agnostic component while the parent wouldn't.
react causes unforced errors from developers of all levels of experience and I just dont think it can be considered good whilst this is true
For large projects with many developers Angular provides really good projects structure and guidelines how to structure your code to manage complexity! If such guidelines exist for React then yes React will be a winner! With great flexibility of technology comes great responsibility which means developers should be much better but they don’t. Majority of average developers need strong guidance to avoid creating mess which will be very difficult to support in the future!
I agree. BuT rEaCt Is So SiMpLe AnD iNtUiTiVe
Sorry if this ignorant, but wouldn't something like remix or nextjs fix this problem to make react more opinionated and structured?
@@tumpperi3891 Unfortunately, no. They just introduce new features without providing guidance or structure. I’m using Next.js 14, and I can do whatever I want, which increases entropy and chaos because anyone can do anything.
@@tumpperi3891 Unfortunately, no. They just introduce new features without providing guidance or structure. I’m using Next.js 14, and I can do whatever I want, which increases entropy and chaos because anyone can do anything.
@@tumpperi3891 Unfortunately, no. They just introduce new features without providing guidance or structure. I’m using Next.js 14, and I can do whatever I want, which increases entropy and chaos because anyone can do anything.
I love integrating new cool shit into my code base. That’s why I program.
I disagree with the react team not having a preferred/recommended way of writing apps. They do and do in fact enforce it quite strongly at times. The problem is that they don't ever tell you what that is publicly.
I strongly suspect that the relay+flow+internal facebook stack is the only comfortable and correct way to write react apps. Though the rest of us are out of luck as most of it is internal/not publicly documented.
ActionScript 1.0 rulez!!!
you should be ashamed of yourself 😂
I really enjoy watching your longer videos because it gives me a better sense of how good I am at doing code-related things.
- "A good engineer will weigh the pros/cons of what thing to use. A bad engineer just picks what's on Twitter or RUclips." I'm a bad engineer.
- "If you approach things by writing the most minimal thing possible, and only making changes if it doesn't work, awesome." I'm a good coder.
Since you say separation of concerns is so mis-used, do you have any good examples of the phrase being applied correctly? I definitely don't understand it, but I'd like to.
How is it a separation of Concern if removing the function to custom hook, is just create new state for each and every time it is called, and if you are saying that, maintaining state is the job of the state management library or prop driling then it's just syntax difference right ??
React allows more bad code to be written. Other libraries have better guards to prevent bad code to be written.
Separation of concerns in a frontend application whether it's with React, Vue, or Svelte isn't a bad thing by itself. The UI should be a representation of state, but they are inherently two different things. Hell one of our frontend apps at work was a mess. State being mutated all over the place (in pages, layouts, components and the BFF), and it took us close to 3 months to separate the responsibilities of each thing:
- state should be initialized, mutated and fetched via the store
- components should have minimal side-effects and should just render what is passed in
- layouts should only compose a specific way of rendering components
- pages should render a single layout
Is this not separation of concerns? I think it is and I'm open to hearing others' thoughts.
This separation is what allowed us to find issues much quicker, and ship faster since then too. When someone wants to update how a component looks or behaves, there are no changes in anything but that component and it's tests (if needed). If someone wants to fetch something extra from the backend and add it to the state, only the actions and the structure of the state changes. Code review is so much easier and faster since then.
Unless I misunderstood what Theo was saying completely
The OG "separation of concerns" freak out in React was JSX. Mixing JS with HTML was the thing that was violating separation of concerns according to everyone complaining. What people didn't understand was that React is not based on MVC, it was inspired by XHP which was a server component-oriented architecture used at FB as an alternative to MVC. In react, the concern is the component. This fundamental difference in approach has led to numerous misunderstandings and controversies.
Many developers struggle to adapt to this component-based mindset, often trying to force React into an MVC context. This cognitive dissonance between the familiar MVC pattern and React's component-oriented architecture continues to be a source of confusion and debate.
Maybe you meant something else by "mutating state", but mutating state directly in React is generally considered a bad practice. Also, now that we have RSCs, the formula is closer to UI = f(data, state).
25:01 useEffect for analytics is not the right solution. Actions should be triggered from user events, not from state transitions. state might change based on transient thing like remount, or async data loading.
Analytics (and other actions) are properly done at the point where the user event occurs. useEffect docs cover this topic.
So yeah, React is complicated. And React state, as people typically learn it, does not scale well on vast majority of projects.
I see this a lot in my companies legacy code. They'd take some redux state (API state), and then on mount or component did update, would take the things they need (or often times just all of it) and put it in local storage. Then you'd end up with duplicated state instead of derived state and it's a big mess. You'd refetch APi data, but it wouldn't update because the component only synced state on mount, or if you mounted the component too early, it wouldn't have any state. It's not reacts fault, you seriously have issues if you think duplicating state and then keeping it in sync is logical, even as a caching tactic (which is the only argument that I think you might be able to make, even though it's a horrible one).
To me, the most important thing about writing code, is considering how others in the team will read it 6 months down the line. If you can't close your eyes and picture that, then your code is bad and try again. I'm not a perfect developer, I'd consider myself quite fresh, but I think having that mentality helps realise why some of these patterns are not good, and helps avoid them
43:00 this was slightly before your time, if you watch React documentary they always talked about backbone+React, that's the architecture for which React was initially created, it was before Redux and stuff like that
my 2ct on the first 4 : more likely the stanford guy was trained in high level math and most of the time was tought to think abstract , so his code --- note that it does not discuss the quallity only the readabillity --- will prolly reflect that , if your doing math with symbols and single letters and have no problem keeping track of whats what , you prolly also will do this for your function names and variables , making the code unreadable for someone who's breain is not trained in such a way , i personally have problems keeping track of what exactly a long variable name or function is , especially if there are multiple similar ones , so my vars functions mostly are 3 and 4 letters with an effor to have similar ones with the same with ... (even go back and ad a letter to all of them if required , it makes spotting bugs and typo's allot easier for me)
As someone with no React experience but I've been programming since before the "Internet" was a thing, my first thought was that you can write bad code in any language/framework. I know, I've done it on occasion before having an adequate understanding. Glad to see that that was largely the issue.
@54:12 you don’t put user state (ei user meta data) into a context?
The failure of CSS, JS, markup as web's "separation of concerns" poisoned so many frontend brains. Sometimes you just need to do stuff that doesn't impact other stuff. Jamming everything into one giant inlined render function makes that hard.
Tanstack/react query calls for example - its easy to pepper them all over your render tree, have a network call trigger a render call which triggers another network call. Suddenly because you've coupled data to component rendering the page takes 10 seconds to finish loading and you have a cumulative layout shift score of a million. I've worked in that codebase and it sucked.
It's fine if you want to bring YAGNI to separation of concerns debates, but at some point there will be concerns in your code, they will be things that sound orthogonal (why can't the button be blue when the service is down?), and making it so one thing doesn't affect the other will require codebase design decisions.
I once facepalmed so hard that I knocked myself out. I inherited a project where the team used Vue but assumed EVERY component needs to have its own correlated Vuex store. Was that Vue's fault? Nope. The team just didn't take a moment to understand what is _actually_ necessary vs. what is the right tool for the job. I love React's context and provider feature for this reason btw. Such a nice middle ground between having a store and just making certain types of data available to any component that cares about it.
Where to search for the best ways for an application architecture?
The biggest problem with the JavaScript community in general is that the rate of change is too rapid. It’s why you don’t as much of these problems with C#, Perl, Python, Php; because those languages and the most popular frameworks among them are changing much more slowly.
Even within JavaScript, vue and angular have been changing much less rapidly than the rats nest of technologies orbiting react. With react there is a million ways to do things by how many options there are around using it, and expecting all the developers to get on board and do it “the right way” is a much bigger ask than what we’ve given it credit for. Its herding cats. Even if there was a uniform way of doing things, the rate of change makes it much more difficult for the general body of developers to keep up with. Some developers stay on the bleeding edge and others are actually getting things done at their job. That’s about the gist of it.
This why I'm a bit positive about the server functions(formerly server actions) in react, it will bring a bit structure into the code
Would love to know what you think of the data flow model used by other reactive UI frameworks outside the web, such as SwiftUI.
Appreciate what you do man.
can you do a tldr for this? 1 hour plus is crazy man, no offense
That form example for functional vs class components is the worst example I've ever seen anyone give on any topic related to anything. it's so far off and missing the point I actually lost most of the brain cells just watching it. thanks
Double standards shilling. React is great because reasons, everything else is bad because of reasons.
Bottom line React is not aging well, it has layers and layers of abstraction which can catch you out as an application grows and the fact it is so open means that those abstractions can easily become unmanageable.
One of reacts features, its easy to adopt, and get started without really understanding what react is doing under the hood.
The constant upgrade of react libraries and meta frameworks, makes react hell to upgrade sometimes.
Im not sure whats hes on about with regards to Angular. Sure AngularJS to Angular2 was... well a disaster, but Angular4 is pretty backward compatible, and was debeloped with that in mind. I imagine that Angular being quite prescriptive in its project structure made this easier
JQuery, i can see it have the same issue as react, it can be solved with code reviews in much the same way as theo is claiming can fix knowledge transfer in react.
I really uncharitable rant from Mr React
7:40 React by itself incentivizes you to download a large chunk of json on load
I'm came here to say the exact same thing. When you're incentivized to do everything in the browser and not have any backend logic, you will push all data to the front end and process it there.
@@JamesWendel agree but only semi incentivized. React not incentivized , just allow all. People just like to explore and do lot of stuff because they can.....Probably their AI that allow server side, is more easier than dom... React's wrapped dom is another standard.....I don't even fully understand pure javascript dom yet react had another layer. it is pain in the ass, if you want to do interaction / local only experimental web interaction
read the entire comment section and everyone who isn't just circlejerking agrees with the reddit post. lmao.
Watching Theo attempt to justify and code with react just proves the original post correct.
MVVM exemplifies state driven UI (as in various desktop and mobile app frameworks).
If we can make that mindset shift, life becomes so much easier. That is how I approach React. I build VERY PERFORMANT ERPs with React. And those things are LARGE. Once you enable code-splitting and divvy up your app properly, and use Redux the way it should be used, you are good. By the way, I don't use the ReduxJS toolkit. I go barebones that allows me re-use a lot of pieces in a somewhat unconventional manner...
The perfect mixture of rant and counter-rant, I love it!
please dont say c# is bad if you havent given it at least 6 months.
Great video, love the deep dive
I'd love seeing some experienced React dev evaluating Feature Sliced Design architecture. It really feels to me it solves this issue while still being very comprehensive
I wish these videos were 15min. I often click his video because the title makes me interested but then don't watch at all because it's super long.
just wait a couple months for google to arbitrarily change the algorithm to incentivize shorter videos again
I'm with you on this one, most of the problems described are a skill issue. No wonder you end up with shit code if devs can't be bothered to at least read the relevant doc for the framework/feature they're trying to use
Imagine needing voodoo magic to achieve acceptable performance lol
theres a standard angular folder structure (module based)which every dev follow whereas depending on the devs experience they create different folder structure fox react
There is a difference between "separation of concerns" and "single responsibility", I feel like people think that you achieve the latter by doing the former, when this is fundamentally just being unable to perceive the benefits of a new approach.
08:45 I think the person who wrote this did not have a chance to get familiar with enterprise code but I see his point. All codebases turn ugly at some point. Most enterprises are driven by their "time to market/customer" so you have to cut some scope, have a partial release, or do some a/b testing because you have hypotheses that may or may not hold.
Then when a change is required, we tend to patch things rather than doing a major overhaul. It has been proven that by committing small incremental well tested changes, you minimize your exposure as a company.
It is our job as seniors to identify these emergent "black holes" and ticket them never to be heard of again :)
I 100% agree with the article's author. I’ve been working with React for the last 5 years, and the feeling is the same: every project I've worked on was/is a freaking mess, and no one seems to understand React at all. Sometimes I have the feeling that most RUclipsrs/Twitter influencers have no idea what most codebases out there look like.
so react currently is like php5??
I think if you asked most people writing they would say it scales really well. A medium sized project in go is more manageable than the same in some other language usually.
I never thought I'd say that but Theo kinda sold me on react with this one. I don't have any UIs to make yet which probably makes me a happier man. But still.
I don’t want to call out any repos - but there are a lot of popular, large repos with poor structure
28:45 Agreed that ad-hoc useEffect should be banned. And that all the docs should be read.
I don't like that the conversation becomes about React-isms, not about software principles. This is a sign that the framework is part of the problem.
I would be much happier if React team told everyone that react state is only for actual UI state, and all domain data should be loaded and held outside of component tree.
React should be for DOM handling, not as the full application.
6:36 You give too much credit to " _average_ large codebases"
Did you say "Microsoft Investor" like, you bought stock?
React had it's day it's no longer the best choice for EVERY SINGLE PROJECT. And at 5:40 bro this is a libary/framework it should act nothing like a language, that is just silly.
The one thing that always comes up when I see this stuff. Just because JS and TS don't have the fundamental language features that are used in other frameworks, does not mean that all those frameworks and patterns like (gasp) MVC are bad. Chromium code? Yep, models, views and controllers everywhere. And yea, a React codebase will require a lot more care and feeding to not become unusable as it grows, because you have zero of the features most other languages use to manage that growth.
Not to mention that Reach uses MVC terms in a completely different manner. A React Component is much more of a View and ViewModel (with a bit of validation logic?) stuffed into a JavaScript closure. There really isn't any business logic there (because that can screw things up). In the MVC, components are where most of the business logic lives. It's too late to change, but call the difference out in the documentation at least for those from that background.
i have been interviewing frontend devs with 7-10+ years of experience and 99,99% of them do not know design patterns and solid principles.
hmm comments say 10 days ago but if u go the reddit post its 4 months ago. prerecorded?
Great breakdown with amazing educational value as well, learned new things as a mid-level React developer!
React is the C or C++ of web development. Sure, you _can_ build performant and good applications with it but you are getting skill checked every step of the way. There are no enforced rules and a lot of opportunities to make mistakes.
Saying things like "get good" and "you are doing it wrong" is not helping. It's just shifting the responsibility away from the horrible API design.
By not enforcing or encouraging the correct way to do things on an API level or at least prevent or discourage the bad way we will sooner or later end up with tangled messes. Every code base tends to get messier the bigger it gets and the less structure the language and tooling enforces the quicker this happens. This is why a bigger go code base tends to be easier to work in than a C code base of the same size. Go forces you to write things a certain way, C doesn't.
Code reviews can help against this but they will not catch 100% of the errors. Especially not in teams with inexperienced react developers where you have too few experienced devs to to double and triple check every line (which is most teams).
"react as default" is a mistake and a project should only use it after careful consideration and if they can provide the necessary knowledge and structure (e.g. enough senior react devs and enough time for reviews).
Maybe I'm just pampered with skilled colleagues, but I don't like your mindset at all. Languages are there to give you an expressive toolset, not to protect you from your own foolishness. I like the motto "Provide sharp knives". Give people powerful tools, but educate them how to use these tools responsibly. Everything else is not a language/framework, but a prison.
10:31 is there anyone who can explain to a person such as myself, with a very small brain, how to interact with a canvas element with react and without useEffect? Like “render” to a canvas?
8:30 - Following this reasoning, one could also argue that you're not seeing any bad Angular, Svelte and Vue codebases...
Another problem that I see all the time that wasn't even mentioned in the original reddit post is having teams not know how or when to use custom hooks. Without moving any state management logic to custom hooks or abstracting away parts of your render to another component, you can end up with these massive God components that are thousands of lines long and really hard to reason about. Again, not necessarily the fault of the framework, but it's another way to shoot yourself in the foot with React.
having engineers either A) wrapping everything in memo/useCallback B) reaching for memo/useCallback too early, has been something I've had to deal with.
In general every time I've seen it in a PR its never been necessary. If it is a performance issue , then spending the extra time to deal with the core of the state management issue results in a better outcome that's not a absolute pain in the ass to look after.
Having class based mix-in sucks. It was terrible in vue2 - having methods just magically get injected and super jank TS support.
It was slightly better in React but yeah (agree) it still wasn't grate. The only thing I miss was the ability to wait for setState to update and now people usually try to do that with changing multiple useEffects (many unnecessary re-renders) together instead of picking a better pattern.
I have also had to deal with the over use of memoization. Doing this means you never really get to write idiomatic react and at that point, you might as well use solid. I can't wait for the react compiler.
I can 100% agree with the original author. With one exception all projects I had the "pleasure"to work on were a mess. And oh gosh the discussions I had as a mainly Angular developer about code structures, code consistency, abstractions and so on. This article speaks from my heart
I have to agree with the reddit post. Every react code base I've worked in that is even remotely large, is an utter mess and it's not because the project wasn't structured. The code itself is awful and that's largely due to how React wants you to do things to achieve acceptable performance.
It might be more of a project lifecycle issue than a technical one.
React shines for products in constant development, with frequent updates and iterations.
More rigid frameworks could be better suited for projects with a clear endpoint and infrequent post-release changes.
hooks are still better, but the class code is outdated.
You can do:
state = { firstName: '', lastName: '' };
handleFirstNameChange = (e) => this.setState({ firstName: e.target.value });
handleLastNameChange = (e) => this.setState({ lastName: e.target.value });
render() {
return ... the rest ...
}
So sure, functions as components and hooks I also agree are better, but you can still do clean class based code on react
yep, I was a contractor, and man, I haven't worked with react for such a long time, but I remember my last project I made it more maintenable with a npm package coffee-react-class (but man how has Coffeescript evolved and Javascript post ES6+ made that package kinda obsolete...)
If you are using MobX, your react application can scale infinitely, just use MVVM or something like that.
In regards to the ex-PayPal / ex-Twitter engineer comment - I didn't read it as you did. I read it that those places did not hire the best people - far from a free pass, more like a... 'yeah typical' type comment.
My theory on those places during the big firing was if you were good to stayed - and those that were gone probably needed to go in the main, and probably should be not hired anywhere else, at least not at the level they were previously at as they clearly either were not experienced enough, or just can't hack it.
It is so easy to just add props and make a mess. I’ve seen it at three companies . It’s just too easy to shoot you self in the foot.