5 ms·

Always a huge fan of Thomas Fuch's tweet: ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writ

by neya 6y ago

Always a huge fan of Thomas Fuch's tweet: ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this. https://twitter.com/thomasfuchs/status/810885087214637057?lang=en https://twitter.com/thomasfuchs/status/810885087214637057?la...

tiborsaas 6y ago
Interesting that people in the replies are really hostile, like "vomiting" and likes. Now 4 years later it's a standard way to write frontend with JSX.
sbergot 6y ago
For css this is the best explanation that I can find: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... For react maybe this one: https://medium.com/madhash/rethinking-separation-of-concerns-with-react-7e5de1b5c0f7 https://medium.com/madhash/rethinking-separation-of-concerns... People are confusing separation of concerns with separation of languages. They are also acting as if we are all writing websites like zen garden where the html is fixed and we are changing the stylesheet every week. In reality react & most frontend technologies are used by webapp were UI consistency is achieved with a small css stylesheet and a base set of components (buttons, forms, etc). The css gives the design rules and the html implements them. The component are implemented in some files and the business rules in other files. Instead of making fun of this approach I invite you to try it out.
- mattacular 6y ago
  I've never worked on a production website or web app that managed to achieve the "small css stylesheet and a base set of components." Especially not in the responsive design era. Can it be done in theory? Sure. But in my experience working as a web developer it's one of those goals that always seems attainable at the beginning of a project but for various reasons never comes to fruition by the time it's launched and certainly not by the time it's being retired after months or even years of extending, iteration, changing development teams and maintenance.
  - ratww 6y ago
    I've worked in a few. The trick is starting with a development team with a good grasp of CSS and a designer with a clear direction, instead of jumping straight into Bootstrap or something similar. You can replace the designer with a developer with design experience. It's far from impossible. One of the coolest I did was when I was lead dev in a university and our CSS for the teacher/student dashboard was less than 20k. I used ASP.NET WebForms components, and we didn't have too much variety in terms of components. It looked pretty good for the time (2012) and it was also responsive and teachers/students added it to their iPhone/Android screen. Another one was a web version of a Windows Desktop App. Also didn't use Bootstrap, but got it done pretty quickly. Bootstrap wouldn't work for us since we had to keep the look and feel of a native app. I've also transitioned one app that had more than 1MB of minified css to less than 100kb, which is not exactly small but it's still one order of magnitude less. The trick was vendoring the three third-party frameworks we were using and removing everything we weren't using, and also using PurifyCSS to detect unused nodes and deleting them. Then we refactored to put the CSS back into Vue.js components and voila. A lot of people in HN will say it's a huge waste of time but our market was a 3rd world country, so it made a lot of financial sense for us to make me waste a week on that. One of the most fun and rewarding experiences I ever had. I wish most developers weren't so bullish about not wanting to spend time optimizing this stuff.
    - nbzso 6y ago
      "You can replace the designer with a developer with design experience. It's very far from impossible." And go ask why websites are looking the same. Disclaimer: I am designer (real one). I have become frontend dev with time and moved in this direction naturally driven by challenges in implementation. At first challenge was to move away from table based layouts (xhtlm/separation of content and presentation), next was AJAX,jQuery and now is React, Vue, Angular. In all of this mess I judge the final results. The Product is made to serve the user. In some point in time the incentive moved to "technology serves developers and business" first. This is the real problem for me. I have found in my practice when hiring designers the problem is lack of proper design foundation, using frameworks and tricks is not design process, its design implementation. I have suggestion: Obviously developers hate designers (I doubt that they have worked with real one - and reaction towards "designers" is right), do me a favor and eliminate design by building AI solution already. You have ton of historically proven quantitive data what the principles of visually good design are. Just throw it in GAN, use style transfer and do it. You can split test UX and UI and decorate the results with GAN data. Problem solved. In design space education is broken, business owners and managers don't value design highly so everyone will be happy. Designers will find what to do with their talents, don"t worry:)
