There is nothing about htmx which makes it inherently more susceptible to HTML injection. If you aren't sanitizing the data you get from external sources you are going to have trouble 9/10 times, no matter what you are using.
Next.
>There is nothing about htmx which makes it inherently more susceptible to HTML injection.
True > If you aren't sanitizing the data you get from external sources you are going to have trouble 9/10 times, no matter what you are using.
All poeple say this but no one says how the fuck do you sanitise it. Solutions always seem half assed. It sems to me the only solution is to create some super minimal programming language with like 4 keywords just for processing data from web.
you can get html injection in fucking anything. almost all backend frameworks have magic in their templates that escape interpolated text for you. you have to be a literal idiot to get this
Not a flaw. If you have a problem you can't hold the same problem as a negative of potential solutions.
this, fuck the internet and fuck all webshitters and webshitter technology.
HTMX aims to fix webshitters and webshitter technology. Please don't try to participate in a thread when you don't know the first thing about the topic, thanks.
Every new webshitter technology pretends it's going to improve things. No one cares about your faggy "find a flaw" shitpost thread.
>I entered a thread about a topic I don't like and don't know nothing about, shatpost my useless "opinion", and now people are calling me out and I'm mad. How could this be happening to me?
This is not your safespace. Try reddit.
Is this the currently yearly flavor if PHP or what
It kills the frameworks and makes webdev be entirely server based, with the only responsibility of the frontend being rendering data. This means that you completely remove frontend state, and it also fixes many of the dogshit quirks of webdev, like double input validation.
It also makes updating remote components trivial, because instead of having a complex state graph, you can just reference elements to be updated in your code.
In essence it reduces the need for javascript by a good 90%, if not entirely, depending on what you're trying to do, of course. Pic rel is from their website.
It's relatively bloated all things considered - when not gzipped it's ~46.7kB minified, jQuery slimmed is ~69k. Consider just how much more jQuery offers.
Underneath the algorithms used to "hydrate" the app (not even considering how it's still the suboptimal solution compared to resumability) are still slow, last I remember the library choked on massive dick when it came to extensions and properties from parent elements being used by children elements or something like that. Check their Github issues.
As much as I love the author behind it some of his (and W3C's overall) old ideas are pretty fucking stupid and useless, like using verbs other than GET and POST is pretty fucking gay and will just tangle your backend arch more, using HTML form validation is retarded and you will use JS sooner or later for even the tiniest thing, using diverse HTML elements isn't worth it when not everything is standardised and compatible with same behaviors across all browsers, etc etc. I can keep going.
HTMX is a sign that webdev is healing but it's not it. Also many other libraries like it exist (Unpoly, Hotwire, Laravel - but now it uses HTMX underneath iirc)
>I haven't used JQuery
ftfy homosexual, it's still relevant unfortunately with how Firefox and Chrome suck dick at compatibility for the most basic vanilla JS shit (from my experience).
>Literally justify this claim.
For one, it's easier and gives you more versatility and is more verbose to just append a URL or use search params instead.
Consider a chat messages service with the following URI path:
POST example.tld/<channel ID>/<message ID>/<action>
Instead of being bound to a few keywords you now have a lot more at your disposal, with more expressiveness and probably less backend headaches since depending on your framework of choice it's easier and more readable to have a new file for that path instead of stuffing everything into one file and deciding about what should be a PUT, POST or PATCH and once two or more fit into the same scenario - how you should decode the request.
It's just more versatile to not limit yourself to something nobody ever sees or cares about but you, the developer.
Like if you like it, sure, but saying it should be the proper way to go is just not true.
Also as a side note HTTP/2's HPACK static table includes only GET and POST.
Don't know about QPACK.
>For one, it's easier and gives you more versatility and is more verbose to just append a URL or use search params instead.
But you can just as easily say in that case that HTTP methods are useless in general. I can do the same thing with a GET request as I can just a POST request. The whole point is to have a standard CRUD operation list, even though in practice it doesn't work very well. If anything I personally think methods should just be removed from HTTP, but I'm not holding that against HTMX.
>just as easily
I'm gonna be that guy: you can't do it just as easily because URLs have a length limit and POST requests don't >is to have a standard CRUD operation list
You're not limiting yourself to set and stone CRUD that way was my point, because limiting yourself here is pointless (and gay)
It's so simple there are a million shitty frameworks to try and make it manageable.
Synchronizing state will always be worst than having state in one place only.
>open dropdown >network call
Why? >click out form field >network call
What do you mean "click out?" >network goes down >UI stop working
You've described 90% of SPAs, and the irony here is that with HTMX you are at least likely to have your page in a presentable and consistent state.
I'll be honest I mostly dislike it because all the blatant shilling and people who act like it's the second coming of christ. I don't really see it as doing anything that new either. I'm gonna stick with Vue + PHP.
>html injection
nothing personal kid
There is nothing about htmx which makes it inherently more susceptible to HTML injection. If you aren't sanitizing the data you get from external sources you are going to have trouble 9/10 times, no matter what you are using.
Next.
>There is nothing about htmx which makes it inherently more susceptible to HTML injection.
True
> If you aren't sanitizing the data you get from external sources you are going to have trouble 9/10 times, no matter what you are using.
All poeple say this but no one says how the fuck do you sanitise it. Solutions always seem half assed. It sems to me the only solution is to create some super minimal programming language with like 4 keywords just for processing data from web.
htmlpurifyer is pretty good
wow did you just hear about golang?
>4 keywords
nagger
Kike
Jannie
Cunt
Now you say what each do.
you can get html injection in fucking anything. almost all backend frameworks have magic in their templates that escape interpolated text for you. you have to be a literal idiot to get this
Not htmx thingy, more like skill issue
Not a htmx issue, try again
Still uses javascript in a world where the majority of applications could just be pure HTML RESTful APIs. Other than that, it's pretty nice.
Browsers need to implement HTMX functionality natively.
I agree
But how can browser developers be convinced to do that?
Yeah, right after they natively support JSX and other bullshit formats lmao
it's web related
this, fuck the internet and fuck all webshitters and webshitter technology.
Not a flaw. If you have a problem you can't hold the same problem as a negative of potential solutions.
HTMX aims to fix webshitters and webshitter technology. Please don't try to participate in a thread when you don't know the first thing about the topic, thanks.
Every new webshitter technology pretends it's going to improve things. No one cares about your faggy "find a flaw" shitpost thread.
>Please don't try to participate in a thread when you don't know the first thing about the topic, thanks.
kill yourself
>I entered a thread about a topic I don't like and don't know nothing about, shatpost my useless "opinion", and now people are calling me out and I'm mad. How could this be happening to me?
This is not your safespace. Try reddit.
It kills the frameworks and makes webdev be entirely server based, with the only responsibility of the frontend being rendering data. This means that you completely remove frontend state, and it also fixes many of the dogshit quirks of webdev, like double input validation.
It also makes updating remote components trivial, because instead of having a complex state graph, you can just reference elements to be updated in your code.
In essence it reduces the need for javascript by a good 90%, if not entirely, depending on what you're trying to do, of course. Pic rel is from their website.
>This is not your safespace. Try reddit.
I said kill yourself
>I said
Nobody asked.
>This is not your safespace. Try reddit.
You're trying too hard.
and reinvents the same problem that frontend frameworks solved: LOAD, LARGE LOAD OF MILLION USERS, nagger!!!
Nice dunning kruger post. Best I've seen on LULZ
can't fix something that's fundamentally broken. dig up the tubes and start all over again, that's the solution
If you can't do these things with vanilla html, you're a pajeet and shouldn't be making websites.
/thread
>If you can't do these things with vanilla html
What does this even mean?
Once upon a time people didn't need bloated frameworks to access features that are built into every browser by default.
http://vanilla-js.com/
> vanilla html
> vanilla-js.com
Hmmmmmmmm
lel
Is this the currently yearly flavor if PHP or what
Fad
It's relatively bloated all things considered - when not gzipped it's ~46.7kB minified, jQuery slimmed is ~69k. Consider just how much more jQuery offers.
Underneath the algorithms used to "hydrate" the app (not even considering how it's still the suboptimal solution compared to resumability) are still slow, last I remember the library choked on massive dick when it came to extensions and properties from parent elements being used by children elements or something like that. Check their Github issues.
As much as I love the author behind it some of his (and W3C's overall) old ideas are pretty fucking stupid and useless, like using verbs other than GET and POST is pretty fucking gay and will just tangle your backend arch more, using HTML form validation is retarded and you will use JS sooner or later for even the tiniest thing, using diverse HTML elements isn't worth it when not everything is standardised and compatible with same behaviors across all browsers, etc etc. I can keep going.
HTMX is a sign that webdev is healing but it's not it. Also many other libraries like it exist (Unpoly, Hotwire, Laravel - but now it uses HTMX underneath iirc)
>inb4 reddit spacing
Kill yourself.
>Consider just how much more jQuery offers.
Nothing. I haven't used JQuery in a decade or more.
>like using verbs other than GET and POST is pretty fucking gay
Literally justify this claim.
>I haven't used JQuery
ftfy homosexual, it's still relevant unfortunately with how Firefox and Chrome suck dick at compatibility for the most basic vanilla JS shit (from my experience).
>Literally justify this claim.
For one, it's easier and gives you more versatility and is more verbose to just append a URL or use search params instead.
Consider a chat messages service with the following URI path:
POST example.tld/<channel ID>/<message ID>/<action>
Instead of being bound to a few keywords you now have a lot more at your disposal, with more expressiveness and probably less backend headaches since depending on your framework of choice it's easier and more readable to have a new file for that path instead of stuffing everything into one file and deciding about what should be a PUT, POST or PATCH and once two or more fit into the same scenario - how you should decode the request.
It's just more versatile to not limit yourself to something nobody ever sees or cares about but you, the developer.
Like if you like it, sure, but saying it should be the proper way to go is just not true.
Also as a side note HTTP/2's HPACK static table includes only GET and POST.
Don't know about QPACK.
>For one, it's easier and gives you more versatility and is more verbose to just append a URL or use search params instead.
But you can just as easily say in that case that HTTP methods are useless in general. I can do the same thing with a GET request as I can just a POST request. The whole point is to have a standard CRUD operation list, even though in practice it doesn't work very well. If anything I personally think methods should just be removed from HTTP, but I'm not holding that against HTMX.
>just as easily
I'm gonna be that guy: you can't do it just as easily because URLs have a length limit and POST requests don't
>is to have a standard CRUD operation list
You're not limiting yourself to set and stone CRUD that way was my point, because limiting yourself here is pointless (and gay)
>whining about http verbs
they have semantic meaning when it comes to caching that browsers respect. also it's a bit more clean in the logs.
>genderless HTML
no thanks woke leftist dems
>see you dont need to use JS anymore
>uses JS internally
there is no flaw, there is no point either
what real world problem does htmx solve that one to three lines of modern javascript doesn't
Stateful SPAs.
trash. got it
extremely simple in js
It's so simple there are a million shitty frameworks to try and make it manageable.
Synchronizing state will always be worst than having state in one place only.
now there's a million and one shitty frameworks
how about engineer the page better
htmx is not a framework, clown.
>htmx plus SQLite plus Go plus ngnix
That's my stack.
>open dropdown
>network call
>click out form field
>network call
>network goes down
>UI stop working
>open dropdown
>network call
Why?
>click out form field
>network call
What do you mean "click out?"
>network goes down
>UI stop working
You've described 90% of SPAs, and the irony here is that with HTMX you are at least likely to have your page in a presentable and consistent state.
>You've described 90% of SPAs
Stop outing yourself as a retard.
I'll be honest I mostly dislike it because all the blatant shilling and people who act like it's the second coming of christ. I don't really see it as doing anything that new either. I'm gonna stick with Vue + PHP.
Htmx is one of the toy project languages. It looks to suck for anything complicated but makes easy things bit faster.