You must log in or # to comment.
Anyone that builds a SPA and breaks opening in new tab or history caching and back/forward nav isn’t a good frontend developer (or lacks experience, which is something that’s fixable!). These have been solved problems for a long time.
I mean, for sure, and this meme isn’t trying to say that all SPAs are bad. But defaults matter, even for experts.
This meme was inspired after I had to use an SPA, which among those points in the meme, also broke using Alt+Left to navigate back. The normal back-button worked (even if it then had to load for ten seconds to re-display static content).
Which is just a typical example to me. You don’t even need much expertise to figure out why Alt+Left is broken. But you have to think of testing Alt+Left, because it’s broken by default.
My friend I’ve been using the Internet for 27 years and developing for it for most of that time and I can promise you I’ve never once hit Alt+Left
Yeah, I have no trouble believing that. It took quite a while before I learned of this shortcut and when I did, I was wondering why I would ever want to use it.
But I generally work from my laptop these days, without an external mouse connected, so reaching from my touchpad, the Left key is right there.
You can probably go back by swiping two fingers to the right on the touchpad. Maybe it depends on the OS and browser.
Yeah, that works on my personal laptop, but not yet on my work laptop, because they insist on preinstalling an old, buggy OS. If that did work everywhere, I would probably be using that, but not breaking Alt+Left for whoever needs/wants it, would still be nice. 🫠
Your reason for using it was exactly my question. “I have a mouse with a built in back button, why would I want to remove my hand from my mouse and navigate with the arrow key?”
But your reason simply makes sense.
As your younger and more modern replacement, I use it regularly
You don’t sound like ChatGPT
I’m sorry, but as an AI language model, I cannot contradict my instructions to remain hidden while commenting.
I have never heard of alt+left, and I’ve been using the Internet since Mosaic was all the rage. Shame on me, it seems to be implemented in all browsers. How could I have missed it?
It’s even implemented in many file managers and text editors and such. Pretty much the standard shortcut for navigating history. But yeah, hilariously it’s somehow also a rather well-kept secret.
Conversly a lot of static websites break new tab by incorrectly slapping
target="_blank"on anchors. Luckily Lemmy doesn’t mess this up.I maintain a couple of Wordpress installations for clients, where new link targets are the same page, as you’d expect.
They still, somehow, manually check “link opens in new tab”. I don’t know why some of these boomers are allowed to use computers, I swear.
If you manage the WordPress installation, can’t you disable the ability or create/install a plugin that removes that ability? This hurts usability.
I could, good point. I do disable plugins for clients so they can’t beat up their own website too much.
Still, there are legitimate uses for opening a site in a new tab; e.g. when it’s an external website. I don’t think I should automate that, since there’s a granularity in there.
legitimate uses for opening a site in a new tab; e.g. when it’s an external website
This is not a legitimate use—this breaks the default user agent behavior & completely removes the autonomy of opening in the current window (there are tons of ways to open in a new tab/window). Consider rechecking the article linked higher up the thread tree.
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?
Where did I call it a framework?
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.
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.
You’ll forgive me if I say this is an instance of splitting hairs and having a particular definition for something that includes extra qualities separate from what those terms are actually describing for most people. Also, things like, I dunno, React, are going to extensively use ajax to accomplish what they do. It’s literally just asynchronous javascript. It’s like someone saying “my vehicle of choice is a motorcycle” and then someone else saying “A motorcycle isn’t really a vehicle. It’s a transportation device with wheels. A car is a vehicle.” They are both vehicles. They both have wheels. The wheels are ajax. A page made with htmx and a page made with React are both SPAs.
My point is just that I think to most people, HTMX doesn’t create what is classically considered to be a SPA any more than older MPA’s that called utilized AJAX would be. There’s a reason those old-style pages aren’t really considered SPA’s. Is it splitting hairs? Absolutely.
I think we’re gonna have to agree to disagree on definitions. To me, and I believe, to most people, an SPA refers to a UI/UX design pattern that can be implemented with any number of underlying techniques. I would also say that the Wikipedia page for SPAs (on the assumption that wikipedia is a valid tool for establishing consensus for definitions) supports my definition:
A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages.
There are various techniques available that enable the browser to retain a single page even when the application requires server communication.
And it goes on to list frameworks, AJAX, Websockets, etc.
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.
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
This demonstrates a profound misunderstanding of HTMX, and how websites in general operate. So much so that I would not hesitate to describe this as somewhere between a baldfaced lie and just malicious incompetence. You can’t “invoke logic via HTML attributes,” but you can describe it. HTMX is a client side javascript library that parses custom elements you define in your HTML and uses the data described by them to initiate AJAX calls via the fetch() or XMLHttpRequest browser APIs, which CSP explicitly covers via the connect-src directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src. It’s literally just a javascript library that parses HTML and uses it to parameterize AJAX calls. If HTMX were somehow able to bypass CSP, then every single piece of clientside JavaScript in the world could violate it.
You can’t “invoke logic via HTML attributes,”
Oh boy a semantic argument
Proceeds to describe how you can use HTMX to invoke logic via HTML attributes
Whatever you want to call it, trigger, invoke, whatever.
You can leverage HTML attributes to automatically cause arbitrary Javascript ajax calls to happen by extension if those attributes being present.
Trying to argue the semantics of this is stupid.
You put HTML attributes on shit, and the presence of those attributes in turn causes arbitrary Javascript client side logic to fire off purely due to the presence of those attributes.
That’s like, literally it’s entire shtick.
And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.
“HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”
It’s bonkers how many people don’t grok this, SMH.
I felt like I had a good understanding of both htmx and csp, but after this discussion I’m going to have to read up on both because both of you are making a logically sound argument to my mind.
I’m struggling to see how htmx is more vulnerable than say react or vue or angular, because with csp as far as I can tell I can explicitly lock down what htmx can do, despite any maliciously injected html that might try to do otherwise.
Thanks for this discussion 🙂
Oh boy a semantic argument
It turns out the language you use can be semantically ambiguous or misleading if you phrase it incorrectly. Today you learned.
And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.
Oh, did you finally manage to fucking Google how HTMX works so you could fish for more reasons to say it’s unsafe? What you’re describing is not a particular concern to HTMX. If an attacker can inject HTML into your page (for example, through an XSS vulnerability), they could potentially set up HTMX attributes to make requests to any endpoint, including endpoints designed to collect sensitive information. But, and this is very important, this is not a unique issue to HTMX; it’s a general security concern related to XSS vulnerabilities and improper CSP configurations.
Do you know what the correct cure for that is?
PROPER CSP CONFIGURATION.
“HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”
Do you genuinely not understand that CSP works on the browser API level? It doesn’t check to see if your JavaScript contains reference to disallowed endpoints and then prevents it from running. I don’t know how you “think” CSP operates, but what happens is this: The browser exposes an API to allow JavaScript to make HTTP requests - specifically XMLHttpRequest and fetch(). What CSP does is tell the browser “Hey, if you get an API request via XMLHttpRequest or fetch to a disallowed endpoint, don’t fucking issue it.” That’s it. HTMX does not magically bypass the underlying CSP mechanism, because those directives operate on a level beyond HTMX’s (or any JS library’s) influence BY DESIGN. You cannot bypass if it if’s properly configured. Two very serious questions: what part of this is confusing to you? And, have you ever tested this yourself in any capacity to even see if what you’re claiming is even true? Because I have tested it and CSP will block ANY HTMX issued request that is not allowed by CSP’s connect-src directive, assuming that’s set.
HTMX comes with a variety of CSP options, though…
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
how HTMX works and what it does inherently bypasses CSP
Well, no, not really. All HTMX really does are AJAX requests to remote resources, which are performed by interpreting attributes in HTML. You specify the type of request and the target for updating. Those requests can sometimes contain parameters, of course, but any API that accepts any kind of conditional or user generated input has to sanitize that input before doing anything meaningful with it. This requirement isn’t something particular to HTMX.
You fundamentally are invoking logic via HTML attributes, which bypasses CSP
This is not true, though. You are manipulating the DOM via HTMX, but CSP has nothing to do with dynamic content manipulation. CSP is more concerned with preventing the injection of malicious code. If what you’re referring to, however, is the possibility of someone maliciously injecting HTML with HTMX that performs some nefarious action, then I have to ask (again) why you didn’t properly sanitize user input or limit the possible connection sources in your CSP.
If you have a specific example, however, of a way in which HTMX by design violates CSP that can’t be dismissed with “you coded your website poorly,” I would love to know.
why you didn’t properly sanitize user input
This is like someone pointing out that blowing a giant hole in the hull of your ship causes it to take on water, and you respond by asking “well why aren’t you bailing out the water with a bucket?”
You do understand why Content Security Policy exists, and what it is for… right?
“We don’t need a watertight ship hull for the voyage, just reinvent and implement a bunch of strapping young lads that 24/7 bail water out of the ship as it sails, it’s faster and more efficient than doing something crazy like building your ship to be secure and water tight.”
“Wow, these screen doors really suck. I’ve stuck them on my submarine, but they just don’t keep the water out at all. Some people are going to say that I’m a fucking moron and don’t understand the technology I use or that I’m too goddamn lazy to actually take the necessary steps to keep water out of my submarine, but I know they’re wrong and it’s the technology’s fault.”
In all seriousness, HTMX is a tool designed for a specific job. If you have an API that has either non-parameterized endpoints to hit or an endpoint that accepts a single integer value or UUID or…whatever to perform a database lookup and return stored values to be interpolated into the HTML that endpoint returns, then, great, you’ve got a lightweight tool to help do that in an SPA. If you’re using it to send complex data that will be immediately and unsafely exposed to other users, then…that’s not really what it’s for. So, I think the core issue here is that you don’t really understand the use case and are opposed to it because to use it in a way that is beyond or outside the scope of its established convention is unsafe without extra work involved to guarantee said safety. It also implies you are running a website with a content security policy that either explicitly allows the execution of unsafe inline scripts or which does not care about the sources to which a script connects, which is the only way you could realistically leverage HTMX for malicious ends. So, ultimately, the choice to not adopt comprehensive security measures is one you are free to make, but I wouldn’t exactly go around telling people about it.
That’s not broad enough.
If you in any way have functionality that handles anything remotely requiring security, do not use HTMX.
This goes way beyond “parameterized endpoints”.
Listen extremely closely and pray to God anyone dev with more than 2 brain cells groks how serious th8s vulnerability is:
HTMX enables arbitrary invocation of ANY api endpoint with cookies included, through html attributes, which inherently can’t be covered by Content Security Policy
This is deeply important for any web dev worth their salt to understand.
Sanitizing User input should be your LAST layer of defence against attack vectors. Not, NOT, your first and only
It’s supposed to be your “break in case of emergency” system, not your primary (and only remaining) defense layer.
