HTML First (opens in new tab)

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.

There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives.

I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something.

With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.

While I agree with most of the arguments here, this article feels a little contradictory - it recommends Tailwind but also tells us to 'stay clear of build steps'. Shipping massive CSS/JS resources goes against the whole inclusivity principle - many people don't have super fast internet connections or powerful enough computers..

OP Here. This got more engagement than expected, some of the bits I've picked up in discussion:

"Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development.

"Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production. Nor do I love any of the libraries on unsuckjs.com, which has a good collection. We're working on something here which we'll launch at some point.

"OP should look at the recent Rails updates" - Been using Rails for 10+ years - everything we build is on top of Rails - I'll write a post on HTML First Rails at some point. I think they'll get there but currently all the named libraries (Turbo, Hotwire, Strada, Stimulus etc) are 1. Rails specific, and 2. Have a high learning curve. One of the points of HTML First is to avoid framework lock-in.

"This is a blog spam post written by an author that has no credibility in the space": Brutal

This one confuses me:

> Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax

And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious?

[0] https://hyperscript.org

Can the people that want this HTML-first world style it to look the ways they want themselves?

My experience has been that proponents of HTMX and the like skew heavily backend and never feel comfortable with CSS.

Why listen to UX thoughts from a population who are scared of UX?

“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.

I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react.

My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use <input type="date" /> do we get a datepicker across browsers? (Looks like yes.) Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)

Multiselects are similar - shift/control-clicking to get multiple things is a flat no-go from a UX perspective - but at my last check, this is still how the default elements work, and it can't be changed. Similarly, the look/feel of multiselects (and even selects!) is terrible and largely cannot be changed.

There's a reason third-party components for this kind of thing get built for any new framework. The built-in stuff just doesn't get it done. It's the same reason 90% of my projects still have lodash as a dependency, even though the list of built-in stuff on MDN's Array page grows year by year. It's better than it was 10 years ago for sure - but its still not there.

The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for web sites. For web apps, at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.)

I used to be really big on this, though (and it makes me sad that these days most sites are 1 big unreadable line of HTML). In fact, I find a beauty and elegance in shipping the whole thing as a single HTML file with no dependencies (1 network request!), though I did eventually make a "build system" (my build system is cat) so I could have a sane editing experience. Boom, self-contained portable software in 1 human-readable file!

Along the same lines, I think the coolest thing about web development is that you can make your first (interactive!) programs with Notepad and whatever browser ships with your machine. (Just drag the HTML file onto the browser!) It's magic!

Edit: Just found an unexpected benefit of self-contained HTML: makes your software immune to bit rot. I tried loading an old project of mine on Web Archive but it hadn't archived the external JS file! Sad! Meanwhile, this one loads fine because all the JS is in the HTML! Winning!

https://web.archive.org/web/20210508133239id_/https://andai....

This is my homage to the old SodaPlay Constructor. (Never made an editor, sorry!) Feel free to view-source!

Maybe I’ve already drunk the koolaid, but if I end up building a new app from scratch, I would really like to experiment with something similar to what the author describes:

Django for most (if not all) of the server-side code, Django templates generating HTML, htmx handling most interactivity with html attributes and, when necessary, hyperscript (for use cases that can’t be covered easily by htmx). I would probably stick with downloading minified Bootstrap for styling (Tailwind requires a build step, and I don’t think I have done well in the past when I waded into “class soup”).

Has anyone here tried something along these lines for a non-trivial app? How is it going?

I want to agree with this based on the title, but why would you do something like this:

    <div class="bg-green" onlick="this.classList.add('green')">Click me</div>

if you're already using React? Yes the React code is a lot more verbose and has a bunch of "cruft" for lack of a better word. But you're already using it for the rest of your site, so you should (IMO) continue using it rather than mixing and matching approaches.

I gave up this year, it's no longer possible to keep fighting these react, vue, angular monsters with their bundlers and transpilers and all the junk that comes with them, like node with npm which always throws at you the message that your brand new, seconds old project has 7 severe and 8 critical vulnerabilities in it, because it must download thousands of files, possibly including a wrapper for boolean values.

The times where I could use the Python backend servers to also serve the frontend seem to be over for me.

`<button onclick="this.classList.add('bg-green')">`

Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics.

This is a terrible idea.

