[antris]

100% true.

But I'm not even talking about academic really. There were plenty of people who didn't buy into the "MVC/jQuery/templates" thing, and we were writing apps into production for actual customers. I've never been taught academically, but I realized that writing my DOM operations as declaratively as possible made my code much easier to maintain. So I started creating and updating my DOM in JS way before React, when it was considered "heresy" by people who didn't know better. And there were plenty of programmers like me, who never got academically trained or looking up category theory. They had just shot themselves in the foot with the silly MVC stuff too many times to care anymore about what other programmers think.

For me, and people like me React was a GODSEND. We started immediately hyping it, but there was huge resistance early on to adopt it. React was a great improvement from the status quo. But then later on we realized that people started using it as a framework just like they had with "templates+jquery+backbone+whatever" and although the DOM things are a bit easier now, many people don't understand any better why or how React is good and when it's bad to use...

[8note]

I think the innovation comes from making it easy to do. Its been transformative for how people write UI code as a result

Its innovative in the same way as the iPhone was. All of the concepts existed before, but nobody made them practical and cheap

[miralize]

On that point, I think the next innovation to come to front end development is to declaratively think about states using finite state machines & statecharts.

A concept that also has existed before, but with XState, I think a lot of developers will latch onto this paradigm.

The ability to think or plan a feature/apps states in the beginning rather than imperitavely or as an afterthought during development is really valuable. And perhaps if we're dealing with something more visual at the beginning, its easier to demonstrate what will happen if I click "X". and then it becomes easier to spec out & to involve PMs/designers and QA.

[antris]

I suppose. It just feels weird that the post was highlighting hooks and context, while VDOM was omitted. VDOM was easily the biggest thing in my opinion. I had never seen anything like it and it worked wonderfully. It's not to say that everything else in React is bad, it's more like everything else pales in comparison to how huge VDOM was when it was introduced.

Kinda like hyping iPhones innovation without ever mentioning touch screens.

[Mogzol]

I read it more as talking about a revolution within React. Hooks and context are (relatively) new features that do "revolutionize" how you write components. That's not to say VDOM isn't important, it just isn't anything new, it's been a part of React since the beginning.

[madeofpalk]

I'm so confused by what you're saying all over this thread, apart from "React is something that exists, and I modified the DOM before it existed". Okay?

[varrock]

> many people don't understand any better why or how React is good and when it's bad to use...

Your comment was very insightful, but I feel like you've left me on a cliffhanger. I'm someone who got into the industry right when React was reaching enterprise levels, so I missed out on what came before it. I got my job, was told to learn React, and have gone from there.

Is there any way you might be able to expand on the problems you were solving with your declarative approach, why it was useful, and how you think React should be used in modern day web development?

[antris]

One these problems usually:

- application is in one state and the UI is in another state

- jQuery operations mutating the DOM causing weird edge cases after several user interactions

- the template language (handlebars, mustache etc.) was getting in the way because it lacked the expressivity of javascript

- application state was split all over the place between Models, Views and Controllers. instead, if you put as much state as possible in a single place in your application, it's much easier to just create declarative functions that take in an immutable state and output a DOM node object: `(state object) => DOMNode`

Right now I'd use React only for projects that require it as legacy or as a part of a framework. If you want to get things done quick, Next.js is pretty good framework for greenfield projects that uses React under the hood and I don't mind it being there too much. But similar things to React can be achieved with Svelte or Lit without having to ship and manage a VDOM implementation or JSX with its quirks (e.g. className).

So in summary, I'd stay away from all features of React other than VDOM, and even skip that if possible. And as a general rule, don't use any frameworks unless you can say why your project specifically really needs it. Surprisingly much can be done with basic HTML, JS and CSS. People who say "just use X" are trying to force simple answers to a field that is inherently complex and needs good judgment on which tools to use and when not to use them.

[thealig]

I have experienced working on a messy application codebase (jQuery + Knockout.js) which was 7-8 years old and seemingly was hastily made by on contract of another company. Had to refactor it to ES6 (dynamic imports) -needless to say it was a big pain with unpredictable barely any performance improvement as compared to refactoring on another codebase.

jQuery is a good tool for simple one page applications but not designed for complex web apps. It is harder to code cleanly in it as compared to React.