
When Does a Project Need React? - mambodog
https://css-tricks.com/project-need-react/
======
romaniv
_> Manually handling the DOM is probably the biggest cause of spaghetti code._

This isn't true. The biggest cause of spaghetti code in "traditional" JS is
due to having multiple conflicting sources of truth for the same pieces of
state information (usually split between JS variables and DOM) and subsequent
multi-directional synchronization.

Having a model that drives all DOM is one way to solve this. However, having
"canonical" representation of your state in DOM works as well.

~~~
mambodog
I think manual DOM manipulation and lack of canonical state representation are
both sources of spaghetti code; which one hurts more depends on the type of
app you're building.

Having the DOM as your canonical representation of state is only suitable for
apps with limited state IMO, because your state effectively has to be turned
into text (CSS class names and element attributes) whenever it is mutated,
which becomes a liability as the complexity of your app state grows.

------
bmer
I don't do any web-dev, so I apologize for the simplistic question: what
alternatives to JavaScript exist for web-dev? The article hints to there being
many alternatives, and that JavaScript may not be right for every
project...but I can't think of any alternatives.

Python? C++? Do these languages have strong support for web stuff?

~~~
GhostVII
JavaScript is basically the only option for front end web dev (unless you do
web assembly, but that's pretty new). There are lots of different JavaScript
frameworks that you can use, including react, so I think they are referring to
the alternative frameworks rather than languages.

~~~
vmasto
Certainly not the only language, see my reply above (or below depending).
There are a lot of great languages which either compile to JS perfectly or
have been built with that purpose in mind.

------
ungzd
React is 38.7K + 7.3K = 46K minified + gzipped. Jquery is 34.6K. And React is
not super-slow. What makes modern sites bloated and slow is definitely not
React. Why not use it even for simple UIs (that may grow into complex after
some time) if you find it useful and convenient?

~~~
blauditore
React and jQuery are two quite different things. React is more a framework,
jQuery more a helper library.

Saying one is slower than the other doesn't really make sense, since they
solve problems in different ways. You can argue that in many scenarios with
complex front end applications, it's easier to avoid performance or spaghetti
issues when using React instead of jQuery, but there are also cases where
jQuery is more convenient and leaves you with more control.

------
z3t4
you should not store the state in the view layer. the easiest aproach is to
store the state in the backend database layer.

~~~
mambodog
What about 'view state' such as which tokens have been typed into a
typeahead/tagging style input? Or the expansion state of levels of a tree
view? The active tab of a tabbed UI?

~~~
z3t4
If nothing depends on the tagging, tree view or witch tab is active, then it's
fine. Or if the state is discarded once the user click the "post" button it's
also fine. But as features gets added things tend to "entangle" and things get
more complicated. You'll end up with weird bugs like when the user has the app
open in two tabs, or on two or more devices, where for example a message is
marked as "read" on one devices but not the other. Or if two models interacts
with the same view and races to change the state or just overwrites it.