React was designed to solve all these problems. Now these problems are used to solve react.

Programming, like life, is a flat circle.

I love the idea!

In my current company we started with HTML and embedded JavaScript at the bottom and Styles at the top. Everything in one file, very easy to find and understand.

It was "a little bit" slower. Pagespeed Insights didn't like it.

Now we are "modern" with CSS and JS in a build process. And nobody knows which file to look at...

My new Projects will start with HTML first, again.

My credibility: 45 years, commercial web programming >25 years, 3 successful web companies founded as CTO

I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do.

The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bigger, area, which has not seen a single ounce of integration into native HTML: reactivity.

So what if we could just solve that? What is preventing us from adding native reactivity to HTML, a language that already contains numerous interactive elements and hard-coded ties to JavaScript? Seriously, why is this not already implemented when we have things like Shadow DOM out there already?

We could get a huge amount of impact with just minor changes. In my view, HTML could meet 90% of peoples' reactivity needs with just two simple tags:

1. `<sync value='variableName' />`: Renders as a text node that shows the current (live-updated) value of the referenced JS variable. If the value is undefined, renders nothing (special case).

2. `<test if='variableName'></test>`: Renders as its children if the referenced JS variable is truthy, and as nothing if the variable is falsy.

That's it. Just these two almost-trivial tags would solve an incredible amount of use cases. And with sufficiently expanded componentization (say, React-style props for `<template>`), the web platform would be well positioned to cover all others in time as well.

In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier.

Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand the sentiment behind this, tools like React or Angular have significantly lowered the barrier to entry in their own ways.

I love this. Could you please consider changing the example from a clickable div – which is an accessibility nightmare – to a button?

Does anyone have a good list of vanilla approaches? I'm a fan of details/summary, but I'm sure there are more I don't know.

I love the ideas here, but honestly the examples are a bit weak here.

> Where possible, default to defining style and behaviour with inline HTML attributes

but their example wouldn't work.

  <div class="bg-green" onlick="this.classList.add('green')">

should probably be

  <div onclick="this.classList.add('bg-green')">

which I think makes it a little more clear how weird this could get if you wanted to add more styles. You just keep growing the params passed to the ClassList add method, in a string. I would personally find

  <button></button>
  button:active { background: green; }

to be much more readable, but the author seems to imply this is complicated due to their approach of "Locality of Behaviour".

--

> Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax

I totally agree! But why is your example of a library not built around javascript or a custom syntax feature:

  <input type="text" _="on input put me into #output">
  <div id="output"></div>

That "on input put me into #output" I think is more jarring that the library shown as the bad example. Even better, this could just be some JS, without a framework at all.

--

> Prefer "naked" HTML to obfuscation layers that compile down to HTML

Their example is to not use Rails ERB tag helpers, in your templates. I don't think this is that big of an issue, these helpers can actually handle a lot of things that will look messy if you use the minimal amount of templating to write them. The example leaves off unique dom ids, turbo tags (very HTML/no JS focused!) and iteration.

Relying on simpler frameworks when you can make sense. But the notion of getting rid of build steps is a complete lark, just be more efficient with build steps, and if necessary, don't include them in production. Also why would you want to prioritize adding your attributes to HTML? Are you making a document and hosting it as a website? In what other world is that preferred? CSS isn't hard to navigate, if anything one should be encouraging better CSS practices. Yes, frontend scripts can obfuscate styling, but perhaps just don't rely on that if you don't need to, which is already a no-brainer, since it's harder to give an attribute via some JS rather than shoving it into a style document.

Some of these make sense and are obvious, like using only what you need (which is preached for half of the article). But the rest of it confusing, if not outright ridiculous. Why are we even assuming that being able to copy an entire HTML page is a good thing? Frankly I don't care, and it's not like there are literally millions of resources to use to learn HTML even if you can't view a few pages' HTML.

Idk man, kind of a head scratcher

This whole post is an anti-pattern and bad advice. It read as from someone who didn’t go through the growing pains of building complex websites.

This is how we started building websites until things started to break with side effects, conflicting class names, bad introspection etc. and React came to the rescue.

The pattern you want is progressive enhancement and your output to be clean, compact html that’s augmented by JS. Which means build step. Everything opposite to this article’s advice.

