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

Htmx in a Nutshell

htmx.org

Post reply on HN
Print view View original

201–210 of 414 posts

Re: Htmx in a Nutshell

#201

Post by infogulch »

_whiteCaps_ wrote: post #85
beauHD wrote: post #66

> The fastest way to get going with htmx is to load it via a CDN HTMLX is great and all, but loading it from a CDN is insecure and wrought with problems. Namely, the JS file in question could be hijacked and replaced with a malicious version that can steal data. It's unlikely, but still a plausible scenario. Also: the resource could just 404 and not be available due to work-in-progress scenarios on the CDN side. I wo…

I haven't done much frontend dev work, but I thought that's what the integrity keyword is for:

The Installing section suggests exactly this for users just getting started: https://htmx.org/docs/#installing

And then it says in the docs right after:

> While the CDN approach is extremely simple, you may want to consider not using CDNs in production.

> The next easiest way to install htmx is to simply copy it into your project.

> Download htmx.min.js from unpkg.com and add it to the appropriate directory in your project and include it where necessary with a tag:

Someone else in the thread was asking about webpack. webpack. What has javascript done to people's expectations?

Re: Htmx in a Nutshell

#202

Post by fatboy »

Quekid5 wrote: post #190
codegeek wrote: post #158

Earlier quoted context omitted.

Can I ask you how long you have been using this stack for and what are your findings ? Do you have a complex UI heavy application and can you deterministically say that this stack can replace frameworks like React/Vue for JS heavy frontend ? Is HTMX really mature and stable for production and massive UI heavy apps ? I am asking because we are starting a big project in Django, Postgres, Tailwind and for frontend, stil…

Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend. I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced"…

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.

Re: Htmx in a Nutshell

#203

Post by icedchai »

kkapelon wrote: post #195
icedchai wrote: post #157

Earlier quoted context omitted.

Maybe you are? Yes, it integrates existing frameworks and libraries. In fact, the home page says "Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services."

While I would love to argue whether DropWizard is a framework or not there is no need for that. Just go to google trends and compare Spring and Dropwizard. Or look at https://www.jetbrains.com/lp/devecosystem-2021/java/ . Dropwizard doesn't even appear in the list of web frameworks. I mean, if you still believe that Java has as many frameworks as Javascript has (and had in the past) there is nothing I can say that wi…

I've been using Java on and off since 1996. It absolutely has had a ton of frameworks over the years. Yes, I realize many of them are niche or no longer in use, but that doesn't mean there isn't a legacy application where you have to maintain 10 or 20 year old garbage.

FYI, I despise both J2EE and Spring. (Maybe Spring Boot is okay.)

Re: Htmx in a Nutshell

#204

Post by FlyingSnake »

dysoco wrote: post #36
leetrout wrote: post #3

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…

Curious at why are you using DRF with HTMX; isn't DRF more common when you need to return JSON for example and render in the frontend? Wouldn't returning Django templates to use with HTMX be the best option? Or is it for POST requests?

Web isn’t the only interface. DRF might also serve REST API to mobile or webhooks etc.

Re: Htmx in a Nutshell

#205

Post by quickthrower2 »

leetrout wrote: post #3

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…

I played with HTMX and I think it just pushes complexity into the back end that now needs to render full and partial pages. Granted on the back end you get to do traditional programming and pick your language

Re: Htmx in a Nutshell

#206

Post by rglover »

ttfkam wrote: post #188
rglover wrote: post #115

Earlier quoted context omitted.

