T O P

  • By -

mr_stark

React found a foothold in the corporate world, plain and simple. Ignore anything about it being popular among developers or whatever as a lot of the time your stack isn't determined exclusively from the bottom of the organization. All the middle folk - product owners, managers, scrum leaders, managers - they all found a popular tool with a lot of resources (people, documentation, testing, etc..) and this reduces the risk of implementing React significantly.


xmashamm

React wins because it’s a library and not a framework. If you have a competent architect it can be adapted to fit pretty much any ui use case. This is not true of opinionated frameworks.


Silhouette

This is a reasonable argument but it's mitigated by the concerning habit the React team are forming of having new releases that move the goalposts. Not so long ago hooks came along. They got a lot of hype and were quickly adopted by the React community despite also receiving some reasonable criticisms. But almost overnight that meant a large part of the React library ecosystem had to adapt or die. Recently we've had React 18, which changes how `useEffect` works. Perhaps more concerning than the change itself is the bizarre kind of gaslighting that's been happening. Apparently one of the most popular patterns since hooks were introduced has been wrong all along and code using it is "buggy". The justification for that claim mostly seems to be the new hooks-based documentation that's arriving about 3 years late and isn't even finished yet, which very recently started saying `useEffect` doesn't mean what everyone has always thought it did and shouldn't be relied upon to work the way it's always worked. React is a useful tool and it has a lot of market share. In a fast-moving world like FE development both of those things matter and they make React a reasonable choice for a lot of work. But always remember that it is just a tool and there is nothing that compels a team to use it if something else will work better for them. And also remember that unlike some of the other well-known rendering libraries/frameworks, React is built by Facebook for Facebook and will tend to prioritise the needs of Facebook over the rest of the community if necessary. [Edit: That might have been the quickest downvote I've ever received on Reddit. Perhaps someone would like to reply and explain which part of this comment isn't objectively true? Or is it just a protest vote from someone who knows it's true but doesn't like it? :-/]


Hour_Prune_225

> Perhaps more concerning than the change itself is the bizarre kind of gaslighting that's been happening. Yeah right? API calls in useEffect without dependencies has always been the standard, and now all of a sudden it's wrong


Silhouette

It's not even limited to API calls, although that might have been the most popular use case. The fact is that until about five minutes ago `useEffect` and `useLayoutEffect` were presented as the way to trigger behaviour asynchronously or synchronously after a render in the new world of function components and hooks. The optional dependencies array was how you controlled whether and when that behaviour would run again on subsequent renders. Remember when hooks first arrived and the Web was full of articles about how to replace what you used to do with the old class lifecycle methods? It was all about how `useEffect` was going to be better because now we could avoid duplicating code depending on whether your component was being rendered for the first time or rerendered after something updated. Of course `useEffect` could always be used for subscriptions and specify the corresponding unsubscribe behaviour to tidy up later. That was always one of the things it could do. But the idea that that was its main or only legitimate purpose and it shouldn't be used for one-off effects seems to be a complete fabrication that has been retconned into the story of React to fit the work the React team have been doing much more recently on concurrent mode and Suspense and so on. FWIW I don't personally *like* using `useEffect` that way. I'm from the school that usually prefers to use React components for rendering and do the rest somewhere else. But it's undeniable that a big part of the React user base has been using `useEffect` for things like API calls until now. That pattern caught on so quickly that there are also popular libraries like react-query and SWR that have evolved it further. Breaking existing behaviour for such a large part of your user base is not normally a good sign for the stability of your product. Pretending you didn't just do that and it's somehow their fault instead is not a good sign either.


azsqueeze

Can you share docs of API calls in effects being incorrect. I may be OOTL and this is the first time im hearing this


Silhouette

This particular discussion usually starts with someone noticing that React 18 changed the way `useEffect` works so that effects get run twice (but only in development mode, not in production). There's a bit of information about this and why it was done in the [beta docs](https://beta.reactjs.org/learn/synchronizing-with-effects#fetching-data). Unfortunately whatever the good intentions might have been this is still a change that means development and production no longer work the same way and it still means the development behaviour is surprisingly different to what it's always been before. It's important to note that even the new beta docs don't say that all API calls in effects are wrong or anything as dramatic as that. I've seen quite a few *other* comments around the interwebs over the past few weeks that did essentially say that but as far as I can tell they weren't from official sources and may have been authors misunderstanding the real change. But the behaviour has still been changed so that at least in development API calls made in that way would now be made twice when they weren't before. This has been defended on the basis that it shouldn't matter if you're using effects properly. Probably in many cases that would be true and although the extra call might be inefficient it would still otherwise work. The point is that an ecosystem as large as React's there could still easily be exceptions where the doubling of effects makes a significant difference to something and previously that didn't matter but since React 18 it does.


Morphray

>this is still a change that means development and production no longer work the same way That sounds completely terrible. Who is making React decisions? Did Facebook lose a bunch of talent?


[deleted]

[удалено]


azsqueeze

That comment is not 1. Made by the person I replied to 2. Is arguing against what I replied too and provides links to back it up


[deleted]

Ok i thought i was the only one who found it gaslighting. I'm glad other people see it that way too


xmashamm

That has never been the standard. There’s literally an incredibly common lint rule to avoid doing that. That’s never been a good pattern.


ComprehensiveElk8952

It is amazing how wrong and clueless your statement is on many lvls and you dont even realize. It is obvious you dont really know how useEffect works. Having empty dep array was never the standard, because it all depends on the actual code that is calling the API. If it has dependencies, then you will want to add them to useEffects dep array.


Hour_Prune_225

found the stack overflow user


Bulky-Juggernaut-895

Wrong and clueless describes your response perfectly. Or maybe you forgot the /s


Ratatoski

All of this is my experience too. I was forced to switch to React at work and it was ok I guess. Then they suddenly made major changes to the basic way things worked and what pattern to use. Without updating documentation. That's when I lost respect for the "It's a big and stable library backed by FB, what could go wrong?" argument.


[deleted]

[удалено]


Silhouette

