Hacker News Reader

Comment by neya | Hacker News Reader

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?la...

View on HN

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.

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.

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.

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.

A templating library that re-implements in a bad way what existing programming languages already do, yes. Honestly this is one of the few things that php/asp/etc got right.

Indeed. IMHO, using a templating library is a very bad idea in the first place[0] - but if you have to glue strings to build markup, then use a regular programming language for that. If you look at popular templating libraries, it's easy to notice how, over time, they all became crappy, Turing-complete programming languages, inferior to just doing <?= ... =?> in PHP.

[0] - HTML is a tree serialization format, and templates are assembling it by gluing raw, dumb strings together. It's a recipe for disaster. The equivalent thing in SQL is the source of SQL Injection category of bugs. You really should use a tool that respect the semantics of the language.

> You really should use a tool that respect the semantics of the language.

What tool are you referring to? If one does not exist, why is that?

HTML generators that work on trees. They do exist, and they're very popular in Lisp world, though they also exist elsewhere.

So instead of reading a template file and interpolating it with strings, you'd write something like (using JS / PHP syntax):

  const html =
    ['form', {action: myHandlerUrl, method: 'post'},
      ['input', {id: 'key', name: 'key', type: 'hidden', value: randomKey()}],
      ['button', {type: 'submit'}, "Send!"]];

  OutputHtml(html);

With OutputHtml() being the replacement for templating engine. The above structure is semantically a tree, and you can't in any way screw it up as to leave tags incorrectly nested (it won't compile/interpret). It's composable too - you can concatenate a bunch of such representations and always get a result that represents a valid tree. OutputHtml() is relatively easy to write even by yourself, because at any given time, when turning a dynamic value into output HTML, it's apparent how the value has to be converted (and/or "escaped").

SQL also has its equivalents of this idea. The most basic of which is "prepared statements" - an API in which, instead of:

  query("SELECT foo, bar FROM baz WHERE bar = " + userInput
        " AND foo > " + anotherInput);

you write:

  query(build("SELECT foo, bar FROM baz WHERE bar = ? AND foo > ?"), userInput, anotherInput)

which against gives the API the most basic ability to recognize and encode interpolated values correctly. There are of course more complex libraries available, which let you parametrize any part of an SQL query, while making the generation template respect SQL's semantics, and that use composable representations.

I love reading this, because PHP is a templating language first, that can do more complex things separately. There is nothing wrong of using <?php> tags in your HTML, and put your logics in .php files.

To the contrary, there's absolutely nothing wrong with using HTML as text format with helper programs to generate dynamic content. It's how the web started with super-practical, no-nonsense backend scripting. I've worked with React and even like it when it fits (eg. a highly interactive app where everything can change at any time). But it doesn't do anything for content-driven sites yet requires enormous infrastructure compared to just run stuff on the command line.

Where PHP got it wrong is that it did just such a hack job of pasting program output into HTML without HTML-aware, injection-free templating for us to endure in the form of DoS attacks. When all this was readily available - you just don't use SGML processing instructions (eg "<?php ..." which is just a fallback method of last resort) but regular, typed entity expansion, with escaping depending on markup context and content model checking for rejecting eg. script elements in user content.

For css this is the best explanation that I can find: https://adamwathan.me/css-utility-classes-and-separation-of-...

For react maybe this one: 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.

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.

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.

"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:)

Functional libraries such as tailwindcss are popular because they are a good way to achieve this goal.

Maybe if you're not working with a designer/team.

I promise you can achieve what the designer envisions with Tailwind, and I would challenge you to describe a design case outside of Tailwind's abilities. I was skeptical too for a long time.

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

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.

> 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.

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.

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.

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.

>" ~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.).

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...

I know, when the most complex thing you’re building is a simple Todo App, you don’t need all that

Not only that but the history and back button hijacking and other weird behaviours make for a really bad experience in the browser.

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?

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

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.

Perhaps your editor can help you see it (?)

That's just adding yet another tool which itself requires a certain amount of context switching.

Reply on news.ycombinator.com