4 ms·

When I learned HTML in the 90's and early 2000's you got a strong notion that they were separate concerns. When I was learning react when it came out I had suc

When I learned HTML in the 90's and early 2000's you got a strong notion that they were separate concerns. When I was learning react when it came out I had such a visceral reaction I just wanted to run away. After coding within react for the past couple years I strongly feel that react has got it right. A concern is after all a generality that has the potential to generate a strong bias. My lesson is that concerns should be taken with a grain of salt, and be willing to try new things with as little as bias as possible; and then form a new opinion, maybe a slightly different concern. P.s I have also started writing CSS in our presentational focuses react components and I couldn't be happier. It naturally did a BEM-like architecture. I highly recommend it. I say this with extensive experience of CSS architecture for applications.

jv22222 9y ago
At the moment my favorite thing to do is think about each web page as a cohesive collection of components that are the sum of what it takes to make that web page work. ie css, html and javascript for that page contained within that page. Then, as you notice common use cases accross pages start to abstract them to a central library (be it js, css). This way it makes it easy to develop any size application because each page is coded as needed and code relevant to each page is always right there with it. I've worked on plenty of codebases that start out with a central library and then build outward but they always seem harder to maintain due multiple layers of abstraction. I guess, in summary, this method is a way to lazy load abstraction.
bauerd 9y ago
Of course React got it right because there's no violation of separation of concerns involved. JSX is just syntactic sugar on top of method calls. One is perfectly free to extract the `render` functions into separate files and call them "templates". Unless the argument is that virtual DOM libraries are an inherently bad idea, I don't see what's to complain about separation of concerns.
- stdbrouw 9y ago
  Separation of concerns is about both the structure of a piece of code (which is what you refer to) and about how it is organized in files, folders and mentally (which is what others refer to).
  - bauerd 9y ago
    As I said, you're free to do this to yourself. Put every function that calls `React.createElement` in a separate file/directory and import it.

jv22222 9y ago

At the moment my favorite thing to do is think about each web page as a cohesive collection of components that are the sum of what it takes to make that web page work. ie css, html and javascript for that page contained within that page. Then, as you notice common use cases accross pages start to abstract them to a central library (be it js, css). This way it makes it easy to develop any size application because each page is coded as needed and code relevant to each page is always right there with it. I've worked on plenty of codebases that start out with a central library and then build outward but they always seem harder to maintain due multiple layers of abstraction. I guess, in summary, this method is a way to lazy load abstraction.

bauerd 9y ago

Of course React got it right because there's no violation of separation of concerns involved. JSX is just syntactic sugar on top of method calls. One is perfectly free to extract the `render` functions into separate files and call them "templates". Unless the argument is that virtual DOM libraries are an inherently bad idea, I don't see what's to complain about separation of concerns.

stdbrouw 9y ago
Separation of concerns is about both the structure of a piece of code (which is what you refer to) and about how it is organized in files, folders and mentally (which is what others refer to).
- bauerd 9y ago
  As I said, you're free to do this to yourself. Put every function that calls `React.createElement` in a separate file/directory and import it.