I work on marketing websites which are essentially disposable. So every 3 years you start over from scratch (in a new version of some CMS). So I don’t get to build super cool functionality much, but I do get to work with newer tech stack. (I still don’t need 99.99% of the js frameworks flavors of the week)

We did a full rewrite of our site years ago going from backbone to react and TS. We just did it page by page, clean sweep on each page, all new work done on a fresh slate with the old code base being abandoned page by page but otherwise left alone until all the pages were migrated at which point we could just completely drop the old code base. We’re so much more productive now and happy working on the code base. Refactors are much easier than before as well.

I’ve worked on massive jQuery code bases before and they turn into worthless spaghetti code in no time at all. Dynamically altering html with no source of truth is the worst pattern you could have on a frontend. I have a ton of respect for what the jQuery library introduced but it was never a framework and was used in a terrible patchwork way. I wouldn’t even bother trying to save any of it. Clean split and keep that codebase tightly quarantined behind lock and key and don’t let it even touch the new code base. The spaghetti code it creates is like a virus.

The joke is that nearly everything these libraries/frameworks do is complicate what used to be simple

What happened was, up until the early 2010s a lot of frontend developers were essentially designers who could write HTML/CSS templates, but not programs. When the industry shifted to client side SPAs they couldn’t follow, so there was a big backlash against the new “complicated” tooling, even though it’s no more complicated than any other domain.

I always wanted to write a response post, “How it feels to learn JavaScript in 1996”. Because yes, webpack is harder than flat JS files. But you have 1 billion tutorial videos to help you do it, and open source project skeletons to start you off, and Q&A sites to fix your problems for you.

Some of us learned JS before YouTube or StackOverflow or even W3Schools existed. When I got my first job browsers didn’t even have developer tools! If your code didn’t work you just had to guess why!

I tried to learn React, but it was unnatural for me, but then senior front dev at my workplace suggested Vue. I remember Vue’s options api being too weird to even try it.

Then I discovered there’s composition api and fell in love with it. React’s flow without its weird quirks.

I think Svelte is next step towards feeling as natural as possible.

I’m sorry but framework and library in this post are going to be used loosely, because even React, Vue, Angular, Svelte, etc devs use the terms loosely.

React is mostly a UI library like you would find in most native app development. Of them all them JS frameworks/libraries is one of the less opinionated and with less batteries included. By design it does not does everything. Most other frameworks do way more.

It lets you define custom components. The components can have properties that their parent component defines and internal state. If the state or the properties change the component gets redrawn (magically). There are some lifetime functionalities (things to do on first render for example) and performance improving stuff (memoization) but mostly that’s it.

All the other features you talk about are third party libraries or frameworks that can operate with react or are build on top of and cover the bases, like routing, fetching, caches, server side rendering, styling utility libraries, component libraries, animation libraries, global state management, etc.

The big difference with the vanilla way is that the approach is mostly declarative. The runtime takes charge of updating the DOM when your components state or properties change.

You take a big performance hit, and an even bigger bundle size one, but the speed of development and huge ecosystem of readymade solutions can be really important for some use cases.

Other frameworks take different approaches to solve the same problems:

• Component system for code reuse and organization.
• Some way to manage state
• Some way to decide what to re-render and when.
• Extra stuff. Some frameworks end here, some have tools for everything you would need for a web app.

The thing is, they look like too much for a simple app with near none interactive elements.

But once app starts growing, concepts like reusable components, reactivity and state management become such an important tool.

Imagine tracking shopping cart’s total value. With these frameworks it’s just one store containing total value, exposing the value as reactive state. Once the value changes, all components using directly or indirectly that value update immediately. In vanilla you would have to keep track of every instance where that value is used manually.

Additionally, if you decide keeping total value of cart in frontend is stupid (because it is), you just modify your store to provide only readonly value, and create setters that require you to pass item or item id. Then that setter would hit up backend keeping your cart’s total value, add an item, and backend would return new total, which would now be set as that store’s new total value.

These frameworks are kind of SOLID principles applied to chaotic world of user interfaces.

That second article is hilarious. It’s trying to point out that the first article is over complicating things then doing the same thing except the author thinks it’s not complicated what they’re saying when it’s actually insane.

That worked out well - one copy in stock for £4.05. I’ve been trying to learn JavaScript for a while, so thanks for the recommendation :)