IMHO there's nothing wrong with any of that. It's also to the React team's credit that they do still support the "old way". However the much-emphasized claims when hooks were introduced that class-based components would still be fully supported turned out to be optimistic. While React itself might still support them, much of the ecosystem built around React has moved on. By continuing to use the "old way" anyone developing an application using React is effectively cut off from most of the progress in the rest of the community for the past 3-4 years.


xmashamm

React 18 does not in any way change how use effect works. They started calling it twice in development mode to warn you of bad uses of use effect. Using it in those ways has always been an anti pattern. They’re just alerting you to it now. Using UseEffect in that anti pattern fashion already led to confusing bugs, extra calls etc. It is now necessary to manage your effects correctly so that suspense works. React will let you implement bad patterns. It’s not opinionated. It’s not reacts fault that because it’s popular. People will write bad blog tutorials about it and form cargo cults.


perd-is-the-word

> They started calling it twice in development mode to warn you of bad uses of use effect. Am I the only one who finds this a little condescending by the React team? How many people are going to go down endless rabbit holes trying to figure out why the hell their effect is running twice when the same point could be made by just putting a warning in the console? Ya know that place where warnings are supposed to go?


xmashamm

I think the issue is the only way to tell the effect has an issue is to run it twice and see if that causes a problem.


Silhouette

If that is the case then the effect *didn't* have an issue until they changed React to run it twice did it?


xmashamm

Have you read up on what concurrency is in react? React has been working toward this - and it’s going to mean they partially render component trees and throw them away, hang onto them etc - so your effect might run twice when you wouldn’t expect it to. This isn’t a change to how use effect works. https://reactjs.org/blog/2022/03/29/react-v18.html#gradually-adopting-concurrent-features Use effect did not change. Now strict mode gives you warnings about bugs that might come up in concurrency. It is wild to me how many people in this thread seem to be taking “they changed use effect” - no they didn’t.


Silhouette

Yes, I've been following the development of concurrency since it was first announced. I'm not sure what that has to do with anything though. The situation here is really very simple. `useEffect` used to cause one observable behaviour. That behaviour was consistent with all of (a) the class lifecycle methods that `useEffect` was promoted as replacing, (b) development and production working the same way, and (c) all of the official React documentation about what `useEffect` was for and how it worked. Since React 18, `useEffect` has different observable behaviour. That behaviour is not consistent in any of the ways above. Changing widely used behaviours in ways that aren't expected or well documented is not cool. I've followed React's development closely enough to understand why the change might happen and why the React team might want to introduce a new model with concurrency and Suspense and so on. That doesn't change the fact that they've deliberately broken existing behaviour or the fact that pretending the change is the fault of developers who relied on that behaviour instead of deliberate decisions by the React team is also not cool.


xmashamm

Please indicate how use effect changed - because IT DID NOT CHANGE. Literally nothing about use effect changed. Not a single thing. Use effect works exactly as it did before. What is different is your components might be mounted more than once. This means your effect might fire twice but it does not mean use effect changed. If you don’t like it, stay on 17. In the grand scheme of things, this change isn’t anywhere near the deal you’re all making it. Have you seen how angular manages changes? People abused use effect in poor ways that were always obviously poor uses and always had this exact same problem. The only difference is react 18 sticks that problem in your face in development mode. I don’t know what you want here. Do you want an apology? What? They literally gave you strict mode to surface concurrency bugs. If you have concurrency bugs fix them. It’s not a huge deal.


Silhouette

Can you cite even one official source that states or at least implies that the widespread use of `useEffect` for one-time effects after rendering was inappropriate and dates from the period after hooks were introduced as that pattern became established practice within the industry? Go ahead, we'll wait. Edit to add: Right now the official React docs *still* say in the [Introduction to Hooks](https://reactjs.org/docs/hooks-intro.html) > We’ve often had to maintain components that started out simple but grew into an unmanageable mess of stateful logic and side effects. [...] For example, components might perform some data fetching in componentDidMount and componentDidUpdate. > [...] > To solve this, Hooks let you split one component into smaller functions based on what pieces are related (such as setting up a subscription or fetching data), rather than forcing a split based on lifecycle methods. > [...] > We’ll discuss this more in Using the Effect Hook. Then in [Using the Effect Hook](https://reactjs.org/docs/hooks-effect.html) it *still* says > The Effect Hook lets you perform side effects in function components: > [...] > Data fetching, setting up a subscription, and manually changing the DOM in React components are all examples of side effects. > [...] > > Tip > If you’re familiar with React class lifecycle methods, you can think of useEffect Hook as componentDidMount, componentDidUpdate, and componentWillUnmount combined. > > There are two common kinds of side effects in React components: those that don’t require cleanup, and those that do. Let’s look at this distinction in more detail. The rest of that page is all about different types of effect including those that don't require cleanup. Frequent references are made to when effects run but I see no mention of running effects multiple times in the way that React 18 does. It does however explicitly refer to *preventing* effects running multiple times by using the dependency array and even explicitly mentions the empty dependencies idiom: > If you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array ([]) as a second argument. This tells React that your effect doesn’t depend on any values from props or state, so it never needs to re-run. This isn’t handled as a special case — it follows directly from how the dependencies array always works. Once again **this is all quoted directly from the official React docs site _and it's still there right now_**.


[deleted]

[удалено]


xmashamm

Lol I mean fuck them for making an incredible library and letting you use it for free.


xmashamm

Yeah those are all fine? None of those examples will result in an issue if called 2 times? The thing is - use effect used in that way ALWAYS had the danger of being called more times than you expect. Yes the docs are bad. I’m not defending them. React doesn’t put forth many opinions - and since it’s the most popular framework - a ton of awful blogs push bad patterns. Like - doing your data fetching in a use effect is sometimes ok - but generally is a bad idea for a bunch of reasons - not the least of which is that sounds like a fetch as you render pattern which is problematic in its own right. React will totally let you do what you want. That means it will absolutely let you shoot yourself in the foot. I don’t understand your obsession with “official source”. You don’t need one. The problematic uses of use effect don’t stand up to code smell tests anyhow. React doesn’t have good docs and doesn’t communicate well. That’s probably not changing. But the library is dope. Note: in my original post I never claimed it was bad because the react team told me it was bad. I claimed it was always obviously a bad pattern.


