4 ms·
This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/ https://htmx.org/examples/update-other-
by nprateem 3y ago
This page made me realise I'm better off with just vanilla JS or jQuery: https://htmx.org/examples/update-other-content/ https://htmx.org/examples/update-other-content/
Solution 3 gave me a good laugh though.
- EspressoGPT 3y agoWhy the heck would you use jQuery in 2023 though?
- nprateem 3y agoMy 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
- maxboone 3y agoIMO that's where alpine.js complements HTMX, you can use HTMX mainly for interfacing with a server and then use alpine.js for any special interaction that does not require a round-trip with the server.
- bardak 3y agoThat's my thought as well. Anything that needs new data from the server uses HTMX and if you need to manipulate something already on the page use Alpine, Jquery, vanillajs, or whatever other framework you prefer.
- rodorgas 3y agoJQuery would make sense when we didn’t have querySelector and fetch API. I can’t think of any reason to use it today on a new project, there are not advantages over vanilla.
- tambourine_man 3y agoThe native API is much more verbose and less composable. It was a real lost opportunity.
- antiatheist 3y agoconst $ = document.querySelector.bind(document) const $$ = document.querySelectorAll.bind(document)
- tambourine_man 3y agoOh, I wish it was that simple.
- synergy20 3y agojQuery's syntax is 10x better than vanilla javascript
- antiatheist 3y agoBullshit, the jQuery "Ajax" API is a hellish convoluted nightmare with zero consistency. https://api.jquery.com/category/ajax/ https://api.jquery.com/category/ajax/ Have you seriously looked at this and thought "yeah thats better than using a single native function (fetch)"? As for the rest of the API - what would you even use besides the css and selector functions? Which again, the native `classList` and a simple bind to the selectors are simpler and less verbose.
- mejutoco 3y agoJquery does not solve everything, but it does have a nice api $(this).closest(".cont") for example, is pretty nice in jquery.
- EspressoGPT 3y agoI'd strongly suggest using something like ArrowJS instead of jQuery for that.
- tambourine_man 3y agoBecause it’s much cleaner, readable code than anything created since.
- varispeed 3y agoIt's a boring and battle proven tool that just works and has no use by date, by the way.
- EspressoGPT 3y agoIt has. The issue jQuery was designed to solve doesn't exist anymore, hence there's no reason to rely on this heavy and convoluted library any longer. There really are better solutions.
- varispeed 3y agoWhat do you mean the issue doesn't exist?
- foooorsyth 3y agoSolution 2 is clearly the best option. htmx authors would be wise to get opinionated and champion that approach. Forget about IE11 compat. Completely rearranging the DOM (Sol. 1) and a two request chain for one update (Sol. 3) are non-starters
- deleted 3y ago[deleted]
- sourcecodeplz 3y agoNot to mention there is no mention of error handling.
- basique 3y agoYou just return an HTML fragment that describes the error with a header that says where to put it. The htmx JS API has events for errors too, if you want to do client-side handling.
- guggle 3y ago> “I need to update other content on the screen. How do I do this?” This is a complete non-issue in unpoly as you can have multiple targets: <a href="/posts/5" up-target=".content, .unread-count">Read post</a> https://unpoly.com/targeting-fragments https://unpoly.com/targeting-fragments HTMX gets a lot of attention, but I think it's not the best option in its field.
- treis 3y agoThis page illustrates why I just don't get HTMX. It seems like a ton of effort to save not a lot of server cycles and html over the wire. I've done tabbed UIs that worked like HTMX. But instead of trying to do div surgery it replaced the entire tab. It was like 20 lines of JS and a few lines in Rails to render without a layout based on a URL query param. When we're talking dozens of KBs of HTML for a tab it's not the extra complexity to try and slim that down.
- mejutoco 3y agoHtmx advantage is not that it sends less bytes, but that it effectively removes frontend. Getting rid of the frontend dependencies, builds systems, and languages can bring a lot of speed to a project. Of course the downside is everything must go to the server. While not perfect, many spa also do not work nicely without a connection, although they could. Another thing is that the templates can get a bit crazy quick. I found a good solution is to use swap-oop (https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/) for everything and have a "component" wrapper server-side to abstract the ids and which template to choose. Then, some kind of typed data structure tracking all the element ids, since you need to refer to them from the templates to know which element to update. This way you can easily find all the templates that update a specific id or all the ids that are updated by a template.
- treis 3y ago>Htmx advantage is not that it sends less bytes, but that it effectively removes frontend. Right, which you can achieve by replacing the main content div. HTMX takes it many steps further and allows you to slice the HTML up into small bits and replace only those. This adds a lot of complexity for little benefit.
- mejutoco 3y agoIt achieves it by not needing React, etc. IMO. That is the benefit. It might be worth it or not depending on the project.