Oh, by the way, since the optimisations I made on the bundle size, it now takes ~3.61 seconds to download and install Kitten¹ on my machine and ~1 second to update it (the initial install takes longer as Kitten downloads its own Node.js runtime and that takes the bulk of the time).
Every second you don’t spend waiting for something is a second you can spend doing something else 🤓
(And remember, Kitten is a server. So you don’t have to download and install a framework every time you start a project – no npx this or that or anything. Just start writing your code and run kitten.)
My dive into #Rust and its web ecosystem continues. This time, I'm using #Axum to serve HTML from an endpoint and sending static files from a directory.
Note: Cool features from RustRover include automatic dependency refresh, HTML Language injection, and a built-in browser in the IDE (via plug-in), not to mention really good language support.
College Prof: HATEOAS is how you should build on the web
Me in College: That’s lame and outdated. Frontend frameworks are the future.
Me now: He wasn’t wrong. He had it right all along.
I wasn’t able to see it then. It took writing complex frontend apps and managing tons of state on the client for me to realize that he was right. Always consider the point of view. Even if it seems dumb at first, upon reflection it might not be that dumb. The crowd isn’t always right.
TIL about #hyperscript, a mini language meant to be used in conjunction with #htmx to chain together multiple actions. e.g. a modal that displays and then fetches its contents
my sense is that you should avoid using it. but when you need it, it’s very readable and easy to reason about https://hyperscript.org/
I know the term is coined already but recently it came to my mind more than once:
Code that fit's in your head.
That's what I love about vertical slice architecture (wrt coupling and cohesion).
HTMX and Alpine are a nice fit due to locality of behavior.
Paired together with Event Sourcing (not having to guess what might have happened to the state) it gives me some peace of mind I've missed for a long time.
Once again, #TDD and #HexagonalArchitecture meant that when I hooked up the "real" timer broadcaster (using WebSockets), everything just worked.
Only took 35 lines of WebSocket code and 10 lines of #SpringBoot configuration code and a few #htmx attributes on the HTML page. (Not counting the separate transformer code that generated the HTML.)
@rstevens I've build web "apps" that use tables with infinite scrolling and that allow toggling rows between view/edit modes thanks to #htmx and it is great.
@alcinnz Love this article. Thank you for sharing!
Under the “no solutions” section, I’ll suggest https://htmx.org as a potential option. Yes, #htmx socials are filled with silly memes, but that’s only to reinforce the point that today’s “front end” devs have taken themselves way too seriously.
The library itself has been a breath of fresh air for me, in an otherwise absurd world where simple things are obfuscated into oblivion by layers of meaningless abstractions.
If there was an #HTML element that changes it's content when users interact with other elements on the page, what name would it have?
PLEASE NOTE: I am not suggesting that this element needs to exist; I am only asking what it would be called. I'm building a CustomElement, I just want it to have a name that makes sense.
Vote and suggest others in replies. Please boost for reach!
Round 2; because I've gotten some good suggestions
This <HTML> element updates itself with the result of an HTTP request that some other element on the page made. It can replace, append or prepend it's contents.
An <HTML> element that updates with the result of an HTTP request that some other element on the page made.
Links and forms inside it may be changed so that they only update this element instead of the whole page; similarly to Hotwire: TurboFrames https://turbo.hotwired.dev/handbook/frames