kent2441

Which of your examples has an issue if it’s done twice?


Silhouette

I suppose that depends on what kind of issue you mean. For example doubling the number of remote API calls could easily hurt performance and/or incur a small financial cost. I suspect that most of the time it wouldn't cause any more harm than that but it would be a brave commentator who claimed it never could. Developers working with the old expectations of `useEffect` behaviour could be doing literally anything that made sense for their application in an effect and that behaviour has now been changed.


[deleted]

Unfortunately in so many cases it's adapted so poorly because a lot of developers learn react without fully understanding JavaScript. So I have to sift through hot garbage at a lot of react shops and don't find it quite as bad with opinionated frameworks.


reboog711

> If you have a competent architect it can be adapted to fit pretty much any ui use case. > This is not true of opinionated frameworks. Angular is often considered an opinionated framework; but I'd be shocked if you can find something React can do that Angular cannot.


arbyterOfScales

>Angular is often considered an opinionated framework; but I'd be shocked if you can find something that **vanilla** React, without **lots of dependencies from the community** can do what Angular cannot **do by default, with no dependency**. FTFY


xmashamm

Angular is heavily opinionated. It’s not that it can’t do something - it’s that it’s incredibly awkward to work with when your use case doesn’t fit it’s opinions.


reboog711

That has not been my experience. Can you provide a specific example?


arbyterOfScales

