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

241–250 of 414 posts

Re: Htmx in a Nutshell

#241

Post by sureglymop »

scoofy wrote: post #236
sureglymop wrote: post #233

Earlier quoted context omitted.

Interesting! Is it open source?

Not yet. Eventually, but right now it's just a hobby trying to become a business, and until I get a big enough database to provide a moat, I'm a bit nervous about giving it away for free. I'm not sure if that's the best course of action, but I'm just a guy who's a bit embarrassed to really like to programming in python and playing golf.

I completely understand, best of luck with your project!

I was looking for an example authentication implementation in htmx that's why it caught my attention.

Re: Htmx in a Nutshell

#242

Post by runarberg »

fatboy wrote: post #210
runarberg wrote: post #180

Earlier quoted context omitted.

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…

Not really, the shadow DOM is an opt in choice for that reason. Only a subset of cases do you actually want the styles to be encapsulated. The shadow DOM is actually harmful for form components as interactive relations are voided if there is a shadow barrier between them (which has implications on both UX and accessibility; I think there is an effort in WHATWG to fix this). But when there is a usecase, the shadow DOM can be really nice. As you get nice things like component scoped styles and unique idref, among others.

> All the blogs I read spoke about exposing a styling api using css variables.

This might be an outdated advice. You are supposed to use a mix of CSS variables and ::part()[1]. CSS variables should cover the most basic styling while you are supposed to expose style-able elements of your components with the part attribute.

1: https://developer.mozilla.org/en-US/docs/Web/CSS/::part

Re: Htmx in a Nutshell

#243

Post by devmunchies »

zelphirkalt wrote: post #48
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…

But HTMX is a JS library. Anything done with it is basically done with JS.

It’s almost like htmx is a byte code target that you feed to the htmx JavaScript library. It’s easy to generate htmx markup with any backend language.

So instead of a backend language transpiling to JavaScript (like clojurescript), I can just generate htmx markup.

Re: Htmx in a Nutshell

#244

Post by StreamBright »

My problem with JS is that every framework we tried sucks in different ways. The worst is to handle the kind of silly crap that JS does (wat). The other big part is the every bricking API of pretty much everything. We are lucky if there is no warning about deprecation for a couple of day after updating a library. Minor version changes regularly break the build. The best is when yarn dev works and after building the app and deploying it to prod it breaks.

After dealing with these issues for years I am really happy to return HTML from a backend API that uses a language where [1, 2, 12, 3].sort() return what I expect from a sorting function sorting integers.

That is all, and that is what htmx gives us. I am not sure if we can replace our UIs that are written in Vue for now but at least it I have a good time porting some of the web things to htmx + Rust from Vue + Python.

Re: Htmx in a Nutshell

#245

Post by codegeek »

jonesnc wrote: post #126

We're migrating our apps from Vue.js to HTMX, and it has been a great experience. The size of our codebase has consistently gone down as we move things to HTMX, and it feels like the level of complexity goes down as well. I highly recommend using HTMX.

Would you be open to sharing your experience on this a bit more ? We have a JS heavy app with 100s of VueJS components. Could those be transferred to HTMX ?

Re: Htmx in a Nutshell

#246

Post by iamgopal »

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?

HTMX can be used with templates and JSON with extensions.

Re: Htmx in a Nutshell

#247

Post by StreamBright »

jonesnc wrote: post #126

We're migrating our apps from Vue.js to HTMX, and it has been a great experience. The size of our codebase has consistently gone down as we move things to HTMX, and it feels like the level of complexity goes down as well. I highly recommend using HTMX.

We are planning to do the same thing. Would you have any write up that you could share?

Re: Htmx in a Nutshell

#248

Post by silver-arrow »

m4lvin wrote: post #114
recursivedoubts wrote: post #2

howdy, I'm the creator of htmx, happy to talk about it

How does error handling work? If I try to replace the content of some div with a reply I get using htmx, but the request fails or times out etc., what content is then put into the div? What if the reply is not valid HTML? Sorry for the newb and lazy questions.

It’s pretty simple to use the htmx events on the Response to handle errors dialogs or other behavior

Re: Htmx in a Nutshell

#249

Post by drdaeman »

theptip wrote: post #109
zelphirkalt wrote: post #48

Earlier quoted context omitted.

But HTMX is a JS library. Anything done with it is basically done with JS.

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

Re: Htmx in a Nutshell

#250

Post by revskill »

Modern frontend is easy to get burn out not by the complexities of tooling. It's more about upgrade and backward compatibility. Same story as backend, but backend is likely less broken on that aspect.
Post reply on HN