Building “applications” out of HTML documents – a single one or otherwise – is the sort of thing that belongs in one of those “stop doing X” memes, unironically.
These things are true if you build a SPA wrong. Believe it or not there are lots of ways to build server side rendered pages wrong too.
There are a lot of standard practices like… using a router to load the content of your SPA according to the url.
What I’m saying is, there’s no right way to build a thing that is inherently wrong.
Skill issue
HTMX is great and is the only frontend development tool I don’t absolutely loathe. It enables lightweight SPA development, and provides a very simple and efficient mechanism for doing HTML over the wire.
Not sure I would call HTMX a SPA framework though? Like it all’s easy async content fetching for sure, but it’s usually done across a MPA?
Sure, wrong term. I think my point still stands though. A SPA is *generally *“rehydrated” DOM elements from JSON data pulled from an API though. Where as HTMX is more akin to classic AJAX style page dynamism.
Unfortunately it also kicks Content Security Policy square in the nuts and shoots a giant hole right through your website security, so if anyone on my team brings up using it I inform them it’s an instant security fail if we so much as touch it.
It’s a cute idea but horribly implemented. If your website has any security requirements, do not use htmx
Edit: the fact so many people have no idea about this and are downvoting is sad. People need to learn how CSP headers work, and why inherently HTMX completely bypasses this as it currently is designed.
Doesn’t matter, the entire implementation principle of how HTMX works and what it does inherently bypasses CSP. There’s no getting around that.
You fundamentally are invoking logic via HTML attributes, which bypasses CSP
Can you elaborate on that? I haven’t used it, but just assume if you host it on your own domain you can have it play nicely with csp, there are docs in their site about it. Where did it fall short for your use case?
CSP allows you to whitelist/blacklist arbitrary Javascript, and ideally you completely blacklist online js from being executed at all, such that only .js files of same domain can be invoked by your website.
This serves the role of locking down injection attacks, only your explicitly approved Javascript can be invoked.
HTMX enables invoking of logic via HTML attributes on HTML elements… which CSP can’t cover
Which means you re-open yourself to injection attacks via HTML. Attackers can inject an HTML element with HTMX attributes and no amount of CSP will stop HTMX from going “Okey doke!” And invoking whatever the attributes say to do.
This effectively shoots even a completely locked down CSP config square in the nuts, totally defeating the entire point of using it.
It’s a cute idea but what is needed is a way to pre-emptively treat HTMX as a template file that transpiles everything out so the ajax happens in a separate .js file
If we had that, then it’d be safe and secure, as the whole “htmx attributes on elements” thing would just be a templating syntax, but when transpiled it wouldn’t be supported anymore so attackers can no longer inject html as an attack vector
As an elder developer… yea, we could use react to render complex web pages that erode expected functionality.
Or, like, I’m happy to just go back to server-side rendering… it’s surprisingly cheap to build and dead fucking simple.
I’ve seen front ends that build queries that are blindly executed by the backend - I’ve seen GraphQL that allows the client to read arbitrary users’ passwords from the database - I’ve seen attack ships on fire off the shoulder of ori- whoops, wrong memory.
Anyways, you can create vulnerabilities anywhere using anything - imo more server side logic might mean more vulnerabilities on the server but it means less vulnerabilities overall.
I prefer just writing my html, js, css, as is, and then transpiling to pack it down, treeshake, hash, cache bust, CSP, etc etc.
The amount if headache, overhead, inversion of control, mess, and bloat involved in frameworks tends to make me spend way too much time on writing boilerplate.
template and slot exist now, and modern js can do most of the shit fancy libs used to.
There’s very little need for frameworks unless you meed a SUPER dynamic website that has tonnes of mutability.
The amount if times i see people load in like 3 frameworks and 10mb of bullshit and ten js files to make a fucking static form that doesn’t even do anything fancy is insane.
Just fucking write the like… 8 lines of normal code to populate the form, wtf? Why are we using routers at all, HTTP already exists and does that, why did we re-invent http?
Front-end devs need to spend less time installing npm packages to try and magically solve their issues and just learn how to actually write code, SMH.
Elder developer here too, correctly making my SPAs has made my work significantly more efficient and maintainable now that my back end is basically a rest api and my front end requires very little network interaction after the initial load, which has been made pretty minimal.
I too have been doing this for years and I whole hearty agree with this comment.
For large complex sites, I ain’t never going back.
Actually even for simple sites I’m not sure I’ll go back.
Elder developer too, you can easily render react server side and statically. Once you remove state, react simply becomes pure functions that output jsx nodes, it’s also dead fucking simple, but gives the the possibility to add hydration and state later if you need it.