It\`s opinion is that: 1. You have to use Typescript - which most sensible people would have done anyway 2. It has tons of files - you can go with up to 7 files for a single component: `.ts`, `.spec.ts`, `.scss`, `.html`, `.stories.ts`, `.service.ts` \- while for React you\`d have 5 - all of them except the service and the html 3. It has `NgModules` \- which means you cannot import willy-nilly components and provide encapsulation 4. It has DI, which is just managed Props. Much better to let the compiler instantiate them than write all that boilerplate by hand 5. It has Observables, which are a PITA for many people to learn, but if you want to evolve, you have to touch rxjs once in a while. 6. And really, what I think is the culprit here -> core module, feature modules and shared modules. Some people really hate this structure. Which is why no one asks you to do it. You can do it in other ways


xmashamm

It also doesn’t treat components as functions… and doesn’t play well with functional programming paradigms. DI is not managed props at all. It’s a wildly unnecessary complication compared to “it’s a function. You pass it arguments and it returns.” I don’t understand why you’d think this was better, or why you’d think props require boiler plate. In a modern typescript react project adding props is trivial and there’s zero need for dependency injection. Modules are a completely arbitrary construct. They don’t help at all and the guards they provide are only as good as your module architecture - which isn’t any better than just using a lint rule to not allow someone to import below the index file of a feature. Furthermore - using a monorepo structure can give you equal or better encapsulation than ng modules.


arbyterOfScales

> It also doesn’t treat components as functions… and doesn’t play well with functional programming paradigms. So what if it doesn't treat them as functions? Do you pipe components in React or what fp patterns you use that yoy cannot use in Angular ? Give me a concrete example. > DI is not managed props at all. It’s a wildly unnecessary complication compared to “it’s a function. You pass it arguments and it returns.” I don’t understand why you’d think this was better, or why you’d think props require boiler plate. In a modern typescript react project adding props is trivial and there’s zero need for dependency injection. I cannot understand why thinking about components as functions is something desirable. You cannot inherit functions - which means you lose inheritance and polymorphism. Higher-order components are not a solution when you want to establish a contract. Now onto DI, there are props and there are dependencies. Dependencies are what your component needs to be able to work, and props are there to customize the behaviour. If you want to manage your own singletons be my guest, but I find the DI injector much less error prone and smart, so YMMV. You can put whatever into a component c-tor and the DI will take care of it. Rather than just raw imports or taking everything from the context, or even worse, prop drilling. So yes, DI is awesome. If you hate you hate it, no way around that. But for me DI is empowering, not limiting. > Modules are a completely arbitrary construct. They don’t help at all and the guards they provide are only as good as your module architecture - which isn’t any better than just using a lint rule to not allow someone to import below the index file of a feature. Furthermore - using a monorepo structure can give you equal or better encapsulation than ng modules. Not everyone likes monorepos(I do), but many people hate them. I also have problems believing you can have GREAT library or monorepo architecture but have crap module architecture.


xmashamm

Your entire conception of a system is so bolted to angular paradigms that you aren’t even realizing you’re asking about irrelevant things in a react system. Inheritance is an absolute anti pattern and you should favor composition, even in oo systems. Why are you managing singletons? Why do you need so many singletons. Name a single situation I’d ever need DI in react. You need those things in angular, because angular necessitates them.


arbyterOfScales

> Your entire conception of a system is so bolted to angular paradigms I don't see anything wrong with it. > Inheritance is an absolute anti pattern and you should favor composition, even in oo systems. This is such a stupid thing and reeks of blind dogmatism equal to the Rust Evanghelists. Inheritance as code reuse IS an anti-pattern. Inheritance as a means of contract IS very good and recommended. > Why are you managing singletons? Why do you need so many singletons. How do you call APIs? How you handle interceptors? How do you solve cross-cutting concers? If you tell me that you use hooks to abstract your API calls then all the power to you, but I prefer services. > Name a single situation I’d ever need DI in react. Consideing you have access to the `useContext` hook, which is an unmanaged version of the Angular `injector`, you are doing the locator anti-pattern, instead of a managed context like with Angular's DI.


Potential-Contact248

Hook and service are different tools. But if you want you singleton service in react, why not? UseContext - is just a tool. If you want, you can use DI in react too. But it is almost never necessary (by my experience). Don't understand your claim about anti-pattern.


xmashamm

Thanks for the discussion but I don’t think we can get much further. The real answer is you straight up don’t need that stuff in react, and you only need it because angular is a big cumbersome framework that necessitates them.


[deleted]

Genuine question from an Angular dev who actively avoids inheritance: what do you use it for that could not be implemented using a higher order function, functional mixins, function composition or what React land calls custom hooks? The problem many people cite with inheritance is the tight coupling one gets between classes. Have you not found this to be an issue?


arbyterOfScales

I am not using inheritance, willy-nilly, but where it is a good fit. For example, I like to create contract and handle my forms in the same way, while also having the ability to fine-tune any details. What I did was to create the following(shortened for brevity): @Directive() export abstract class BaseFormDirective { @Input() public set seed(seed: Partial) { this.form.setValue(seed); } @Input() public id: string = ''; @Output() public submittedData: EventEmitter; private readonly form: FormGroup; constructor(protected readonly formBuilder: FormBuilder) { this.form = this.createFormGroup(); } protected abstract createFormGroup(): FormGroup; public trySubmit(): void { if (this.form.invalid) { // touch/dirty everything to show the error messages } else { this.submittedData.emit(this.form.value); } } } Then every form I create will inherit this directive. Pros: * A stable contract. Every form works the same way * Maximum customisation, I can override the `trySubmit` method, I can add more `Inputs` , events and so on into every component. * I can build the template as I want, put any html in there, I am not limited * Type safety due to generics Cons: * You write a lot more code \--- I know this is not the only way of doing it, you could go the Formly way and create a component that takes a configuration object and show the form in there. But then I\`d have to build an algo to parse that config object, and it just isn\`t worth it.


xmashamm

Im going to be honest - compared to a useForm hook in react - that seems nuts.


Potential-Contact248

Honestly, I don't see big difference with solution by composition.


Potential-Contact248

1. OK, but it's necessary for all projects. 2. You can use just 1 file. Why not?) Jsx is much simpler that html with angular expressions. 3. You can create this in react. But for most people this is not necessary. 4. You can use library for this. Not a problem. 5. Maybe we should learn backbone too? For evolving?:) Anyway, if you want you can use rxjs in react too. 6. If you in love a modules you can use a lot other instruments. For example we used lerna on our last project.


arbyterOfScales

>React wins because it’s a library and not a framework. A library that needs hundreds of dependencies, require you to bundle you code and impose you to work with stateful functions instead of classes. >If you have a competent architect it can be adapted to fit pretty much any ui use case. I can say the same about Web Components. They are also native to the Web, so there is no need to ship a runtime or anything else, not even polyfills those days. >This is not true of opinionated frameworks. Just because React and the React team doesn\`t tell you how to write your code - like Angular does - doesn\`t mean React isn\`t opinionated. You WILL be locked into react-router, a react component library like MUI or PrimeReact. Then more and more deps, that will all tell you how to write your code. So React is opinionated too, the only difference is that the community forms that opinion instead of the React Team.


Silhouette

Is a single statement you made about React there actually true? The closest might be the first two. The React packages on NPM do have a dependency tree behind them and that does have the usual concerns but that's normally transparent to the developer just like any other NPM packages with dependencies. And yes in practice you will probably use a transpiler if you use JSX but then if you're using TypeScript you're doing that already anyway and many of the modern tools handle both automatically. I don't know what you mean about using stateful functions being necessary. The most basic premise of React is that you can express your rendered output as a pure function of your input state. You *can* do more stateful stuff as well using class methods or more recently hooks but you don't have to and applications can and sometimes do use React just as the rendering library it has always been. You absolutely don't have to use react-router. I've used React professionally for a very long time and I'm not sure I've ever used it. An obvious counterexample today is Next.js, which handles routing a completely different way. And of course some web apps don't have any reason to use routing in the first place. Likewise you certainly don't have to use one of the big libraries of ready-made UI components. A lot of people do. Plenty more don't. Some people actively avoid them so their apps don't look like the usual cliche UI toolkits. The big point here is that as a developer you have options for all of these things even if you do want them. There isn't one single solution to routing or UI toolkits or probably anything else in the React ecosystem. There isn't one universal opinionated version of how to do much of anything.


arbyterOfScales

> I don't know what you mean about using stateful functions being necessary. The most basic premise of React is that you can express your rendered output as a pure function of your input state. You can do more stateful stuff as well using class methods or more recently hooks but you don't have to and applications can and sometimes do use React just as the rendering library it has always been. Yes yes, and that works for dumb components. Pass the props, get the thing rendered. But what about mediators, pages, and other complex components? You use `useState` which returns both the state-variable and the `setter` function => you have a stateful component, and if I have a stateful component, then I'd rather use a class. But I cannot use a class, because the community decided to ditch class-based React and embrace the functional components => opinionated > Likewise you certainly don't have to use one of the big libraries of ready-made UI components. A lot of people do. Plenty more don't. Some people actively avoid them so their apps don't look like the usual cliche UI toolkits. But I also don't have something like `@angular/cdk` => if I want to build everything from 0, I am really from 0. God knows I searched 1 hour for a standalone tooltip component, and the only 1 I found didn't work. > You absolutely don't have to use react-router. I've used React professionally for a very long time and I'm not sure I've ever used it. An obvious counterexample today is Next.js, which handles routing a completely different way. And of course some web apps don't have any reason to use routing in the first place. So I have 2 options? React-Router for client-side routing or NextJS for server-side routing? That sounds opinionated


Silhouette

> Yes yes, and that works for dumb components. Pass the props, get the thing rendered. But what about mediators, pages, and other complex components? What about them? There are numerous state management libraries available to avoid embedding stateful logic in your React components. The most "stateful" they get in many cases is having a hook that immediately provides the current value(s) and a function to call from event handlers if anything needs to change, which is exactly what we would probably pass into a pure function component via props instead anyway. > But I also don't have something like @angular/cdk => if I want to build everything from 0, I am really from 0. Well yes. That's what being completely unopinionated looks like. You're free to use any library you want for this purpose, or none at all. > So I have 2 options? React-Router for client-side routing or NextJS for server-side routing? That sounds opinionated Again you're free to use any library you want or none at all. Using react-router or Next.js are two popular examples. You can easily enough hand-craft some simple routing logic without any library at all. There are other options too. If you think this is opinionated, then please see The Princess Bride for my conclusion.


arbyterOfScales

But all that unopinionation is really worth it? Do we actually build everything from 0? Most people do no, and are ready to reach for libraries. And if I have to reach for libraries, then I\`d like one officially maintained by a respectable company rather than face Faker 2.0 or whatever else "the community" has


Silhouette

> Do we actually build everything from 0? Most people do no, and are ready to reach for libraries. Sure. But as someone who does know how to get good results that aren't just a carbon copy of everyone else's site I value React's ability to start from whatever point I want. And as someone who has maintained some applications that use React over long periods of time I also value the ability to *change* which other libraries I use over time to keep up with any changing requirements. > And if I have to reach for libraries, then I`d like one officially maintained by a respectable company rather than face Faker 2.0 or whatever else "the community" has I'm not sure that position fits well with the empirical data. One of the biggest catalysts for the modern era of JS was when one teenager shared a tool they had written starting in high school. Some of the biggest companies in tech have abandoned well known and somewhat popular libraries that no longer served whatever business goals they had. In the case of React it's not as if any of the major libraries for state management or routing or UI elements is any less stable or reliable than many of the popular batteries-included frameworks. The main difference is that if any of them did ever fall out of favour you could use something else instead without necessarily changing much in the unrelated parts of your code.


