Probably unpopular opinion, but still better than react and angular. at least you don't need to build your whole site around it. Nor all sites need those heavy frontend framework.
React is 7.4 kB. It's a myth that react is a heavy framework. You can absolutely implement only certain parts of your web app in react, and other parts using different libraries or vanilla JS.
Angular gives you everything you need to build a complete client-side app, React is just for the view part. You still need other libraries for state management and other things
Car part is a library: tools you choose, you put together. If you choose enough parts you can build a car, but that's not the point. You can attach your windshield wipers to the battery to function, but that won't give you a functioning car, just a feature. Same with React, it gives you rendering, but won't store state. You need Redux for that, another car part.
A barbone car with an engine, a chassis and a steering wheel is a framework. You bring your own wheels, you plug in your own driver seat and then the car runs. That's angular. Angular is built from car parts.
A complete car with everything attached is an engine, you just sit into it and steer it.
You have been so very good at the explanation that my argument feels a little cheap. But still true, you drive the car and it's parts either way, a whole car or a collection of parts bolted to wheels it matters not.
Library is a set of methods/tools you use and you call. A framework is a more complete package, a "frame" around your code, where you write a piece of code that hooks into the framework and the framework itself handles/calls it. The difference is who calls who: with React you call the render method and you setup a lot of things by hand for React to work. Angular is a framework, it comes with a complete package, it tells you what files you should create, it sets up a lot of stuff before it executes your code. And then there are engines which are a complete, self-contained set of code and tools but it gives you the ability to control it with your scripts/code.
Arguably and perhaps subtly I've been saying that when you and your team get hold of a library and make one single integration into your own codebase, one single none conformist non idiomatic usage, react becomes a framework.
Your own code base becomes the framework that uses React as part of its frame. React is still a library. Redux is still a library. Your code base + React + Redux + Other Libraries = Framework.
Yes, React is a library. And yes, to get the same functionality as with a framework like Next.js you need more dependencies. But you can choose what you need. Libraries give you more freedom: for example, you can choose between many different routing libraries for React, or even build your own. Next.js has a built-in router which you have to use.
Libraries are also more flexible for niche use cases. For example, I've successfully used React for a Chrome extension's popup. There's no routing and no server, so a full-stack framework makes no sense. (And by the way, that Chrome extension has exactly 1 runtime dependency, which is React).
Everyone who's ever used React knows that their comment is incredibly disingenuous because of all the other libraries that get tacked onto every React app. No one is shitting on React here, they're just being realistic about it.
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?
As a former web-dev, the older I get the more I hate using web-apps. The best sites, for me, are just HTML with a little bit of Javascript where necessary. And, for that sort of thing, jQuery is perfect.
Better how? They are completely different things made for completely different usecases. It’s like comparing basejumping to hopping on a tranpoline because you’re both technically in the air.
That said, jQuery is most definitely legacy at this point and you can do everything using vanilla js.
yes, vanilla js can do what jquery does, but at the time when i was using it, i found jquery better syntax wise, and there were some pretty cool jquery plugins that required jquery. i am not a frontend developer though.
also, i was talking about many sites using react/angular just for the sake of it, even when there was no real need for using those frameworks. i still see these react sites even now, buggy and less interactive, sometimes not registering interactions properly or crashing.
with jquery, if some javascript breaks, usually that particular functionality stops working, but the rest of the site is still there. with react, especially an SPA, a lot more of the UI depends on the javascript app working properly, so when something goes wrong, you can end up with a much bigger part of the site being broken.
also, with react you generally end up with a whole buildchain. while with jquery you can just load it from a cdn or host it yourself, use it where you need it, and don't use it where you don't. it doesn't really get in the way.
but yes, if your site depends on reactivity a lot, using one of these frontend frameworks is a no brainer. in one of my sites, i am using django and svelte on a few pages where i need to show data more frequently, while the other pages use pure django templates.
also, i was talking about many sites using react/angular just for the sake of it, even when there was no real need for using those frameworks
A lot of people do it because of habit and that they like the paradigm, see how that is starting to look the same as your use of jQuery?
there were some pretty cool jquery plugins that required jquery.
Kind of how there are as many if not more frameworks that depend on react nowadays that people enjoy?
It's also a lot easier to start with a somewhat capable framework and later add things, rather than realizing your project needs react a few years down the road.
sometimes not registering interactions properly or crashing.
This has nothing to do with react, and developers that make broken UIs are just as likely to make broken UIs in any other framework.
with jquery, if some javascript breaks, usually that particular functionality stops working, but the rest of the site is still there. with react, especially an SPA, a lot more of the UI depends on the javascript app working properly, so when something goes wrong, you can end up with a much bigger part of the site being broken.
I'm struggling to picture what you're talking about here. I don't think you fundamentally understand how react works well enough and why this statement makes no sense. What do you mean by broken in this case, and why would react be more broken than vanilla or jQuery?
React is also very opinionated, meaning in theory you should do less mistakes not more.
also, with react you generally end up with a whole buildchain.
This buildchain usually includes things like linting and often TS, things that are great additions to ship less broken code. Again, at least in theory. You also don't have to use JSX/TSX, meaning you can use react form a cdn just the same.
I just find it odd how you defend jQuery so feverously, which objectively has zero use in modern development. But yeah, if you're hosting a couple of static pages with a dropdown menu, who cares what you're using really, but then I don't really know what we're talking about and you definitely don't need jQuery either.
100% this. If I'm doing website work, jQuery is a breeze to write.
Application work, I prefer angular but I wouldn't waste my time on a website rigging this into it and I think it's overkill if you're not handling data on the fly, reusing components and want single page app performance.
483
u/winter-m00n 3d ago
Probably unpopular opinion, but still better than react and angular. at least you don't need to build your whole site around it. Nor all sites need those heavy frontend framework.