- wildrhythms 6y ago
  I used to follow the "separation of concerns" ideology, but there's a single sentence in the Tailwind CSS guide[1] that changed my entire perspective on this: "No more adding silly class names like sidebar-inner-wrapper just to be able to style something, and no more agonizing over the perfect abstract name for something that's really just a flex container." I work in front-end primarily, and so much of my time is spent building a tightly coupled dependency between a HTML template and a stylesheet, coming up with names like ".container" and ".wrapper" and ".content", and when the layout changes, I have to change the stylesheet too. Do these things really need to be separated? Outside of uniquely implemented animations, I'm now of the opinion that... no, they really don't, and I've started adopting Tailwind into my projects to great success, less maintenance toil, and faster iterations. [1] https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first
  - cptskippy 6y ago
    I feel like the ability to separate concerns has been sabotaged in the pursuit of performance. It's often recommend to reduce the complexity of CSS Selectors to speed things up. Common performance analysis sites will ding your site for using all but the simplest selectors. When you couple that with tools that can never understand page layout or relationship, you get horrible CSS where every element has a corresponding unique CSS class or any number of utility classes.
- cptskippy 6y ago
  > For css this is the best explanation that I can find My take away from reading that article is that the author completely misses the fundamental concepts of CSS and only ever tried to use tools to generate it. I realize that in the pursuit of high performance websites, it's been recommended to avoid complex CSS selectors but, beyond that, the author chooses to style each element individually. I kept reading hoping for him to have an "Ah-ha!" moment but instead he just finds different ways to bang his head on the table.
dgb23 6y ago
The counterexample to this is not JS and HTML separation. It is a templating engine that pulls in data and renders HTML, not HTML, and imperative JS code that is tightly coupled to that output. HTML is inherently broken for the general use case, because it enforces a rigid tree data structure. Would you rather have a document db like mongo as your source of truth or a relational or graph db?
aphextron 6y ago
>" ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this." It's a funny observation, but not really a meaningful statement. JSX component based development saved web dev from the jQuery plugin based "truth-in-the-DOM" hell that was early web application development. Things like CSS in JS might be going a bit far, but there's nothing inherently wrong with combining HTML and JS. Most other UI development environments use this same approach (QT/QML, SwiftUI, etc.).
amelius 6y ago
The separation is still there, but you've got to train your brain to see it.
- Zelphyr 6y ago
  And therein lies the problem. That context switching comes with a cost. It's like trying to identify the eggs, chocolate chips, and flour once you've started mixing. You can do it (up to a point of course--recognizing this is where the analogy fails) but it's so much easier to do when they're not mixed together.
  - amelius 6y ago
    Perhaps your editor can help you see it (?)
    - Zelphyr 6y ago
      That's just adding yet another tool which itself requires a certain amount of context switching.
dmje 6y ago
Amen. I'm still in the "why on earth use all that React/Vue/HipsterEtc STUFF to do a simple web page?" camp. I get it for anything resembling an app, I really do - and I'm in awe of the people who can make web apps feel as responsive as desktop ones by doing some kind of magic that I don't understand. But [most] websites? IME they're all just better off being simple, solid and maintainable, not brittle or subject to the latest Cool Thing. Call me oldschool, but that also means separation of concerns in the form of HTML, CSS, Javascript...
- mirthflat83 6y ago
  I know, when the most complex thing you’re building is a simple Todo App, you don’t need all that
- tartoran 6y ago
  Not only that but the history and back button hijacking and other weird behaviours make for a really bad experience in the browser.
