Hacker News Reader

Comment by Kalabasa | Hacker News Reader

Yes this was a response to htmx. It was a half-parody half-I wanna make it work project. Like https://github.com/vilgacx/aki

I would fear if anyone wants to use this in production BUT I would love someone to get inspired and use the concepts rather than the actual code. Hmm maybe i should write a disclaimer...

View on HN

It's funny, I stumbled on a similar use for iframes a few years ago that I did put into production. I needed to have a rather large SPA for employees hosted locally - that is, on a server on a local network in retail stores, not accessible from the web or unless you're on the same network as the server. The employee had to be able to load it on a tablet (but wouldn't necessarily know the server's local, dynamically allocated IP address without checking). And it had to be deployable without any complicated local DNS setups, router changes, etc.

I solved it by writing a discovery service... a wrapper that's accessible on a public (non-SSL) web page that basically opens a pile of hidden iframes and uses them to war dial local IP addresses until it finds the app and replaces the page's content with the winning frame's. Amazingly this janky thing has held up ;)

Anyway, nice work, and a cool idea!

Pretty sure recent browser security features will break that.

That's a truly brilliant/horrible way to solve it. Love it!

I don't see why you wouldn't want someone to use this in production. This is pretty close to the way it should have been all along.

Love it! I think this idea has some legs in that a programmer can build their own f****k. Bundling only the pieces that they actually use. I don't see why it should not be used in a production environment...other than someone in the internet disapproves...a fear many of us suffer from. It's a simple idea & can be easily managed in a codebase.

In he spirit of breaking apart HTMX piece by piece, I created hyop (Hypermedia/Hydration Operation). It weighs in at 61 B but uses the "hyop" attribute. I know, I know, I'm bad...but at least I save bytes.

https://github.com/hyopjs/hyop

I'm going to use some of your concepts, with credit of course...like the snippetware idea among others.

What does single__hyop actually do? I read the whole README and couldn't find a definition of it. Is it essentially the same as onload="..." ?

I released it a few days ago & I appreciate the feedback. A single__hyop is a strategy to run a hyop mapped to a key...opposed to a multi__hyop which runs multiple hyops on keys delimited by whitespace. Other strategies are possible, like implementing an HTMX-like api with tree-shaking...but I havn't yet run into a use case for such sophisticated behavior. TBH, I only use single__hyop but wanted to leave the api space open for more sophistication. I mainly use this pattern instead of the overly-bloated hydration feature that come with the large UI frameworks.

It is like onload for all elements, it works with tree-shaking, & the hyops can keep local scope (do not need to be assigned to globalThis/window). I didn't use the onload attribute because hyop has different semantics than onload. eval would need to be used & the functions would need to in global scope to preserve onload semantics.

There is a DEBUG preprocessor which ensures that all of the hyops are loaded in the browser build & there are no unused hyops as well.

It's only 61 bytes, so it's basically snippet-ware at this point. There may be more built on this foundation as I mentioned earlier. I wanted to express this pattern b/c it's been useful for me.

It looks like it's used to register hooks to invoke custom behaviour on elements defined by the hyop attribute. The document load handler defines a central dispatch table for all of these hooks.

What is f****k? Fuuuck? Or maybe framework but HN has eaten some of your stars?

It's supposed to be framework, the same way it was censored in TFA

> I would fear if anyone wants to use this in production

Why? How would it be different from using htmx?

For one thing, it seems like it wouldn't gracefully degrade in functionality if JavaScript was disabled or unavailable. With htmx you can use its HX-Request header to check whether a request is from htmx or not, and serve a partial HTML or a full page accordingly. So no matter the circumstances, you can maintain a good user experience.

It's just a weird feeling for someone to use a hack / experiment as a foundation or something. I know 'the software is provided "as is ", without warranty'.

The difference with htmx is that they are more polished.

I would caution against using HTMX in production, either, from personal experience.

I've been looking for someone to write a negative htmx experience analysis to host on the essays page:

https://htmx.org/essays

i don't want people to pick htmx if it's going to be a bad choice for their particular application, would be happy to work w/ you to get something put together

Very nicely done. Your intent was quite clear reading the site and code.

It sounds like 'probably, yes' to adding a disclaimer, if only because I rather took it at face-value seeing it posted here on QBN so bookmarked for investigation later... .

Reply on news.ycombinator.com