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.

I’m genuinely asking. I never understood this argument that people bring.

In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.

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.

For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.

Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.

While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.

The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.

Why?

TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of a sudden doing things client side makes sense.

Engineering is all about tradeoffs. I’m tired of people trying to make blanket statements like “React is always better”, or “SSR is always better”. It’s not, and we know it’s not. There are several successful, performant, maintainable apps written using React. There are plenty written using a backend framework and SSR too. Heck, there’s successes that use both!

The common denominators in the success stories? Competent engineers. And I expect a competent engineer can analyze requirements and determine what would be the best outcome for their target users. A booking site absolutely benefits from a front end framework that handles client side logic. It probably also benefits from a clever backend for processing the data after the user is finished with it. Let’s not pretend there’s a one sized solution that fits everything, because there isn’t.

A tangential answer (focusing on backend not language) is because I'm (we're) going to have to reproduce much of the fronted complexity of the business logic on the backend to validate what the frontend sends.

I'm mostly agreeing with you. I've built multiple web-platformed insurance systems and booking systems in the last decade and moved from fully server rendered pages to client rendered forms. The complexity increased with that change but as you highlight once it's done the ability to test different frontend flows is great.

But I'd like a way to share more of the business logic rather than writing it twice.

A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to make a lot of network calls, so you're going to deal with latency, there's no client-side solution that avoids it without risking the issues above.

The big projects are of course important. But even chrome needs a simple little website with a download link.

Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.

A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.

The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.

But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with technical (e.g. tech bloat) limitations in mind feels important only to technical people and not to actual computing.

If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).

Our online lives would be a lot better if the product folks listened to the tech folks a bit more.

I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.

The small projects are where the people I care about are struggling.

Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step.

And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.

It's almost impossible. The first reaction is always `npm init`

You can still find developers who are using the basics, but mostly they're designing WordPress themes or working for boutique web design agencies, because those are the sorts of problems that are solved with just simple HTML, JS, and CSS.

It's like asking a Java developer when the last time they developed something without maven or gradle is, or Python developer why their first reaction is to use pip. If the majority of problems developers had to solve were simple enough that they didn't need these tools, then there'd be far fewer developers and most of them would still end up working on the 20% of projects where they're necessary. Because, well, that's where the complexity lies.

And, while only a minority of projects are that complex, those projects are the ones most developers are working on. Most other projects are probably better served with a wordpress install and a bit of theme customisation. Which means it's going to be a minority of developers who work with the very minimal things that are sufficient in these sorts of cases.

e.g. WhatsApp back before the acquisition

Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.

However I'm taking about even lower down the food chain than this.

something like this: https://www.hotelpalacebarcelona.com/

they don't care it's not "html first"

I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.

If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.

I can say with confidence that unless I royally screw something up in my component lifecycles or render loops, everything is just as snappy as ever. No latency. No lag. Just a zippy fast web app with URL/route changes that fly, fetched data populating quickly, and interactions feeling wonderful -- and that's because said apps I'm developing _aren't_ using any heavy tracking libraries.

People are too quick to blame slow performance on modern view libraries, and even likelier: they've never used them before.

Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you.

The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either.

Just like the original article, you might want to test your assumptions a bit more.

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.

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.

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.

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.

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

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

One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event listeners. It's actually somewhat worrying - when regulations hit us, we'll have to scramble hard to get back what we threw out.

But all in all I kind of agree with you that it's very hard to find high profile examples of sites that are "HTML first". I believe in it, but haven't actually seen it pan out. But I suspect the reasons for it not panning out might be purely in education. By the time HTML became powerful, frontend dev education was already deeply framework-focused.

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

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?

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

If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.

> entirely on you

of course - choosing a framework or hand rolling one makes no difference. It's still not production ready, if it doesn't have accessibility built in.

Choosing, for example, whether to use a div with a click handler, or a proper button, is a decision you need to make regardless of whether or not you're using a framework.

So it seems incorrect to say that you lost accessibility in this case due to the framework. You lost accessibility due to developers who didn't understand the web platform well enough to design proper accessible controls. If they hadn't used a framework, they'd probably still not have made the site accessible.

And i actually think that it is _better_ for a developer not to have to do their own accessibility controls, but delegate this problem to the component framework. They have to know about the problem, but not have to spend cognitive budget thinking about it while they compose their UI from framework components - this should _automatically_ be taken care of by the design of the framework.

I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.

Nothing is more convincing than real world success stories.

Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatible components, having to update things in different parts of the screen. And the last often requires a total paradigm change in terms of how data is handled in the app thanks to the introduction of state managers (React-sans-Redux looks totally different from regular React). All those require extra work on every project I worked, and no, libraries often don't solve them completely or as easily as it is with previous backend tech.