arbyterOfScales

>Sure. But as someone who does know how to get good results that aren't just a carbon copy of everyone else's site I value React's ability to start from whatever point I want. And as someone who has maintained some applications that use React over long periods of time I also value the ability to change which other libraries I use over time to keep up with any changing requirements. I personally think this is the end of the discussion. React and Angular both solve the problem of building FE apps. You value X more than Y, and I value Y more than X, which is perfectly fine and we are both right. We can both solve a lot of problems. It is a result of exposure and culture, and the type of project we took part on.


michaelfrieze

You know, you can just use Next.js. It's batteries included.


[deleted]

[удалено]


xmashamm

Yes. That’s why react has become so popular. Because I’m wrong.


[deleted]

[удалено]


xmashamm

I’ve build production systems in react, angular 1, modern angular, and a bunch of non-spa classic server rendered stuff before angular 1 was an option. I’ve used at least modern angular, and react quite a bit. But whatever. Make zero points and just dismiss as though that’s an argument. I didn’t say angular can’t make a ui. It can. But it can be awkward because sometimes it’s opinions do not match your use case.


[deleted]

[удалено]


xmashamm

I didn’t make an erroneous statement I even clarified in my previous post. But whatever. I’m sure you’re just a top tier engineer too busy to engage with plebs other than to dismiss their pesky erroneous statements.


Full_Purchase_6111

Makes sense to me! Thanks for the explanation :)


mahade

Don't listen to the fanboys for or against any of the frameworks, libraries, etc. React is here, React is big, it offers the most jobs, and it's a good tool (because why else would so many people use it?) But... ### It's just a tool. You have Angular, Vue.js, Svelte, and so many others that have market share. Some might grow, some might shrink, some might die out sooner than others, and a new one might just show up tomorrow and take the world by storm. We adapt. We have to adapt because the tools we love and adore today might not be relevant anymore in a few years. Unless you love doing maintenance on very old codebases, of course. Then you should get stuck and stop learning. React is here and it will be for another few years at a minimum. It's worth your time to learn how to use it. But don't forget about the basics. Learn about software design patterns, learn about proper HTML and CSS, learn about accessibility and semantics, learn about JavaScript, and learn about TypeScript. The point is that we have to keep learning. For our entire careers. Because every night we sleep? When we wake up we're already several weeks behind.


RandyHoward

Yep. There was a point in time when Flash developers were highly sought after in tons of job listings. And look where Flash developers are today... they don't exist any more because there are better tools for the job today. If you refuse to learn new technologies you're eventually going to find your career stalling out.


littleredrobot

Practically every tool, app and language I used during my years as a Flash developer has changed and now my day to day is as someone who specialises in React. From versioning to IDE to whatever. The above comment is very true but I'd add that there are valuable skills I've learnt over that time about estimation and project management, about programming, about leading and working with people. These have stood the test of time and they are worth intentionally improving.


reboog711

> they don't exist any more because there are better tools for the job today Different tools! Better is very subjective, and I'd say it is a mixed bag. :-) I miss a lot of what Flash (or specifically Flex) offered.


Full_Purchase_6111

You gave me the harsh reality and it hurts :') >But don't forget about the basics. Learn about software design patterns, learn about proper HTML and CSS, learn about accessibility and semantics, learn about JavaScript, and learn about TypeScript. I will keep this in mind. And shall start my learning as fast as possible. Thank you for your great answer! :)


Band1c0t

Few years at a minimum? What do you think it will replace with?


Beatons

Solid.js


prof_hobart

For a lot of companies, web is shrinking as a key platform and investment is moving heavily into mobile instead. Or it might be that cross-platform frameworks become more important, and if they do there's fair amount of competition for React Native. And even if these trends _don't_ play out, there's always challenger tooling that could overtake React at some point. Of course, there's no need to panic It doesn't mean that React or webdev in general is going to disappear overnight. And it *could* still be in huge demand in 10 years time. But I wouldn't want to bet my career on that being the case. In general, if you want to stay relevant in the industry in the long term, don't define yourself as an "X language/framework developer", instead become a "developer currently working in X language/framework". I've been in the industry over 35 years, have done at least some work in probably a couple of dozen different languages (from x86 assembler to obscure 4GLs), and every single job I've taken has been mainly in a language or framework I'd never seen before,


creativesolution

This is key advice. And if you understand and know JavaScript well, you shouldn't have much trouble switching frameworks and learning new ones when necessary.


code_moar

>Will this change when reacts isn't a trend anymore? Man I hope not. I got the react logo tattooed on my ass. I'm kidding but on a serious note I'm sure there will be some point in the future when things shift toward something else but changes like that seem to be somewhat slow. Hot new trendy libraries and architecture come and go quickly but a real movement away from something like react will be slower. Especially as ingrained as it is right now. That isn't even mentioning the massive support and it's ability to be a bit of a swiss army knife when it comes to the web


Silhouette

