Hacker News Reader

Comment by samwillis | Hacker News Reader

This is a brilliant list, I'm a particular fan of HTMX and Alpine.js.

The move back towards small dependancy free JS libs, in combination with modern JS ES Modules, is absolutely brilliant.

I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things.

Obviously larger apps, with many dependancies, will require all the incredible work thats gone into modern JS tooling, but for so many simpler (and not so simple) sites this process really does make sense.

View on HN

> I learnt web dev back in the late 90s by doing "view source", and was still learning about new things that way well over a decade later. If we can move back towards that, by not having a build step, it will be amazing for new devs starting out and learning new things.

Same here, and I couldn't agree more. Had minified library soup with dynamic page content been the norm back then it would've been much harder to get started, and there's a high chance I would've just given up somewhere in the process.

Having a build step also increases activation energy and friction which impedes the sort of in-the-moment tinkering that often sparks projects.

> Having a build step also increases activation energy and friction

Yes this! As an interpreted language it should not need a build step. Every project should be

    git clone https://github.com/user/foo && cd foo && google-chrome index.html

You guys are singing the song of my people. For years I've been confounded at the idea that we need to be building/compiling interpreted code.

And the tooling... my God! I know this makes me sound like an old man (because I am) but, it used to be all I needed was an editor, an FTP client, and a browser. write-upload-refresh. Today, I find VS Code, `git push`, and a browser still serves me very well.

I'm also against building and compiling (I work with Python and Ruby on the backend) but there were good reasons to have those steps, at least in the past and probably still now. Short and very incomplete list, feel free to reply and add points:

* slow network, especially on mobile

* reduce the size of the download by minifying

* reduce the number of calls by bundling files in a single one

* Inconsistent JS and HTML feature support among browsers

* transpiling to a common older version of JS

* add polyfills to implement missing features

* add widgets to implement fucked up default implementations or widgets that are nearly impossible to standardize (date and time pickers might need tons of features and are projects on their own)

Most of those points could be taken care of by building only when deploying though, skipping the phase during development. I think most of the annoyance with a build step comes from how you can’t do anything unless the tooling for it is set up, as well as how it gunks up the tweak → reload cycle.

Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!

Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style

Or, tailwindcss…

Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes.

Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better.

It's an experiment, seeing where it leads.

Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.

If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives

I'll never understand CSP not allowing onclick handlers. Having all your javascript in a separate file makes it very hard to diagnose and understand what is causing the event on the element.

onclick and other in-HTML handlers have some unsafe eval-like behavior for old compatibility reasons (with ES1 and the old web/old DOM) and I feel like the CSP designers were overly-cautious of XSS exploits via DOM manipulation that are hard to do in practice, but still in theory a major security concern.

I wonder if there were a better way to opt-in to "use strict" (and maybe even ESM friendliness) in onclick handlers if that would have fewer CSP concerns. I doubt there are any current proposals to build such tools for HTML, though.

Unfortunately we need the JS still because the standards are so lacking, and when they’re not it takes a while to get everybody on it.

As a general example, despite three decades of the web existing across the world in many jurisdictions with more than one language, the solution to translation for a site is just some translation framework or tediously maintaining a whole copy of your site per language.

The standards are fine. The problem is that the front end web is the DOM. I love the DOM, but it scares the shit out of people. Most people would rather cut their hand off or sell their children into child slavery than walk the DOM with 3 instructions. Its super weird and gets more weird when those people are actually confronted with this irrational behavior.

If you use htmx what backend technology do you choose?

The beauty of htmx is that it doesn't matter what you use on the backend.

Literally anything that'll render HTML will suffice. Even static HTML files on a web server will do. No need for an application server at all if you're clever and your needs are simple.

What if I want the website to work even when JavaScript is not turned on? I'd need a backend server and some frontend logic handling that case.

Not necessarily. It depends on what you need. For example suppose you were implementing an news reader with two panes. Left pane is a list of titles and previews, right pane is a full article for the selected item in the left pane.

You can make the left pane a list of links to dedicated pages, and then add an htmx attribute to indicate that when the user has JavaScript to instead fetch a html snippet with just full article and swap it into the right pane.

If you had a reasonably bounded set of articles you could statically generate all the /article/id.html and the /article/id/snippet.html files, though a backend probably makes sense.

At that point, how big is the difference really between sending the right pane only as opposed to the whole page performance wise? I'm just not sure if this approach is worth it for me.

In that case you need to have everything rendered server side and perhaps get creative with the usage of forms firing off events that can be intercepted by the server and then return a new page.

Certain things like Nav menu drop downs and folding text can’t be done with native CSS and HTML.

Hold my beer: that’s something you can do with the input checkbox trick.

Here’s an example: https://codepen.io/daviddarnes/pen/abVaGG

You might also be able to use a <details> element for the drop-down state.

Bash, duh. https://twitter.com/htmx_org/status/1657378246336598018

I still wish 80 to 90% of those JS function on the list should be part of HTML5 and not as a JS library.

Reply on news.ycombinator.com