Developers Do NOT Understand the POWER Of HTMX

💯 yeah that's right

Good morning,
I agree, what is missing in my opinion are opensource examples of projects a little more complex than POCs, to see the full potential of HTMX, and for it to really take off.

Htmx is not that hard to understand. It's like html frames back in the days.. have the nav in one frame and have it load the content in an other frame by doing a get request.

I strongly agree, why has everything to be so complicated today. The little Timmies don't even know about the olden ways. XHR, SOAP, etc. and NEVER trust the CLIENT.

As a guy who hates Js and doesn’t like the whole frontend bs, HTMX is a god send. I can finally make highly reactive apps without or very little JS. I love it.

💯 agree

People who say that HTMX is vulnerable to XSS attacks are just ignorant React Andys. They know nothing about the backend. Every self-respecting backend developer knows how to prevent XSS attacks and knows it well. I just can't imagine how many vulnerabilities will introduce those React Andys when Next.js will become "obligatory" for React apps.

"why are you going to over-complicate it?"

cos of the people who pay for the product and the people who pay the salaries 😂

HTMX is literally just HTML forms at its core. If you are a web developer and you don't know how to sanitize data coming from HTML forms you should be fired immediately...

At some point you guys will understand that this is all bullshit, and you will code CGI, Perl and HMTL again

My man casually leaks creds

HTMX is definitely powerful but! I still cannot recommend it because of whole UI libs that exist in React, Vue etc. ecosystem that make my life easier as I don't want to write everything from scratch (I don't think here about simple cmpnts like btns, inputs but more complex, see for example prime-react lib ).

I’ve been using HTMX/Templ/Golang to construct an MVP for an ad tech platform.

It’s a very clean way to make things.

It’s nice not to have to write a whole state management cycle. If I want to update something, I can update it and just target the dom element I want to swap with the new data.

You forgot the hx-trigger on the button btw.

:p

a script hijacks "hx-get"?

Hi Anthony, youre not 100% right about xss, its not only the Backend that need so be safe. Can we make a deal, i will teach you xss techniques and you can teach me Golang interfaces. 🤗 best regards, Aleks

That is very interesting, thanks, Anthony

But we’re doing the same thing right now. The API sends you JSON, you map the data to JS objects with a fancy name JSX, and then in runtime those JS objects are inserted in DOM as HTML elements


Same thing, but with quite some steps :)

You can send CSV files from the API, if your client can handle it, the question is why?

Anthony, have you tried Elm before? If not, would you consider exploring the language in one of your videos?

what if someone’s purpose to attack the client not the server?

I love the brutal honesty:X

Well yes you must validate and sanitize user inputs, but that won’t guarantee your site is XSS proof. Not to mention that sanitizing for database storage is not the same as sanitizing for html output. The potential attack vector for XSS attacks is quite large actually.

McDonald's said they won't take me back. :(

What about CSRF protection? Could you share an example implementing this protection?

Thanks

One major problem with the web dev industry is that we have successfully been brainwashed to believe that if something is simple then its wrong, has a catch, is not secure, not safe etc etc. We now believe that a good solution must be complicated. We have developers building websites or apps that will never have more than 10,000 users saying they can't use technology X because technology X can't scale. We have become idiots. I did a Laravel + Livewire site to replace one that was aging and full of bugs from one of those frameworks that gets a new release every time it rains and "senior developers" kept asking how i pulled it off without React. It's like you can't build anything unless you use some hippy shiny, complicated and over engineered tool.

If to think about it, htmx is very similar to jQuery's `$(targetElem).load(url)`, which wasn't very popular even before reacts. Something was off about the idea to just switch html code in place. Virtual DOM gained popularity immediately, on the other side..

However, tools like Livewire, Liveview are very popular among backenders, although they're basically HTMX plus shared state between back and front 😂

HTMX is just another framework you have to learn that is more limited than JavaScript. I'm personally just fine with lightly using JavaScript in my projects and not worrying about 3rd party imports

.. it's time to get back to the MC Donalds job ... hahahaha ... lekker man ..

HTMX is so absurdly simple that it threatens developers who are used to complex technical masturbation.

It's pretty remarkable how far you can get with HTMX without needing a heavy UI framework.

req: in-depth htmx and golang

cheers grandma!!

They may get a wrong idea coming from updating the whole html of htmx. The point is that the frontend is cooperation with a trustful team member, not with a stranger. If you're working with go, templ and they're one proj. Sanitization is supposed to be done from the server side. Nowadays, there are lots of double works by dividing two sides, frontend and backend. It might be needed depending on some factors, teams, people or whatever. I guess there might be some projects sanitization is done in front side and the api responses then the full data, maybe that's why they think that, you know they only see onside..or they're just confused the concept. I could imagine one situation, the backend is broke down by some hacks and the code was changed and responded the vulnerable code to the clients. Somehow, the frontend code is saved, only the backend is broke down. Let's say the two parts were dividing from different servers. Hmm.... then ja maybe... If you‘re writing the whole code in a project like golang templ stack, it would not be consideration though. Let's say there are pure htmx client project and go lang server... somehow the server is broken and some body changed the code to hijacking clients' data without them knowing. So.. vulnerable html code is loaded to client's side and they're hacked and no body knows... and could say it's XSS vulnerability..... no.. it's wrong from the first place. There are so many considerations cause it's already broke down it's not about htmx, it's the problem regarding security. I made myself complicated lol. Thanks for the video. I subscribed 👍 I was thinking of using htmx for the next project and that you've done your service with htmx gives me a lot of trust to htmx. Thanks! I will go look for a Mcdonald's job.

I love HTMX too, but you are being a little too dismissive of the XSS risk. You can deploy the safest possible backend API sanitizer today in 2024, retire tomorrow, and then have 20 XSS exploits discovered about your backend of choice in the next year leading to all of your customers having their payment information stolen and ruining your business. I hope we can start seeing more advanced client-side security validation features for future versions HTMX.