Grumbledour 6y ago
I feel this complaint misses the point. This code is highly readable and reminds me a lot of the early times when we build HTML in PHP. You can also use it just like that. Render it server side and be done. Maybe load some additional js to act after all that on the rendered page. Problem is, while this is the better user experience than having to download and run a react behemoth to gain basically nothing, no one seems to have come up with a good version to write this kind of heavily AJAX dependent webpage without it being a real hassle. So while react apps kind of suck from a user perspective, as a developer, my code has never looked cleaner and was never this easy to maintain because everything that happens and can happen is right there instead of been loading delayed from other files and then changing everything client side and needing additional endpoints for full html and fragments/JSON on the server. Now, sprinkling in CSS there an top of that or even one of these awful "write css in js" solutions would be were I also draw the line, though.
- mattacular 6y ago
  There are reasons why writing PHP using <?php> tags mixed in with HTML is not common practice anymore and most people tend to use a templating library to have something that feels and reads more like plain HTML.
  - Grumbledour 6y ago
    I think this is actually more a matter of taste. Been there, done that. These days I prefer to just mix in my language of choice with HTML instead of mixing it in with some extra templating language that basically does the same but is harder to read and reason about. But that is the whole debate about jsx in a nutshell I guess. Considering Reacts popularity, it is an interesting question though if templating languages replaced php and asp or are on the way out again in favor of that style of coding.
    - mattacular 6y ago
      Yes I agree it's essentially the same debate. I think it has to do with subjective taste as well as what kind of app you're building (ie. how much HTML are you templating out?) Edit: I will add that I have some experience working on apps that do both ways - React mixing HTML and CSS into the JS code (JSX) and Vue with its strange template language which extends HTML for somewhat the opposite approach. I don't really like either one that much. I still actually prefer the string templating library era as cleaner but not without its flaws.
dasil003 6y ago
A lot of the early philosophy around CSS was in response to a world of nested tables and font tag soup managed across large websites with no build step. Similarly JS was sprinkled on and wholly additive. In that world separation along file type made perfect sense. However when all your code is pre-processed before deployment, it opens the door to organizing your code in different ways. Because markup, appearance and behavior are all intimately intertwined, it’s an illusion that they can be meaningfully de-coupled. For simple document based sites with a small number of styles and a large number of homogeneous pages the classic style is good. For large web apps there is a reason React and JSX is so successful-99% of the time the visual, structural and behavioral changes happen together so it makes sense for the code to be together. The reason Webpack is so successful is because at scale it’s really hard to identify dead HTML and CSS, but if you unify under one build paradigm you can get tree-shaking that could never be made reliable with a homegrown solution or enforced coding standards.
- TeMPOraL 6y ago
  I did webdev jobs in that period and I never felt it made sense. The soup of nested tables only got replaced with a soup of nested divs, themselves already breaking the "separation of content and presentation", because many of these divs only existed to hook specific CSS rules of them. HTML markup was driven by limitations of CSS in expressing a particular graphical design of the page that you had in mind.

by neya 6y ago

tiborsaas 6y ago

Interesting that people in the replies are really hostile, like "vomiting" and likes. Now 4 years later it's a standard way to write frontend with JSX.

sbergot 6y ago

For css this is the best explanation that I can find: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-... For react maybe this one: https://medium.com/madhash/rethinking-separation-of-concerns-with-react-7e5de1b5c0f7 https://medium.com/madhash/rethinking-separation-of-concerns... People are confusing separation of concerns with separation of languages. They are also acting as if we are all writing websites like zen garden where the html is fixed and we are changing the stylesheet every week. In reality react & most frontend technologies are used by webapp were UI consistency is achieved with a small css stylesheet and a base set of components (buttons, forms, etc). The css gives the design rules and the html implements them. The component are implemented in some files and the business rules in other files. Instead of making fun of this approach I invite you to try it out.