These frameworks are also steering a lot of software into some very problematic product decisions. Like using fancy third party components where stylized native would suffice (and be more useable/accessible), using date pickers for absolutely everything that looks like a date (it sucks to type your birthday in those unless you were born this month), saving things in the browser instead of in the backend (so the site looks different in different computers), or just having some specific UI-framework forced on you so you have to use a certain framework.

There are obvious advantages to frontend frameworks, and I'm a big fan of React/Vue/Svelte. I really like those things, been using those for years and I was doing what used to be called "DHTML" since the late 90s. But it takes so much more complexity than the average web app to reap those advantages... IMO they are definitely overused.

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.

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.

whereas you can addEventListener anywhere you want

I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities.

Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps.

With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the front-end, built om modern principles like functional, reactive programming.

Now I can do software development. Before that, with HTML, CSS, plain JS, PHP it was ... just hacking, nothing else. (Rails was good for full-stack, was not shining on the front-end)

I'll skip frameworks when the web stack will be ready for the apps, too. Now it's (perhaps) good enough for sites, I should admit.

"But we need this and that custom dynamic logic..." well now we're in the realm of software development.

At that point, I'm just going to start the project with React / Vue / Svelte every time because almost 100% of the time, I realize I need to support the features they offer that raw HTML/CSS cannot, or if they do, are very poorly implemented by browsers, hitting limitations with them that become frustrating and prevent you from achieving the scope you're aiming for.

Using any of those three libraries/frameworks is painless, and I can get a project going rapidly and with high confidence that I can support any functionality, interaction, animation, content, routing, and other common web problems, with great ease.

Like it or not, the web is an excellent platform for delivering software applications to users, especially one-off or infrequently used applications.

Let’s use software development tools, rather than web publishing tools, to develop that software.

As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based on the features you need vs. the market share of older versions.

People (and teams) choose web development for the lower barrier to entry, and as a platform, browsers get products most of the way to their goals, and fast.

Is it your preference to install a new local first desktop application any time you wish to do any of these things?

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.

With the introduction of Angular 1.x and eventually React, Vue, and Svelte -- creating web apps finally felt productive, easy to debug, and easy to ship. Wiring up interactions finally felt intuitive. No more jQuery code colliding with itself as you struggle to organize your project and cobble together a bunch of poorly maintained "component" libraries and pray they work together without obvious user-facing bugs on your site or app.

Or worse: on a team of engineers.

I won't lie, learning how early build systems worked was a pain, but the curve was completely worth it, and I wouldn't change a thing. Today, using tools like Vite with their default project templates is almost too easy, and you can hit the ground running in no time.

Publishing to Vercel, Netlify, and other modern hosting stacks is a breeze, and they all support direct tie-ins with every popular package & build system.

When you make a product that looks like it works but doesn’t, they don’t understand. They put you on a path to overpromise and underdeliver.

One of the lesser known features of unit tests are that they give the code that management can’t see more QA prior to being wired up. They narrow that awkward window from first paint to shipping.

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.

[1]: https://docs.astro.build/

Then of course you're left to reimplement basic browser functionality that you now lost (or more likely, you just grab another package that solves that and throw it in your payload).

Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites.

In my opinion, people today are afraid of writing code. Everyone wants some framework to write code for them. That is not how we push our industry forward.

Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.

Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily using it at their day jobs. React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens.

React might be 10 years old, but it changed like 5 times during that time. Something built in first or second version of React is pretty much an entirely different framework at this point. (Would it even build with using the newset toolchains?). It's almost disingenuous to ignore that fact.

So while it's unlikely that there won't be a thing called "React" in the future, it's not that crazy of an idea.

Today, it's moving heavily towards server-side rendering because the client-side / SPA format is already quite mature. Their approach with server components is an optimization path that uses concepts/patterns from already popular server-side languages and frameworks + templating, and blends them seamlessly with client-side development, giving engineers the best of many worlds.

This was a natural evolution from NextJS which popularized this way of using React, and it's giving engineers more choices in how they build + optimize their apps.

It’s just going back full cycle, with a few extra steps. And the only clear purpose is SEO.

And speaking from experience maintaining React apps is quite nice. React has great backwards compatibility, and where it doesn't there are usually codemods available. Dependencies can be tricky, but that's not exclusive to React.

Also don't forget React evolves, backed by multiple #huge companies, and still innovating.

But here's the thing, hot-shot devs, and hot-shot dev wannabes look down on maintenance; and humans are social creatures, me included. So I'm not going to do a job for you that you look down on, unless you carry me in (and out) on a sedan chair.