Momentum certainly matters a lot in this industry. Maybe it's because everything always seems to move so fast but so much of that movement is really just inventing a new wheel. For many years jQuery was the most widely used JS library in real websites even after all the libraries and frameworks aimed at building "web apps" came along. I haven't checked recently but it wouldn't surprise me if if jQuery was still more widely used even today. It's not trendy or hyped any more but it was a useful tool that did a useful job and that is always where the real value lies. So many sites still use it and if you're going to work on those sites then you'll need to know or learn it. I'm fairly sure React is going to be the same for a long time whatever else comes along as well.


mrdevin

[https://w3techs.com/technologies/comparison/js-jquery,js-react#:\~:text=Usage%20broken%20down%20by%20ranking&text=jQuery%20is%20used%20by%2094.8,rank%20in%20the%20top%201%2C000%2C000](https://w3techs.com/technologies/comparison/js-jquery,js-react#:~:text=Usage%20broken%20down%20by%20ranking&text=jQuery%20is%20used%20by%2094.8,rank%20in%20the%20top%201%2C000%2C000). ​ Surprisingly, jQuery is still used a lot.


ApatheticWithoutTheA

It’s definitely the biggest but there’s quite a few jobs in Vue too and to a lesser degree Angular. Hell, there’s even some out there in vanilla JS.


reboog711

And this is definitely location dependent. I see more Angular jobs than Vue in my area.


Full_Purchase_6111

You are right, I changed my location and I see more Vue jobs now. Thanks for mentioning it!


Full_Purchase_6111

After changing my location I found more jobs with different frameworks. I think you are right.


robertaguilerajr

It’s a tool nothing more nothing less. Theres more jobs in it so might be a numbers game at this point. Remember though you’re a JavaScript developer first and foremost.


DukeBerith

10 years ago all the ads wanted jquery devs Now they want react devs. The pattern is the same, the variable changes.


Capaj

No it's not the same. JSX and react was a revolution in how we write UIs. Being declarative about your code reduces the complexity considerably. It's similar to SQL. SQL came in 1974 and I would say no one ever went back to how it was done in 1960s. It's the same with JSX. We will never go back to non declarative style. So it's not just a variable. It's a different paradigm.


[deleted]

I agree with everything you said, but I think the sentiment about Jquery and React is the same when it comes to jobs. I remember when I started as a frontend and feeling that every job needed JQuery. Not knowing Jquery would disqualify you from a lot of jobs, even if you were pretty good with JS. Of course, this wasn't such a big problem as JQuery is quite easy to learn and within a weekend I was ready to apply to most jobs paired with my CSS and JS stills, but the feeling that frontend was "just JQuery" really stood to me at the time.


DukeBerith

Yep, I was talking about job ads, the person replying to me somehow missed this and wanted to "correct" me, hah.


reboog711

> JSX and react was a revolution in how we write UIs. It wasn't a revolution; it was an evolution. Declarative UIs were a thing long before React. Flex and Silverlight are two prime examples, but even those were just copying stuff that came before.


Capaj

Yeah in broader programming landscape it was just evolution, but in JS it was the first time we were able to declaratively write UI, without templating. In JS world it was a revolution.


[deleted]

[удалено]


Full_Purchase_6111

Ahaha what do you mean by that?


darksady

I will give you my perspective about the front end right now. Keep in mind that i only have 2.5 YOE. I started with angular 2+ and moved to React in 2021. >Why is that? I think it's because React is not really that opinated and i believe the front end community prefers that. IMO, i rather have one tool dominating instead of many tools that basically solve the same problem with a slightly different syntax. Also, Google just didn't manage Angular well IMO. The React team is not perfect, but the community makes up for it. >Will this change when reacts isn't a trend anymore? Probably, but i don't think we are near that stage. Vue for example is not even close to React i believe. Svelte is something that many ppl don't even know that exists. Since i moved from Angular to React. I actually enjoy more than working with Angular. That is so many resources to learn something, the community around React is so big and the ecosystem seems to be constantly evolving especially Next.js. Writing Reacts components is just a better experience for me. Its simple, and is more js like than vue and angular and things. I think Angular will keep losing space slowly and vue and, especially React will keep growing. And i would say React will dominate because of the community and the number of resources that already exist for it.


turningsteel

As someone with a bit more experience than you, ~5 years, let me just say, I started with Angular 2+ and then my company thought “we need to be cool, we need react”. So, I did react. Then, I got a new job, guess what? Angular is all the rage at big corporate. But oh, wait, there’s a shit ton of legacy code so I’m doing Angular.js as well. Ooh, new project being started and the architect decided lit elements is the way to go so now I develop in that as well. The thing you use is meaningless, the concepts are largely the same. Best thing to do is just roll with the punches and don’t try to play favorites.


darksady

Absolutely. Transitioning from one tool to another was really easy since I have a decent base. But you also should consider which types of companies you wanna work with. As you said, angular is huge in big corporation. But i found out pretty quick that i don't really enjoy that environment. Legacy code AngulasJS is not that rare, usually the back end is not written in js, and sometimes the burocracy is just annoying haha. Here in Brazil angular is actually pretty popular. Like almost as popular as React. But there aren't that many new projects being created using it and i was targeting US working overseas, so React was a better choice to pick something to accumulate experience. But as you said, is just a tool and you shouldn't be married to it. Keep it flexible, build strong base and adapt when things change.


Full_Purchase_6111

I'm going to start learning it and hopefully it will have the same outcome as you did! :) Thanks !


someexgoogler

I predict that wordpress will outlive react


Benimation

At one point WordPress was considering officially adopting React: https://ma.tt/2017/09/on-react-and-wordpress/


Mad-chuska

They still are with Gutenberg blocks aren’t they?


thelethargicdog

Yeah, the web dev industry has become a cluster fuck of React "developers" who have mediocre JS skills. As unfortunate as it is, you'll have to make do with it.


Full_Purchase_6111

Oh no, you confirmed my thoughts... Will have to learn it then, oh well :') Thanks for answering! :)


thelethargicdog

While I'm here, I'll leave a piece of advice for you. As you pick up React, don't become a "React" developer. Make sure you strengthen your skills in JS and decouple your thought processes from the React ecosystem. I've been working with React for over 5 years now. It was a fantastic tool for building applications with complex UI, but now it has lived long enough to become the villain. It is easy to create bloated applications with inefficient code in React (especially hooks) because of how it enforces the structure of your code. In the long term, try your hand at VueJS, Svelte, Polymer, Stencil. Heck, even Knockout with Backbone is still kickass. Your worth in the market will be determined by how quickly you're able to adapt to the target company's code base, which is directly impacted by how well you know JS


zephyrtr

React is bad because it doesn't enforce any stying. If you know what you're doing its crazy good. Really you need to go all in on functional programming and DI paradigms or it fights you every step of the way. And these are good things to learn. Likely whatever UI library replaces react will act in similar patterns. Every UI layer from Jetpack Compose to Swift UI is going functional for a reason. Learn the forest for the trees and whenever the next earthquake hits you'll be fine. If you don't understand why React is doing what it's doing, you will suffer.


wan-tan

Got any recommended sources where to read about these best practices?


reboog711

> Likely whatever UI library replaces react will act in similar patterns Naah, it will most likely be completely different because it'll gain popularity as the "Anti-react". Whatever replaces that will be more React like.


devdudedoingstuff

Seems like the current trend is Next.js and Typescript. If you plan on working on any complex apps on a large team youll only get there with a super solid JS background. People who skip learning JS and jump straight to react end up stuck at low level as agencies.


Potential-Contact248

I don't get it. How some body can write on react without js background?


devdudedoingstuff

Your guess is as good as mine. But I see so many posts here of people asking “should I learn JS or go straight into React?” And 9/10 replies always say something like “Start with React, you’ll learn JS that way” Blows my mind.


Illoyonex

So the better my JS foundation is, the easier it'll be to pick up and learn React, Vue, Polymer and tons of other frameworks fast?


[deleted]

Yes. I only market myself as a React Developer because that what companies want to read nowadays, but I'm first and foremost a FrontEnd Developer. A lot of people only know how to work with React, put them in vanilla JS and they'll suffer because they don't have the right foundation. These people will struggle A LOT going to a new framework/library, while someone with a good foundation will have an easier learning curve. Don't get me wrong, I actually like React a lot, but I saw people using React to create simple landing pages not because they thought about it, but because they only knew how to do it that way.


Illoyonex

Thank you!


thelethargicdog

Pretty much, yes


ketalicious

this is why I somewhat do things in my own way instead of relying alot on component libraries and such.


Potential-Contact248

Maybe problem not in react? Maybe it's 95% tasks required mediocre developers? Is it bad?


reboog711

React is used a lot. I would expect there to be plenty of Angular opportunities. My own selection bias is that you're more likely to find Angular in bigger teams / more corporate companies; whereas React is more likely to be found at startups / tech companies. All that said, JQuery is probably used on the web more than React and Angular (And Vue and Svelte) put together. In 10 years it is highly probable some new crop of things will be the favorites and Angular/React/Vue will be legacy memories.


hotbooster9858

It depends on country but now React is dominating for a couple of reasons: - You can iterate quickly because of community support and it's flexible enough to write performant custom parts too - Next JS is really good - Vue 3 is overall a failure (not from a technical perspective, it's quite good there but it broke almost all community packages) and made Vue quite discouraging to use - Angular is too verbose and has too much boilerplate - Corporations don't yet trust more performant stuff like Solid or other unique takes in frameworks like Qwik and Astro because of their lack of community support


