It’s good for users that HTML, CSS and JS are separate languages(hiddedevries.nl)
hiddedevries.nl
It’s good for users that HTML, CSS and JS are separate languages
https://hiddedevries.nl/en/blog/2020-11-25-why-its-good-for-users-that-html-css-and-js-are-separate-languages/
12 comments
HTML was for providing declarative markup.
CSS was for styling that on a user-agent.
JS was for enhancing the capabilities of the user-agent in the context of the markup.
We then tried to make what was basically gopher++ into an app framework. Then we wanted all user-agents to behave the same, wanted pixel perfection. This meant we didn't empower user-agents to make their own presentation decisions.
Glad you refer to SGML, I thought XHTML was amazing at the time too, then HTML5 broke compatibility with everything. JSON has been inferior in every way, but XML and attendant standards had also blossomed into fractal complexity. Ever try XSL-FO?
Everyone can roll a wheel, and imagine a vehicle, but not everyone can build a car, at least not without engaging with some complexity. We need better tools for the middle ground, but need to avoid building new layers of abstraction that pretend the complexity isn't there.
We then tried to make what was basically gopher++ into an app framework. Then we wanted all user-agents to behave the same, wanted pixel perfection. This meant we didn't empower user-agents to make their own presentation decisions.
Glad you refer to SGML, I thought XHTML was amazing at the time too, then HTML5 broke compatibility with everything. JSON has been inferior in every way, but XML and attendant standards had also blossomed into fractal complexity. Ever try XSL-FO?
Everyone can roll a wheel, and imagine a vehicle, but not everyone can build a car, at least not without engaging with some complexity. We need better tools for the middle ground, but need to avoid building new layers of abstraction that pretend the complexity isn't there.
> Glad you refer to SGML, I thought XHTML was amazing at the time too, then HTML5 broke compatibility with everything.
HTML5 was explicitly designed for backward-compat with the large body of HTML4 (and earlier) content out there. And HTML5 can still be parsed using SGML, which as a superset of XML is every bit as powerful as XML, yet also has tag inference, attribute shortforms, and other minimization features dropped from the XML subset of SGML that are necessary for HTML, though. So there's no reason to be bitter about XML's demise on the web; I've even written a tutorial for XML workflows involving HTML integration or output using SGML [1].
[1]: http://sgmljs.net/docs/sgml-html-tutorial.html
> XML and attendant standards had also blossomed into fractal complexity.
Fully agree. It appears that once XML was out there, people wanted to apply it to each and everything. When markup is really only useful for semistructured text. In that department, you actually might find SGML much more useful, since not only can it deal with HTML, it can also parse markdown or other custom syntax (even JSON and s-exprs!), has built-in styling and transformation facilities capturing core CSS, and much more powerful templating and transclusion/fragment reuse mechanisms for actual text authoring and processing.
HTML5 was explicitly designed for backward-compat with the large body of HTML4 (and earlier) content out there. And HTML5 can still be parsed using SGML, which as a superset of XML is every bit as powerful as XML, yet also has tag inference, attribute shortforms, and other minimization features dropped from the XML subset of SGML that are necessary for HTML, though. So there's no reason to be bitter about XML's demise on the web; I've even written a tutorial for XML workflows involving HTML integration or output using SGML [1].
[1]: http://sgmljs.net/docs/sgml-html-tutorial.html
> XML and attendant standards had also blossomed into fractal complexity.
Fully agree. It appears that once XML was out there, people wanted to apply it to each and everything. When markup is really only useful for semistructured text. In that department, you actually might find SGML much more useful, since not only can it deal with HTML, it can also parse markdown or other custom syntax (even JSON and s-exprs!), has built-in styling and transformation facilities capturing core CSS, and much more powerful templating and transclusion/fragment reuse mechanisms for actual text authoring and processing.
Interesting. Makes me wonder if even YAML could be brought to heel ...
There was a moment in the web's history where we were trying to figure out how to make XML, HTML, RSS, and 'microformats' all play well together. Next to that were a million authors of WordPress themes who thought 'semantics' was academic rubbish, and just wanted to make the web into another word processor. We got OWL, RDF triples, and no-one paid attention, and just carried on farming complexity.
The cries for simplification are more the result of the tooling, build chains, etc., in my mind than the core tech of HTML, CSS, JS. I'm just concerned that we redouble the complexity by inventing new abstractions to wrap the old.
There was a moment in the web's history where we were trying to figure out how to make XML, HTML, RSS, and 'microformats' all play well together. Next to that were a million authors of WordPress themes who thought 'semantics' was academic rubbish, and just wanted to make the web into another word processor. We got OWL, RDF triples, and no-one paid attention, and just carried on farming complexity.
The cries for simplification are more the result of the tooling, build chains, etc., in my mind than the core tech of HTML, CSS, JS. I'm just concerned that we redouble the complexity by inventing new abstractions to wrap the old.
> HTML5 broke compatibility with everything
How? It's backward compatible, it's the first spec that tells the browsers how they should handle errors and introduced new semantics. Semantics that gracefully degrade in non html5 browsers, I find this thing simply wonderful. It's for this same reason sites like https://spacejam.com/ still renders fine like they did back then.
HTML5 is no longer XHTML compliant. There were a suite of tools that worked with markup that weren't browsers. This allowed the web to be the input, output, and middle of other chains of tools. It was sort of like removing '|' from the CLI.
I still don't get it, HTML5 lets you write your documents in XHTMLish way. The spec doesn't care, you just decide. And tools should still work as expected
And BWT it was xhtml to broke backward compatibility "XHTML is not compatible with the IE8 and other older versions of the browsers. HTML5 is capable of using XHTML style tags but not vice versa. While writing code in XHTML, there are several restrictions that the developers need to adhere to"
HTML5 documents are not XML; this means that tooling that isn't a browser, or isn't 'HTML aware' became excluded. The web 'special cased' itself at this point, and HTML and common data processing pipelines of the time parted ways, this is my only point.
You can't compare it to the pipe operator, you can still write xhtml valid documents in html5
But most of HTML5 documents aren't written like that, which is the problem.
> The result is a media format that is simply unusable for creating acceptable results by a layman
Not that I disagree, the web is a mess, but to be really fair, is there any media format, like at all, that can be used by a layman to achieve reasonable results? The only one I can think of is latex, and that requires taking a very generous definition of 'layman'.
The real problem I'm seeing here is that the web was designed as a document presentation media when what everyone really wanted from the get go was an application platform, and we're forever stuck in this contradiction because frankly every other platform has entirely disjoint but at least equally grievous issues.
Not that I disagree, the web is a mess, but to be really fair, is there any media format, like at all, that can be used by a layman to achieve reasonable results? The only one I can think of is latex, and that requires taking a very generous definition of 'layman'.
The real problem I'm seeing here is that the web was designed as a document presentation media when what everyone really wanted from the get go was an application platform, and we're forever stuck in this contradiction because frankly every other platform has entirely disjoint but at least equally grievous issues.
Sure. Plain old HTML worked just fine for dozens of years, for a vast majority of text-based and mixed text/image media content.
But it wasn't precise enough for the designers, or dynamic enough for the developers, or closed down enough for the media conglomerates and ad companies.
But it wasn't precise enough for the designers, or dynamic enough for the developers, or closed down enough for the media conglomerates and ad companies.
Maybe I'm looking at the past with rose-tinted glasses, but I think Hypercard was something that could be used by a layman to create good results.
>is there any media format, like at all, that can be used by a layman to achieve reasonable results?
I'd argue a WYSIWYG that outputs PDF. But that's probably shifting not only the goal post but the playing field. (It does get at whether the creator should have full control of display or not debate though.)
I'd argue a WYSIWYG that outputs PDF. But that's probably shifting not only the goal post but the playing field. (It does get at whether the creator should have full control of display or not debate though.)
If you need a responsive layout then PDF isn't really an option.
I mostly agree with you, HTML is stuck in the mindset of the era it was created in, to represent static documents that are created once and are not supposed to ever change.
This is why I feel projects like htmx (https://htmx.org/docs/#introduction) can really be what HTML should be in the 21st century: a container for dynamic data fully driven by the server. It's all made possible with javascript of course, but the idea is to not write a single line of it of course.
There are so many things that would make the web a better platform, instead of every single website reimplementing: proper authentication and account management, proper payment for a better monetization, proper separation of application and data, ... instead it's gone deep down into the valley of extreme graphical customization to the point it's now impossible to create a browser from scratch that can respect all the specs
This is why I feel projects like htmx (https://htmx.org/docs/#introduction) can really be what HTML should be in the 21st century: a container for dynamic data fully driven by the server. It's all made possible with javascript of course, but the idea is to not write a single line of it of course.
There are so many things that would make the web a better platform, instead of every single website reimplementing: proper authentication and account management, proper payment for a better monetization, proper separation of application and data, ... instead it's gone deep down into the valley of extreme graphical customization to the point it's now impossible to create a browser from scratch that can respect all the specs
>reveal menus ... interrogating scroll position
No one wants these.
No one wants these.
Well... not you, or me. Unfortunately, I can find a dozen UX designers and project managers who do, in fact, want these things, and advocate and whip developers to add these things under the pretense of "cohesion" and "brand intuition" and other such terms that lead to someone (not me) being promoted.
This simply isn’t true
Then perhaps it's better to say that the overwhelming majority of end users don't want those (or wouldn't care if they disappeared tomorrow).
I'm sure designers love 'em.
I'm sure designers love 'em.
I'm as much of an old-school markup geek as it gets, but still there are website visitors expecting to scroll unto the bottom to see "all there is" on a site. You may say this behavior is learned from doom scrolling, reminicent to taboola crap, etc., but who I am to judge? Personally, I find the development of content UIs and new idioms fascinating.
Just to be sure, when I've written about reveal menus and scroll position above, I didn't mean capturing/blocking scroll events or otherwise messing with default browser behavior.
Just to be sure, when I've written about reveal menus and scroll position above, I didn't mean capturing/blocking scroll events or otherwise messing with default browser behavior.
This debate is really about what people want and how they envision the Web.
> Who's to say digital text has to stick to a 80s concept of casual academic publishing?
Hypertext is a valid business case as it was back then and it still is today.
What changed is how the Web evolved from a small group of academics and engineers 30 years ago into the billions that it connects today. It's not just hypertext. It's hypertext and every other conceivable business case which is being shoehorned into the browser.
The Web originally wasn't conceived to provide affordances that allow for "rich media experiences". Foundational technologies - HTTP, HTML, CSS, JS,... - weren't originally designed to build complex user interfaces and applications. Yet, as more and more and more people got connected: that's exactly what they wanted.
Remember Flash? Or Java applets? Or Silverlight? Those were hailed as additional technologies that would merge complex user interfaces into the Web. Macromedia coined the term "Rich Web Applications" back in 2002. All of them failed for various reasons.
Ever since the Web Standards moving of the mid-00's, communities of designers have taken CSS and HTML and tried to bend and use them in any way possible to bring visually stunning experiences on the Web. This is where you will find the direct roots of many ideas and dynamics that are currently in vogue. It's their influence, as well as other dynamics - e.g. the introduction of the smartphone, the rise of big tech - that has defined how browser technology has evolved.
Over the past decade, browser vendors have tacked on additional browser API's on top of the original, decade old foundations, while communities of frontend developers have spawned ever intricate constellations of interlocking JavaScript libraries and frameworks that specifically try to break out of how the Web originally was intended to work.
Some things have become easier as specifications evolved a bit (e.g. CSS3). But at the end of the day, your browser still needs to download HTML, JS and CSS, parse all of that, execute and render it onto a canvas.
Even so, it's safe to say that this approach is miles removed from what native applications offer in terms of performance and maintainability. Markets being what they are, web applications are in vogue because they earn big money if done well. (Slack just became the latest poster child for that, right?) I don't see that changing anytime soon either, lest someone is willing to go back to the original drawing board and design a totally new paradigm that integrates the promise of Rich Web Applications in the browser properly.
And so, I think it's hyperbole when someone states that "HTML, CSS and JS are broken". One may also consider the history of Web technology over the past decade as a great example of how the popularity of a set of technologies turned them into Maslow's Golden Hammer. Used to solve any and all problems under the sun, but still not any closer to what native applications aspired to achieve back in the 80's, 90's and 00's.
> Who's to say digital text has to stick to a 80s concept of casual academic publishing?
Hypertext is a valid business case as it was back then and it still is today.
What changed is how the Web evolved from a small group of academics and engineers 30 years ago into the billions that it connects today. It's not just hypertext. It's hypertext and every other conceivable business case which is being shoehorned into the browser.
The Web originally wasn't conceived to provide affordances that allow for "rich media experiences". Foundational technologies - HTTP, HTML, CSS, JS,... - weren't originally designed to build complex user interfaces and applications. Yet, as more and more and more people got connected: that's exactly what they wanted.
Remember Flash? Or Java applets? Or Silverlight? Those were hailed as additional technologies that would merge complex user interfaces into the Web. Macromedia coined the term "Rich Web Applications" back in 2002. All of them failed for various reasons.
Ever since the Web Standards moving of the mid-00's, communities of designers have taken CSS and HTML and tried to bend and use them in any way possible to bring visually stunning experiences on the Web. This is where you will find the direct roots of many ideas and dynamics that are currently in vogue. It's their influence, as well as other dynamics - e.g. the introduction of the smartphone, the rise of big tech - that has defined how browser technology has evolved.
Over the past decade, browser vendors have tacked on additional browser API's on top of the original, decade old foundations, while communities of frontend developers have spawned ever intricate constellations of interlocking JavaScript libraries and frameworks that specifically try to break out of how the Web originally was intended to work.
Some things have become easier as specifications evolved a bit (e.g. CSS3). But at the end of the day, your browser still needs to download HTML, JS and CSS, parse all of that, execute and render it onto a canvas.
Even so, it's safe to say that this approach is miles removed from what native applications offer in terms of performance and maintainability. Markets being what they are, web applications are in vogue because they earn big money if done well. (Slack just became the latest poster child for that, right?) I don't see that changing anytime soon either, lest someone is willing to go back to the original drawing board and design a totally new paradigm that integrates the promise of Rich Web Applications in the browser properly.
And so, I think it's hyperbole when someone states that "HTML, CSS and JS are broken". One may also consider the history of Web technology over the past decade as a great example of how the popularity of a set of technologies turned them into Maslow's Golden Hammer. Used to solve any and all problems under the sun, but still not any closer to what native applications aspired to achieve back in the 80's, 90's and 00's.
"Even so, it's safe to say that this approach is miles removed from what native applications offer in terms of performance and maintainability. Markets being what they are, web applications are in vogue because they earn big money if done well."
Disagree. I really do love the speed of native apps, but there's a very good reason the web has become the way most software is delivered. Web apps cost less to build, distribute and maintain for both publisher and user. Web apps are often, but not always, easier to install (just type a url in the browser, press enter, done), easier to learn, more interactive, and more likely to run on the device you own. Native apps are a load of work for both the publisher and user, and that is just to get the app installed and running.
Maybe the current web isn't what was envisioned. I'm ok with that.
Disagree. I really do love the speed of native apps, but there's a very good reason the web has become the way most software is delivered. Web apps cost less to build, distribute and maintain for both publisher and user. Web apps are often, but not always, easier to install (just type a url in the browser, press enter, done), easier to learn, more interactive, and more likely to run on the device you own. Native apps are a load of work for both the publisher and user, and that is just to get the app installed and running.
Maybe the current web isn't what was envisioned. I'm ok with that.
Well, you make good points. I don't disagree with you.
I'm weary of drawing the discussion towards pitting web apps against native apps in absolute or general terms. I think that would detract things too far from reality.
It's a complex debate because the 'right fit' - native or web app - depends on the use case or business case as well as the perspective of the stakeholders involved: developers, business owners, customers and users. The many trade off's each and every stakeholder has to make are what sparks tensions and debate.
Speed is just one of those.
It's true that web applications have set a new bar as far as customer / user convenience as well as application maintenance are concerned. But then there are also trade off's regarding privacy, confidentiality, security, legal compliance, accountability, trust, expenses,... There's also reliability / availability of a services, and there's even a moral question regarding energy consumption tied to operating data centers.
Again, I'm not going to take position on those in absolute terms. Rather, I think it's very much valid to look at your own business case or use cases and keep taking native applications into consideration as well, rather then dismissing them outright as yesteryear's technology.
> Maybe the current web isn't what was envisioned. I'm ok with that.
Oh, I'm okay with that as well.
It's interesting to see you use the phrase "current Web" because what is the "current Web" exactly? In the vast majority of discussions, it tends to be reduced to the well known big tech companies and their products. For many the "current Web" is mainly Reddit, HN, StackOverflow, LinkedIn, Medium,... For others, the "current Web" might be a plethora of self-hosted websites which they have bookmarked in text documents. Your mileage really varies depending on who you ask.
The Web is far larger then the perception we get from it through our own daily use. And a vast amount of it will remain dark simply because we either can't find it, or because we aren't aware it exists, or because we simply don't look for it's existence.
I'm weary of drawing the discussion towards pitting web apps against native apps in absolute or general terms. I think that would detract things too far from reality.
It's a complex debate because the 'right fit' - native or web app - depends on the use case or business case as well as the perspective of the stakeholders involved: developers, business owners, customers and users. The many trade off's each and every stakeholder has to make are what sparks tensions and debate.
Speed is just one of those.
It's true that web applications have set a new bar as far as customer / user convenience as well as application maintenance are concerned. But then there are also trade off's regarding privacy, confidentiality, security, legal compliance, accountability, trust, expenses,... There's also reliability / availability of a services, and there's even a moral question regarding energy consumption tied to operating data centers.
Again, I'm not going to take position on those in absolute terms. Rather, I think it's very much valid to look at your own business case or use cases and keep taking native applications into consideration as well, rather then dismissing them outright as yesteryear's technology.
> Maybe the current web isn't what was envisioned. I'm ok with that.
Oh, I'm okay with that as well.
It's interesting to see you use the phrase "current Web" because what is the "current Web" exactly? In the vast majority of discussions, it tends to be reduced to the well known big tech companies and their products. For many the "current Web" is mainly Reddit, HN, StackOverflow, LinkedIn, Medium,... For others, the "current Web" might be a plethora of self-hosted websites which they have bookmarked in text documents. Your mileage really varies depending on who you ask.
The Web is far larger then the perception we get from it through our own daily use. And a vast amount of it will remain dark simply because we either can't find it, or because we aren't aware it exists, or because we simply don't look for it's existence.
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.
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.
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.
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.
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.
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.
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.
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.
--
[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?
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):
SQL also has its equivalents of this idea. The most basic of which is "prepared statements" - an API in which, instead of:
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);
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);
query(build("SELECT foo, bar FROM baz WHERE bar = ? AND foo > ?"), userInput, anotherInput)
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.
[deleted]
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.
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.
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:)
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:)
[deleted]
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
"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.
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.
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.
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.).
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'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?
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.
I was the biggest advocate of this approach.
Then, by chance I landed flutter/dart side project.
The power of language where you can mix business logic in presentation files is awesome. You can include your own or 3rd party clients and get full autocomplete and type safety.
The styling did feel awkward at first, but even I, being the first time developer managed to create pixel perfect replica of whatever crazy widget style our designer came up with. And using cols/rows made it easy to make app look good on variety of screen sizes.
I hope that in some moment in time we get same experience for the web, and I encourage more people to try flutter/dart, you migh be pleasantly surprised.
Then, by chance I landed flutter/dart side project.
The power of language where you can mix business logic in presentation files is awesome. You can include your own or 3rd party clients and get full autocomplete and type safety.
The styling did feel awkward at first, but even I, being the first time developer managed to create pixel perfect replica of whatever crazy widget style our designer came up with. And using cols/rows made it easy to make app look good on variety of screen sizes.
I hope that in some moment in time we get same experience for the web, and I encourage more people to try flutter/dart, you migh be pleasantly surprised.
But that side project was an app, I presume? The web is not an application platform per se. Web content should be rendered as transparently and accessibly as possible. Just imagine a world where you can't use browser extensions, screen readers, even text selection...
To note, you can use flutter/dart and just have a web output (which works still fairly bad tho, last I checked).
"native apps" can be used with screen readers, and you can select text with them?????
Flutter uses a canvas rendering strategy where it’s painting all controls itself, so it’s not “native” in that it’s using controls from the OS, and therefore all a11y and select functionality is implemented custom.
Ahh. So its a bad app/framework then.
That really depends heavily on the platform and specific app. It is not there by default for most. Using canvas based rendering is pretty much as accessible as flash apps where, which is not much by default.
> The web is not an application platform per se.
It may not have been envisioned as one, but it certainly _is_ an application platform today. It's arguably the most popular most accessible application platform today.
It may not have been envisioned as one, but it certainly _is_ an application platform today. It's arguably the most popular most accessible application platform today.
> pixel perfect replica
How do you know your users have pixels and not, for example, screen readers?
How do you know your users have pixels and not, for example, screen readers?
Modern development is all about ignoring edge cases. If the analytics say that only 1% of users use something, they shave that functionality off. A natural consequence is that disabled users are ignored.
Strong IDE support is a feature of a vendor language? Not surprised. The web has a few good IDEs too, but as you're free to use your own compilers, linker, dependency management, etc., it's a little tougher to do this with.
While I personally think Flutter is a mess, shouldn't it be easy to port it to the web?
Dart was created as a JS replacement and for a time the Dart to JS compiler emitted code that was more performant than vanilla JS.
Dart was created as a JS replacement and for a time the Dart to JS compiler emitted code that was more performant than vanilla JS.
As someone who is just beginning to learn Flutter, I am interested to know why you think it's a mess. I've been a full stack engineer with a focus on backend for a while now and was just getting my feet wet with app development with Flutter. Is there something else better than Flutter I can give a shot? Thanks (in advance) for your advice.
Don't think there is a real alternative.
I personally prefer React-Native, but only because I know JavaScript and think flexbox is a really clean solution for mobile layouts.
Flutter draws its UIs in a custom way, which is the exact opposite approach that React-Native takes.
I personally prefer React-Native, but only because I know JavaScript and think flexbox is a really clean solution for mobile layouts.
Flutter draws its UIs in a custom way, which is the exact opposite approach that React-Native takes.
I don't understand... All these things are possible in systems where no such separation exists.
What happens in other systems is that you can ask the system for an accessibility tree (for instance) and get a DOM like tree (for example in Android) so stuff like screen-readers still works just fine.
Ditto for contrast - all these things are possible if the platform builds its building blocks with them in mind and the users don't have to deal with it.
All the things and use cases the post mentions are possible in flutter/dart, Android and iOS.
The thing preventing you from "sticking your app in Google Translate" isn't your app in iOS/Android/whatever or the technology - it's Google/Apple.
What happens in other systems is that you can ask the system for an accessibility tree (for instance) and get a DOM like tree (for example in Android) so stuff like screen-readers still works just fine.
Ditto for contrast - all these things are possible if the platform builds its building blocks with them in mind and the users don't have to deal with it.
All the things and use cases the post mentions are possible in flutter/dart, Android and iOS.
The thing preventing you from "sticking your app in Google Translate" isn't your app in iOS/Android/whatever or the technology - it's Google/Apple.
The nice thing about the web is that when a page does something stupid or malicious the user can inspect and modify the tree on their own.
The thing making this easy in web pages is the _tooling_ though.
The reason this is harder in Android than in web environments is that web tooling is just _very_ mature.
Theoretically nothing is preventing you from exposing this functionality in Android/iOS/flutter/react-native/ whatever.
In practice hot-reloading is a lot more valuable and useful since you edit from your IDE (and not the devtools) and all modern UI platforms (flutter/android jetpack/SwiftUI) support it from what I recall.
The reason this is harder in Android than in web environments is that web tooling is just _very_ mature.
Theoretically nothing is preventing you from exposing this functionality in Android/iOS/flutter/react-native/ whatever.
In practice hot-reloading is a lot more valuable and useful since you edit from your IDE (and not the devtools) and all modern UI platforms (flutter/android jetpack/SwiftUI) support it from what I recall.
Is it tooling? I think it's a culture thing.
With Android/iOS/flutter/react-native there's an expectation that developers are a separate community from the rest of the users, one that might not even use the apps they right daily. This contrasts heavily to the web where the users and developers are often using the same tools.
With Android/iOS/flutter/react-native there's an expectation that developers are a separate community from the rest of the users, one that might not even use the apps they right daily. This contrasts heavily to the web where the users and developers are often using the same tools.
I think the author is conflating how product-developers write code with the abstraction browsers should consume.
For example, the author talks about the benefits of HTML as allowing accessibility features and parsing by other tools: Agreed that this is important, but this is just as possible if developers wrote a single language which declaratively/imperatively outputs a tree representation of the hierarchy they would like to display; in fact, there are even many other platforms that do this and maintain the accessibility benefits stated in the article, such as the view hierarchy on iOS or [blockskit](https://api.slack.com/block-kit) in slack.
Most modern web frameworks (Tailwind / Bootstrap / React) blur the lines between structure/style/scripting aggressively - and today they kind of have to: is a modal a structure or a style thing? Why is responsive design stylistic only? Is it crazy that structure would change when you have less real estate? What if I need to compute some client-side-only value to show the webpage - should I block load? or put a placeholder and update later?
I agree that it's important that the browser be able to have those abstractions so it can decide how to ultimately render the page to the user, but that's not the question at hand. The question is whether the current languages are the best ways for developers to express those abstractions. And if developers are already choosing to hack it (by opting for frameworks which work in a way the current web wasn't optimized for because they offer features such as code-locality, component reuse, and modern primitives), shouldn't we optimize the standards to better match reality and offer users a more optimized experience?
For example, the author talks about the benefits of HTML as allowing accessibility features and parsing by other tools: Agreed that this is important, but this is just as possible if developers wrote a single language which declaratively/imperatively outputs a tree representation of the hierarchy they would like to display; in fact, there are even many other platforms that do this and maintain the accessibility benefits stated in the article, such as the view hierarchy on iOS or [blockskit](https://api.slack.com/block-kit) in slack.
Most modern web frameworks (Tailwind / Bootstrap / React) blur the lines between structure/style/scripting aggressively - and today they kind of have to: is a modal a structure or a style thing? Why is responsive design stylistic only? Is it crazy that structure would change when you have less real estate? What if I need to compute some client-side-only value to show the webpage - should I block load? or put a placeholder and update later?
I agree that it's important that the browser be able to have those abstractions so it can decide how to ultimately render the page to the user, but that's not the question at hand. The question is whether the current languages are the best ways for developers to express those abstractions. And if developers are already choosing to hack it (by opting for frameworks which work in a way the current web wasn't optimized for because they offer features such as code-locality, component reuse, and modern primitives), shouldn't we optimize the standards to better match reality and offer users a more optimized experience?
Title doesn't quite match the article. The central thesis, that the separation of structure, interactivity, and style is a good thing for users, is a separate need than the need for different languages.
Sure, the languages are custom designed for each need, their differences engender separation, and decoupled domains means each can evolve at different rates. But none of that is necessary to separate interaction or style from structure through language constructs.
Sure, the languages are custom designed for each need, their differences engender separation, and decoupled domains means each can evolve at different rates. But none of that is necessary to separate interaction or style from structure through language constructs.
Totally agree. How I look at this.
I want to write simple text posts. I don't care how it looks. Let the browser present the way it wants. I want only HTML. I don't care about CSS or JS. I don't even want to know what they are.
I care about how my text post looks. I add CSS. I don't want to care about JS in my language I work with.
I want to add dynamic functionality to my page. Maybe it is not a post but an app. Now I want JS.
I want to write simple text posts. I don't care how it looks. Let the browser present the way it wants. I want only HTML. I don't care about CSS or JS. I don't even want to know what they are.
I care about how my text post looks. I add CSS. I don't want to care about JS in my language I work with.
I want to add dynamic functionality to my page. Maybe it is not a post but an app. Now I want JS.
Then just use markdown.
If course, any good you get from them being separate languages is basically lost to how non stable the languages are.
Don't get me wrong, progress is good. However, so is stability. And if there is a spectrum between the two, few are holding the stability line.
Which is why apps and pages written years ago probably don't work anymore. And that is ridiculously user hostile.
Worse, for users, we have made the barrier of entry rather high. Which is silly, as a browser is clearly more advanced than the old qbasic prompt I grew up with. Yet building your own page is something you have to jump elsewhere to do.
Don't get me wrong, progress is good. However, so is stability. And if there is a spectrum between the two, few are holding the stability line.
Which is why apps and pages written years ago probably don't work anymore. And that is ridiculously user hostile.
Worse, for users, we have made the barrier of entry rather high. Which is silly, as a browser is clearly more advanced than the old qbasic prompt I grew up with. Yet building your own page is something you have to jump elsewhere to do.
HTML, JS and CSS all have great backwards compatiblity. I have sites that I built in 1997 that still render fine in browsers today. Features are really only ever added; very few are deprecated.
If anything, modern tooling raises the barrier considerably for new devs. Getting started with a simple HTML page, including some CSS and JavaScript, then running it in the browser is — by contrast — easy.
If anything, modern tooling raises the barrier considerably for new devs. Getting started with a simple HTML page, including some CSS and JavaScript, then running it in the browser is — by contrast — easy.
I confess the complaint is more geared at JS. That said, I suspect I just burned heavily on the xhmtl fiasco. Combined with how much has been added to CSS, I would more expect that pages made years ago would just violate so many current best practices that are practically required practices.
I also favor more direct use of fixed positioning. The rube goldberg machine people make in order to get their squares where they want is borderline crazy.
Edit: And, I should say that I agree on the tooling point. I don't see any technical reason it should be hard to make a web page. Getting my kids to create 3 files to get started, though, is less than promising. :D
I also favor more direct use of fixed positioning. The rube goldberg machine people make in order to get their squares where they want is borderline crazy.
Edit: And, I should say that I agree on the tooling point. I don't see any technical reason it should be hard to make a web page. Getting my kids to create 3 files to get started, though, is less than promising. :D
HTML and CSS are pretty stable, and quirks mode still exists for old websites.
Javascript is where the majority of the churn and instability lies.
Javascript is where the majority of the churn and instability lies.
Agreed. As stated in my other reply, I think HTML and CSS have been oddly stable in that older stuff will still work. But, you are punished if you still write pages like they used to be written.
An amusing case of this recently when I was ordering a book from Tufte's website. Perfectly fine and workable page. My gut is it would get roasted if created in any of the CR cultures I've seen where we developers run the show.
An amusing case of this recently when I was ordering a book from Tufte's website. Perfectly fine and workable page. My gut is it would get roasted if created in any of the CR cultures I've seen where we developers run the show.
It's the eternal debate: should you group things based on what they are (/bin, /etc), or by project (date_picker/, progress_bar/)?
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML and CSS for rendering.
- used PostScript data instead of XML and JSON for data representation.
https://en.wikipedia.org/wiki/NeWS
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML and CSS for rendering.
- used PostScript data instead of XML and JSON for data representation.
https://en.wikipedia.org/wiki/NeWS
I wouldn't mind throwing HTML, CSS, and JS away and replacing it with a single language, perhaps something more functional. I'm imagining writing all my websites and web apps in something like Clojure:
(html
(head
(title "My Website")
(style
(heading {:weight bold :size 24}))
(body
(heading {:level 1 :title "Welcome To My Website!"})
(nav
(item {:title "Home" :link "/home"})
(item {:title "About" :link "/about"})))
(script
(doseq [item nav]
(if (= current-page (:link item)) (highlight item)))))
You should check out Elm[0] if you haven’t already. It’s also worth noting that things like JSX and Vue templates are just syntactic sugar over render functions that look very similar to the example you gave (albeit less terse).
John Sundell also has a Swift DSL[1] for generating HTML in a similar fashion, though Swift on the server is still very niche.
Obviously these all still ultimately produce HTML, but they do offer some nice accordances for the developer.
[0]: https://guide.elm-lang.org/
[1]: https://github.com/JohnSundell/Plot
John Sundell also has a Swift DSL[1] for generating HTML in a similar fashion, though Swift on the server is still very niche.
Obviously these all still ultimately produce HTML, but they do offer some nice accordances for the developer.
[0]: https://guide.elm-lang.org/
[1]: https://github.com/JohnSundell/Plot
I read through the linked Grand Unification Proposal out of curiosity. I’m sure its author means well, but it shows a great deal of ignorance of all parts of the stack (HTML, CSS, JavaScript, accessibility, computer science, &c.) and why they are the way they are, and proposes extremely impractical solutions to the perceived problems, while introducing problems ten times as bad as the ones it solved.
It proposes ditching HTML and CSS in favour of JavaScript, but never seems to acknowledge that it also replaces JavaScript with a radically different beast that’s extremely incompatible with JavaScript, integrating an unspecified form of reactivity to the language, and shifting to some unspecified kind of lazy execution semantics. (Greenspun’s tenth rule of programming also applies to this mutation of JavaScript.)
It drops the web’s layout system completely, including all text handling of things like wrapping or inline blocks, in favour of something absolutely crippled that accidentally embeds the halting problem and unbounded mutual recursion. Dropping text layout would certainly lead to people reimplementing much of the existing system in user space, and that would be a multi-megabyte library that now everyone would be shipping. (This is not the only case where shifting it into JavaScript is a much bigger deal than people tend to imagine; CSS transitions are surprisingly fiddly to implement correctly in pure JavaScript; in the best case, your single line becomes a dozen obscure lines and some kind of extra state storage.)
Its examples of this brave new world are more verbose than the comparable HTML, elide critical details like z-ordering (which looks like it’s been done completely back to front, which would never fly for rendering performance), and get some basics of layout wrong, so that you’ll get collisions on tiny screens where the HTML a sane person would write using grid or flex (and perhaps even some float if they wanted!) would not have fallen over, and would be more maintainable.
There’s also a substantial dose of cognitive dissonance: “I cannot stress enough that it is imperative to adopt preexisting and proven concepts rather than reinventing the wheel” and bemoaning the inefficiency of the documents that people write because they have ten times as many elements as it seems they should need, while proposing (a) shifting such fundamentals as layout and even text layout into user space, which is plain insanity; (b) reimplementing hyperlinks in JavaScript, in the `onclick = "open('…')"` style; (c) replacing functioning accessibility and metadata systems with… some vague idea that’s going to be better, or something, but doesn’t actually say anything. (Least of all about the accessibility tree—I get the impression the author may not even have heard of that.)
No, I’m afraid this is all up a technically terrible proposal, with no real redeeming qualities at this time: most of the things it says are problems I disagree with, and most of its solutions are actually much worse problems. But I do think the proposer might like to learn some Lisp—you’re never going to convince people to replace the whole web stack like this, but understanding Lisp’s unification of data and code would definitely help develop some of these ideas into more practical things. Certainly any real unification of HTML, CSS and JavaScript would work best with S-expressions rather than some JSON- or JavaScript-like syntax.
It proposes ditching HTML and CSS in favour of JavaScript, but never seems to acknowledge that it also replaces JavaScript with a radically different beast that’s extremely incompatible with JavaScript, integrating an unspecified form of reactivity to the language, and shifting to some unspecified kind of lazy execution semantics. (Greenspun’s tenth rule of programming also applies to this mutation of JavaScript.)
It drops the web’s layout system completely, including all text handling of things like wrapping or inline blocks, in favour of something absolutely crippled that accidentally embeds the halting problem and unbounded mutual recursion. Dropping text layout would certainly lead to people reimplementing much of the existing system in user space, and that would be a multi-megabyte library that now everyone would be shipping. (This is not the only case where shifting it into JavaScript is a much bigger deal than people tend to imagine; CSS transitions are surprisingly fiddly to implement correctly in pure JavaScript; in the best case, your single line becomes a dozen obscure lines and some kind of extra state storage.)
Its examples of this brave new world are more verbose than the comparable HTML, elide critical details like z-ordering (which looks like it’s been done completely back to front, which would never fly for rendering performance), and get some basics of layout wrong, so that you’ll get collisions on tiny screens where the HTML a sane person would write using grid or flex (and perhaps even some float if they wanted!) would not have fallen over, and would be more maintainable.
There’s also a substantial dose of cognitive dissonance: “I cannot stress enough that it is imperative to adopt preexisting and proven concepts rather than reinventing the wheel” and bemoaning the inefficiency of the documents that people write because they have ten times as many elements as it seems they should need, while proposing (a) shifting such fundamentals as layout and even text layout into user space, which is plain insanity; (b) reimplementing hyperlinks in JavaScript, in the `onclick = "open('…')"` style; (c) replacing functioning accessibility and metadata systems with… some vague idea that’s going to be better, or something, but doesn’t actually say anything. (Least of all about the accessibility tree—I get the impression the author may not even have heard of that.)
No, I’m afraid this is all up a technically terrible proposal, with no real redeeming qualities at this time: most of the things it says are problems I disagree with, and most of its solutions are actually much worse problems. But I do think the proposer might like to learn some Lisp—you’re never going to convince people to replace the whole web stack like this, but understanding Lisp’s unification of data and code would definitely help develop some of these ideas into more practical things. Certainly any real unification of HTML, CSS and JavaScript would work best with S-expressions rather than some JSON- or JavaScript-like syntax.
Looks like the author suffers from Dunning–Kruger in a big way. Surely, he may know a lot, he has a MSc., not a stupid person at all, but it's obviously not enough.
Not that self-declared web "standardization bodies" care; web vocabulary activity has essentially stopped in 2017 when W3C published the final HTML spec and cancelled the SVG2 WG, and Mozilla stopped investing into core web tech. The only new proposals since were for example Google's "portal" element to aggregate third-party snippets.