mattacular 6y ago
I've never worked on a production website or web app that managed to achieve the "small css stylesheet and a base set of components." Especially not in the responsive design era. Can it be done in theory? Sure. But in my experience working as a web developer it's one of those goals that always seems attainable at the beginning of a project but for various reasons never comes to fruition by the time it's launched and certainly not by the time it's being retired after months or even years of extending, iteration, changing development teams and maintenance.
- ratww 6y ago
  I've worked in a few. The trick is starting with a development team with a good grasp of CSS and a designer with a clear direction, instead of jumping straight into Bootstrap or something similar. You can replace the designer with a developer with design experience. It's far from impossible. One of the coolest I did was when I was lead dev in a university and our CSS for the teacher/student dashboard was less than 20k. I used ASP.NET WebForms components, and we didn't have too much variety in terms of components. It looked pretty good for the time (2012) and it was also responsive and teachers/students added it to their iPhone/Android screen. Another one was a web version of a Windows Desktop App. Also didn't use Bootstrap, but got it done pretty quickly. Bootstrap wouldn't work for us since we had to keep the look and feel of a native app. I've also transitioned one app that had more than 1MB of minified css to less than 100kb, which is not exactly small but it's still one order of magnitude less. The trick was vendoring the three third-party frameworks we were using and removing everything we weren't using, and also using PurifyCSS to detect unused nodes and deleting them. Then we refactored to put the CSS back into Vue.js components and voila. A lot of people in HN will say it's a huge waste of time but our market was a 3rd world country, so it made a lot of financial sense for us to make me waste a week on that. One of the most fun and rewarding experiences I ever had. I wish most developers weren't so bullish about not wanting to spend time optimizing this stuff.
  - nbzso 6y ago
    "You can replace the designer with a developer with design experience. It's very far from impossible." And go ask why websites are looking the same. Disclaimer: I am designer (real one). I have become frontend dev with time and moved in this direction naturally driven by challenges in implementation. At first challenge was to move away from table based layouts (xhtlm/separation of content and presentation), next was AJAX,jQuery and now is React, Vue, Angular. In all of this mess I judge the final results. The Product is made to serve the user. In some point in time the incentive moved to "technology serves developers and business" first. This is the real problem for me. I have found in my practice when hiring designers the problem is lack of proper design foundation, using frameworks and tricks is not design process, its design implementation. I have suggestion: Obviously developers hate designers (I doubt that they have worked with real one - and reaction towards "designers" is right), do me a favor and eliminate design by building AI solution already. You have ton of historically proven quantitive data what the principles of visually good design are. Just throw it in GAN, use style transfer and do it. You can split test UX and UI and decorate the results with GAN data. Problem solved. In design space education is broken, business owners and managers don't value design highly so everyone will be happy. Designers will find what to do with their talents, don"t worry:)
wildrhythms 6y ago
I used to follow the "separation of concerns" ideology, but there's a single sentence in the Tailwind CSS guide[1] that changed my entire perspective on this: "No more adding silly class names like sidebar-inner-wrapper just to be able to style something, and no more agonizing over the perfect abstract name for something that's really just a flex container." I work in front-end primarily, and so much of my time is spent building a tightly coupled dependency between a HTML template and a stylesheet, coming up with names like ".container" and ".wrapper" and ".content", and when the layout changes, I have to change the stylesheet too. Do these things really need to be separated? Outside of uniquely implemented animations, I'm now of the opinion that... no, they really don't, and I've started adopting Tailwind into my projects to great success, less maintenance toil, and faster iterations. [1] https://tailwindcss.com/docs/utility-first https://tailwindcss.com/docs/utility-first
- cptskippy 6y ago
  I feel like the ability to separate concerns has been sabotaged in the pursuit of performance. It's often recommend to reduce the complexity of CSS Selectors to speed things up. Common performance analysis sites will ding your site for using all but the simplest selectors. When you couple that with tools that can never understand page layout or relationship, you get horrible CSS where every element has a corresponding unique CSS class or any number of utility classes.
cptskippy 6y ago
> For css this is the best explanation that I can find My take away from reading that article is that the author completely misses the fundamental concepts of CSS and only ever tried to use tools to generate it. I realize that in the pursuit of high performance websites, it's been recommended to avoid complex CSS selectors but, beyond that, the author chooses to style each element individually. I kept reading hoping for him to have an "Ah-ha!" moment but instead he just finds different ways to bang his head on the table.

dgb23 6y ago

The counterexample to this is not JS and HTML separation. It is a templating engine that pulls in data and renders HTML, not HTML, and imperative JS code that is tightly coupled to that output. HTML is inherently broken for the general use case, because it enforces a rigid tree data structure. Would you rather have a document db like mongo as your source of truth or a relational or graph db?

aphextron 6y ago

>" ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this." It's a funny observation, but not really a meaningful statement. JSX component based development saved web dev from the jQuery plugin based "truth-in-the-DOM" hell that was early web application development. Things like CSS in JS might be going a bit far, but there's nothing inherently wrong with combining HTML and JS. Most other UI development environments use this same approach (QT/QML, SwiftUI, etc.).

amelius 6y ago

The separation is still there, but you've got to train your brain to see it.

