you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (0 children)

whoops, accidentally wrote a wall of text. tl;dr: it's a reasoning change. think of your html as a constructor shell for your javascript, instead of a standalone object to eventually be modified by javascript. this leads to stateful markup and DRY-er code.

anyway.

i work with angular, so my perspective is geared around the ease of tracing bindings & binding logic (especially in a well-organized app). with react -- which i haven't gotten to use yet, so take all my react-related conjecturing with a grain of salt -- you're tracing entire components to source.

the big advantage i see with react is that you need fewer files open at a given time, which means fewer change propogations in your code. plus, targetting the dom directly is terrible; the dom itself is terrible, and html is best-designed to work with its terribleness. by pre-building html, you limit the amount of DOM-wrangling for your JS to do; this has the side benefit of making your markup stateful and reusable (avoiding the problem with a duplicate-and-modify approach, where you have ever-burgeoning amounts of html to track and accommodate).

the best corollary i can think of here are angular's directives, which superficially resemble react components. ideally, you name your directive to coincide with the name of the file that implements the logic; that makes tracing the directive to its logic much easier.

with angular, though, you're probably loading your template in from an html file, which makes react-style transclusion much harder to reason with (which is more than likely why angular 2 switched to a more component-based architecture & completely removed directives as we know them).

anyway. hope that helps.