note that the <input> tag does not use and does not need a closing slash and never has in any HTML specification.

https://html.spec.whatwg.org/dev/embedded-content.html#the-i...

Which makes the example even more egregious. There are certainly better ones that:

1. Can't be easily done with vanilla JS and so can justify using a library.

2. Don't need a library with a DSL in direct opposition to the claimed principle (avoid DSLs).

I'm not saying hyperscript isn't serious (I have no opinion on it at all actually). I'm saying the claim "avoid DSLs" followed by an example using a DSL is a sign of unseriousness on the part of the author of HTML First.

Six principles and one of them is presented with an example that blatantly violates that same principle. I could see a mistake like this slipping through if there were many more principles and examples, but this is a relatively short piece for such an error to slip in.

Perfect. This place is overdue for an exhaustive debate about HATEOAS/REST/etc, and you have an incomparable talent for starting such a debate.

I find I'm in the opposite position - I would rather the date picker is not consistent, because different date pickers have different purposes. The date picker I want to use to put in my date of birth is different to the one I want to use to add an appointment to my calendar, and that's different to the one I want to use to browse prices for different days, and that's different to the one I want to use to be able to select a range of dates, and even that's often different to the one I want to use to select the two dates of a return journey.

Of the classic form controls, choosing a date is probably the one that has the most application-specific needs, and therefore the one that I would most expect to vary between applications.

Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.

The optimal date picker depends heavily on the platform too. Don't want your crusty custom date picker over my platform specific date picker that I know well.

The default datepickers in browsers are not feature-rich at all though. They're fine for extremely basic "pick a date" type of usecases, but as soon as you want to do anything slightly complex like picking a range, a date & specific time in one or having it be interactive in some other way like Google Flights showing you a range of prices alongside the date etc., you have to create your own datepicker component (or use an already built one).

This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse, etc.

The default date picker is laughable. For example there is no way to control the format in which the date is displayed.

Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking. A more UX-friendly alternative is to have checkboxes; you can still have shift/control-clicking on top of that (for selecting many things quickly), but it shouldn't be the only option.

Yeah, shift/control-click is a longstanding workflow for multiselect and macOS, Linux and windows all support it with various platform-specific subtleties. The worst part of the web is losing all these sorts of features because some web designer thinks they’re a “bad UX”

Drag and drop? At least that’s only using a pointer device without modifier key…

I think GP is talking about how, without the tailwind build step, you ship all of tailwind, which is unquestionably a lot of CSS that you aren't using.

Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided?

Still though, tailwind is pitched WITH it's build step normally, making the author's point about avoiding a build step a bit odd.

I think what the OP meant is: Tailwind requires a build step to extract use classes. Otherwise you need to ship all of it.

Did your experience involve the (recommended) build step? It uses, at least last I checked, a purgeCSS step to remove unused rules and decrease the css size.

> Tailwind output was usually a lot smaller than hand-written CSS:

Tailwind output is massively bigger than the one with semantic CSS. Here's a comparison:

https://nuejs.org/blog/tailwind-vs-semantic-css/

Imho, bullet points on the border box seems weird to me (https://ibb.co/d0sDsQ2).

Tailwind doesn't exist without a build step (at least since v2) — the whole point of Tailwind is that it is a build tool, an alternative syntax for writing CSS.

There's a kind of development version where that build step runs in the browser on page load, but it's still a build step in the sense of generating all that CSS dynamically, and it will produce a poor experience for a user if you try and use it in production.

I read it the same way, yes. Good point with the cleanup: - it’s one thing to need to run build for it to work; - it’s another thing to run build to make it smaller;

> The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version.

This isn't true, though—Tailwind's build step isn't just stripping out white space, it removes unused selectirs, too, which can't be done in advance.

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects.

Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.

I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.

I'd be more than happy to see small or medium projects and how these tips improved them. Any real world examples would be great.

I would also add that a lot of us do work on the bigger projects, which makes sense as bigger projects require more people. So at least in my life, and I expect many others, it is quite relevant.

I also don't believe the article qualifies that these tips are only for small to medium projects, I'd read it very differently if it did, but I would still like to see some real world examples though.

This.

Big companies are in the minority and what they do would not classify as "normal" or "standard practice".

It really bugs when people say "it's standard industry practice" when actually what they mean is "thats how the big businesses do it".

> In my view, the web is 95% small to medium projects.

I'm not sure that view is correct. For one thing, I'm not sure how you even define this.

As technology has advanced, many of the "small/medium" projects that used to require lots of dev time have turned into fully-built alternatives. The days when you need a dev to setup a blog are gone, as are the days you need one to setup a store, or a simple marketing website.

Are these part of the 95%? In some sense, yes, but in the sense of giving advice on a framework to choose, not at all, because no dev will even be making that choice - it's irrelevant.

As for medium-sized projects, there are tens of thousands of small, internal company tools that aren't even on the open internet. They probably fit your definition of being medium sized, let's say have a few devs working on them for many years, certainly medium sized compared to FB etc - but I'm not sure that whether this approach is right or wrong for them. (Genuinely not sure!)

I'm just saying, you need to much better define what you mean by small and medium sized, because some people might be thinking of my definition, while for some people medium-sized is, idk, AirBNB, which is tiny compared to FB but gigantic compared to most projects out there.

I would say that explaining where guidelines are applicable is on author side.

For text at hand I understand that author expects this way should be “the best” for everyone.

Then author gives examples that even in medium project at first requirement change or first additional non-trivial rule are going to have 2-way bindings plus bunch of other plumbing implemented where “html first” doesn’t have it and someone will have to write some JS monster to handle state etc.

If your project is small, doesn't matter what you use, it won't be complex anyway.

This is not only about big projects.

Their second principle, to use inline styling, makes it harder to create a consistent look across the entire website. Defining that in one place and referencing it everywhere is better and easier.

Anyway, a well organised big project is a collection of related small projects :)

