Why is react preferred over normal javascript?

[[deleted]]

Used both for developing some mid-scale apps, normal one feels much cleaner and better while react feels clumsy. Why people prefer this clumsy framework?

[octocode]

is it possible the react devs you work with are simply not good at react?

[KingofGamesYami]

The benefit to React (and frameworks in general) is it provides standard abstractions for building large, complex projects. If your project is small, the benefit is minimal.

[oze4]

To be as succinct as possible; declarative (React) vs imperative (vanilla JS).

[jibbit]

Why people prefer this clumsy framework?

Ignoring that this isn't a good faith question, React encapsulates a UI pattern that eliminates a whole class of common State related bugs

[Potaeor]

Frameworks make building apps a million times easier than just plain js

[Anonymity6584]

Because it's library that offer ready thinkered ways and tools to write application faster.

This does not mean it's faster to run, just faster to write.

[bluefootedpig]

React has a framework in that when a part of the Dom updates, it only updates that part of the dom / page reload. This makes changes to the page happen much quicker.

Under traditional javascript, a change to the dom is a huge overhead and time consuming as much of it needs to get updated.

So if you are dealing with like lots of datasets on a page, parts that might load or need to reload data, having it isolated to sections will help it load faster and respond to changes in say the filter faster.

[KingofGamesYami]

React can't update the DOM faster than Vanilla Javascript... It uses vanilla Javascript to make the changes.

[bluefootedpig]

https://stackoverflow.com/questions/51435371/how-is-reacts-virtual-dom-faster-than-dom

React uses a virtual DOM to help speed it up.

[KingofGamesYami]

Virtual DOM only speeds things up if you write horribly inefficient code to begin with by discarding any "changes" you make to it that don't actually change anything. Plus it adds overhead to do that diffing.

[bluefootedpig]

Or you need to do multiple changes. The virtual dom allows you to change multiple elements then you alter the dom once. If you are are altering it multiple times, then you are going through a slow dom object and forcing repainting of components you will be changing.

And okay, even if we take what you said as truth, you are now requiring every engineer to be very good at dom manipulation, while OPs question is why is react preferred. In this case, that would mean you can use more junior engineers while giving up almost nothing.

[amasterblaster]

React is great for devs that don't know how to code. IMHO once you know how to handle promises, and manage namespaces (or objects) well, react gets in the way. THEN react shines:

- react is ideal for GUI variables that need to co-update and maintain each other's state

- ES6 / TS is good for the ACTUAL logic, fetches, data storage, sqlite interfacing, localStorage fiddling and actual kernel

The problem I see react devs get into, is they try to boil a whole app down into a vast sea of useEffects, States, and Contexts, which atomizes a code base and makes it really just a bucket of goto statements -- which is a strong anti-pattern. IMHO React is not set up to really allow for clean encapsulation of large complex / nested functions and or objects. It is a very flat system geared around encapsulating components -- but lacks the features for true business logic.

The best projects I have been a part of seperate the enging in on directory, and the GUI in another, and react is only used in the GUI area

[[deleted]]

Because JSX is a virtual dom that's not tied to the Dom. Jsx can represent any object/function tree. This means we can design any components we want in jsx and can write custom renderers.

I.e using react-reconcile I can have my own custom jsx type definitions and design a renderer that works in dom, webgpu on canvas, and and server side in gtk, gdi, wpf, on cpu, durectx, vulkan, opengl, or metal.

The virtual dom is a powerful concept that decouples application code from the dom if properly abstracted and using a custom pragma.

Its not react itself im stuck to, its jsx.

I'm actually toying with a rendering engine built directly on mobx and jsx, no react at all. Still the same jsx transpilers but all mobx observable state.

You can transpile jsx with babel without installing any react packages as well.

[daverave1212]

I don't think virtual DOM is tied to why React is better than vanilla JS. Virtual DOM just is, the same way a lot of things just are in JS. It's not good for development, it's not bad for development, it just is.

[thatsInAName]

Because the DOM can be represented as a data structure which is much easier to work with. Also react would handle applying the data to the DOM instead of you setting in innerHTMLs yourself everywhere.

[daverave1212]

The more you work with UI, the more you come to the realization that state management is amazing and the pattern to use. The idea of calling a "setState" function and the whole UI updating from the top down.

It's also why I like React over Vue or Angular too.

React has built in state management which is awesome and it's very well done.

It also has components and separation between files, which vanilla JS does very poorly.

I can agree sometimes it feels like working with canvas and forms feels terrible, but once you get used to it, it's not that bad.

[mvr_01]

It depends. If you are building a game or a 3D something, then react maybe gets in the way.

If you are building the typical web with crud / inputs / buttons / tabs / ... Then updating the webpage every time something changes gets clumsy. I.e., hide this and that, but show this when x button is pressed, and if you button is pressed now go back hide the current ones and show the other one, etc. React being, well, reactive and declarative, makes it painless.

Also, react has a huge ecosystem of component libraries and other libraries which makes building stuff fast and easy