Hacker News Reader

Comment by nprateem | Hacker News Reader

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.

View on HN

> “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

HTMX gets a lot of attention, but I think it's not the best option in its field.

That's what I was expecting to see, a way of specifying a target. Certainly not returning custom headers for the benefit of such a 'simple' frontend library.

And also up-hungry to opportunistically update navigation and cart item count. :-)

Solution 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

This 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.

Htmx 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/) 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.

>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.

It achieves it by not needing React, etc. IMO. That is the benefit. It might be worth it or not depending on the project.

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

IMO 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.

That'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.

JQuery 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.

The native API is much more verbose and less composable. It was a real lost opportunity.

  const $ = document.querySelector.bind(document)
  const $$ = document.querySelectorAll.bind(document)

Oh, I wish it was that simple.

jQuery's syntax is 10x better than vanilla javascript

Bullshit, the jQuery "Ajax" API is a hellish convoluted nightmare with zero consistency.

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.

Jquery does not solve everything, but it does have a nice api

    $(this).closest(".cont")

for example, is pretty nice in jquery.

I'd strongly suggest using something like ArrowJS instead of jQuery for that.

Because it’s much cleaner, readable code than anything created since.

It's a boring and battle proven tool that just works and has no use by date, by the way.

It 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.

What do you mean the issue doesn't exist?

Not to mention there is no mention of error handling.

You 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.

Reply on news.ycombinator.com