Finally, electronic html

When I was a kid I printed some BASIC tutorials and would bring them to school and write my code on paper then type it up at home. I only ever made a few simple programs for my Cybiko. Totally forgot about that until seeing your comment.

When I was a kid in school and got bored I would write html on a paper notebook. It got tedious quickly and sorta made me adopt a haml like notation for brevity.

Around the same time I had a pocket pc that I would take to vacations. It had a limited mobile IE, but no code or raw text editor, and I didn’t know how to get one. So I would code in JS 1.5 using pocket Word, then as soon as I got back home from holidays I would use ActiveSync to retrieve the word docs to my pc, convert them to HTML, and then sync them back to my pocket pc for use in pocket IE.

Made so many fun apps this (clunky) way. I also completely forgot about this until I saw your comment, thanks for triggering this trip down memory lane and apologies for the massive OT.

I like this a lot (and am also a big fan of HTMX). I asked you in a different post, but can you compare/contrast this to HTMX?

While on the surface it might look like htmx, it really is quiet different.

Htmx is all about embracing hypermedia and its only goal is to enhance the shameful shortcomings of html. See also the hypermedia.systems book.

E-html seems to be more about how can I do client side rendering without pulling in something huge like react, vue or whatever thing you fancy.

Just my POV as a non web dev that is not affiliated with any of these projects.

Something huge like React or Vue? The linked ehtml[0] file seems to be 1.23 MB, that is considerably larger than React or Vue.

[0] https://github.com/Guseyn/EHTML/blob/77d14539d1a9b39785db6f3...

Yeah, because I am using highligher for code fragments in markdowns, will try to optimize it.

> E-html seems to be more about how can I do client side rendering without pulling in something huge like react, vue or whatever thing you fancy.

Wait isn’t this what htmx is about too？

Seriously what’s the fundamental difference between them?

Yes, you're right, thank you for such explanation.

Seems pretty neat. Really like the Unison app though it was a pretty fatal UX flaw of not following the notes being played. Still, impressive.

thank you!

I read that you don't want to collaborate but if you need help with accessibility, I can help with that. :P

>The beggest focus of this library is to offer the easiest way to perform AJAX operations just by using HTML.

Sounds like an impossible task using HTML alone.

I've seen similar attempts, what they do is allow you to mark the HTML with some markup syntax that gets automatically parsed by the JS lib and invoked into AJAX calls. So it's still powered by JS but you aren't technically writing anything but HTML markup.

But that's not what it says it's doing. It says it uses HTML alone.

Is this an alternative to htmx?

How does this library compare to Turbo/Stimulus?

Happy to see competition in the world of "minimal JS" frameworks. Have you done a comparison with Turbo/Stimulus from DHH and company?

I believe Turbo/Stimulus rely more on server rendering + their Turbo Drive is quite powerful, will try to catchup on turbolinks. I had implemented them previously, but it's quite difficult to make them smooth.

Blank page without scripts enabled by default or in a TUI browser. Seems these docs are just static content so I’m not sure why JavaScript is in the way of reading them.

JavaScript is integral to this. I suppose there is a need for a, "This is what the page is about if you don't have it turned on" bit.

This isn’t a demos page--they are just static docs where the only interactive part is some JS to make it quicker to copy/paste. Right now these docs aren’t accessible to many reading options or search indexers since there is nothing on the page.

True I suppose. But if the reader is a "I disable JavaScript" type of person, isn't this pretty far from something they'd be interested in? I will preface the following with an, "OK yea kind of a joke but you get the point" comment, but I mean you don't use QR codes as a marketing strategy for the Amish.

I don’t know I agree with this perspective. The internet is in many ways an unsafe space & surfing it with JavaScript in allowlist mode (e.g. blocking by default) should be in the bag of tricks users can use to mitigate some potential issues. One may also want to automate scraping these docs to put in another tool or in a new, independent search engine whose MVP isn’t including a whole JavaScript runtime (and can be trick to read from the source code if using a tool that generates docs from comments instead of a generic file so the output HTML is easier to consume).

Setting a good example & being a good steward of the net is something docs like these could/should provide; that is to say, the author could make the static parts static & offer a <noscript> with a brief description of the interactivity the user might be missing. The docs are likely coming from dog-fooding the library, but came at the cost of making static content maximally available & providing a noscript message.

It's not just static content. It's Markdowns loaded right into HTML.

The content is static. The fact that you’re loading it dynamically is immaterial and a bug, not a feature, at least at this scale. If you serialised the resultant DOM and shipped that minus the now-superfluous pieces (ehtml bundle, template, preloads), the result would be identical but it’d load significantly faster and more consistently for everyone. (I say “more consistently” in part for user agents that don’t support, or that disable, the scripting, but also for agents that do support it but it fails to load properly due to network conditions, which is way more common than most developers realise.)

For bonus marks, inline all the subresources (SVG, CSS and utils.js) and strip dead styles, and you can probably squeeze the entire thing into the 14KB TCP slow start window (compressed), so that it would have completely loaded for me in about 430ms at most (though it should have been closer to 200ms) instead of 1.7s, and with no reflow due to the logo not having been given dimensions.

Slow down pal. How am I supposed to have SSG and hydration and hook with such a simple setup!? I need my system to be webscale™, not maintainable with minimal moving parts.