For the sake of being precise - the “form_with” is not equivalent to the presented HTML. The form_with helper injects an additional hidden input element that makes sure that the form cannot be submitted “illegally”.

The author raises some interesting points.

But these arguments seem a little tired now. Does a customer actually care what technology you use - absolutely not. If react is easier for you, go for it. If that’s HTMX - fine.

What matters is speed of delivery of new features. And react has huge amounts of support (and a large developer base) that makes development quick and cheap.

I’ve never understood these html purist arguments. As if React/Vue/Angular are desecrating this pure text language.

There are other issues of far greater importance - accessibility, multi-language, browser consistency, sane defaults and easy tooling.

What's the opinion on re-introducing HTML attributes for style properties, eg. <div width=40pct color=red> (possibly with additional enumerated attributes usable in short value-only syntax as in <div disabled>) rather than <div style="width: 40%; color: red">? I mean, introducing a secondary syntax for item-values, like CSS did, quite never made sense to me personally even though it was nevertheless thoroughly defended ([1]). I guess it doesn't make sense to me coming from an SGML background which had style sheets capable of stateful/automaton-based assignment of attributes for ages. But now with tailwind so popular and little more than inline styling with sane defaults perhaps, and this manifesto expressing a strong preference for markup attributes, isn't it time to come to the realization that, whatever point CSS had when it was new, surely is driven ad absurdum by its obscene syntax proliferation and extreme redundancy (something even W3C CSS WG's chairman/staff contact already was warning against over ten years ago [2])?

Personally, I don't care for web "apps", seeing the unique value of HTML rather as authoring format for web "docs". For mere apps where JavaScript is obligatory anyway, I think I'd actually prefer CSS-in-JS.

[1]: https://wiumlie.no/2006/phd/css.pdf

[2]: https://www.w3.org/People/Bos/CSS-variables

I get the sentiment of this, but I struggle to recommend it (not least for the spelling mistakes, especially in the code examples)

My main criticism is that you cannot really advocate for "View-Source Friendly" HTML with the view of widening the pool of people who can work on it, and then simultaneously recommend that people use libraries like HTMX or Hyperscript that have their own unique syntaxes that aim to be compact and concise, but actually are just confusing and unfathomable unless you are already familiar with them. This flies totally in the face of the main goal of this site because you're advocating for people to use niche and sparsely-used custom DSLs for coding part (...yes only part!) of your site's business logic.

I also don't really see the value in trying to aim for view-source compatibility on a page-by-page basis - a better approach might just be a link to your source repo in Github (or elsewhere) that contains your entire project along with e.g. README.mds etc. And if you expect people to "view source" to learn, how can you expect people to do that when you have inscrutable non-HTML/non-JS nonsense like `_="on input put me into #output"` in there? I get it - I learnt HTML originally back in the day by looking at the yahoo pages source code, but we are not in the early 90s now: people can learn HTML from other places these days that offer a better experience than looking at a sites source in a vacuum (e.g. Github but also so many more ways now than those early days - there are millions of decent online courses, youtube videos, bootcamps that teach the syntax (i.e. all you get viewing source) as well as the rationale and the reasoning for decisions made and approaches used)

