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.