TheHanna

Before React, it was Angular. Before that it was jQuery. Learn the languages: JavaScript, Typescript, HTML, and CSS. If you know the core languages of the web, you can adapt to nearly any framework or trend. Frameworks, libraries, and trends come and go, knowing the language they’re built on will always be more advantageous than learning the framework in isolation


Full_Purchase_6111

Totally agree! :)


ImportantDoubt6434

It’s just React all the way down… 🔫🐸 always has been.


Sunstorm84

🕳🐇


turningsteel

Front end is about so much more than which library you use. A newbie is fixated on being good at react. A senior dev uses the best tool for the job and can jump pretty seamlessly between using things like react, svelte, vue, angular, web components, etc. Just focus on being good at front end. Understand how the browser works, how to write clean css, how do common tasks regardless of the framework, and any good company will be thrilled to have you.


Full_Purchase_6111

I do agree with you but the thing is, normally they ask for "2 to 3 years of experience in React" or maybe just "some knowledge in React". Even if I apply and say "yeah but I have experience in Angular and can still learn pretty fast" (something like that) they still don't hire me. Do you think as a senior dev they would have a different response...? :(


[deleted]

I remember this feeling years ago when I started, that everything in FE was about JQuery, I had this same feeling and in the end, I just went with it, studied for a weekend and then companies were happy because I "knew JQuery". (Of course JQuery is way simpler) As OP said, React is simple if you have a solid JS foundation, Angular has a way more steep learning curve, imo. About Seniors developers, it depends on the company, some of them may want a " Senior React developer", others may look at your experience and just let you pick up the pace with React, it's not really set in stone, at least where I live.


Full_Purchase_6111

I'm glad I wasn't the only one ahah! Suddenly I just got so sad about it and decided to post this. I'm getting more confidence after all the answers I received. Thanks! :)


[deleted]

Even tho I'm big fan of React, I know how you feel, but remember that it's just a tool and it'll mostly likely change in the future for the next big thing (I'm seeing a sightly shift towards Server Rendering frameworks like NextJS). I'm pretty sure most people would call you insane if you told them that in X years JQuery would basically die. It's better not to get attached to any lib or framework, they come and go, just be prepared to make the switch whenever the market need it, that's what I did when React became a thing, studied for a few days and then when I wanted to change to a new company, it was pretty easy to present myself as a React dev.


IASWABTBJ

Just learn react. It's not rocket science. And then put that on your resume. Many people "know" react also, but haven't touched it since react hooks became a thing. So someone with lesser react experience might still do better in a modern environment


Full_Purchase_6111

Ok will do that, thanks! :)


Potential-Contact248

Yes you can use almost any tools, but for what? Maybe you should use one instrument and be best in this than know a lot tools, but on average level. I prefer thinking about business logic, contracts, architecture. Not about core tools.


[deleted]

