[antris]

>In my opinion, React made a revolution with hooks and contexts

I agree with your overall point 100%, but to be honest nothing in React was / is innovative except for the virtual DOM diffing, but even that is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture. React made a huge impact on web dev and deservingly so, but all of the other ideas have been implemented and used on the web before.

Of course it's great that React is bringing some of these good ideas to mainstream, but they've been there way before they have been distributed along with a VDOM algo.

[madeofpalk]

> nothing in React was / is innovative except for the virtual DOM diffing

Maybe there wasn't much academically innovative in React, but it certainly brought declarative, functional UI programming to the masses. Its innovation was in making that as easy and accessible as possible with a tiny API.

I feel saying React wasn't innovative is so dismissive and ignores the massive paradigm shift that's happened in web development because of it.

[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.

[Oddskar]

I'll bite. What part of React has really been innovative?

Because it seems to me that around the time React really gained popularity there were lots of options that did largely the same thing. Knockout, Ember etc.

Personally I only see it as the real proof that VDom could work for large applications.

[ketzo]

Well, isn't there something a little "revolutionary" about mainstream adoption of cutting-edge techniques?

After all, like you suggest, things like functional programming and monads have existed for quite some time. The thing that makes React special is how rabidly people adopted it, and continue to adopt their major updates.

[antris]

>Well, isn't there something a little "revolutionary" about mainstream adoption of cutting-edge techniques?

Taking the example of hooks, React has hooks because it was released with a bunch other stuff in addition to the VDOM, people started using those things as a (poor) framework, shot themselves in the foot repeatedly and finally hooks had to be introduced as a fix on top of that.

Calling that band-aid "revolutionary" or cutting edge technology, kind of sounds wrong. They never would have been there and wouldn't have been needed if it weren't for the bloated original release.

But of course, even if that band-aid makes people think differently about building apps, it's all good. That's why I mentioned in the post that it's a great thing. But calling it "revolutionary" when a large fraction of programmers have been doing it that way for ages is a bit of a stretch.

[warent]

> but all of the other ideas have been implemented and used on the web before.

Is this true? I've worked in web dev for like 6 yrs now and React has provided a significant number of concepts and technologies I'd never seen before and still dont see elsewhere.

For example, JSX. Yes, it originated in php but React was its first time being implemented in the frontend.

Also the concept of hooks and functional components. The fact that you explicitly define side-effects in the render of a function, with memoization or execution dependent on arbitrary state, is a new invention as far as I'm concerned.

[tppiotrowski]

Honestly, the separation of concerns movement where content writers do HTML, designers do CSS and programmers do Javascript, all with with minimal overlap, set web development back a good 10 years. React was a wake up call that the three are intertwined so closely that you cannot think about them in isolation.

One of the early criticisms of React was: “You can’t do HTML in Javascript. You shouldn’t be styling in JS! That violates the separation of concerns.” React skyrocketed productivity and allowed scaling without spaghetti. That’s why it won.

CSSZenGarden was fun, but how many companies seriously did redesigns by just swapping a style sheet? Only repeat the dogma if it makes sense....

[sircastor]

HTML in JavaScript still feels wrong to me and I still hate JSX. The Vue and Svelte approach to simply having the HTML in the same file was much more digestible.

I think React won because it had a more gradual learning curve than Angular and a didn’t drastically change between versions.

And the idea that HTML/CSS/JS are non-isolated is over-thinking it. It only applies to the world of Webapps. HTML can be published and served all day without CSS or JavaScript. And you can do a lot with HTML and CSS alone.

[kentor]

Why hate JSX? There are lots of benefits to it, like debuggability and variable scoping rules are exactly those of javascript. Templating languages, on the otherhand, are not debuggable and have awkward scoping rules. And, they always feel broken in one way or another.

JSX is not magical which is what I appreciate the most about it.

[graftak]

Don’t forget proper and full typescript support. Going back to vue (2) after doing tsx was like going back to jquery; loads more context switching and mistakes.

The ability to type `children` alone makes a world of difference.

[antris]

Yes, yes and yes. All of these concepts are variations of what has been done before in a number of ways. Mostly by "FP academics" who "live in fantasy land", until everyone else starts using them too.

Transpiling, hooks and components have all been done (and done better) before React came along, but often they were laughed out as esoteric toys that have nothing to with "real programming". It's just hard to teach these concepts until you actually use them, and it's hard to get people to use these concepts unless they are included in something else that you need.

The same happened early with React, both JSX and VDOM were laughed at by many developers because "they looked stupid" to people who didn't understand them and were used to one way of doing things. MVC+jQuery+templates was the flavour of the day.

Same thing with TypeScript, FRP and so on.

Most likely, whatever concept is gaining momentum today, it's an exact or approximate copy, or in rare cases a novel remix of what has been researched 10-20 years ago, and used in production for 5 years before you heard about it on HN

These people who like to apply category theory etc. in programming have heard this mocking of their work as stupid esoteric fantasy (and then seeing them become mainstream later) so often that they literally called one of their specs "Fantasy Land" https://github.com/fantasyland/fantasy-land

There's still lot of work to be done. JavaScript doesn't even have proper immutable data structures natively, which would be a REAL low hanging fruit.

[ZephyrBlu]

I'm very curious what the better, academic version of VDOM, hooks and components that has already been done looks like in comparison to React.

[antris]

Svelte does reactive UI without a VDOM at all. Every DOM operation flows from declarative instructions based on the state of the application, without a need for VDOM or hooks.

The compiler is quite mature and used by countless apps in production right now.

https://svelte.dev/

I've been using it myself and it doesn't feel academic at all. The Svelte Kit toolkit, a successor to the Sapper frameworks is also ready to use but it's not 1.0 yet so might be a bit unstable. But if you're worried about having to figure things out then you can use Sapper+Svelte or just Svelte just fine, and they're very robust and well documented.

[ZephyrBlu]

I know what Svelte is. Svelte wasn't done before React or by "FP academics" though, which is what you said in the comment I replied to.

[antris]

As I said, the VDOM was novel. However, unidirectional data flow, lenses and FRP with RxJs all predate React. There was also Elm which was a full framework that was based on these concepts, and ClojureScript with its whole ecosystem that did things a bit differently. Though most people who do utilise functional programming concepts prefer not to use a framework but pick-and-choose libraries that do the job for that specific project. That means that the field was (and is) very scattered, and there's no single "React but better and made earlier". Because React is a unique combination of tools. But each of those tools have been done in one form or another many times, except for the VDOM, which I believe was novel.

On another note, a React component in FP is just any regular old JS function with a signature: `(state) => HTML string`. React is such a simple concept that it wouldn't have needed any sort of library, if it weren't for the performance and DOM reset issues.

[eurasiantiger]

The esotericity is not in the expressible semantics, but in the syntax.

[nextaccountic]

I think the Opa language was doing JSX-like code in the frontend before JSX http://opalang.org/

Both Opa and JSX were created in 2011. Opa had other innovations as well, such having the same code base run on both client and server (like Next.js). Unfortunately it didn't get traction and was abandoned by the creators.

[hajile]

JSX as syntax goes back to ES4 and the E4X specification (though the function aspect goes back to php as far as I know).

[ptx]

> virtual DOM diffing ... is becoming increasingly irrelevant as apps are moving towards more and more reactive architecture

Could you expand on this? What was it that necessitated DOM diffing before, and which architectural changes are making it irrelevant?

[antris]

State and DOM being mutated all over the code base was the norm before React. In many apps, state was a thing that was spread out all over the code and could be mutated by any part of the code. And a DOM was another global state on top of that, that had to be kept in sync with the data of the application. Otherwise users would be shown a state that wasn't representative of the actual state of the application. People did this with careful DOM modification code, trying to always remember to set, reset add and delete DOM nodes correctly. Of course, this caused many bugs and sometimes huge performance issues.

If you tried to solve this problem by redrawing the DOM every time your app state changed somewhere in the code, the browser would freeze and all your form elements would be defocused on every update, scroll states would be reset etc. etc.

React solved this by the diff algorithm and doing surgical updates of the dom based on the components state. It does this by manually reading the state, keeping a virtual DOM in its memory and doing diff calculations.

But if your whole app is reactive by design, there's no need to read the app state, doing diffing or figuring out which DOM node to update which one not to update. The DOM update operations flow naturally by the declarations given by the programmer. Frameworks such as Svelte are moving into this direction and they're already seeing quite significant performance improvements compared to VDOM implementations.

[atom_arranger]

The best part about React is declarative rendering, you tell React what the DOM should look like, it makes it so. React does this using a virtual representation of the DOM, but this is an implementation detail.

If you can do declarative rendering without keeping a virtual representation of the DOM and diffing it against the real DOM then "the virtual DOM is overhead" (https://svelte.dev/blog/virtual-dom-is-pure-overhead).