It’s good for users that HTML, CSS and JS are separate languages
hiddedevries.nl
hiddedevries.nl
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.
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.
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.
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.
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.
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.)
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.
> 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.
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.
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.
No one wants these.
I'm sure designers love 'em.
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 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
~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this.
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.
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.
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:)
"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.
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.
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.
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?
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.).
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...
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.
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.
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.
--
[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.
What tool are you referring to? If one does not exist, why is that?
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)
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.
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.
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.
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.
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.
How do you know your users have pixels and not, for example, screen readers?
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.
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 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.
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.
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?
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.
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.
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.
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 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
Javascript is where the majority of the churn and instability lies.
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.
- 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.
(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)))))
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.
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.