Zelphyr 6y ago
And therein lies the problem. That context switching comes with a cost. It's like trying to identify the eggs, chocolate chips, and flour once you've started mixing. You can do it (up to a point of course--recognizing this is where the analogy fails) but it's so much easier to do when they're not mixed together.
- amelius 6y ago
  Perhaps your editor can help you see it (?)
  - Zelphyr 6y ago
    That's just adding yet another tool which itself requires a certain amount of context switching.

dmje 6y ago

Amen. I'm still in the "why on earth use all that React/Vue/HipsterEtc STUFF to do a simple web page?" camp. I get it for anything resembling an app, I really do - and I'm in awe of the people who can make web apps feel as responsive as desktop ones by doing some kind of magic that I don't understand. But [most] websites? IME they're all just better off being simple, solid and maintainable, not brittle or subject to the latest Cool Thing. Call me oldschool, but that also means separation of concerns in the form of HTML, CSS, Javascript...

mirthflat83 6y ago
I know, when the most complex thing you’re building is a simple Todo App, you don’t need all that
tartoran 6y ago
Not only that but the history and back button hijacking and other weird behaviours make for a really bad experience in the browser.

Grumbledour 6y ago

I feel this complaint misses the point. This code is highly readable and reminds me a lot of the early times when we build HTML in PHP. You can also use it just like that. Render it server side and be done. Maybe load some additional js to act after all that on the rendered page. Problem is, while this is the better user experience than having to download and run a react behemoth to gain basically nothing, no one seems to have come up with a good version to write this kind of heavily AJAX dependent webpage without it being a real hassle. So while react apps kind of suck from a user perspective, as a developer, my code has never looked cleaner and was never this easy to maintain because everything that happens and can happen is right there instead of been loading delayed from other files and then changing everything client side and needing additional endpoints for full html and fragments/JSON on the server. Now, sprinkling in CSS there an top of that or even one of these awful "write css in js" solutions would be were I also draw the line, though.

mattacular 6y ago
There are reasons why writing PHP using <?php> tags mixed in with HTML is not common practice anymore and most people tend to use a templating library to have something that feels and reads more like plain HTML.
- Grumbledour 6y ago
  I think this is actually more a matter of taste. Been there, done that. These days I prefer to just mix in my language of choice with HTML instead of mixing it in with some extra templating language that basically does the same but is harder to read and reason about. But that is the whole debate about jsx in a nutshell I guess. Considering Reacts popularity, it is an interesting question though if templating languages replaced php and asp or are on the way out again in favor of that style of coding.
  - mattacular 6y ago
    Yes I agree it's essentially the same debate. I think it has to do with subjective taste as well as what kind of app you're building (ie. how much HTML are you templating out?) Edit: I will add that I have some experience working on apps that do both ways - React mixing HTML and CSS into the JS code (JSX) and Vue with its strange template language which extends HTML for somewhat the opposite approach. I don't really like either one that much. I still actually prefer the string templating library era as cleaner but not without its flaws.

dasil003 6y ago

A lot of the early philosophy around CSS was in response to a world of nested tables and font tag soup managed across large websites with no build step. Similarly JS was sprinkled on and wholly additive. In that world separation along file type made perfect sense. However when all your code is pre-processed before deployment, it opens the door to organizing your code in different ways. Because markup, appearance and behavior are all intimately intertwined, it’s an illusion that they can be meaningfully de-coupled. For simple document based sites with a small number of styles and a large number of homogeneous pages the classic style is good. For large web apps there is a reason React and JSX is so successful-99% of the time the visual, structural and behavioral changes happen together so it makes sense for the code to be together. The reason Webpack is so successful is because at scale it’s really hard to identify dead HTML and CSS, but if you unify under one build paradigm you can get tree-shaking that could never be made reliable with a homegrown solution or enforced coding standards.

TeMPOraL 6y ago
I did webdev jobs in that period and I never felt it made sense. The soup of nested tables only got replaced with a soup of nested divs, themselves already breaking the "separation of content and presentation", because many of these divs only existed to hook specific CSS rules of them. HTML markup was driven by limitations of CSS in expressing a particular graphical design of the page that you had in mind.