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

111–120 of 256 posts

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

#111

Post by ComplexSystems »

Kalabasa wrote: post #29
troupo wrote: post #16

Earlier quoted context omitted.

The inline editing demo also has a separate URL for the "we're editing" state

Yeah it's terrible in some use cases. If only HTML provided a way to navigate without adding a history entry, like . If this was a real product i would market it as "Native time travel debugging! Go through your application state as you would go through your browser history!"

Could you perhaps modify the iframe to clear the new URL from history using JavaScript?

You could also make it optional; perhaps there'd be syntax like ... or something.

Probably would be better to make the no history default though.

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

#112

Post by zestyping »

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 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="..." ?

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

#113

Post by superkuh »

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…

If you would've told anyone in the year 2000 that it'd become standard practice to blindly execute programs sent to you by anonymous people you don't know you'd get a lecture on why that's stupid.

But in 2024 it's standard accepted practice. And that standard has made it so browser developers have to literally prevent the user themselves from having control over their browser because it's too dangerous to do otherwise.

The problem with the entire commercial web application ethos, despite it being a perfect fit for for-profit situations, is that it forces the rest of the web stack to gimp itself and centralize itself, CA TLS only, etc, just to keep the auto-code executing people secure. The one horribly insecure user behavior (auto executing random code) takes over from all other use cases and pushes them out.

So, we end up with very impressive browsers that are basically OSes but no longer functions as browsers. And that's a problem. Design your own sites so that they progressively enhance when JS is available. When work requires you to make bad JS sites, do so, but only in exchange for money.

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

#114

Post by zubairshaik »

bee_rider wrote: post #108
briantakita wrote: post #40

Earlier quoted context omitted.

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?

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

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

#115

Post by pier25 »

This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX.

Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances.

Yes, you can move the compute layer of your app close to the user in multiple ways. Moving the data to the edge is much harder.

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

#116

Post by mariusseufzer »

pier25 wrote: post #115

This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX. Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances. Yes, yo…

Texting from NZ: I don’t know how snappy your experience is but all I can say is that we‘re used to slower websites here in New Zealand. Switching between the tabs and having a <1sec delay is totally acceptable imho. It doesn’t feel „instant“ but instant enough!

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

#117

Post by trws »

pier25 wrote: post #115

This seems snappy from the US but I doubt someone in say NZ will have a good experience. Going back and forth between the client and the server on every interaction can result in terrible UX. Users will be happy waiting 1-2 seconds after submitting a form but waiting that much to switch a tab is not gonna fly. Plus there's internet weather etc which might result in unpredictable latencies over long distances. Yes, yo…

FWIW, I happen to be in Australia and it’s quite snappy. No noticeable delay at all. If I were on a satellite connection or something it would be different, but trans-pacific cable seems to be doing just fine. Really it’s the super-long initial latency connections where this remains an issue.

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

#118

Post by safety1st »

keepamovin wrote: post #41

This is great. I had an idea to use named iframes and targeted forms for simple, server-rendered pages with built-in style-scoped widgets, without leaning into complex JS client-side. But, I never simplified it well nor expressed a polished and elegant realization of that idea, as this htmz looks to me to be. A reminder to never give up good ideas, focus on excellence, and focus on refinement to a completion of an id…

I am a little bit confused because your comments seem to imply initially that htmz is written by someone other than you, and then later that you wrote htmz.

Who are you and what is your relationship with htmz and its creators? Please be honest and refrain from violating federal law and FTC guidelines in your response.

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

#119

Post by intrasight »

Very cool snippet.

This is what I now wished existed. A flowchart/wizard that let you choose a development framework based on some questions and answers. So that a minimum framework (HTMZ) is used if it can satisfy. Or HTMX if one of your answers indicates that it's needed. Or Vue, etc. - getting "heavier" platforms as needed.

Of course we don't always know ahead of time the answers to the question. But being given the questions and the flowchart would be beneficial for the up front analysis.

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

#120

Post by moritzwarhier »

oneshtein wrote: post #96
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…

It can be used in Markdown with HTML enabled but JavaScript disabled.

Haha I hope not ^^
Post reply on HN