> But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS.

I would certainly agree that using a little JS can get you further than just HTML. But I think that a plain HTML page is far more pleasant to use (and thus, functional) than the JS monstrosities that dominate the Web today. There's a reason people use the NoScript addon: because a whole lot of website designers use JS in ways that make the experience a ton worse for the user.

> There's a reason people use the NoScript addon

To be snarky, do they? The average user doesn't even know what JS is.

Users want websites that are fast and solve their problems, with a good UI. They don't care how it's made.

Make websites that people enjoy using. A good developer can do that with any set of tools, though a no-JS approach is limited in scope.

It's not an either/or. Modern Javascript is actually really nice to write and use, and you can write it in a tight, minimal way that doesn't bloat the page or slow it down.

>you can write it in a tight, minimal way that doesn't bloat the page or slow it down.

Yet most people don't.

There are some problems with the language itself but it's mostly from a users perspective that I find it frustrating.

Of course you can, but most people still opt to pull in a whole framework (React) or heavy library (jQuery) just to achieve what's essentially a few XMLHttpRequests and some DOM changes.

Maybe because it is easier to track one library, react and jsx. I wouldn't use xmlhttprequest since the request api exist.

> Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code.

You're overthinking htmx then. I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.

Server always has authoritative state and code is dead simple to reason about.

> You're overthinking [noun]

Yes, almost certainly!

> I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.

Good trick! My only experience of HTMX in production entailed porting Stimulus code, hence the partials, but your approach is obviously much neater. I'll give it a shot, next time it might be suitable.

OT: marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same.

I have been trying to find other more commonly known UI patterns that could be done natively. The time has long come for tabular data to be put into HTML tables just by referencing the source. Xslt almost did that. Another one is integrating xml http requests with native html. I think HTMz came close to this.

Sounds great <table type="text/csv" src="mydata.csv"> Then have it generate actual html so that you can target th's, tr's and td's with css.

I believe the lowest hanging fruit would be <div src="article.html">

I think formData should also be available as interactive JSON but perhaps it is possible to also populate a form with fields from a json with something like:

   <form src="mydata.json">
     <table>
       <input name="baz" type="number">
     </table>
   </form>

Where mydata.json is:

   {"foo" : "bar", "baz" : "42"}

And have something like this come out:

   <form><table>
     <tr>
       <td><label for="foo">foo</label></td>
       <td><input type="text" name="foo" value="bar"></td>
     </tr>
     <tr>
       <td><label for="baz">baz</label></td>
       <td><input type="number" name="baz" value="42"></td>
     </tr>
   </table>
   </form>

It wouldn't cover everything but it is very nice not to have the later if you don't really need it.

There's a usability and design issue with that as you lose what you're reading as it scrolls off the screen. Also, scrolling is a styling issue and not a document description issue which is what HTML is for.

Note: <marquee> has never been part of any HTML standard since the beginning except the current one which only has it for the purpose of marking it obsolete so people will quit using it.

> marquee tags were a missed opportunity to implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same. I have been trying to find other more commonly known UI patterns that could be done natively.

Are you sure you are talking about the functionality of the marquee tag? What exactly do you mean by "implement horizontal scrolling often used on shopping websites. Now it uses JS to achieve the same"?

For a banner-type text "Sale: 50% off until New Year" I can imagine this. And this is possible with almost no JS, by using a CSS animation on translateX. I think you need to pass the initial width of the content one time from JS to CSS via a custom property IIRC, and update that variable on resize, for example using a ResizeObserver, to avoid a jump when reaching the "wrap around"...

But – sorry if this a misunderstanding – I have a sneaking feeling that you might also have things in mind like swipable horizontal lists etc?

This is also possible using CSS in theory (scroll-snap and overflow-auto, and CSS to hide the scrollbars). But last I tried to use it, it simply wasn't good enough to sell it, compared to a fat JS library that did the trick, perfectly, on mobile and desktop.

When it comes to UX niceties, I feel it's pretty common to have HTML+CSS solutions that are good enough in theory, but suck in practise.

For the horizontal scrolling with "snap", I would also like a good JS-free solution. But I feel that the more interactive and complex the UX patterns become, it would be senseless bloat to build a specific implementation into the platform.

I think that "autocomplete" inputs are a good example for this, as discussed in another thread.

I once tried to implement a custom autocomplete using datalist (including dynamically updating the list with xhrs). In the end, the native element had so many issues that it was a waste of time and a JS solution was way better. At the time, that JS solution was Alpine.Js, because it was a b2b app with minimal a11y requirements and JS-allergic developers.

Within an hour, I was polishing keyboard use while the "near-native" solution using datalist was broken in a thousand different ways in every browser and in the end didn't work well at all.

I miss marquee... I burned more tokens than I'd like to admit to build a marquee-like feature in react and it was really just the same text twice with an animation that hopefully no one notices isn't a clean loop on some viewport sizes (since it restarts after reaching the end).

I haven't used it in anger myself, but if you know Elixir and Phoenix you might like Gleam, which compiles to Javascript.

I appreciate the helpful reply, but I think this is precisely the kind of indirection I need to avoid. I'm a sucker for elegance. If left entirely to my own devices I'd probably design a language / write a transpiler of my own, and wind up with exceedingly elegant tooling for websites, and no websites. :)

This is why I don't use Typescript or frameworks in my own projects, I just constantly seek the cleanest abstraction and never get anything done. Using a deliberately messy solution is annoying but at least I accomplish stuff.