man, I am not a fan of OO javascript

hyperscript is probably always going to be a simple reactive programming language, but I am sorely tempted to add a normal class system just out of spite

As someone who built my own ORM, dependency injection framework, and message queueing system out of spite, I know where you're coming from, and I salute you. The trouble with most "out of the box" standard packages is that they usually suck -- please use XML as my exhibit A.

However.

For development on the browser, I would rather ask "what does the platform already do for me" instead of piling on a whole bunch of custom code. That's what makes HTMX so interesting. It's less about the coding style (functional vs OO) and more about which APIs can we reasonably depend on being there (with bonus points for "progressive enhancement" to supercharge people with modern browsers).

(For example) I love Typescript for this, and have learned to put up with other buildchain-y tools. Some simple compile-time magic could (for example) make it simple to publish two versions of the library -- a tightly optimized one that runs on "modern" browsers, and another larger one with IE11 compatability.

@User What challenge would a class system solve?

@User thank you; it was useful to learn

@User the challange of me being disgusted at the JS OO model

but, practially, nothing

:/

There are so many transpilers out there...TypeScript, ReScript, Elm, Haxe

@gorgeous-ghost-95789 When compiling with Google Closure Compiler you can tell it different js versions as a target and it will add polyfills etc to support older browsers

Hey @nice-jordan-5031 — yeah, I think raw Typescript has similar options. I always targeted ES5, which added a bunch of polyfills for new-ish features that I wanted to use. I know it’s possible to ramp up the target version, too. @mysterious-toddler-20573 has mentioned that he doesn’t want to deal with a build system for now, which is reasonable. I think I’m just planting seeds for the joyous day when there are no more fires, race riots, and we can finally retire IE11.

Well, I’m using gcc for minification, this happens anyway 🙂

Yeah. I looked in to gcc. My impression was that it’s the most work to set up, but it does a really deep inspection of the code, so it (probably) gets the best results.

It needs setup only in case when you want to use its type system and type verification, but when used as a minifier it’s the same as other minifiers 🙂

fixing a bug in htmx history snapshotting and came across this interesting article: https://www.igvita.com/2016/01/12/the-average-page-is-a-myth/

as of 2016, the average HTML page size was actually decreasing

kinda interesting.

I ended up using about 350k worth of HTML as my perf test for a snapshot, after looking at the monstrosity at cnn.com and pulling out the body content, which came in around 300k.

browsers are fast: I was able to clone, inspect the content for a class, and get the innerHTML in < 12ms on my machine

I try to keep this in mind when working on htmx: native browser functions are really, really fast compared with javascript. The dumb, brute force approach with native functions is usually much faster than a complicated javascript approach.

Agreed, let the browser do what it's good at 👍

Moreover, the code is smaller and easier to maintain; letting you focus on higher-value items. Only optimize when it's important to do so.

@User If there's any reason to drop IE11 to make the code/process simpler or more functional, I'd do it in a heart beat. On the other hand, no need to add dependencies just to add dependencies. Making hyperscript require newer browsers seems like a great compromise.

Much of this proxy library is based on the idea that you'll have a data structure client side, need to observe it to synchronize multiple views (MVC). I was just assuming I'd implement my HTML rendering server side, and that's why I'm focused on htmx. This isn't a perfect fit for everything, however, I've got data intensive applications with complex screen drawing mechanics (and probably SVG). However, seeing the Alpine/View tutorials does make me wonder if I'm discounting reactivity too much; having a round trip to a server to update a bunch of views seems like it'd be a potential problem. Am I thinking about reactivity correctly? Is this just a 1-M problem, or do you run into 1-1 issues? When changing data client side via editing, you often want to have multiple components update, if they are server rendered, how would we do this? Just babbling. It's been a while since I did any UI work.

@mysterious-toddler-20573 On a light note; is it possible to include the hash of the library in the front page example?

I think reactivity is really cool -- for widgets and other things that live strictly on the client. That means that it's probably out of the domain on HTMX, which is helping to redefine MVC as a server-only feature. Need an amazing calendar widget? Great. Drop in a WebComponent, or something from Alpine (or Bootstrap) and leave HTMX out of it. Need to figure out routing or application state? Put that on the server and send updates via HTMX. I like the separation a lot because it simplifies each task and highlights the tools that are best for each job, instead of us putting that int HTMX too.

@User So, I'm having a challenge selling a colleague why you wouldn't just use one of the "standard" Vue/React baselines, like Ant.Design, and then setup our Julia backend using REST or GraphQL. When I see lots of projects written this way, I see quite a bit of work setting up the in-memory client side "model" so that the views could access it, and then work on how to synchronize the model. On the other hand, I just remember the time when I could just implement the screen with server-side HTML generation and not have to be bothered with that entire middle tier. I suppose it matters just how much control over the model you need from the server side, it seems silly to replicate a huge chunk of your application's model client side.... just to be able to show it. I wonder if Vue really is "progressive" in this way, that you could use it for your leaf nodes on a screen but not the general application as a whole; however, once you go that route, you kinda lose the entire tree shaking features, etc. On the other hand, I'm wondering if it could be inverted, use standard JS build process for the whole application, but for the components which have deep modeling server side, use HTMX for it's visualization. Probably I'm just rambling...