HTML First

Never read the comment section!

Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides?

Nothing is more convincing than real world success stories.

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

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.

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 , don't use ) 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.