Deku: How we built our functional alternative to React

Re:Deku: How we built our functional alternative to React by sls on Monday May 11, 2015 @09:23PM (#9528980)

I reflexively dislike the notion, but am trying to consider it with an open mind. The notion that a subtree of the DOM and some JavaScript that manipulates it, designed together to create a single functional component, represent a single concern and should be packaged together, is not unreasonable.

I think it is very different than the spaghetti pages found in jsps and php pages of yore, and the emphasis on component is a big part of why.

[ Parent | on HN ]

Re:Deku: How we built our functional alternative to React by visarga on Tuesday May 12, 2015 @12:05AM (#9529548)

I took the same route - instead of trying to keep HTML in one place, JS in another, CSS in another I made separate files for each component including all the necessary HTML, JS and CSS in one file. It makes more sense because I write them together and debug them together. Also, I don't need to find where are the CSS selectors in a huge monolithic CSS file, or the same about JS functions. I don't let a component become too complex, so the 1 file/component ratio is just right.

[ Parent | on HN ]

Re:Deku: How we built our functional alternative to React by wtetzner on Sunday May 17, 2015 @01:19AM (#9558822)

> The notion that a subtree of the DOM and some JavaScript that manipulates it, designed together to create a single functional component, represent a single concern and should be packaged together, is not unreasonable.

I think part of the problem is how you think about it. You're not writing some HTML and then some Javascript to manipulate it. Conceptually, you're writing a Javascript function to create a chunk of HTML.

[ Parent | on HN ]