11–20 of 520 posts
This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/ Solution 3 gave me a good laugh though.
Why the heck would you use jQuery in 2023 though?
Also, no compilation step, so no need for npm, etc
Congratulations! I had a fun time making a little project with Htmx, though ultimately went with something else as I ended up heavily using a openlayers, and map libs are notoriously heavy with clientside javascript and Svelte ended up being a better tool for the job. I plan on using it again for a future Golang project and look forward to following it's development. If you're in need of a simple/medium complex front…
Earlier quoted context omitted.
Why the heck would you use jQuery in 2023 though?
My main use case will be basic UI interaction, mostly just posting or fetching data from a backend then updating the innerHTML on some element. Vanilla might be enough, but I'm keeping my options open. Also, no compilation step, so no need for npm, etc
This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/ Solution 3 gave me a good laugh though.
People have typecast htmx as something to use for simple use cases that dont "warrant" getting out the serious guns. There is something to that, but it is limiting. Htmx and related 'back-to-the-server' approaches are a distinct category that could have been explored much earlier but for various reasons isnt
Earlier quoted context omitted.
Why the heck would you use jQuery in 2023 though?
My main use case will be basic UI interaction, mostly just posting or fetching data from a backend then updating the innerHTML on some element. Vanilla might be enough, but I'm keeping my options open. Also, no compilation step, so no need for npm, etc
I've gone to the home page it poorly explains what it is and doesn't say why would you want to use something like this.
Seems like another distraction.
Am I the only one who looks at HTMx and thinks "this is like CICS all over again"?
Could you elaborate?
It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...". Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course…
Circa 2007 or so it seemed a to be a huge mistake because it didn’t play well with the so-called “model-view-controller” paradigm where, most importantly, the request handler could decide which view to render. (e.g. you fill out a form and if you mad a mistake it redraws the form with an error message, otherwise it might render one of several different forms depending on what you filled out on the first form.)
He thing about HTMX is that it really wants support on the server side. For instance, you might have a that gets drawn as part of an HTML page or that gets updated with new (s) via HTMX when you push a button. Similarly you might have a form that can be rendered as the only form on a page or that can be rendered as a modal dialog that is pulled from the server when you open the modal (as opposed to unhiding it.). Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. (Modal dialogs are so fun to implement with HTMX.)
It’s something you can do in a situational way or that you could have a framework to help with, but it is part of the HTMX puzzle.