Careful, it doesn't work inside shadow dom, nor hyperscript.
what does this mean ? i have been recommended hyperscript over alpinejs several times.
Htmx in a Nutshell
331–340 of 414 posts
Re: Htmx in a Nutshell
#332Is anyone here working with Java and HTMX ? we have faced a lot of resistance in doing this. Basically because java already has versions of server side rendered frameworks - specifically JSP & Thymeleaf.
So while, the value proposition of HTMX for the larger nodejs world (or anyone using React) is "back to Server Side Rendering". I'm kind of struggling to build a value prop on the JSP/Thymeleaf side which is already popular.
So is HTMX a "better JSP" ?
Re: Htmx in a Nutshell
#333Earlier quoted context omitted.
The point you're missing here is that if you use HTMX, you often don't need to write any JS. You just write HTML with some special tags, and the library handles everything for you.
Spoiler warning: it doesn't. Unless you only consider the happiest path, as in "I develop on localhost with zero latency, 100% uptime, and my backend validation logic perfectly matches my frontend policies" (and probably a lot more other "if"s and "only"s).
this is an interesting comment. so it has been sold to me like that. Could you talk about where it fails.
alpinejs does make the claim that it is a "better jquery". What is the development experience here?
especially for backend teams (python, java, whatever) who are now also building HTMX.
Re: Htmx in a Nutshell
#334Have been using htmx for a little over a year now, and I am so thankful for this library. It has simplified our development tremendously from ClojureScript / React to vanilla Clojure on the backend doing SSR of HTML with htmx HTML element attributes. All with 1 script tag that includes this wonderful library. Kudos to the creator of htmx! This is what hypermedia architecture with true HATEOAS is all about. It feels l…
here's a question to you...since ur like, almost from the Java world!
Why not clj-thymeleaf ? or even clojurescript ? this is very interesting that you find HTMX better than clojurescript - typically clojure devs prefer to stay within the lisp world for any markup.
ive been getting pushback in a java team against htmx. cos the value prop is unclear vs jsp or thymeleaf. Would love to hear ur perspective.
Re: Htmx in a Nutshell
#335Earlier quoted context omitted.
Do you know off hand how much JavaScript your pages are including now versus when you were using ClojureScript/React? I ask because I know ClojureScript is built on Google Closure which has pretty advanced dead code elimination (and typically for React functionality people use libraries like reagant that take advantage of this - I think?). Presumably with htmx users are having to download the whole htmx lib.
The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags. Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements…
why hyperscript and not alpine.js ? just asking. alpine.js seems to be a lot more popular generally (even without htmx)
Re: Htmx in a Nutshell
#336Earlier quoted context omitted.
Typescript is a bandaid. We need improved DOM access for web assembly, followed by a new icon in the URL bar that indicates you're on a "legacy" site if it's using javascript (my vote is for a cute snail emoji)
We should make more bandaids like this, taking over big chunks of the programming world.
Google-affiliated Carbon looks awesome (to fix often-hated C++).
What I like is that they have skin the game (sunk cost of millions LOC of C++ to maintain) to make it highly interopable.
Re: Htmx in a Nutshell
#337Earlier quoted context omitted.
You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.Then you can get rid of almost all your js code. The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.
> You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively. Yeah, but why? The javascript snippet to accomplish the same is absolutely trivial and avoids a dependency. > The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast. The true price is that you've now rewritten your HTML code in a non-standard DSL and…
> absolutely trivial and avoids a dependency.
I disagree with this other than in a simple example. Updating something that depends on sth is far from trivial. It looks trivial.
> The true price is that you've now rewritten your HTML code in a non-standard DSL and are forever dependent on a third party library
So, like React. Prob also a build and scaffolding tool, and a linter were added in that case.
Regarding arsthetic I actually find htmx kind of ugly but it works so well I cannot ignore it. It simplifies everything a lot, but I am just discussing here.
Re: Htmx in a Nutshell
#338Getting some MacroMedia ColdFusion flashbacks! But not in a bad way.
Re: Htmx in a Nutshell
#339Earlier quoted context omitted.
Or in a similar vein I remember Github making a mediumly big deal years and years ago about having no-reload moving between pages of the directory tree within a repo with... I think their library was called pjax? And it fetched some partial HTML from the server and updated a container, plus having some pushState/popState to make it work with browser history. The most interesting part of it to me is that the mainstrea…
I made some sites with Pjax. It was crazy fast and didn’t have the issues that React had. Back button works 100% of the time, users always had a working link to share and so on. When I saw this I immediately had to search the comments for Pjax because the idea was quite similar. I think the main problem was that heavy backends started to go out of style, especially C# ones that had good Pjax support.
"Everything old is new again" feels like a reductive reaction but...
Re: Htmx in a Nutshell
#340Earlier quoted context omitted.
Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start. I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.
The only real advice I can offer is: Try to implement an example of the most complicated UI interaction that you have in your (conceptual) application in both and then decide. Development-by-random-recommendation is usually a recipe for disaster.
This is the best advice in the entire discussion.
Everyone's definition of 'complicated UI' is different, as is the amount of reactivity you have in your app (e.g. when this data changes, what else in the UI needs to change?).
There is one caution I will give: try and predict where you will be in 2-5 years. 5 years ago I built an app with complicated screens server-rendered with a smattering of Vue to enhance them. We are now moving more and more of the screen into Vue because the reactivity has increased. It would've been better to decide to build _this section of the app_ in Vue from the start, though situational constraints (aka the budget) would have prevented us from doing so anyhow.