I am not arguing against your actual point, but in modern browsers you don’t even need jQuery, because all of it is available natively.
(Kicking in a very open door)
Not arguing either but if JavaScript can write perfectly fine web applications with a welld refined standard, why are we still in react land. I use react all the time, I know what vanilla can do, I use a lot of AI so it's not a knowledge gap anymore... Very curious and frustrating situation.
People use React because it provides reactivity. JQuery doesn't do that.
You can in fact write web applications in Vanilla JS, I have done it many times. But for interactive pages that are frequently updated in response to user events, using React (or Svelte or Vue) is more ergonomic.
Tbf, that's usually because frontend devs often tack React frontends onto OOP backends like PHP or C#. That's fine and all, it just makes for a clumsy mix.
I occasionally teach at a boot camp, and I can confirm that there's no real depth given to the differences. We explain it briefly, show how the data is typically received, and then move on with explaining how to interact with it. So, yeah, I think you're spot on, mate. Cheers.
No sarcasm intended.
I suppose the truck has been redisgned for several specialist roles though, company adoption and specialists use cases are why plain old JavaScript solutions still exist and on the other end of the scale why we still have react.
Because it provides separation of concerns, which is super important once you start working in a team and not as a solo developer. Team projects written in jQuery tended to rot very fast because it was very easy to mix business logic with DOM manipulation.
Also one thing React is super good at is writing components that are very easy to reason about in isolation, because they are for the most part declarative and stateless. Everything comes in as props or context and when one of these things changes the entire component gets re-rendered
React apps tend to rot in enterprise applications because of the proliferation of third party extensions necessary to get a full developer environment. Angular puts basically everything you need in one place (component libraries are the main gap) so every angular app should roughly look the same code wise. React apps will look very different based on how they were set up.
Obviously, someone will reply with an anecdote that THEIR collection of enterprise react apps are all homogeneous under the hood, but they will miss the point. They likely have the same set of 3rd party dependencies to round out the toolchain AND they were likely architected by the same person/team. Much more discipline is necessary to get react to work at enterprise scale.
I've read a lot of angular code, and I'd categorize it as the worst code I've ever read.
Mainly due to the design patterns commonly used, and the complexity it introduces for no benefit.
When I tell someone to add a thing to the UI, and they take 3-4 days to do a half-assed job at it, I am justified to hate the ecosystem of angular and the community.
React doesn't have that stigma or complexity.
Heck, you could switch a react project to SolidJS in under a day, depending on what dependencies you have ofc.
With React, I set the complexity, and if I am not satisfied, I don't have to accept it and can improve it.
I don't disagree with you. Angular is heavy and I am definitely biased as I have been using angularjs and angular professionally for about 14 years now so things look different to me than they would someone else.
You didn't provide any examples of complexity so I'll do the annoying thing and assume one or two likely causes and they're not angular specefic, but angular does make it very easy to fall into these traps:
Component code is too fucking large. Developers should look to encapsulate some of that into services and minimize business logic in the code.
Mutating component inputs gets real hairy real fast.
Usually a lot of the bs goes away once a developer structures their app so that their app has a few top level components that own the major objects and keeps track of the state. Everything under it needs to be dumb and treat the inputs as read-only and let the top level components orchestrate updates, but that's just how I do it. I guess angular stole the signal reactivity thing from React (which itself isn't a novel concept but whatever) so I'll have to reevaluate how angular apps get maintained if my next job uses it.
I was mostly annoyed with giant monolithic shared components, or useless middleware y'all call facade, patterns like that.
Not saying that you can't write angular code w/o them, but in a team that's hard.
Also, I hate rxjs, don't ask me why.
What you said about components needing to be dumb is a good pattern, using a store for state would be even better.
Also, I hate how angular's typescript support is iffy.
Like, a generic component is basically impossible to type, or well, impossible to use (?) in a generic way. Cause if you do, you get any instead of an inferred type from a type param.
React is very simple, and works remarkably well with generic typescript types.
You're definitely right about typing components themselves. And typings in the templates have gotten better but still aren't what I want. I had a feeling about the monolithic shared component thing being an issue for you. I see it all the time, but I don't think it's angular specific. Angular just tolerates it and there's a lot of ceremony around creating a child component (I mean mechanically creating the files and decorator metadata) so much that the cli has a script for that. So I can see people being lazy and just adding to the existing component. It's gotten better but it's still heavy.
I'm unsure what you're referring to about facades or middlewares. I'm guessing you mean injection tokens to provide configuration values at runtime?
And I don't really write react so I can't say how it is but I love rxjs. I know react doesn't use it because the philosophy is different. Angular treats components as accepting streams of values the change over time. React really just wants to be an efficient snapshot of a view in time.
Anyway this was good because I lightly forgot that I applied to some places that HEAVILY use react so I needed the motivation to brush up on my fundamentals. Thanks for the push (but only in one direction because no two way binding, but I think that's another way to get yourself in trouble with Angular).
Most of my issues with angular, lie with the community and the libraries.
e.g. a side effect of angular's bad typescript support, is that angular devs (one-trick ponies) often don't know proper typescript, and they just use any everywhere.
Or if they use types, the types may be incorrect, but the code works because they slap any on the function parameters, and then from trial and error have correct code but wrong types.
Garbage like that is what makes me hate it.
PS: good luck on your react adventures, the only real thing to look out for is useEffect, make sure to master it
I'm in a team we have a legacy handlebars evented state container thing. It's not really any better than react because at that point it was well established, no I'm not saying react isn't a better technology, but we are moving to react because AI writes it and hiring etc etc.
I lived through the jQuery days, and I think backbone for example and a few other technologies were created to give that mvc flavour, I suppose that's less of a jQuery problem and more of a, how prescriptive is your technology.
And components o find this point interesting, feature first, islands, these ideas completely change the idea of components so perhaps it's not actually a solved problem, still I can't disagree react is good at creating components, but the philosophy perhaps isn't perfect. Signals the future or something else?
84
u/Nils_Larson 2d ago
I am not arguing against your actual point, but in modern browsers you don’t even need jQuery, because all of it is available natively.
(Kicking in a very open door)