Same for writing doc, I'm good at it and enoy it, but there's no pleasure in doing something that other people don't really value.

Popular backend templating systems face the same problem with possible sunsetting and decay of collective knowledge over time.

React is a great investment, and is here to stay for a long time because its team (and community) are massive, and are keeping pace with newer libraries/frameworks that are in a lot of ways doing things better. React's market share has hardly been touched by Vue, Svelte, Solid, etc. and less so by HTMX and other new attempts at un-frameworking the web.

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.

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.

Not everything has be a Large Enterprise Application.

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

Basecamp (formerly 37signals) has a track record of challenging the status quo, whether in business or engineering practices and to actually be fair, they're not changing their front-end philosophy on a whim or to simply follow a fad. They're trying to solve real problems. In the past, their flagship product served as proof that exposed many established counter-advices as merely baseless beliefs. Over the years, they've demonstrated how many "bad ideas" could actually work better for you, once you allow yourself to become a bit more pragmatic.

They might not be BIG, but they're also not small. Imo, what they say and do engineering-wise tends to matter much more to average developers than what Facebook or Google might recommend.

I think the question stands, is Basecamp a good enough example?

To me it seems more like they’ve evolved it.

From Rails UJS using jQuery, to vanilla Js, then TurboLinks and onto today’s tools like Turbo and Stimulus.

The evolution isn’t a bad thing, and the older approaches still work in modern rails.

They’ve changed and updates the build tools, but then you have to keep up.

They went from Sprockets, to Webpacker, and then module loading to replace Webpacker.

So they’ve haven’t changed philosophy as such, it’s just considered and measure evolution and refinement.

Feels that way in practice to me anyway! :-)

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

My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use 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.

> Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)

Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1 website on all browsers. (Its of course a different story if you need custom functionality.)

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.

For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page.

But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.

* For adding an appointment, I probably want something closest to the conventional date picker, but even then, if I'm making an appointment for a group, I might still want additional information about when people are available displayed directly in the calendar view as I'm choosing a date.

* If I want to browse for the cheapest date, then I want a way of seeing all the dates available and the prices of those dates at the same time, meaning a relatively rich date picker control. If all I have is "next day"/"previous day", then I need to manually click around a lot to get good deals.

* If I want to select a range of dates, then I want a single control that allows me to select that range immediately, not having to open a "start" field and an "end" field separately. I also probably want multiple months visible, depending on how long my range is, so I can see the whole range at a glance without having to click back and forth between months.

* This is more subtle, but a hotel visit requires a range of dates, but a flight to and from the hotel requires two discrete dates, which might potentially be indicated with yet another date picker variant.

These are all flows that require me to pick a date, most of them from a calendar, and all of them could arguably be considered important enough for a native element (in the sense that I use all of these elements in my day-to-day web browsing). But they're all very different, require different interactions and content, and have subtly different purposes.

There are hundreds of ways to support this using JavaScript because the community has cleverly come up with many different flavors of view handling to suit different mental models and preferences. What could be better?

Screen readers and voice input: https://a11ysupport.io/tech/html/input(type-date)_element

YYYY-MM-DD or GTFO.

    YMYY-YD-DM

https://en.wikipedia.org/wiki/Date_format_by_country

And to think that having a native look-and-feel used to be considered a must for any desktop application!

I would be much happier if all websites's UI components (not the actual website design of course) had the look-and-feel native to my browser (and if browsers actually cared to make them look good, TBH) rather than inventing their own dumb styles for everything.

- Select 5 non-adjacent items

- Select 5 adjacent items.

Report back with success rates.

Anyways, my favorite multiselect paradigm is the old windows one with two list boxes side by side and buttons in between.

Now we tend to have a part of the record appearing to have texture (stripes or bumps) as a clue that grabbing it will afford pushing it up or down.

There’s many little common standards like that which have never appeared in “out of the box” controls provided by the platforms.

Checkboxes are a good choice for a small number of options: https://m3.material.io/components/chips/overview . I'd say past a dozen options though this starts to become unwieldy.