I would modify this guide and offer some different/additional advice:

  - Use vanilla JS + vanilla Web APIs (Element, Fetch, Promises/async-await etc) for all business logic, and split code into modules (e.g. https://byexample.xyz/javascript/ECMAScript2015/modules/ ) so that your code is simple, has fewer dependencies, and is understood by 100% of web developers (unlike HTMX, Hyperscript et al that no one understands without having to go specifically learn it specially)
  - Use HTML-based Forms validation rather than custom-logic wherever possible.
  - Structure your DOM logically and use the correct semantic HTML elements for their intended purpose (e.g. use <button>, don't use <div onclick="...">) so that your page is accessible and easily navigated by keyboard users ("power users" and otherwise)
  - Either add CSS classes directly via inline handlers, or do it via javascript, but whatever you do make sure you are consistent within the same project.

Good luck with your project.

Personally I prefer to take away from this the aspects that might work for me, as opposed to looking for anything I can come up with to rip the author a new ass.

In my case, I decided to keep using jQuery as opposed to React or other newer frameworks when I started building an app I was getting ready to update around 5-6 years ago. Not because I found anything negative about React.js and other, newer, JavaScript libraries, but because jQuery still does what I needed and I was familiar with it.

I have no doubt that React is a great choice for teams but end users don't care at all about what's under the hood, they care about usability and stability. What I cared about was my personal productivity.

If I were managing a team I likely would've used React.

I get real confused by these.

Imagine if an iOS developer posted a blog about the specifics of files backing UIViews and how the XML configuration language was underutilized.

Wouldn’t that be kind of a weird blog post? The declarative syntax of various UI frameworks is an implementation detail. The hard part is in CSS on the web, or style properties in native frameworks. Business logic as well. Presumably encapsulated in a component, which React does well and web technologies are catching up to.

Why should I care about this, any more than I should care about XML config files on Android? It’s a markup language that is an artifact of the runtime we’re using. I don’t care about that in other contexts, and it’s the least interesting thing in a web development setting too.

doesn't the inline JS (onlick="this.classList.add('green')") harm/complicate CSP headers?

HTML should have been improved by now. What is sad is that fundamental things like a put request through a form can't still be done by simply a method. Keeping html hobbled is literally a conspiracy.

A return to unsafe-inline? That feels like a bit step backwards when it comes to cross site scripting attack surface. Content-Security-Policy forces you to opt into unsafe for good reason.

The main feature that introduces the need of a build step is having a template engine in order to reuse blocks of code, like footer, header, menu, etc..

I think Dreamweaver MX introduced something like template files, and it would make a "build" step that would copy the files from template to actual html files. Then it started to get complex, with data sources and generating pages in the backend. (php, asp, cold fusion?)

This seems like it came from a newbie/inexperienced dev.

> substantially widen the pool of people who can work on web software codebases

This isn't a problem. There's already more people who can work on web software than there ever was.

> A second goal of HTML First is to make it more enjoyable and seamless to build web software

Subjective. If people enjoy it like this that is fine but these shouldn't be touted as principles everyone should follow.

I agree with everything but inline javascript

<button onclick="this.classList.add('bg-green')"> Click Me </button>

This is going to be problematic when it comes to debugging. I still think scripts should be in a file and loaded in the header.

Been doing this with mkws and on https://mkws.sh since day one!

Yeah, I agree with others, not good. Recommending inline CSS is just wrong.

This is perfect for Svelte

The no-code (HTML markup only) SaaS platform I'm working on seems to fit well with this philosophy: https://www.saasufy.com/

As a demo, I was able to build a chat app with it: https://saasufy.github.io/chat-app/ You can log in via GitHub OAuth (also implemented with HTML tags).

Less than 120 lines of HTML markup in total for the entire functionality.

The source is here: https://github.com/Saasufy/chat-app

There is no custom backend logic, all the logic is in that repo as HTML + CSS.

> "Prefer vanilla approaches using HTML"

> Proceeds to insert JavaScript and CSS into HTML attribute.

> "HTML is easy to understand"

> Proceeds to import external JavaScript library which uses an ultra-obscure, totally unclear HTML attribute `_=`

I like the spirit of the article.

My personal preference is server side templating using as much default HTML as possible with JS as progressive enhancement (using HTMX or something similar).

Does anyone find it strange that a syntax highlighting library needs to be loaded on a site singing the praises of HTML? Sometimes I don't think the web platform takes its own original purpose seriously (presenting documents).

Specifically on the “use libraries that leverage html attributes” point:

I find this “dishonest” to the overarching ideals of this manifest: If you want to follow standards, and allow view source, you can absolutely write vanilla JS, and end up with more idiomatic and approachable source than

    _="on input put me into #output"

And then as you grow out of the simple examples you’ll probably adopt a library like React which will restrict you less than these html attribute “abusing” alternatives.

Of other points, I especially like the “no built step”. A native support for JSX would really smooth out the path from vinalla to React.

I'm a big fan of that approach, but it's kind of funny (and sad) that such a simple page doesn't even look as intended with JavaScript disabled, as there are some placeholders of CloudFlare's Email Address Obfuscation visiable in some of the code listings.

I've successfully used this pattern (HTMX hypermedia style) to create an offline-first web app SPA[^1]. One of the pages is pretty dynamic and I wasn't sure if I would need a traditional front end library to work with it. But, nope, hypermedia to the win, it worked fine without a front end framework.

To build it I used my own library called HTMF[^2]. I started out using mpa-enhancer[^3] but found that that pattern is a little to janky sometimes. I think reloading a page every time on every interaction uses too many resources for a browser especially when you use a phone that doesn't have as much power as a laptop.

But overall I find the pattern very easy to use and keeps the complexity down.

I think some of the issues with traditional SPAs is that they have a lot of state and state is nonlinear in complexity. But using templating systems makes the complexity more linear in nature.

Also, I find libraries like React to be overly complex for what it does, see above. The way React works is just odd and counter intuitive. All for problems that are easy to solve. I do think there are places for a React-like library is needed but those are for websites that are inherently highly state-based. But most websites aren't state-based even ones that appear to be state-based at first.

The websites I work on are usually just forms and forms are pretty powerful and can get you a long ways before you need to go outside of that paradigm.

[^1]: https://github.com/jon49/Soccer

[^2]: https://github.com/jon49/htmf

[^3]: https://github.com/jon49/mpa-enhancer

I strongly believe that no one would hate or love to hate the build step if we didn’t have to mess around with so many unmaintanable configs, dependencies and pipelines of translations like typescript -> js with commonjs or es modules and so on. Still, for me, which ever code I write I want it to be compiled/translated by a machine, that given a “browserlist” knows better than me how to output code that works for the most system around. And that’s especially true if you have a successful product with a lot of customers. I agree on rolling back most of the abstraction madness we built so far, but surely I can’t remember how to write es5 compatible code anymore, should be a no brainer for me. Lastly, I can’t disagree more on improving inclusion with “html first”, whatever approach you choose it’s still super hard to have a web app that has: perfect audit score, adpative ui for all screens, accessibility, print(! what id customers demand that each app page should be printable?) and more I can’t think of now. This job is hard, it’s not for everyone and going back to first principle won’t save us from hardwork anyways

<details> and <summary> are great, but animating them to slide open instead of "pop" is difficult to implement without JS when the contents are not a fixed height.

Sliding open guides the user that something has changed, improves the UX.

I've found that using the `open` attribute in CSS behaves differently across browsers as well. Sometimes it doesn't even work consistently in a single browser implementation.

If you're creating a web page, use HTML. If you're creating an application interface, use a UI framework like React.

Don't use React for web pages, don't use plain HTML for application interfaces. But don't pretend that web pages and application interfaces are the same thing just because they both use the browser, or because "the application runs on the web".

I don't think I buy the premises under the goals here.

> The main goal of HTML First is to substantiall widen the pool of people who can work on web software codebases.

Fair goal.

> A second goal of HTML First is to make it more enjoyable and seamless to build web software.

Also a fair goal.

> The way we achieve these goals is by acknowledging that HTML is very easy to understand, and thus using HTML as the bedrock of our product - not only to define content and structure, but also to set styling and behaviours.

It's not. It's a large, heterogeneous collection of behaviors based on the arrangement of various tags with coupling between the tags defined by hundreds upon hundreds of pages of individual tag descriptions. And that's before we even consider that there's a matrix of browser compatibility layered atop that.

If I code up some complex behavior in React (such as the details-summary example here), the result is obvious, shows up in the deubgging tools, and works on every browser that supports React. Most importantly, the knowledge is composable: that approach to showing and hiding content works regardless of the content being a "details" and "summary" or a shopping cart contents pane or a modal dialog. With vanilla HTML, every aspect of the default behavior is dictated by the browser, and very few pieces compose with each other sanely (what happens when I nest <details> tags? I have to try it to find out; if it's a React component, I can read the JavaScript and know).

I'm not saying one shouldn't use vanilla HTML or should only use <div> with style for the whole layout or anything like that; there are semantic concerns that make using HTML where possible a good idea. But I'm not going to trip over myself to memorize every behavior and interaction of the declarative HTML model if it's easier to build things like collapsible details tags in React.

In other words, return to web development practices from the early 2000s? Isn't this just the pendulum swinging the other way? Haven't there been genuine problems with that style of authoring websites that the last twenty years in web development have been trying to solve?

I love that people are finally coming around to abandoning the build step.

The majority of web pages fall into one of two categories: long-form content where the primary interaction is reading, and applications (consoles, editors, tools). I do not think the latter benefits from an HTML-first approach as outlined in the featured article.

Why on earth do so many projects like this have to hide behind this weird inclusive language?

Why can’t we be honest with ourselves and admit that our pet projects are just pet projects? Not everything has to save the world or even take any sort of moral stance at all!

I'm missing a bit "if you have to use javascript, use vanilla javascript where possible" here.

HTML attributes are no silver bullet. You can still have a bloated framework that puts some ill-fitting, homegrown data model over your code and drowns the codebase in "magic", even if all the interaction with that magic is through HTML elements and attributes.

Generally, I think there is lots of good advice here, but I don't really understand the "messianic" attitude of the HTMX crowd. Why all the effort to actively discourage any other approach?

I published this article on Template Animation (aka DOM Templating) 12 years ago:

https://benkoworks.com/your-templating-engine-sucks-and-ever...

It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM:

https://github.com/iaindooley/Fragmentify

https://github.com/iaindooley/fragmentify-js

Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side:

https://github.com/dgrinton/remote-standalone

The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.

I love how many folks here seem to think JavaScript (and its popular libraries / frameworks) are somehow threatening to the web. This is like saying people should write native user interfaces for iOS and Android, "but no, not with Swift or Java" (respectively).

All the templating, but without the language or libraries to support its interactivity, navigation, data calls, calculations, you name it.

It's rather quite silly.

The overall sentiment of this approach is valid, but there are some tweaks to it that I've found effective.

Rather than using Tailwind, applying BEM syntax to styles in an inverted-triangle style has been good for existing websites where using Tailwind isn't an option. Especially if the code has very clearly defined components.

Instead of inlining the JS, I'll still keep that all pretty separate from the HTML. That's probably the thing I disagree with the most here. Maybe very simple things could be used this way-Might be a case-by-case decision there. It's also nice to write a few JSDoc comments to help bring some TypeScript-ness to the table.

I like the push for being more View-Source friendly. My work pushes for squeezing out as much performance as possible on a site, but even we have found that build steps for things like minifying/concatenating has diminishing returns compared to the overall workflow overhead when there is probably an image on the page that could be trimmed down.

Like what a lot of people have said here, I think much of it comes down to what you are building, too.

Sorry but this example is just bad

  <button onclick="this.classList.add('bg-green')">
    Click Me
  </button>

First of all people might have difficulties with the color green. So do you add alternatives as well, maybe with media queries, right here inline in HTML? Or do you just use the class *active* as in the discouraged example? And then you could make it even more accessible by providing aria attributes to signify the the active state. Depending on the use case you might not even need the class (you know ... leverage real html attributes).

There is a reason why semantics are more important than the concrete style and why they are separated. HTML and CSS first is a great idea but show more care for your users.

It seems the author was trying to apply KISS to web sites here, but being unnecessarily dogmatic they added additional complexity over mundate aspects such as whether you call your CSS /dist/output.css or /styles.css. This is completely irrelevant.

HTML is a presentation layer, as such it's 99% the output of some other layer. HTML first therefore is the wrong mindset.

You can't have an HTML first CMS for example, that's a recipe for spaghetti disaster. You need to define clear, constrained models that then you can adapt for given media.

I feel almost weird arguing with this site, because in general I also prefer simple HTML where possible, and I can't stand overdesigned JS-generated framework monsters.

But going from one extreme to another is not smart. No simple rule is a substitute for "intelligence first", and intelligence has lots of subtle rules and relies on rich context to make the right decisions for that context.

Nice domain name though.

The style presented is far from the norm at the moment not just because of gate-keeping and over-engineering, but because web software is refactored and improved so many times over.

For example, <summary> only supports a weird set of child tags. Personally I like <details>, but due to this constraint it is not always appropriate. Certain aspects of its native style cannot be controlled.

Many event handlers are awkward encode into onclick if not impossible.

"Naked" HTML requires a lot of boiler plate. The form helpers that are discouraged relate to validation, error reporting, form authorization, and localization. It's not an obfuscation layer.

The encouraged styles are easier on the eyes for now, but it's easy to imagine them developing into issues which would be the subject of some ticket, or else disappearing due to general improvement to the code base (DRY principles, SoC, UI touch ups, etc).

It's easy to preach this. I went to the author's projects using the link in the bottom and found the first project[1] to be using 4 MB of CSS and 1 MB of javascript in the landing page, which is just a static signup.

In big projects, the generality of codebase and faster option to do one off tasks matter more rather than best design for the current task. And it is lot harder to have making codebase small or without libraries as a requirement.

[1]: https://clerkmoney.com/users/sign_in

Not bad, and reminded me of Simple & Useful:

> Can html be styled well enough and simply enough so that anyone can write for the web, using just a text editor, and share that work with anyone else, regardless of the platform they are using, the speed of their connection and any disabilities they may have?

https://s3.amazonaws.com/simpleuseful/index.html

From the old-school Introduction to Web Design:

https://web.archive.org/web/20210414030104/https://www.cours...

I built something recently with the same ideas in mind: https://github.com/sethkimmel3/tailgate. It allows people to build generative-AI applications without any of the complication of setting up a backend, and in the simplest cases only requires adding HTML attributes.

I originally learned to code with HTML, CSS, and JS, and I think it's still the easiest way to experience the magic of shipping a working application to others. We should keep encouraging more patterns and tooling that lower the barriers of entry to those just starting out.

Writing your code in a way that makes sense to someone else is a skill.

If someone writes the bonkers code in the article’s bad examples, I guarantee their “HTML-first” code will be just as bad.

Isn't this just Unobtrusive Javascript all over again?

We lost that war once, I don't see why we would win now. I'm saying "we" because I am particularly for this approach, too.

Don't get me wrong: I absolutely hate React, and am very cinical about the whole "server side rendering" fad (well, we've been doing server side rendering for 30 years, right?). Still, I think the overall web community simply does not care enough, so I've kind of given up.

It’s ok to use whatever stack, framework or tooling you are most comfortable with as long as the result loads in 1 second on mobile, half a second on desktop and scores 4 x 100 on https://pagespeed.web.dev/ without using any divs, or, god forbid, statements like container class=“wrapper”, but that goes without saying really.

A lot of these points are great, but the examples here don't help for building more complex components or pieces, that could contribute to a larger application...

If people are looking for a way to build native web-components using HTML-First principles, I've been working on a library to do just that!

https://tram-one.io/tram-lite/

This trend makes total sense given the current web panorama.

I have been disabling javascript for a lot of websites during the last year, the experience is not damage at all, it's the oposite, you get a snappier navigation, no ads tracking and if you have bandwidth issues you now can browse those sites without problem.

The drawbacks, some interactivity is lost, but nothing major.

Amen to that!

The popular pattern of constructing React components with Organism, Atoms, Molecules and so on, makes following an unfamiliar codebase a nightmare!

JSX is hard to use in my eyes.

At first I thought it must be me, but I’m glad there is a movement to reject all this front end React based madness.

Building API layers with GraphQL and React on the front end just for a few business forms is madness!

I agree.

I also really like writing software that builds HTML to be served as a static page. E.g. https://gist.github.com/HalCanary/61276afbab042e204e54268f6a... Then that complexity is hidden from the client.

I'm on board with this conceptually. Most of the independent sites I build I still do this.

But some of the things being spouted on this site are junk:

    <button onclick="this.classList.add('bg-green')">
      Click Me
    </button>

No. Absolutely not. Don't ever do this.

This is an unmaintainable mess.

I started messing with early web dev stuff in the late 90's. It took over a decade to finally get enough momentum to move people away from this kind of crap.

I'm going to lovingly refer back to https://www.csszengarden.com/. Separation of concerns is a good thing and should be used as much as possible.

> Where possible, default to defining style and behaviour with inline HTML attributes

I'm not aware that an inline style, and particularly the inline JS in their example can be nonced to prevent script and style injection.

So no. I will not be following that part of the guideline. Not until the security aligns with reality.

I would add that for noscript/basic (x)html version of web sites, 2D "semantic" HTML documents are not harmful, and table navigation is ok for screen readers if not done too weirdly.

Of course, I am not talking about the abomination of "semantic web" we had a decade ago.

This is all nice and suckless, until you will have to scale your codebase and/or add some more features (possibly alter someone's code) and deal with exponential complexity of DOM manipulation. React came to solve all this

There is a valid philosophy behind this, but the arguments are a bit flawed. For ezample CSS is not only styling (as in theming) it is important for GPU animations and is hard to sync with app state ans JS without some tooling.

I think the recommendation to use tailwind and avoid build steps and incompatible.

I made some web app with the least amount of logic in the JS, and almost all of it in a flask server, with a few ajax calls.

I have to admit that managing asynchronous js callbacks is really a pain to deal with.

JS is really an awful, awful language.

I think of myself as a very "semantic, HTML-forward" guy when it comes to front-end work and I found myself disagreeing with the vast majority of this.

Does anyone else find that blue tint on the top of the page makes it really hard to read? I guess I usually scroll the text I'm reading to the top...

My theory is that now that central banks money run out we're going back to sanity. The end of centralbanking-driven-development is coming

The article says 'For styling this can be enabled with an SPC library like Tailwind or Tachyons.'

What does SPC stand for?

Article doesn't even have anchor tags

What goes around comes around.

Once upon a time these first principles were the bedrock of web development.

> If a developer who has familiarity with HTML but not with your backend framework looks through your view files, they should still be able to understand 90%+ of what they see

I don't see why this is beneficial

"<button onclick="this.classList.add('bg-green')"> Click Me </button>"

I don't like this at all

User/Customer needs SPA, not HTML, they just don't care the tech, lol.

We are getting back on track!

Another web development prophet with quick solutions for simple cases.

Meh.

I say build software in the way that you like. Or the way the boss says.

thanks I'll use it on my auntie's cupcake website

I agree completely, but hiccup rather than html.

Doesn't Tailwind have a build step?

aka make your website look like shit because half the default elements can't be styled

The person who created that website should have a look at the recent Rails updates :-)

Or check out DHH's most recent thoughts on minification etc.

Raúl Gúrru Miau {Miáu} 8

Locality is underrated

I stopped reading after "This is good from an individual perspective because it allows a greater number of people to become web programmers, to build great web software, and increase their income.".

Thank you

This is a blog spam post written by an author that has no credibility in the space rather than creating an agency that touts itself as "A software agency that doesn't suck.". How bizarre.

Even more, the author uses every possible library under the sun, from Tailwind to Framer, only to evangelise about raw HTML and topics he provides no credibility on.

To add to that, even the links to learn more about their agency all lead to Twitter, rather than LinkedIn, Clutch and Sortlist.

It is so much easier and faster to build web apps using TypeScript, Vite and React (or any other similar stack) rather than vanilla JS. I find this “leveraging the extreme simplicity” effort wholly misguided.

It’s neither “enjoyable” nor “seamless” to manually synchronise the backend, the frontend logic and the DOM of your app without frameworks.

And maybe the trite talking point of helping young developers by sending unoptimized unminimized comment-rich source code directly to end-users held at least some weight in the 00s; nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development.

I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css?

The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is never going to work for these types of applications.

I find this hand wringing over the complexity of the web so strange. Can we all just move on? The web has changed. I have been programming for over 15 years professionally. Yeah its changed. yeah frontend frameworks are a pain in the ass a lot of the time. So lets make it better, not fall backwards to a “simpler” time.

> Where possible, default to defining style and behaviour with inline HTML attributes

Wow, have we just come full circle after 25 years?

To me this reads like a polite version of motherfuckingwebsite.com. Don't get me wrong, I love the idea and forked the pug/jade templating language just to build my site in pure HTML but without endless closing tags noise.

I'm not a big fan of JSX...

But that trend to put everything back into HTML were possible is also wrong...

Yeah this may work for static websites with some forms but I don't see Discord being build like that or any other bigger app.

Its like people want back the HTML version of Gmail. Its a nice experience when a big part of your screen flashes /s

What about i18n? or a10y? The examples of the form don't support any of that.

Have fun writing the right input every time without a well abstracted text input that does the hard and annoying stuff for you.

We switched to components for a reason but it seams like people forgot.

And yes not every blog or form needs to be writen in nuxt or some other big framework.

The Web was never meant to have an interactive scripting layer. It got there by accident. Microsoft's XmlHttpRequest paved the way for page loads without page loads, and it became an accidental standard due to how it worked.

We can go back and replace Javascript with whatever we want, or expand the <script> element to be able to handle more than one language type.

Not really sympathetic of big web apps having to adjust to such an environment. I already don't consider them truly part of the web. They're something you can make with the Web but don't actually represent the values or accessibility that the basic Web already provides.

I only use JS when absolutely required.