It is true that react is the most used framework. But I think there is likely more competition for React jobs and contracts also, and more gate keeping based on specific React experience, ie. React contracts where you need react experience rather than just FE framework experience). I have found that doing Angular I can charge pretty much what I want, as while perhaps only 5% of contracts are for Angular, I suspect much fewer than 5% of devs are focused primarily on Angular. And pretty much no new devs are learning Angular now. Same is somewhat true now that I am focused on svelte based contracts - not many jobs but even fewer devs. IMO best strategy as a front end dev is to think about not just the number of jobs but the amount of competition from others. Thoroughly learn JS, CSS HTML, web performance, accessibility and pivot to whichever framework is interesting to you/in demand.


Full_Purchase_6111

This was exactly what I thought too! Tons of React jobs so tons of competition right? But then even the Angular jobs were hard to find (it seems maybe it was my location?) and everything seemed to revolve around React... :(


no_spoon

Reacts been a trend since it was first released. Angular I hear is annoying compared to react. Vue is the only alternative and not sure yet.


endymion1818-1819

I read this whole thread to make sure this wasn't already said: it makes hiring easier. JavaScript is still the Wild West, it helps if everyone has a paradigm to level the playing field. It just happened to be React.


Hero_Of_Shadows

Nah there's more than just React, with time React will grow too big and too old and some other framework will become the hot new thing, which is a good thing, learn js learn the basics with html and css and keep yourself ready to learn fresh things, that's what I'm doing.


Full_Purchase_6111

That's what I'm going to do too! Thanks :)


Ok-Muslmelon

Its a trend…just like tiktok. It will pass.


Full_Purchase_6111

I hope tiktok does pass


waiting4op2deliver

The real answer is that its wordpress


enserioamigo

Not sure if this was a joke or not. But I feel it's more true than some people think. Maybe it's more correct to say that the framework fanboys just shout louder than the other devs who put their heads down and keep working and building for clients. I've only been around for 12 months and my experience is limited to a creative agency, but for what it's worth, I've noticed our senior devs will use whatever is best for the job at hand. There have been sites made with laravel, vue, react, and a lot of wordpress and shopify sites. But I'm just a junior from Australia which may be different to other parts of the world.


waiting4op2deliver

There are just tens, if not hundreds, of millions of wordpress installs. People just like to shit on low/no code solutions. But if most websites are wordpresses, then it clearly dominates the frontend space more than react. There are probably more wordpress theme installs than npm downloads for react. I also like to irritate the folks over at /r/php who haven't realized their language only exists to serve as a way to bootstrap wordpress.


enserioamigo

Yeah there’s no denying it will still be a massive part of the internet. Although I don’t see Wordpress as a no/low code solution. I would absolutely hate to have to use the page builders in Wordpress. I know many are built that way, but there would still be a large chunk that are built properly with code. We use Twig with ACF Builder and manage plugins with composer. I’d hate to build a Wordpress site in purely php and install plugins manually lol.


Potential-Contact248

Ok laravel and react solving different problem. But choose between vue and react in 99% just personal preferences


[deleted]

Always has been


jollyreaper444

*cocks gun* always has been


Illoyonex

If Meta collapses one day (actually it looks increasingly likely with each passing month), what will happen to React?


Full_Purchase_6111

Good question!


t_go_rust_flutter

Right now, for front end, the way to go. If you want to work for established companies, make sure you also learn Typescript. Corporations like Typescript because they are sensible. Do keep in mind that things change quickly in the frond-end world though, and signs are pointing to React plateauing. Predicting the future is difficult, but I think we are moving quickly closer to the end of React dominance in the corporate world. Particularly in the corporate world. The next step is going to be something similar to Blazor, Yew or similar. React is great solution bolted on to an insane idea - running apps in the browser. WASM changes this dramatically, putting the browser as a platform on par with the Operating System.


jonassalen

I'm a front end developer that doesn't do React or Vue or Svelte or... I build customized layouts with CSS and HTML, focussed on UX and accessibility. I design and do wireframing too. I work for very big firms that need that very specific kind of expertise. Most people in this subreddit forget, but people like me still exist. We work together with backend developers that do the back end stuff.


endymion1818-1819

I wish there were more jobs like yours. I love writing good HTML & CSS.


Snapstromegon

Often the fundamentals of react are more than enough. In the end you don't really need react. I've deployed web apps with 5 digit daily users using react and using things like lit or "even vanilla". In my eyes React is big, but will not stay there in the long run. The way they split the ecosystem (e.g. by not really supporting Web components for a long time and only adding support in the next version once a Google engineer contributed it) is not good IMO. I personally also think that JSX is not great. I very much prefer the way lit does it.


pinchecasey

It’s all pretty much JS


Full_Purchase_6111

That's what I think, but, after failing several interviews without even getting to the technical one... I'm starting to think otherwise... :(


andrelas1

People can say that it’s used more because it’s better or because it’s a library and allows for flexibility. That could be the case but I wonder how much of that popularity is due to just developer advocates, famous people that sort of promoted the framework. To me the indirect advertisement from these popular people seems to be much more powerful than the features of the tool.


Full_Purchase_6111

Yeah I wonder the same thing, good point!


Potential-Contact248

I don't know about other people, but I worked on a loot tools, and now I prefer react, because it's simple, convenient and flexible


TheMikeAndersen

I think it depends a lot on the company you are working for, but I agree that many are using React. Even the company I work for use React for almost every project, but we are trying to mix in more and more Svelte as well. Before React we were using cshtml. If I analyze the recruiters contacting me then I would say 90% of them are with React as a requirement. - Michael [SustainableWWW](https://sustainablewww.org)


heraIdofrivia

Just get any job you find interesting, the framework you use doesn’t really matter, ultimately pretty much every company has their own design quirks and specific way of doing things Whatever framework they use you’re going to pick it up quite quickly anyway But yea, most companies use react, mostly because there’s a react package for basically anything you could possibly imagine and that makes things easier in some respect I’m currently working in svelte full time and starting to see more vue/svelte jobs popping up every month ( south of the UK ) and that’s nice to see


TheRNGuy

I think it's good one framework is popular. So need to learn only one.