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

Show HN: htmz – a low power tool for HTML

leanrada.com

Post reply on HN
Print view View original

101–110 of 256 posts

Re: Show HN: htmz – a low power tool for HTML

#101

Post by samtheprogram »

pmontra wrote: post #88
SushiHippie wrote: post #85

Earlier quoted context omitted.

Or uBlock origin (from the same author) which is still maintained

It is maintained but the UI for dealing with JS is horribly time consuming and overly complex compared to uMatrix. I'll never really understood it and I keep using uMatrix on my laptop. I switched to NoScript on my phone. Maybe I can install uMatrix now if Mozilla really unblocked many extensions. If uMatrix stops working, I'll switch to NoScript everywhere for JS and uBO for all the other issues.

This is what I do and it works great - uBlock Origin defaults, and NoScript.

It’s surprising how well the internet works without JavaScript.

Re: Show HN: htmz – a low power tool for HTML

#102

Post by eproxus »

recursivedoubts wrote: post #66
tambourine_man wrote: post #15

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

I'm the creator of htmx and think this is a great library/snippet. Much closer to what htmx-like functionality in HTML would/should look like in that it is following existing norms (iframes, the target attribute) much more closely than htmx. From a practical perspective, a lot of the bulk of htmx is bound up in things like history support, collecting inputs, a lot of callbacks/events to allow people to plug into thin…

Kind of makes me wish there was a htmx-lite of sorts. Like an 80/20 solution at 20% of the size, which could be extended to the full blown package with extensions.

Have you thought about moving more features to extension, like was done with the web sockets feature?

Re: Show HN: htmz – a low power tool for HTML

#103

Post by nashashmi »

MatthiasPortzel wrote: post #36
Arch-TK wrote: post #9

Given that this uses `target`, doesn't it mean that unlike htmx you can't easily make this gracefully degrade when JS isn't enabled? And, yes, I know, saying "when JS isn't enabled" in 2024 is a bit like saying "when the user is on Mars and has a 10 minute RTT" but forgive me for being an idealist.

> being an idealist Could you describe your ideals for why websites should gracefully degrade without JS enabled? It’s not an unpopular view on HN, but from my perspective as a web developer, JS is a part of browser application just like HTML, and there’s no reason for the website to work if you’ve disabled a part of the browser. I suspect “doesn’t have JavaScript” is being used as a proxy for a lot of other ideals t…

I browse the web without JS. It is a fast easy way to load websites. And some sites with heavy app interaction features need JS. And that is fine. It is the other sites that use JS to figure out if their users have read more than 2 articles that are the problem.

Degrade gracefully is a required development skill. Sites need to allow for their pages to work in limited fashion without JS. JS should only be a layer added for interactivity, animation, and app construction. Otherwise, workarounds are great.

Is there a way to make this gracefully work? YES!! Instead of using hash tag names, use '?id=example'. And let the script in frame figure out the real destination of the output. Otherwise, the page will load the full site. Also use script to add "target" attribute to links.

Re: Show HN: htmz – a low power tool for HTML

#104

Post by aeontech »

noduerme wrote: post #83
Kalabasa wrote: post #24

Earlier quoted context omitted.

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

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 a…

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

Re: Show HN: htmz – a low power tool for HTML

#105

Post by sesm »

moritzwarhier wrote: post #38

It's a fun one liner, but what is the use case? When I want to replace some element using JS as the user clicks a link , it is progressive enhancement. Usually links enable history navigation. If you do stuff like this, you need to code it in a way that uses the history API to fix it for users with JS enabled (majority of users). If you don't want history navigation and URLs, why do you use links? This breaks history…

The use case is to show that you can do core htmx functionality in a one-liner.

Re: Show HN: htmz – a low power tool for HTML

#106

Post by sesm »

woah wrote: post #77

Waiting for htmz on rails, the 100k loc batteries included htmz framework to implement full featured UX patterns and make development delightful

We need to keep the naming convention, so:

- htmz on handcar (still on rails but you have more manual control)

- htmz on horseback (if you want to reject modernity)

Re: Show HN: htmz – a low power tool for HTML

#108

Post by bee_rider »

briantakita wrote: post #40
Kalabasa wrote: post #24

Earlier quoted context omitted.

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

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 (Hyperme…

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

Re: Show HN: htmz – a low power tool for HTML

#109

Post by harryvederci »

recursivedoubts wrote: post #66
tambourine_man wrote: post #15

That's a great hack and it shows how close the browser is to offering SPA natively. Just a few attributes and we could avoid the iframe. It's probably more useful to prove a point than an actual day to day tool. And the point seems to be: htmx is too much trouble for what it offers. We just need HTML native ajax.

I'm the creator of htmx and think this is a great library/snippet. Much closer to what htmx-like functionality in HTML would/should look like in that it is following existing norms (iframes, the target attribute) much more closely than htmx. From a practical perspective, a lot of the bulk of htmx is bound up in things like history support, collecting inputs, a lot of callbacks/events to allow people to plug into thin…

I'm not the creator of htmx and you are wrong.

I am now officially emotionally invested in htmx so I have to justify investing my time/energy in htmx instead of something else, so all alternatives to htmx are stupid and their existence make me very angry.

Re: Show HN: htmz – a low power tool for HTML

#110

Post by smaudet »

MatthiasPortzel wrote: post #36
Arch-TK wrote: post #9

Given that this uses `target`, doesn't it mean that unlike htmx you can't easily make this gracefully degrade when JS isn't enabled? And, yes, I know, saying "when JS isn't enabled" in 2024 is a bit like saying "when the user is on Mars and has a 10 minute RTT" but forgive me for being an idealist.

> being an idealist Could you describe your ideals for why websites should gracefully degrade without JS enabled? It’s not an unpopular view on HN, but from my perspective as a web developer, JS is a part of browser application just like HTML, and there’s no reason for the website to work if you’ve disabled a part of the browser. I suspect “doesn’t have JavaScript” is being used as a proxy for a lot of other ideals t…

Supporting as many devices as possible, breaking RESTful APIs, etc.

A JS engine pre-supposes many, many things (too many) about a client, stuff like implicit assumptions that "this device has enough power and bandwidth to process my javascript, perform appropriate security checks on it, handle this fast enough to service other requests in a timely manner, and also not take over the user's entire computer".

Accessibility means you should presume the least number of things possible. There's no sound, no visuals, no powerful cpu (maybe there isn't even a cpu), the device is the only working device from 20 years ago performing some critical function (e.g. government poverty assistance), there's only a couple minutes of power left, the internet is not available currently or quickly, etc.

You should never assume you have JS, period, and features should gracefully degrade in the presence of JS engines.

Post reply on HN