[HN Gopher] Show HN: htmz - a low power tool for HTML
___________________________________________________________________
Show HN: htmz - a low power tool for HTML
Author : Kalabasa
Score : 643 points
Date : 2024-02-19 13:12 UTC (9 hours ago)
(HTM) web link (leanrada.com)
(TXT) w3m dump (leanrada.com)
| Alifatisk wrote:
| Kind of impressive that the installation script was that small.
| turnsout wrote:
| That's not the installation script, it's the entire
| "framework!"
| sodimel wrote:
| Simple and powerful, as the vanilla web should be. Thank you for
| this (small) gem :)
| kickofline wrote:
| At what point does it cease to be a framework and become just a
| regular line of code?
| p4bl0 wrote:
| From the FAQ:
|
| > * Is htmz a library or a framework?
|
| > htmz is a snippet.
| vcg3rd wrote:
| From the README:
|
| > htmz is a minimalist HTML microframework
|
| So, some ambiguity.
| Kalabasa wrote:
| Author here. to be honest I have no idea
| joshfarrant wrote:
| Finally, a Hacker News comment I can relate to.
| alexpetros wrote:
| Hah that's amazing
| p4bl0 wrote:
| This is a neat hack, I like it :). Thanks for sharing.
| internet2000 wrote:
| Apparently it breaks your back button too.
| rnmmrnm wrote:
| If you're talking about the tabs demo, I think it's reasonable
| for some use cases to respect back button as previous tab. as
| long as it's easy to opt out.
| troupo wrote:
| The inline editing demo also has a separate URL for the
| "we're editing" state
| Kalabasa wrote:
| Yeah it's terrible in some use cases.
|
| If only HTML provided a way to navigate <a> without adding
| a history entry, like <a nohistory href=...>.
|
| 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!"
| devmor wrote:
| That would be terrible UX.
|
| The real answer is that web developers should stop using
| anchor tags to target non-stateful links and should
| properly handle navigation to pages that are short lived.
|
| But that battle is a bit like asking people to use their
| turn signals when merging.
| ComplexSystems wrote:
| 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 <a href="asdf.html#myElement;no
| history">...</a> or something.
|
| Probably would be better to make the no history default
| though.
| jdp wrote:
| Reminds me of pjax [1], except pjax works over XHR instead of an
| iframe and uses pushState by default to keep the back button
| working.
|
| [1]: https://github.com/defunkt/jquery-pjax
| captn3m0 wrote:
| GitHub itself used pjax heavily and I liked those interactions
| far more than the newer React ones, the HTML was much more
| semantic for one, with middle click always being respected.
| Arch-TK wrote:
| 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.
| beretguy wrote:
| I use Disable JavaScript extension with js disabled by default
| and only enable it if website is broken.
|
| https://addons.mozilla.org/en-US/firefox/addon/disable-javas...
| efilife wrote:
| You should use uMatrix so you can only enable the scripts
| necessary to unbreak the site
| SushiHippie wrote:
| Or uBlock origin (from the same author) which is still
| maintained
| pmontra wrote:
| 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.
| samtheprogram wrote:
| This is what I do and it works great - uBlock Origin
| defaults, and NoScript.
|
| It's surprising how well the internet works without
| JavaScript.
| SushiHippie wrote:
| I've never used uMatrix what can uMatrix do what uBlock
| can't? I have set all sites to no js, and if something
| does not work I click the JS toggle in the menu, reload
| the page and thats it.
|
| And yes uMatrix should work on Firefox on Android. ( At
| least it is installable)
| pmontra wrote:
| uMatrix has a spreadsheet like matrix of features and
| sites. It's immediately clear what happens when I click a
| cell, a column or a row. With uBO I don't even understand
| where to click to toggle JS for one of the sites a page
| got scripts from. I learned it years ago but it was too
| cumbersome. I kept using uMatrix and I forgot it. I
| attempted to use it again now and I couldn't find
| anything. I didn't google for it.
|
| I installed uMatrix on my phone and disabled NoScript. Of
| course I keep using uBO for filtering out ads and hiding
| annoying parts of sites with the element picker.
| samtheprogram wrote:
| I use NoScript for this as well, I'll have to check out
| uMatrix.
| Kalabasa wrote:
| Yeah it breaks without JS. You could add the iframe behind JS,
| so the target would default to a new tab. But the server would
| still be designed to return HTML fragments. I never found a way
| for a server to check if the originating request is for an
| iframe or a new tab. It's not quite a graceful degradation.
| naasking wrote:
| You could intercept the clicks with JS and add a special
| header, like htmx does, to return fragments, otherwise fall
| back to full documents.
|
| Edit: rather than a header, dynamically adding a query
| parameter to the URL of the element that was clicked would
| probably fit better with htmz's approach.
| simpaticoder wrote:
| _> I never found a way for a server to check if the
| originating request is for an iframe or a new tab._
|
| There is no such technique. One way to distinguish is to pick
| a URL convention and modify the URL (before the hash) of the
| iframe URL. For example, add ?iframe=true to the URL, and
| then have the server check for that. Perhaps more usefully
| you could include information about the parent URL, e.g. url
| += '?parent=${document.referrer}'. Or something.
| sesm wrote:
| Can we add a cookie instead of modifying URLs?
| simpaticoder wrote:
| No. The same cookies are added to both the host and guest
| pages.
| MatthiasPortzel wrote:
| > 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 that I do understand, like "should
| work on as many devices as possible" but that's a rough
| correlation and doesn't make the use of JS inherently bad.
| J_Shelby_J wrote:
| Chances are I'm on your website for information, mostly text
| content. Which really doesn't require JavaScript.
|
| So then, most JavaScript on the web is enabling revenue
| generation rather than improving the user experience. So
| yeah, disabling JS is a proxy for, "don't waste my time."
|
| But I agree that it's not inherently bad, but just mostly bad
| (for the user.)
| SigmundurM wrote:
| A reason people might want to have JavaScript disabled, is
| because of the immense tracking possibilities that JavaScript
| has, which can't easily be safe-guarded against.
|
| The people who do disable JavaScript completely are
| admittedly few and far between, but are, I would assume, more
| common among the Hacker News crowd.
| Arch-TK wrote:
| So I've been in numerous situations where having JavaScript
| enabled was either undesirable or impossible, granted, it's
| my own fault for using strange platforms like a Nokia N900 or
| whatever, with strange web browsers. But it's still nice when
| interactive websites continue to work even in contexts where
| JavaScript isn't a thing. I always thought of JavaScript as
| something you use to "upgrade" the web experience, not to
| build it. Although obviously there are some things you simply
| can't do without JavaScript and for which there exists
| literally no alternative. There's also situations where
| JavaScript is a liability. See, for example, the Tor browser.
|
| Especially my ideal is that all functionality which can work
| without JavaScript should work without JavaScript. So, for
| example, I am not expecting someone to implement drag-and-
| drop calendars without JS, but there's no reason why the
| editing function of a calendar item should fundamentally
| require JS.
|
| That being said, I know this is an idealist position, most
| companies which work on developing web-applications simply
| don't care about these niche use-cases where JS isn't an
| option and as such won't design their web-applications to
| accommodate those use-cases to save on development costs and
| time. But, while I am not really a web-developer, whenever I
| do deal with the web, I usually take a plain-HTML/CSS first
| approach and add JavaScript later.
| tambourine_man wrote:
| Because there's a case for a very useful Web without running
| a Turing-complete language on the visitor's end.
|
| If you just want to consume text, images, audios and videos,
| follow links and fill in forms (and that's quite a lot and
| pretty awesome already), you shouldn't need JavaScript.
| nashashmi wrote:
| 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.
| Kalabasa wrote:
| `?id=thing` is a great idea!
| smaudet wrote:
| 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 <insert length>
| 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.
| superkuh wrote:
| 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.
| smaudet wrote:
| Agreed. And treat all JS engine-requiring sites like
| viruses that need to be executed in protected VMs.
| jerbear4328 wrote:
| Of course! Actually, for any website that runs JS, in my
| opinion, we should just automatically forward the JS
| execution into a virtual machine, it is horrible to allow
| any random website to just run code directly on our
| machine.
|
| What if we built this virtual sandbox directly into the
| browser, that way no code could run on our machine, but
| all websites still work fine? That's revolutionary!
|
| Hang on...
| jamespo wrote:
| Part of this is backend devs and admins like telling frontend
| devs what to do
| pmontra wrote:
| It breaks without JS but many JS blocker extensions can be
| configured to always allow JS from the host serving the page.
| For example NoScript on my phone has the "Temporarily set top-
| level sites to TRUSTED" option.
|
| With only 181 bytes it could even be included in the page. It's
| much less than the sum of the meta tags on many sites.
| kevincox wrote:
| Not even just without JS. If you middle-click to open a link in
| a new tab you get just get content that was expected to be
| swapped in. I think that abusing links is a far bigger sin than
| adding a custom attribute.
| dormento wrote:
| I had a dream yesterday, that scientists managed to create a
| new kind of EMP bomb. This bomb was unusual in that, by varying
| the level of EM discharge in the payload (dreamy-sciency
| explanation), it could target all hardware created after a
| certain point in time.
|
| I had access to their facility (dreams being as dreams often
| are), and managed to set it for 1992, and right when I was
| about to press the button, I woke up.
|
| It RUINED my day.
| tambourine_man wrote:
| 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.
| alexpetros wrote:
| "Just a few attributes and we could avoid the iframe" could be
| the htmx/z motto
| Kalabasa wrote:
| 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...
| detritus wrote:
| 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... .
| briantakita wrote:
| 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.
| bee_rider wrote:
| What is f****k? Fuuuck? Or maybe framework but HN has eaten
| some of your stars?
| zubairshaik wrote:
| It's supposed to be framework, the same way it was
| censored in TFA
| zestyping wrote:
| 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="..." ?
| NelsonMinar wrote:
| Very nicely done. Your intent was quite clear reading the
| site and code.
| bachmeier wrote:
| > I would fear if anyone wants to use this in production
|
| Why? How would it be different from using htmx?
| Kalabasa wrote:
| 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.
| noduerme wrote:
| 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!
| aeontech wrote:
| That's a truly brilliant/horrible way to solve it. Love it!
| o11c wrote:
| Pretty sure recent browser security features will break
| that.
| IggleSniggle wrote:
| 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.
| naasking wrote:
| HTML native ajax is the right approach, and what the htmx devs
| fully support if I understand correctly, but I don't think this
| demonstrates htmx is too much trouble for what it offers. It
| offers considerably more than what's possible here, eg. DOM
| morphing, animations, graceful degradation, rich event model,
| server side events, etc.
| recursivedoubts wrote:
| 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 things,
| etc. I expect a lot of htmx-like libraries will come out now
| that it has some traction: it's not a super complicated idea,
| and many of them will pick smaller, more targeted subsets of
| functionality to implement. That's a good thing: the ideas of
| hypermedia are more important than my particular
| implementation.
| tambourine_man wrote:
| Sorry if I came across as dismissive, htmx is a much needed
| counterpoint to React's dominance and a great contribution to
| the industry. And I hope its core idea (Ajax from HTML with
| results loading inside a target element) will be adopted as a
| Web standard.
| recursivedoubts wrote:
| not at all, i understand there are going to be different
| takes on what the right balance of functionality &
| configuration are and htmx has been hamstrung to an extent
| by being IE compatible, which, coupled w/ my commitment to
| backwards compatibility, means some obvious things are off
| the table (e.g. using fetch())
|
| i don't begrudge other people having differing opinions on
| this stuff and agree w/the spirit of your original comment:
| HTML should have a native mechanism for doing what htmx
| does. hopefully htmx (and other takes on the idea)
| contribute to that future.
| DoesntMatter22 wrote:
| Love the fact that you care more about the tech than HTMX
| winning. I like htmx a lot though
| eproxus wrote:
| 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?
| recursivedoubts wrote:
| I've looked at the codebase and there isn't much I feel
| would do well as an extension. As I said upthread, most of
| the code is AJAX, input gathering, history support and then
| book-keeping/event stuff around that.
|
| There will be a bunch of htmx-like libraries coming out
| though and I expect many of them to take different design
| perspectives. Two that I'm aware of are https://data-
| star.dev/ and https://ajaxial.unmodernweb.com/, both were
| created by people on the htmx discord. I know of at least
| two other minimalist rewrites htmx discord users have done,
| but they haven't published their stuff yet.
|
| If you'd like to create your own, I do an overview of how
| htmx works here:
|
| https://www.youtube.com/watch?v=javGxN-h9VQ
|
| I think a minimal, clean room, fetch() based implementation
| could be done in a weekend.
| harryvederci wrote:
| 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.
| recursivedoubts wrote:
| how sweet it is
| felixguendling wrote:
| Regarding the size I would guess that if htmz would be
| extended to have the same features as htmx, it would also be
| similar in size? Would it make sense to modularize htmx in
| order to only pay for what you really use to support adding
| features without necessarily increasing the downloaded size?
| bb88 wrote:
| Thanks for HTMX, I think it's showing the world what the web
| browser could be.
|
| I'm going to be doing a lot of web pages in HTMX in the next
| couple of years, and it will be much easier to develop/debug
| than javascript.
| liendolucas wrote:
| Hi Carson! I've been using htmx sprinkled with hyperscript
| and I find using your tools very enjoyable (though I found
| myself fighting a bit with hyperscript at the beginning but
| past that and once you get the mindset and the hs way, things
| are easier).
|
| Thanks for these tools! I wanted to also take the opportunity
| to ask you something you either mentioned, commented or heard
| in a podcast.
|
| You said that htmx might not be the tool to solve all
| problems (or certain kind of apps). Just asking because I
| think is also great to hear when not to use something to
| solve a problem. So, in your opinion what kind of webapps do
| you consider that maybe htmx is not a good fit? And in that
| case what alternate tools/approaches do you suggest? Once
| again thanks a lot for htmx & hyperscript!
| azornathogron wrote:
| This is a glorious demonstration of someone _really_
| understanding the platform.
|
| I don't expect I would ever use it, but I think it's excellent.
| simplify wrote:
| Understanding or not, certain decisions like overriding the
| semantic meaning of a hash in a url doesn't seem to be working
| _with_ the platform. A better version would be adding a target
| to a `data-` attribute.
|
| It's a fun project overall, though.
| sam2426679 wrote:
| OP addresses this at "We can do a hack that enables you to
| write the target ID selector in the target attribute itself!"
| simplify wrote:
| I'm only addressing the comment on "a glorious
| demonstration" of understanding the platform, where hacks
| like this go against such a take (IMO)
| mirekrusin wrote:
| Just use target, if it starts with #, it's replacement,
| otherwise behaves as is.
| overstay8930 wrote:
| htmx in shambles /s
| recursivedoubts wrote:
| always has been
| hanniabu wrote:
| > Not even a backend is required.
|
| > In a nutshell, htmz lets you swap page fragments with HTML from
| the server using vanilla HTML code.
|
| So a backend is needed....
| Kalabasa wrote:
| Oops, it's just a mistake on word choice in the nutshell
| summary. This works on static files like on a local filesystem
| (in that case the "server" is the local filesystem that serves
| me files that happen to be html)
|
| Edit: on second thought, direct filesystem access has different
| origins which would mess with iframes. I'm not on the computer
| now to test. But at the very least you need a basic web server
| that serves files.
| hanniabu wrote:
| Thanks for the clarification, so it would work the same as a
| static site where you just need a place to retrieve the files
| from
| turnsout wrote:
| Yes, aka a webserver
| spankalee wrote:
| Reusing the <slot> element like this is a bad idea - it has very
| specific behavior in browsers. In a shadow root it'll be replaced
| by the children of the host element, no matter what the library
| does.
|
| HTML already has an inert <output> element for things like this.
| Kalabasa wrote:
| Thanks for the suggestion, I'll update the examples.
|
| Edit: that is, after I wake up...
| Kalabasa wrote:
| Woke up... It's at the top of HN...
|
| Anyway I chose div instead thanks to the other commenter http
| s://github.com/Kalabasa/htmz/commit/153a5a448b60a0898604...
| KatrinaKitten wrote:
| Slight correction - <output> is not inert for users who use
| screen readers, though in this case it shouldn't cause issues.
| If you need an actual inert element, use a div.
| sublinear wrote:
| This seems likely to have issues with most "Content-Security-
| Policy" rules because of the inline script in "onload" and the
| iframe. Makes it a non starter in real world production
| environments.
| tommica wrote:
| But isnt it the same exact domain?
| morbicer wrote:
| Can be imho solved with nonce or hash based policy
| moritzwarhier wrote:
| 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 navigation and bfcache for no good reason, or
| am I missing something? bfcache already provides SPA-like speed,
| or even better.
|
| No need to avoid regular links if you e.g. link from a list to a
| detail page.
|
| Also:
|
| > No preventDefaults. No hidden layers. Real DOM, real
| interactions. No VDOM, no click listeners. No AJAX, no fetch. No
| reinventing browsers.
|
| So many words saying nothing, just to cater to some sentiment.
| fetch is part of browsers by the way.
|
| If I need to replace an element as the user clicks a _link_ , I
| can code it myself (without using this abstraction layer, however
| thin it is). I also don't need an iframe for doing this. And
| _preventDefault_ is aptly named and a good reminder for what
| progressive enhancement should do. If it 's not meant to be a
| link, don't use a link.
|
| And if you want to react to clicks, you know, use click listeners
| (event handlers). Where's the problem?
|
| It is understandable to developers and uses native browser
| functionality as intended. As opposed to this hack, which I'd
| find pretty glaring, bug-prone and hard to understand, would I
| have to debug an issue on some page that uses this snippet.
|
| To me this seems like useless indirection and technical debt. If
| you really need low-code AJAX "links" (who says you need that, if
| you don't want an SPA?), code yourself some understandable JS
| that is properly tailored to your site and respects history
| navigation, or use a library that is a good fit for your concrete
| use case.
|
| As a joke, I like it though...
| scwoodal wrote:
| The use case is a fun one liner.
| moritzwarhier wrote:
| As a fun hack / code golf it's great. I was being tonedeaf I
| guess, woosh as they say.
|
| The marketing pitch on the landing page is written so well
| that I took it too seriously probably.
|
| I know htmx but wasn't able to see this as a parody, so my
| fun capabilities were failing :)
| Kalabasa wrote:
| I have changed it to explicitly state within the first
| paragraphs that "htmz is an experiment" now. I started this
| as a joke but turned into a fun working solution - I myself
| am not sure if this is just a joke or a thing. Maybe I'll
| use it in some smaller projects, or maybe not!
| oneshtein wrote:
| It can be used in Markdown with HTML enabled but JavaScript
| disabled.
| moritzwarhier wrote:
| Haha I hope not ^^
| sesm wrote:
| The use case is to show that you can do core htmx functionality
| in a one-liner.
| keepamovin wrote:
| 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 idea, and communicate
| well!
|
| Also the comments here:
|
| - _This is a great hack and shows how close the browser is to
| offering SPA natively._
|
| - _This is a glorious demonstration of someone really
| understanding the platform._
|
| - _Simple and powerful, as the vanilla web should be. Thank you
| for this (small) gem :)_
|
| - _This is a neat hack, I like it :). Thanks for sharing._
|
| are _exactly_ what I hoped to hear reflected about my creation,
| and are totally on point for what this type of thing should be.
| Close to the web-grain, using the given material of the web in
| the best way possible. Fuck yeah! :)
|
| Thank you for being a genius! :)
|
| And for inspiring about what's possible! :)
|
| P.S - also your communication and marketing skills are top notch!
| I think the way you have communicated this elegant technical
| thing, from the choice of name, API, examples, copy -- is just
| awesome. I learn from it! :)
| cschep wrote:
| thanks for a high quality top comment!
| safety1st wrote:
| 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.
| jkingsman wrote:
| I don't think this person is implying that at all (nor do I
| think that anyone needs to be trotting out federal law and
| FTC guidelines here :).
|
| "I had an idea to use named iframes [...] But, I never
| simplified it well nor expressed a polished and elegant
| realization of that idea, as this htmz looks to me to be.
| [...] the comments here [...] are exactly what I hoped to
| hear reflected about my creation, and are totally on point
| for what this type of thing should be."
|
| Seems pretty clear to me. This person had a similar idea but
| didn't complete it, and finds the flavor of appreciative
| "nice hack" energy (as opposed to "this is enterprise" or
| "this is a revolution" energy, I guess) appropriate for the
| project and the type of feedback they had wanted to hear had
| they completed their project.
| TimTheTinker wrote:
| > 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.
|
| My name is John Galt and I wrote this library. When you learn
| who I really am, then you'll understand.
| MikeTheGreat wrote:
| You're a convenient fiction?
|
| _ba-dump-ching!_
|
| No, no don't bother, I'll show myself out :)
| scubbo wrote:
| You seem to have misinterpreted "[those comments] are exactly
| what I hoped to hear reflected about my creation". They
| weren't saying "I enjoyed hearing those comments about htmz,
| which is a thing I created" - they were saying "those
| comments are what I _had_ hoped to hear about my (unreleased
| and unnamed) creation, which indicates that htmz is a good
| implementation of a similar idea that I had"
| synergy20 wrote:
| I happened to spend a little more time on htmx this weekend which
| htmz was inspired by.
|
| htmx/htmz does do well for simple use cases, htmx does well for
| SSR heavy cases(e.g. django).
|
| in the end I returned to vue.js, with a few lines code(put in a
| library) I can mimic htmx easily plus all the extra stuff vue.js
| brings, and no I do not need use a build tool for that, vuejs
| works fine via CDN inside a html for simple use cases the way
| htmx does, but vuejs can do more, e.g. draw live chart from data
| returned via ajax calls where vuejs is json by default, htmx is
| html by default instead.
| angra_mainyu wrote:
| This.
|
| I think Vue.js "scales down" excellently. You can just load it
| via the cdn and write some widgets and go about your day.
|
| In the past I've tried to make use of "microframeworks" like
| alpine.js and such but often found myself returning to Vue.js.
| synergy20 wrote:
| same here, spent lots of time poking around, even tried
| svelte and react.js(heavily), and now firmly back to vue.js.
|
| vue.js does not mix SSR with SPA into one, make it much
| simpler compare to what React.js is doing today, and it
| provides way more than alpine.js and htmx etc, it's the best
| one in practice for me now.
| spankalee wrote:
| I think there's a pretty strong argument at this point for this
| kind of replacing DOM with a response behavior being part of the
| platform.
|
| I think the first step would be an element that lets you load
| external content into the page declaratively. There's a spec
| issue open for this: https://github.com/whatwg/html/issues/2791
|
| And my custom element implementation of the idea:
| https://www.npmjs.com/package/html-include-element
|
| Then HTML could support these elements being targets of links.
| flanbiscuit wrote:
| Was curious to see the code so found the GitHub. Posting it here
| in case anyone is interested since the author doesn't link to it
| on the site and also the npm page doesnt link to it either
|
| https://github.com/Kalabasa/htmz
| atahanacar wrote:
| It is right at the end of the first sentence.
| qwertygnu wrote:
| ha, I'm working on a dev-side version similar to this (mostly
| just for me, but hopefully publishable). I opted for an entirely
| pre-deplopyment build tool, where you just put
| <custom-tag custom-param="value"></custom-tag>
|
| in your HTML, run the build and it outputs the filled in file
| somewhere else. I know its functionality is very similar to many
| web frameworks (e.g. React, handlebars) but it does _one thing_.
| koliber wrote:
| In 2001 or so, I was building an HTML based email client. We used
| a hidden iframe to execute JS to load data from the server and
| manipulate the DOM with the result. It was not quite as neat and
| elegant as this--the browser support was not there. However, the
| basic mechanism was the same.
|
| It warms my heart to see the basic mechanism in such a compact
| package, without libraries upon libraries and machinations to
| make things work. This is probably perfect for 90% or so use
| cases where react or similar FE frameworks are used at the
| moment.
|
| We later used to joke that we used Ajax before Ajax was a thing.
| LispSporks22 wrote:
| This brings back memories. We did the same thing with a giant
| Fortran 77 app turned CGI app. It was my first job, fun times.
| smrtinsert wrote:
| I think I posted it before, but I had SPA using Spring Webflow
| running in dom nodes (no iframes required) with animation event
| handling, csrf, all back around 2006 or so. The calling html
| was also pure save for a jQuery include at the top and my app
| include. The backend used JSP. No back button issues, no client
| or server state (I used a db instead of some options webflow
| gives you), it was a dream. Completely lost on the company I
| worked for at the time. I was up and running with a new user
| flow, in half a day or so. Static blocks suddenly would "do
| stuff" from the perspective of the business team in about half
| a day.
|
| This is the problem with technology. When it works well and
| really solves the problem, it is _invisible_. No one gets
| promoted for invisible.
| atum47 wrote:
| I'll take a deeper look in the code later, but it seems useful.
|
| If been using the window location hash to do some simple
| navigation on my SPA, but i use JS. (Just hide all sections and
| shows the one that matches the hash i.e.: #main
| Kalabasa wrote:
| > hide all sections and shows the one that matches the hash
|
| Oh there is a good hack you can do here! I've been meaning to
| write a blog post about this exact thing!
|
| See CSS `:target` selector section {
| display: none; } section:target { display:
| block; }
| franky47 wrote:
| If anyone is wondering, `htmy` is available on NPM, and `htmx`
| there is not what you think.
| andrewmcwatters wrote:
| Except using a URL fragment refers to a "resource that is
| subordinate to another, primary resource" not a destination. They
| point out the URL abuse, so why do it?
|
| Slot is also a part of the custom elements standard, but they say
| no custom elements.
|
| Why use only web standards and then use them incorrectly?
| chuckadams wrote:
| > Why use only web standards and then use them incorrectly?
|
| Because it's a clever hack, not a standards proposal. Lighten
| up, Francis.
| ulrischa wrote:
| Me so: What? I looked at the code and it is really hacky. But so
| great
| fractaledmind wrote:
| I cannot believe how simple and elegant this is. Using an iframe
| as a request/response proxy to enable targeted replacement is
| just
| yellowapple wrote:
| One downside of this approach is that it fills my browser history
| with a bunch of extra entries, which ain't ideal (especially for
| my Back button). I'd guess that's probably fixable as an htmz
| "extension"?
|
| That aside, I love the concept.
| lyxsus wrote:
| This is incredible. I really want it to take off.
| chuckadams wrote:
| It's not my style, and I'll stick with Vue SPAs thanks, but
| still... damn this is _elegant_.
| germandiago wrote:
| How it compares to htmx?
| mixmastamyk wrote:
| It's a subset.
| lelanthran wrote:
| Jesus Christ, this is all at once simple, powerful and useful.
|
| So little code, achieving so much!!!
| woah wrote:
| Waiting for htmz on rails, the 100k loc batteries included htmz
| framework to implement full featured UX patterns and make
| development delightful
| sesm wrote:
| 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)
| _ix wrote:
| This looks neat! I've never really been in to web development,
| but I'm curious... is it possible to create a standalone .html
| file for a browser-delivered app? Like, not just PWA or SPA,
| but... a single HTML App?
|
| If I had modest amount of data in JSON baked into html, what's
| the barrier to something interesting, say... implementing a
| minimal spreadsheet or maybe just a sortable/filterable table?
| SushiHippie wrote:
| > This looks neat! I've never really been in to web
| development, but I'm curious... is it possible to create a
| standalone .html file for a browser-delivered app? Like, not
| just PWA or SPA, but... a single HTML App?
|
| Yes, you can include your JavaScript and CSS directly inside
| the <script> [0] and <style> [1] tags, so you don't need to
| include any other file. Images like PNG, JPEG, ... can be
| either embedded with a base64 data URL [2] or an SVG with the
| SVG tag [3].
|
| > what's the barrier to something interesting, say...
| implementing a minimal spreadsheet or maybe just a
| sortable/filterable table?
|
| Well, you could go the easy route and use an already existing
| JavaScript library for this. Libraries are normally included
| via a URL, but you can just copy the contents of this library
| into the script tag as mentioned above.
|
| Otherwise, I think it's manageable to do develop it yourself
| (sortable/filterable tables) much knowledge, but frontend
| development can be a PITA very fast
|
| [0] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/sc...
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/st...
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Basics_of_...
|
| [3] https://developer.mozilla.org/en-
| US/docs/Web/SVG/Element/svg
| eproxus wrote:
| That's how TiddlyWiki works for example:
| https://classic.tiddlywiki.com/
| sunshinerag wrote:
| Hi,
|
| No babel plugin? Npm module... sheesh /s
| jallasprit wrote:
| It's quite good. I noticed that my back button had to be
| repeatedly pressed to go back to write this comment, after
| interacting with the examples a few times. I'm sure that's simple
| enough to fix.
| d0utone wrote:
| Refreshed 10 times to see the neat animation on top!
| d0utone wrote:
| Refreshed 10 times to see the neat animation on top again!
| aitternh wrote:
| fdnl.kakjd
| pier25 wrote:
| 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.
| mariusseufzer wrote:
| 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!
| interstice wrote:
| Also NZ, haven't tested but 200-400ms is standard here and
| west coast US is fine. East coast or Europe is noticeably bad
| trws wrote:
| 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.
| flaburgan wrote:
| But would the response be cached in the browser after the first
| call?
| klabb3 wrote:
| Yeah. I like the simplicity of htmx etc but network round trips
| are simply not suitable for a lot of interactions (at least if
| we're talking about _web apps_ ). For a barebones approach I'd
| prefer tabs etc to be low-JS on top of a _functional_ plain
| html page.
| _heimdall wrote:
| Personally I've landed on the balance of leaving rendering
| wherever the state lives.
|
| In the tabs example, my question is always how dynamic and
| complex the tabs are. For fairly simple tabs its pretty clean
| to server render the HTML for all tabs and use a basic
| client-side script to handle navigation (ideally its synced
| in the URL as well).
|
| For more complex tabs, or tabs heavily dependent on dynamic
| state, I find that its much easier to maintain long term if
| the rendering happens server-side. I personally have enjoyed
| HTMX for this to swap out an island of HTML, but a full page
| reload has worked for decades now.
|
| In my experience the worst solution is shipping the complex
| state _and_ the complex rendering logic to the browser. From
| performance to bug reproducibility, it has always cause me
| more pain that the DX original dev time are worth.
| withinboredom wrote:
| Totally disagree as a regular user of 2g internet on a phone.
| If you are downloading a 1mb bundle to show me your home page,
| I'm going to give up within 30s or go elsewhere. I'm more than
| happy to put up with laggy feedback.
|
| That being said, usually people writing downloads using fetch
| will implement a promise-based timeout on top of the network
| timeout, which causes all kinds of issues on 2g internet. One
| of my favorite side-effects are implementations that "retry
| after 2s" that don't actually cancel the in-flight request,
| causing my entire bandwidth to be hogged up with dozens of
| these requests "retrying" when the initial request eventually
| returned successfully. Javascript developers are
| unintentionally evil to non-5g internet.
| mhd wrote:
| I don't think every solution in the webdev space is supposed to
| be a one size fits all panacea. Especially this, which seems
| more like an incentive to think about structuring webapps.
|
| Sometimes it's interesting to see how far you can go without
| going the "let's download the web in a JS blob" way.
|
| One of these days, I'm going to see whether I can still build
| something reasonably modern with Seaside, the continuation-
| based framework from the olden days, where basically the whole
| UI state is stored in the server-side session and everything is
| a request. Worked quite alright, way back when not everything
| had a local CDN and the internet tubes were a bit narrower.
| eddd-ddde wrote:
| > Moving the data to the edge is much harder.
|
| Which means its gonna be the same thing if you try to render on
| the client, since you still need a round trip for data...
| intrasight wrote:
| 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.
| lelandfe wrote:
| <base target=htmz> <iframe hidden name=htmz onload="..
|
| I'm somewhat frightened to ask if there's some special voodoo
| need for leaving off the quotes on htmz...
| wild_egg wrote:
| Quotes are completely optional on attribute values in HTML5 if
| the value doesn't have certain characters like spaces which
| will require quoting
|
| I've found this article a handy reference on all the stuff it's
| safe to leave out
|
| https://meiert.com/en/blog/optional-html/
| Kalabasa wrote:
| Nah it's a stylistic thing. It's so that you can see the
| `=htmz>` logo in code if you order the target attribute last :D
| hiccuphippo wrote:
| I think you can use null instead of ':not(*)' in the query
| selector, if only to make it a bit shorter and maybe a bit
| faster.
| Kalabasa wrote:
| Nice, it works! I was a bit scared here because the
| querySelector() MDN docs say
|
| > A string containing one or more selectors to match. This
| string must be a valid CSS selector string; if it isn't, a
| SyntaxError exception is thrown.
|
| I'll test it out. If this works good, we shave off 5 bytes
| towards a 176-byte snippet!
| begueradj wrote:
| wow ! Useful interactions in plain HTML !
| agp2572 wrote:
| This is very similar to how Hotwire does replacing of HTML
| generated on server side in Ruby on Rails.
| tommica wrote:
| Can it trigger JS returned from the proxy? Something like
| <script>alert(123);</script>
| h43z wrote:
| Here a version that works for cross origin requests.
| <iframe hidden name=xhtmz onload="onmessage=x=>document.querySele
| ctor(x.data.target).innerHTML=x.data.content"></iframe>
|
| but website you are requesting has to embed the below script tag.
| <u id=t>just some other text</u> <script>
| parent.postMessage({ target:location.hash,
| content:b.outerHTML },'*') </script>
|
| You would still set the DOM destination on the main page.
| <a href="https://xorigin.com#view" target=xhtmz>dog</a>
| <div id=view></div>
| chatmasta wrote:
| Careful with that snippet, targetOrigin of * is dangerous. I
| could embed your iframed content on my own site and then you'd
| happily send me the entire HTML inside the iframe.
| cmgriffing wrote:
| I think the demo section needs work.
|
| Clicking a "tab" to change the example code to Greeting, or
| anything else adds a history event but doesn't update the url.
|
| I probably would have done the exact opposite in both aspects.
| Use replace to prevent extra navigation entries, but still update
| the url for bookmarking etc.
|
| For something that claims to "just be html", it seems to be
| breaking some fundamental rules of the web/UX. Whether it's a
| simple mistake or not and easy to fix, it does not inspire
| confidence in the framework.
| phinnaeus wrote:
| So that's why my back button didn't work the first time when I
| tried to return to HN...
| h43z wrote:
| Why the "||:not(*)" in the iframe onload handler of htmz and not
| just "null"?
| socketcluster wrote:
| Interesting. I wrote a similar plain HTML/WebComponent-based
| front end for my new no-code/low-code serverless platform
| https://saasufy.com/
|
| It lets you build just about any data-driven application using
| only a handful of declarative generic HTML components:
| https://github.com/Saasufy/saasufy-components?tab=readme-ov-...
|
| I built a chat app with both group chat and private chat (with
| access control) using only plain HTML; only ~250 lines of HTML
| markup for the entire thing, no front end or back end code was
| used: https://github.com/Saasufy/chat-app/blob/main/index.html
|
| You can use it here - All hosted on GitHub pages:
| https://saasufy.github.io/chat-app/
|
| It would be great to add support for other front end tech like
| this. I kind of like HTMX (especially as it's declarative). This
| HTMZ looks interesting. I'd like something with a big community
| and more components to handle more advanced cases (e.g. higher
| level components like calendars).
| torgoguys wrote:
| >I built a chat app with both group chat and private chat (with
| access control) using only plain HTML; only ~250 lines of HTML
| markup for the entire thing: https://github.com/Saasufy/chat-
| app/blob/main/index.html
|
| I _think_ I know what you mean, but we clearly have different
| definitions of "plain HTML." Mine wouldn't involve 9
| javascript files. :-D
|
| Either way, I'm interested and will check out what you made!
| gardenhedge wrote:
| Better than HTMX but it's a JS framework/tool at the end of the
| day
| buremba wrote:
| I wonder how feasible it is to create htmz / htmx -like
| lightweight library with the support for React/Vue/Stelve using
| web components. I agree that 90% of the use-cases you don't need
| React but for the last 10%, most of us are stuck with these
| bloated frameworks. Astro has a similar idea but it's working as
| a full framework instead of being a library. Considering the
| limitations with Astro, I guess the biggest bottleneck is state
| management.
___________________________________________________________________
(page generated 2024-02-19 23:00 UTC)