And what's good for one small project is likely to be good for many small projects.

> In my view, the web is 95% small to medium projects.

In what terms? Sites in existence? I suppose. But sites by usage? Virtually all huge.

> it's very hard to find high profile examples of sites that are "HTML first"

Because the tools to create it are relatively new, and the sites you're speaking of had already been written. What high-profile site didn't already have a massive legacy React/Angular/Vue codebase, and a team of framework-trained developers, as of 2021?

> One semi-objective thing we lost was accessibility.

TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs

This article had as a “good” example a div with an onclick, I think he fixed it, but it shows a lot..

Frameworks also have linters that will help a lot, it’s on you to use them

Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo

Good old times, I used to have a file watcher that would refresh the page on change using a browser extension, not anywhere near the convenience of HMR though haha.

I do agree with you, it's why I'm skeptical about the results of following this advice. I vividly remember how much things sucked, and obv the web has come a long way, but the tools have gotten even further. If I see how much mileage I get out of the tools I use on the daily, I would not be nearly as productive without them, and produce a lot more buggy, inaccessible, and shitty apps.

> starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps

Honestly, and sarcasm aside, I think this is an incredibly important thing for any new web developer to do.

Trying to learn web development in 2023 (or even in 2014, when I started my career) is so hard, because you're constantly standing on top of the shoulders of giants without even knowing how far you are from the ground.

I started a refresh of my personal site a few months back and resolved to write all the html and css "by hand", vanilla style, as a way of forcing myself to relearn the basics, and it was really refreshing to strip away all the layers of extra stuff and build it with simple tools. And I actually learned a ton of stuff that was useful on a daily basis while I worked on a React project during my day job, stuff that I just had never had to do or learn or use because some framework was always helping me out.

Recently I've been working on a little toy app in Phoenix, and I had the "revelation" that Eex / Phoenix components were slowing me down instead of speeding me up, because I didn't understand the underlying concepts as well as I needed to. As soon as I said "fuck it, I'm writing vanilla html and only using Eex where it's absolutely necessary" I was able to get through a whole host of issues that were giving me friction and actually build what I wanted.

I had a similar experience a few years ago when learning Phoenix. I just didn't get Ecto at all, and the reason was simple - I didn't know SQL and database design. Once I resolved to just figure out how to do the thing I was doing with raw SQL, Ecto immediately made way more sense.

We obviously can't peel back layers of the onion forever, or we'd never get anything done. At some point you have to get comfortable with abstracting away the details. But what I've found in web dev is that the big frameworks are written by people who've done the "vanilla" way so much that they've identified places where things hurt and built solutions that abstract that pain away. That's all well and good when you understand why the abstraction exists and the problem it solves, but it can really be confusing before you've put in the work to gain some of that context.

and this is why that example doesn't work - you find out onclick doesn't work where you thought it would work

whereas you can addEventListener anywhere you want

Perhaps web publishing shouldn't be presupposed to be 'software development'?

All of the technologies you used previously were considered "finally fully fledged" until they weren't!

We will be doing something different in a couple of years and saying that the stuff we do now is out of date and the new stuff is home. It's always been this way. We are tech nomads finding ourselves new homes as and when we move on.

No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the industry forward, not by building less, more basic, and shittier applications in a some faux-noble quest to use inline event handlers.

In some sense I agree, I am very mindful of the dependencies I add and I am not afraid to write something custom if that better fits the situation.

But this article is not showing me how to do that and the things listed are not going to have an impact on the complexity of my projects as these basic things are solved quite well.

> By adding an advanced framework you up the complexity by default

If you know your project will remain simple then by all means. That's often not how it works though and then you end up writing a framework yourself once the scope gets increased and features are added.

Adding to that that using a framework gives you so many things for free. There are so many aspects to a good website and leaning on a group of people specialising in all those things is often a smart move with better outcomes.