Yes, I have. It was one of the things I looked at as part of my initial research before deciding to work on Joystick. What I don't like about is that it's a non-standards based pattern for implementing interactivity in HTML (the same reason I didn't like React, Vue, Svelte, etc). All of these frameworks try to wedge stuff in between the core languages of the web (HTML, CSS, and JavaScript) for the sake of speed/being…

Honestly, Joystick doesn't seem at all like React, Vue, or Svelte. You have a lot there in terms of email templates, database connections, and other "full stack" items that far exceed the scope of the others. React is certainly a LOT more cognitive overhead than plain old HTML/CSS/JS. Vue, yes, to a lesser extent than React. But honestly, Svelte is closer to "just plain CSS and HTML" as I've even seen in a framework…

> Honestly, Joystick doesn't seem at all like React, Vue, or Svelte.

The component framework (@joystick.js/ui) portion is best compared to those.

> Svelte is closer to "just plain CSS and HTML" as I've even seen in a framework that also allows two-way data binding

Joystick does this too but with zero need for a special compiler/extra syntax.

> Automatic scoping of CSS to a component is also nice when you aren't trying to set a global style.

Joystick also does this without any special compiler. Whatever CSS you define on a component is explicitly scoped to the HTML rendered by that component.

---

The compiler and data attribute stuff are the hang up for me. It's adding stuff in that's non-standard. Admittedly, it's neat/clever, but that line of thought has lead (JavaScript-driven) web development down a rabbit hole. I started about 10 years after you (2006) and want to get back to that level of simplicity—sans IE6 rendering bugs—without compromising productivity. I think Joystick hits the sweet spot on that.

Re: Htmx in a Nutshell

#207

Post by quickthrower2 »

recursivedoubts wrote: post #191
bogwog wrote: post #98

I don't love the idea of implementing common app state logic via attributes. It probably works a lot better than I'm assuming, but it feels hacky to me. Like it can't solve every problem you'd actually encounter when making a complex app, so eventually you'll need to fall back to using javascript, and possibly a framework or three...on top of htmx. But it does seem like this would be fun to play around with using PHP…

htmx uses the original state model of the web, Hypermedia As The Engine Of Application State (HATEOAS): https://htmx.org/essays/hateoas/ it really tries to focus on extending HTML & the original model of the web, rather than replacing it w/something else good for some stuff, not good for other stuff i like using events when I need to tie things together with some scripting: https://htmx.org/essays/hypermedia-friendly…

For something between static html pages (good for information websites no need for HTMX) and SPA (good for complex SaaS services outgrown HTMX).

Re: Htmx in a Nutshell

#208

Post by recursivedoubts »

bminor13 wrote: post #76
recursivedoubts wrote: post #38

Earlier quoted context omitted.

Hypermedia APIs and JSON (Data) APIs are different. I have a few essays up on these differences here: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/splitting-your-apis/ Generally, I would recommend splitting your data and hypermedia APIs up, so you can take advantage of the features of hypermedia (the uniform interface) and still provide a good data API to clients that want it. Also, t…

Question about this part of the hypermedia vs data APIs essay: "This new end point is driven entirely by hypermedia needs, not data model needs. This end point can go away if the hypermedia needs of the application change" Presumably these hypermedia endpoints are all equally accessible - couldn't the removal of one break another application if the latter app decided to depend on a particular hypermedia snippet from…

in the sense I'm using, an application is a single functional app: you wouldn't have two applications using a shared URL because that would break the uniform interface

you might have two separate apps that maintain their own hypermedia APIs and that, on the server side, then share a data API between each other

the idea is to take advantage of the uniform interface of a hypermedia APIs:

https://htmx.org/essays/hateoas/

but there is an assumption there that the server side gives a client a sensible representation of state

Re: Htmx in a Nutshell

#209

Post by Quekid5 »

fatboy wrote: post #202
Quekid5 wrote: post #190

Earlier quoted context omitted.

Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend. I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced"…

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.

Re: Htmx in a Nutshell

#210

Post by fatboy »

runarberg wrote: post #180
wwweston wrote: post #165

Earlier quoted context omitted.

Do you have any specific suggestions for resources for exercising grid & shadow dom knowledge/chops? I'm updating my CSS understanding after having left the front end for ~6 years (but having done a lot of front-end work for the previous 10), loving custom properties and am intrigued with some of the systems built around them (e.g. Pollen), trying to figure out where else I should be directing attention.

The guides and references on mdn is pretty good for grid: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou... As for the shadow DOM, it is pretty advanced, I don’t recommend going there unless you really want to learn it. Using web components without understanding can cause way more problems then it solves. And at the end of the journey you get a very verbose system with a lot of boilerplate just to get c…

I've just done a small project using web components. I didn't use the shadow dom at all (please note I have no idea what I'm doing).

This was after reading a single hacker news comment saying not to bother with it, after days of research where everything I read spoke about web components and the shadow dom as if they were inextricably linked.

I didn't want the styles to be encapsulated. I wanted the css to cascade in like it does everywhere else. I don't really see many use cases where you would actually want to style a component from the inside and not have the user of the component be able to style it themselves.

All the blogs I read spoke about exposing a styling api using css variables. But by doing that, are you not going to great lengths to recreate what already exists in the normal dom?

Am I missing the point?

Post reply on HN