Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is htmx Just Another JavaScript Framework?

htmx.org

Post reply on HN
Print view View original

281–290 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#281

Post by guru4consulting »

My product has the typical SPA front-end and API backend. I understand that with HTMX, those API backends would have to return HTML fragments instead of JSON data (or another server endpoint that returns HTML fragments). I have few questions with this HTMX approach:

- We don't hire full-stack developers. Our UI/UX designers and web developers fully focus on the front-end (responsive for mobile/tablet/desktop, A/B testing, quick iterations of UI/UX enhancements) without bothering about the backend. The backend API developers focus on API returning the right data and don't care about UI. I like this separation as it helps to really iterate the UI/UX faster. With HTMX, those backend devs will now have to worry about returning the correct HTML fragment based on the client device, position of the HTML div, etc. The presentation concerns spill over to backend developer and we are back to the days of server-side templates like JSP/ASP/RoR/PHP/Django. Anyone else sees issue with this approach?

- React/similar web apps can handle quite complex UI with multiple flows and navigations. I assume HTMX is probably not suited for complex UIs. Is that right? has anyone built any complex UI with HTMX?

Re: Is htmx Just Another JavaScript Framework?

#282

Post by recursivedoubts »

guru4consulting wrote: post #281

My product has the typical SPA front-end and API backend. I understand that with HTMX, those API backends would have to return HTML fragments instead of JSON data (or another server endpoint that returns HTML fragments). I have few questions with this HTMX approach: - We don't hire full-stack developers. Our UI/UX designers and web developers fully focus on the front-end (responsive for mobile/tablet/desktop, A/B tes…

If the FE/BE split is working well for you, then htmx isn't as compelling. It is more compelling when you have full-stack developers who can take ownership of entire features and shepherd them from start to finish, without needing to coordinate with another team to get the data/functionality they need.

Here is an example of a fairly sophisticated application that was written in react, then moved to htmx with good results:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

As far as what you can achieve with htmx, I outline when hypermedia (the more general concept behind htmx) is a good choice or a bad choice here:

https://htmx.org/essays/when-to-use-hypermedia/

You can get an idea of the basic level of interactivity you can achieve with htmx by looking at the examples:

https://htmx.org/examples/

all of which compose well together. You can get more dynamic than that if you are willing to do client-side scripting (https://htmx.org/essays/hypermedia-friendly-scripting/)

another essay that might be of interest, regarding your APIs:

https://htmx.org/essays/splitting-your-apis/

and, if you want a complete introduction and overview of the hypermedia approach, we have a book available online for free:

https://hypermedia.systems

Re: Is htmx Just Another JavaScript Framework?

#283

Post by EGreg »

This is how we do it in our framework, which we started in 2011 and have been using continuously and improving until now: https://qbix.com/platform/guide/tools

We define "tools" to add/remove behavior to/from existing elements. The tools are added by an HTML5-compliant microformat. For example:
Tools can contain other tools, and you can specify them when you attach event handlers, for example, so the handlers get removed when the tool gets removed, e.g. when its container tool is removed:

  event.set(handler, tool); // no need to remove it later
As a more complex example, here we have a chatroom, which has extensions like calling people and mentioning people:

  

      elements may be empty or have some existing content
And we also support Handlebars helpers:

  
  {{#each list}}
     {{tool "Streams/chat" publisherId="abc" streamName="..."}}
  {{/each}}
Finally, we can also activate them dynamically via Javascript:

  Q.Tool.prepare(someElement, "Streams/chat", options);
       or 
  div = Q.Tool.prepare('div', "Streams/chat", options);
Then we just call Q.activate(container) which traverses the container and activates all tools inside it. At any point in the console you can type Q.Tool.active and it will show you all active tools.

You can see it in action for example at https://intercoin.app

PS: I used to originally call it the "Q" Framework but because of people on HN constantly complaining that it was conflicting with the "excellent Q library for promises", I finally relented and called it "Qbix Platform"... now the Q library for promises is obsolete but we still call it Qbix... so maybe it's better for SEO though? https://news.ycombinator.com/item?id=6053211

Re: Is htmx Just Another JavaScript Framework?

#284

Post by [deleted] »

leptons wrote: post #240
dfabulich wrote: post #141

Earlier quoted context omitted.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML. In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get to target a section of the page that isn't an has been argued about and hashed out for years.…

HTMX breaks the "separation of concerns" paradigm. It's not going to help anyone doing anything complex, and it's going to be a crutch for anyone getting started. It breaks down quickly when the problem is anything more complex than clicking a button to load some content, and then what - rewrite everything in a more capable framework?

[deleted]

Re: Is htmx Just Another JavaScript Framework?

#285

Post by dventimi »

troupo wrote: post #250
AmpsterMan wrote: post #181

Earlier quoted context omitted.

Htmx posits that current browsers aren't "truly" hypermedia since only anchor tags and forms can initiate GET/POST requests. It is more of a tech demo showing what client with ANY tag being able to do requests would look like. That's why whether it is library/framework is besides the point. The author posits that these features should be in the spec, and tries as closely as possible to show what something might look…

> The author posits that these features should be in the spec Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"

> The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both.

Does he? Evidence or it didn't happen.

Re: Is htmx Just Another JavaScript Framework?

#287

Post by joedevon »

troupo wrote: post #250
AmpsterMan wrote: post #181

Earlier quoted context omitted.

Htmx posits that current browsers aren't "truly" hypermedia since only anchor tags and forms can initiate GET/POST requests. It is more of a tech demo showing what client with ANY tag being able to do requests would look like. That's why whether it is library/framework is besides the point. The author posits that these features should be in the spec, and tries as closely as possible to show what something might look…

> The author posits that these features should be in the spec Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"

You are missing the spirit of the whole thing. HTMX is a polyfill for the future state of browsers.

Re: Is htmx Just Another JavaScript Framework?

#288

Post by troupo »

joedevon wrote: post #287
troupo wrote: post #250

Earlier quoted context omitted.

> The author posits that these features should be in the spec Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"

You are missing the spirit of the whole thing. HTMX is a polyfill for the future state of browsers.

It's not, and it's not even pretending to be

Re: Is htmx Just Another JavaScript Framework?

#290

Post by flir »

masklinn wrote: post #258
paulddraper wrote: post #188

Earlier quoted context omitted.

> words do actually have meanings that we can look up and refer to It's odd to insist on strict word choice when transferring GIF images using the hypertext transfer protocol.

It's not though? Gifs are media, but they are not hyper media because they don't support hypertext (can't link to to other media). As such, they're ancillary sub-resources to hypermedia but not themselves hypermedia.

If you're going to get that picky (and please be aware I'm only doing this for the sake of the argument) media can never be hypermedia in the absence of the client. HTML opened in notepad is just text. Cat GIFs, rendered in the correct client, would absolutely be hypermedia (you could inline link data as QR codes, if you felt like being perverse).

Hypermedia starts with the client, not with the file format.

Post reply on HN