3 ms·

It's interesting to see a somewhat widespread shift away from the separation of code, templates, styles, and text model of publishing things (mostly websites, b

It's interesting to see a somewhat widespread shift away from the separation of code, templates, styles, and text model of publishing things (mostly websites, but most publishing can be boiled down to that if you squint), where code/templates/style get merged into one. React does this. Pollen seemingly takes it even further and sticks the text in the code, too. Or, rather sticks the code in the text, I guess. It's a surprising shift. "Separation of concerns" is still a thing everybody wants to do, it's just flipping the idea of what should be the same "concern", where React considers every piece of a component to be one concern...and, it seems to work. I'm not sure I'm on board with this for writing, but the results certainly do look very nice; the books the author has published with Pollen all look gorgeoues and are very navigable. I've been tinkering with Hugo for converting my projects docs to something that isn't in a wiki or a CMS (because I find I dread working with either a wiki or a CMS for large documents). I think it's probably "enough" for all of my needs, so I doubt I'll take the time to learn a bigger system like Pollen...but, it's hard to argue with the quality of the results.

dfischer 9y ago
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.
egeozcan 9y ago
IMHO, it is a move from separation of file types to separation of actual concerns.
- kuschku 9y ago
  Well, these are separate concerns. If you have a document, with no interactivity, using just standard elements, but lots of different themes, then separating into content and style makes perfect sense. And I’d prefer if we could go back to that as much as possible.
  - egeozcan 9y ago
    Yes, a general template defined in an external style sheet or whatever format makes sense. However, revealing a message when there is an error, for example, is business logic and should be defined in code - be it styled components or something else.
jcelerier 9y ago
> "Separation of concerns" is still a thing everybody wants to do Separation of concerns was a problem twenty years ago when source code looked like [this](https://github.com/kmainyu/EveHQ/blob/c3406c9cffca744500213f1d5294644dc484e52a/EveHQ/Forms/frmSettings.vb#L1860 https://github.com/kmainyu/EveHQ/blob/c3406c9cffca744500213f...). Since then the tools & languages have reached, maybe not the optimal abstraction level, but at least damn close to it. Everything is here to build apps as fast as possible ; the only thing left to do is write the actual software.
TeMPOraL 9y ago
Note that e.g. TeX is a programming language, and for a reason. Personally, I quickly become disillusioned about "separation of concern". It was a webdev slogan that ignored the fact that form is also content. I mean, it makes sense if all you're doing is hyperlinked free-form documents. But the web ended up being used for web sites (and later web apps), where how you say something matters just as much as what you say. Separation of concerns is not an adequate rule for those kinds of works. You could see its death in every site that had its HTML littered with divs that existed only to hang JS code and CSS rules off them (and for some reason people still believed they're "separating concerns" there). And books, again, are different from free-form documents. Their layout/typesetting decisions are often important part of the content. I think the shift you noticed is a welcome breath of sanity into this space.
otakucode 9y ago
I don't find it that surprising. It's the Literate Programming Knuth came up with ages ago. I own a book called 'Physically Based Rendering' which deals with rendering images through, essentially, simulation of the physics of light which is written in the same manner. As far as I know, Knuths work and the Physically Based Rendering book are the only ones published which are of that type... well until I saw this posting this morning, that is!
- ekr 9y ago
  There are others as well. "A Retargetable C Compiler: Design and Implementation" by David R. Hanson, Christopher W. Fraser is the first that comes to mind. But sure, there aren't a lot of them out there.

dfischer 9y ago

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.

egeozcan 9y ago

IMHO, it is a move from separation of file types to separation of actual concerns.

kuschku 9y ago
Well, these are separate concerns. If you have a document, with no interactivity, using just standard elements, but lots of different themes, then separating into content and style makes perfect sense. And I’d prefer if we could go back to that as much as possible.
- egeozcan 9y ago
  Yes, a general template defined in an external style sheet or whatever format makes sense. However, revealing a message when there is an error, for example, is business logic and should be defined in code - be it styled components or something else.

jcelerier 9y ago

> "Separation of concerns" is still a thing everybody wants to do Separation of concerns was a problem twenty years ago when source code looked like [this](https://github.com/kmainyu/EveHQ/blob/c3406c9cffca744500213f1d5294644dc484e52a/EveHQ/Forms/frmSettings.vb#L1860 https://github.com/kmainyu/EveHQ/blob/c3406c9cffca744500213f...). Since then the tools & languages have reached, maybe not the optimal abstraction level, but at least damn close to it. Everything is here to build apps as fast as possible ; the only thing left to do is write the actual software.

TeMPOraL 9y ago

Note that e.g. TeX is a programming language, and for a reason. Personally, I quickly become disillusioned about "separation of concern". It was a webdev slogan that ignored the fact that form is also content. I mean, it makes sense if all you're doing is hyperlinked free-form documents. But the web ended up being used for web sites (and later web apps), where how you say something matters just as much as what you say. Separation of concerns is not an adequate rule for those kinds of works. You could see its death in every site that had its HTML littered with divs that existed only to hang JS code and CSS rules off them (and for some reason people still believed they're "separating concerns" there). And books, again, are different from free-form documents. Their layout/typesetting decisions are often important part of the content. I think the shift you noticed is a welcome breath of sanity into this space.

otakucode 9y ago

I don't find it that surprising. It's the Literate Programming Knuth came up with ages ago. I own a book called 'Physically Based Rendering' which deals with rendering images through, essentially, simulation of the physics of light which is written in the same manner. As far as I know, Knuths work and the Physically Based Rendering book are the only ones published which are of that type... well until I saw this posting this morning, that is!

ekr 9y ago
There are others as well. "A Retargetable C Compiler: Design and Implementation" by David R. Hanson, Christopher W. Fraser is the first that comes to mind. But sure, there aren't a lot of them out there.