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

Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

getludic.dev

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#31

Post by recursivedoubts »

oefrha wrote: post #13
underdeserver wrote: post #8

On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?

Totally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day. As an asi…

the htmx/hypermedia approach doesn't perclude scripting for client-side interactions:

https://htmx.org/essays/hypermedia-friendly-scripting/

https://hypermedia.systems/client-side-scripting/

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#32

Post by oefrha »

recursivedoubts wrote: post #31
oefrha wrote: post #13

Earlier quoted context omitted.

Totally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day. As an asi…

the htmx/hypermedia approach doesn't perclude scripting for client-side interactions: https://htmx.org/essays/hypermedia-friendly-scripting/ https://hypermedia.systems/client-side-scripting/

It does not, and I was specifically talking about local state changes. I’ve seen it misused a fair bit, and these trivial examples that tend to be local in real applications don’t help guiding developers who are not keenly aware of the existence of poor connections.

Additionally, while not htmx, in the adjacent land of LiveView, client side scripting is a bitch. I built a complex application in LiveView two years ago and later regretted it. Hard to resolve client side state and server side state diverging with complex but local state changes, and complex local changes are made more difficult than good old imperative jQuery thanks to a managed DOM. It’s extremely tempting to render local state changes with an HTML patch from the server to avoid all the pain, but like I said, high latency users will hate my guts for it.

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#33

Post by meiraleal »

allknowingfrog wrote: post #29
oefrha wrote: post #13

Earlier quoted context omitted.

Totally depends on your latency to the server and server response time. Please don’t throw away two decades of client side advancements and do this for state changes that should be entirely local, people with higher latency will hate your guts. Use alpine or something like that if you don’t want to go full react/vue/svelte/solid/etc. It’s utterly terrifying that I now see this pattern evangelized every day. As an asi…

I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness. What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat.…

> others see as a liberating departure from two decades of unnecessary bloat

Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#34

Post by meiraleal »

Difwif wrote: post #12
underdeserver wrote: post #8

On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?

Same. I know this is unfair but it made me subconsciously write off the framework. OP, this is purely marketing feedback but try to make the button fast. Love the direction you're taking, good luck!

That's not really unfair. This trend about moving frontend things to be processed in the server is "coincidentally" what the big cloud providers need to keep hitting their quarterly goals.

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#35

Post by p_l »

meiraleal wrote: post #33
allknowingfrog wrote: post #29

Earlier quoted context omitted.

I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness. What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat.…

> others see as a liberating departure from two decades of unnecessary bloat Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?

Because it might be in fact easier and simpler to implement it on backend?

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#36

Post by p_l »

itishappy wrote: post #27
underdeserver wrote: post #8

On a reasonably fast connection, I hit the increment button and it took almost two seconds for the counter to increment. Is it immediate for everyone?

No. It's fast, but not immediate. It's annoying but not unusable. Worse though, it starts dropping repeated clicks. Triple click increments counter by 2. Unfortunately, this is unusable.

It is honestly a bit too limited example. One way to handle it is for example to appropriately "lock" transaction on HTMX side, which is not done here.

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#37

Post by meiraleal »

p_l wrote: post #35
meiraleal wrote: post #33

Earlier quoted context omitted.

> others see as a liberating departure from two decades of unnecessary bloat Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?

Because it might be in fact easier and simpler to implement it on backend?

it might, it probably isn't. Unless you only have a hammer.

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#38

Post by p_l »

meiraleal wrote: post #37
p_l wrote: post #35

Earlier quoted context omitted.

Because it might be in fact easier and simpler to implement it on backend?

it might, it probably isn't. Unless you only have a hammer.

What is, and what isn't easier has a big honking "IT DEPENDS" attached.

And I have a strong suspicion for many the beloved hammer is big complex client-side JS framework.

Re: Show HN: Web Development with Htmx, Type-Guided Components, Pure Python

#39

Post by allknowingfrog »

meiraleal wrote: post #33
allknowingfrog wrote: post #29

Earlier quoted context omitted.

I've been following projects like Hotwire and HTMX for awhile now, and I haven't seen anyone argue that scraping is a major reason to adopt this approach. I also don't see a lot of opposition to the idea of incorporating something like alpine to add some UI niceness. What you see as a "terrifying" disregard for "two decades of advancements", others see as a liberating departure from two decades of unnecessary bloat.…

> others see as a liberating departure from two decades of unnecessary bloat Is moving the bloat to a blackbox in the backend really a better approach? Why not just not create a bloated frontend?

Using htmx allows you to completely skip a layer of JSON serialization and parsing. It eliminates the complexity of maintaining a second, frontend application, as well as all of its build tools and dependencies. It even opens up the freedom to work exclusively in your preferred language. All of these are examples of removing elements, not just hiding them somewhere else.
Post reply on HN