Tag-style multiselects are fairly common (see https://react-select.com/home for an example). These are good where the number of values a user is expected to have selected is small (less than five imo) but the number of options is large enough to make checkboxes impractical. If you're expecting a higher number of things to be selected, you could have the option list stay open after an option is clicked, so they user doesn't have to reopen it each time they want to add an option (and, in fact, the "Animation" example does precisely that).

Two column designs ( https://crlcu.github.io/multiselect/examples/search.html ) have mostly fallen out of favor, though I feel they still have their uses for larger lists with large numbers of selected values.

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

but their example wouldn't work.

  


should probably be
  


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: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:
  
  


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.
              
        

                      reply
                  
      

This was my critiquing point as well. Style configurations should be separate from actions, with only references linking the two. It's the only way that makes sense for anything meaningful.

Yes, I could technically write a python app where all SQL database connections have hardcoded SQL as one one long file, but that is poor practice. This suggested principle seems the same to 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

Its example is also pretty weak. Vanilla solutions (Tip 1) works just as well:

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).

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

Also using a slash to self close a tag is not part of the html spec and it never has been part of the spec. The browser doesn’t know what that means on any tag. If you write

self-closing tags are necessary for void elements in XML and XHTML, both technologies that are still supported on the Web. Since XHTML processes HTML as XML, it forces it to be well-formed. Unlike HTML, which has all sorts of tag-soup and quirks modes and other things, because it's lax in its syntax.

Void elements lacking the need for a closing tag or closing slash is one of the weird edge cases in HTML. While it's not in the HTML spec, it may still be seen in the wild in XML and XHTML documents and is not universally bad or unsupported.

And if you're writing HTML, the browser considers

to just be a weird way to write

. The slash is non-significant. So confusingly .

The problem I have with self-closing tags is that I've met so many web developers throughout my career who think that browsers understand self closing tags. I used to be one of them! And that will almost always, but not always work out fine:

- React / JSX supports self closing tags. So do a lot of other web frameworks.

- Void elements ignore the /. (And you don't need to close void tags anyway). So you can write input, img, br, etc tags however you want.

- HTML5 will auto-insert missing closing tags when it needs them. Eg,

But it'll confuse you in weird ways. Like - which the browser dangerously interprets as an open script tag. Subsequent text is interpreted as javascript!

I think its good practice to be clear in all source files whether you're writing XHTML (eg in .jsx) or writing real, god fearing HTML. And then never use self closing tags in HTML. Sooner or later, someone will think they matter and you'll get bugs.

There was no real 'war', XHTML 5 is still a thing. Browsers are HTML engines because people who write HTML don't want to be forced into well-formed markup. They want the browser to guess what they meant and run with it.

There's also the whole "we need to be compatible with almost every HTML file dating back to the early 90s" conundrum that makes clean breaks in behavior, like XHTML, hard to pull off without pissing people off.

It should be clear which one is writing based on the DOCTYPE element. IIRC XHTML still requires a DTD to ensure its schema can be validated, while HTML 5 did away with it altogether and now just uses

There was definitely a debate over how web browsers should interpret web pages - as XHTML or "quirks mode". HTML5 (with infinite backwards compatibility) was the outcome. Every major web browser implements HTML5 - complete with its super quirky and complex, but fully specified and consistent parsing rules.

> XHTML 5 is still a thing.

Is it though? On the web? I just tried, with this html:

    
    
      

        

        yo
      
    

If this was an XHTML page, tags should be able to self-close. And in that case it should be black on white. But try it. Its not. The browser ignores the self-closing part of the tag, so "yo" is inside the inner div and it shows up in hot-pink. The outer div is then not closed correctly. (2 divs open, 1 div closes). If the page were processed as strict XHTML we'd also expect a warning or error, but the browser doesn't care. Neither firefox nor chrome emitted anything in the console about any of this.

As far as I can tell, the XHTML doctype has no effect here. The page is interpreted - as all webpages are - by the browser using HTML5's parsing rules. Not XHTML's.

There are contexts in which XHTML still exists. Like JSX. But the browser is not an XHTML renderer. Rail against HTML5 if you want, but people need to stop pretending that the browser supports self closing tags. They are not part of HTML5. Pretending they are causes bugs.

Also you need namespace declaration otherwise it will be rendered as unstyled xml.

This is all part of HTML5 spec: https://html.spec.whatwg.org/#the-xhtml-syntax

https://zlg.space/misc/example.xhtml

Let me know how your browser sees it.

span is a bad example. indeed it will close - but then it will reopen (!) when the next text node occurs.

is a better example, and it will also auto close when you try opening a new

, which can be rather convenient when trying to write concise html.

It's explicitly in the HTML5 spec as allowed, but not required.

I would rather there was just an explicit `onclick` (or some other event) in there with a vanilla JavaScript statement so I know what is happening.

source: I'm the creator of hyperscript.

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.

Regarding the CSS size, my experience was the opposite, Tailwind output was usually a lot smaller than hand-written CSS.

I have nothing against plain CSS either though; but it's at least as easy to make a mess.

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.

Browsers partition caches by origin now for privacy reasons, so this is no longer possible. If the user doesn’t have it cached from your website, they don’t have it cached.

Tailwind requires a build step and shipping the 1.x development build was explicitly not meant for production.

Trying to use tw 1 like this without a build step, you can't even define a custom color scheme.

If this is what you want, I'd use a library that actually supports this. Maybe tachyons? But tbh, without the build step I'd consider using Tailwind at all a massive mistake. Then I'd prefer handwritten CSS.

Custom properties should make sth like this a lot more viable though. I'm sure there are libraries that better fit this use case, if you want to use a CSS library.

I haven't looked at your css, but maybe changing the box model could help?

But IIRC it doesn't offer quite everything full Tailwind does. In general I was frustrated with Fresh for not being up-front about the fact that it is largely built on Preact and Twind, and you must buy into those libraries first.

I use tailwind on my personal site, which is otherwise entirely just vanilla HTML, and it doesn't feel very intrusive to run the CLI in watch mode when I'm writing styles.

For example, tailwind without a build step is just the entire library. This means one can go a long way and even have a functioning web application without introducing a build step.

I would say stripping unused CSS is in the same context as optimizing images, fonts etc perhaps generally a "cleanup & prepare assets for production" step.

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 think what the article is about when it says to steer clear of builds, is complex builds, where transpilations and similar changes in format have to happen, in order for the page to work.

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.

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

You (and indeed everyone else) has no real need for heavy JS front end bloatware. Just say no. Serve light pages from the backend (or cache) and do all the fancy work in CSS (if you must).

Say hello to fast render times and global accessibility.

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.

This should be like three files max (one, ideally) on the BE and similar on the FE. Things I used to 15 years ago in a few minutes takes _hours_ even when you know what you are doing.

So many sites these days are so bloated and slow as to be unusable. Those of us devs who chose the other approach have to work harder no doubt but our users are much happier. Isn't that the goal, after all?

My current users value speed of feature release over almost anything else, because the system needs to adapt to their rapidly changing business rules.

In my previous job, correctness was the most highly valued attribute, followed by adherence to consistent design across the org (which was large, and produced many sites that a user would navigate between all-but unknowingly).

In either case, if I'd gone on a HTML purity rampage, I would not have been helping my users in any meaningful way.

Thought TBH the article's examples are whack to me. Why would I write pure

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!

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.)

This is even easier now we have 'data:' URLs. It's also useful for avoiding problems on file:// URLs, which don't even need a HTTP server.

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.

If "making the red-bouncy-plonk button instead become the blue-wobble-thunk button" requires chasing through a maze of 3-to-7 interfaces and classes to find which classes need new implementations and which can be reused... Suddenly what sounded like a 10 minute change becomes half a day of swearing under your breath at either the compiler or the previous engineer.

Sure, abstract things, but make sure there's also a way to bundle behavior together in one common spot, so I don't have to touch 6 files to update one component.

https://htmx.org/essays/locality-of-behaviour/#conflict-with...

With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.

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.

IMO you no longer need an intelligent naming philosophy for CSS classes due to how far CSS has come.

The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymore? You now either need to change the CSS class name everywhere, or leave it as "green" and confuse everyone because it is actually blue on-screen? This only scratches the surface - there are all manner of other considerations to think about (different display/print medias, dark/light preferences, HCM etc)

Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you write an Approved component. At that point it's better to have the css and html for the Approved component in its own file as when you're updating the style you'll need to change some mixture of the html and css.

Without components tailwind is probably a bad choice.

Back in the late 90s and early 2000s, the dominant ideology is to use semantic class names, e.g. ".sidebar" instead of ".blue_bar" or similar. Essentially, don't describe how something looks with its name.

Even when building JS apps, I use CSS classes semantically with ".selected" ".menubar", etc.

I am interested in reading your philosophy on CSS classes.

Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via

In such an environment, do people decide on no structure for their class names? I'd still want reusable CSS in such a situation.

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

But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence.

Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.

Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick.

But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier.

I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.

>Classes that appear later in a class attribute take precedence over one’s that appear earlier.

This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.

And "separation of concerns" isn't?

What should be separated? Along what lines? How do we determine these lines? When does it make sense to pull some concerns out into another class/framework/markup/whatever? When does it make more sense to leave things stuck together?

The answer is: "It depends".

Not separating anything leads to spaghetti. Separating as much as possible, all the time, everywhere, leads to overly abstracted code that is easily as hard to maintain as spaghetti.

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

Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.

If we look at HTML as a document / presentation language, we cannot deny styling. CSS is not only styling, but also adds animation.

In any case, CSS can be seen as aspect oriented programming.

The real problem described here is the lack of great tooling across languages / frameworks.

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

For example,

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).

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!