I think the initial complexity might be a little bit higher, but there often is a big return on investment later on, and also immediately in terms of productivity.

I'm not going to stop you from not using a framework, I think it's great to experience it, have been there many times before, got burned (badly), and now make different decisions.

The worldwide jobs program that is modern-day Javascript would have you believe that elaborate front-ends are necessary to give end users the experiences they expect, which is an utter pile of lies. What users want is something simple that works.

One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board.

This is why I reach for a view library like React, Vue, or Svelte, even if I'm creating something simple. This is because I'm familiar with using these and they provide me with the ability to implement nearly any kind of dynamic functionality or interactions I could want, fine control over component lifecycle, and tight integration with my CSS library of choice to speed up development.

End-users are none the wiser, that is of course unless I do a terrible job using these tools.

I'm not sure that's always the case — we don't expect assembly to be a high-level language after all! The more specific and batteries-included the browser becomes, the harder it is to go off the beaten track. My standard example here is date pickers — theoretically it's just a simple component, and yet there is no one-size-fits-all option. What works for booking an appointment won't work as well for putting in a date of birth. What works for a date of birth won't work if you're trying to book a set of nights in a hotel. You might want to include prices for individual days directly in the date picker. You might want to show which days are valid and which aren't. You might want to show several months, you might want to show just a week.

I don't necessarily disagree that more components in browsers is a bad thing (I've been very happy to use the new modal element, for example), but I think the browser is working better right now as a lower-level (albeit still fairly high-level) platform that allows people to build a variety of documents and applications on top.

Perhaps, but can you name even one successful, big, bloated institutional project that operates primarily on the principles of HTML First?

To be fair, 37 Signals (Basecamp) which is behind ruby on rails, changes their front end philosophy with every new major version of rails

And to be fairer, it's generally a pretty good philosophy for greenfield apps at that particular point in time, but if I started an app on rails 4 or 5 there's no way I'm updating my front end every time they change their minds about how front end should work

They believe this now, in 4-5 years it'll be XYZ next thing

It's been a while since I used it but I did a limited trial of Hey and it was genuinely miserable to use. Not only did everything take a few ms extra, the entire interface was so incredibly janky and had no accessibility concerns at all. They were shipping their website to their mobile apps and it was horrid. I would not put Hey as a shining example anywhere for this philosophy

It's been a long time since I used Basecamp but that was decent enough

Yeah but have you noticed how hard it has gotten to include simple libraries like day.js or three.js? It's still doable, but it's not easy anymore. Then there's some real value to be found in frameworks like Quasar which gets really painful to use via a cdn, which I've been doing for years now. Vue3 complicated things further so why not just move to react once and for all?

Vanilla JavaScript just didn't manage to solve what it kind of promised to solve via web components, the lack of templating is really a bad shortcoming.

I really do need things like Quasar and the stuff that Vue (and react) offer because it really helps a lot in usability. I've just been doing Vue with Quasar "by hand" via local CDN without compiling and it was such a win, but the more these frameworks evolve the less it's possible to ignore the fact that these are "modern frameworks" and the pain just grows too much.

For smallish or personal sites I'm 100% on board. For a large enterprise-y app, which in a previous era would have been a rich client deployable, the benefits of these hulking UI frameworks outweighs the costs.

I wanted to show people how easy it is to do cool things with a computer, how low the barrier to entry is.* One HTML file. Your OS's built in text editor and browser. You look at the code and you can see it there in front of you! It isn't obfuscated. It isn't even minified. Everything is right there, all together. You can just save the file and drag it onto your browser. No Git, no zipped project folders. No build system! No server! (No MIME type errors!).

The "frictionlessness" of lowering the "activation energy", is not just nice for beginners... heck, it's nice for me! I can just download this file from Wayback Machine and continue hacking on it!

It does, of course, limit you to very small codebases, but that's what I like! Many small projects. The spring physics creature linked above is about 300 LOC total. The ASCII bonsai tree is ~100: https://web.archive.org/web/20220823113003id_/https://andai....

*In terms of tooling/setup, at least! Learning to code is another matter... (Neither of these projects are very readable for a beginner though, so that aspect needs some work.)

Sorry, I didn't mean to imply this! My original comment had "I even go so far as to..." but it got lost somewhere in editing.

Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO.

There is no harm in a plain CSS file, and applying classes at the element level in the HTML.

If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings, letter spacings, font sizes etc etc which lead to quite a lot of extra crap in each element on your page. Repeating those all over each if your HTML files is a real burden. Just use a single CSS file with sensibly named classes - it doesn't need to be sass or anything, just plain CSS is fine.

I think there are some other benefits of tailwind. Say you have a set of css classes for different components.

Then say one component on one page now needs to be styled differently.

You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes.

All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place.

That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable

It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.

Yep. I've said this often but whatever:

JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.