261–270 of 326 posts
Earlier quoted context omitted.
He seems like a reasonable fellow, and I've never seen him bash anybody, even people openly hostile to his library.
I don't know the guy but every htmx thread is filled with js bashing. It's like their main selling point. This technology is not great for complex GUI. You can downvote even more now.
I may have missed it in the video, but where exactly do they store all the "client-side" state? Postgres? Redis? Sessions?
Earlier quoted context omitted.
Github does? Maybe that's the reason why I often get the error message: "page took too long to render" after ten seconds of waiting. example: https://github.com/pannous/hieros/wiki/%F0%93%83%80 this is admittedly a complicated markdown file, however it often fails on much simpler files.
that's a good reason to invest in self hosting! https://git.jeskin.net/hiero-wiki/file/%F0%93%83%80.md.html
Earlier quoted context omitted.
> There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rendered component from the server. I think what you're describing is a form of preloading content but it's not limited to React. For example: The baseline is: You click a link, a 100ms round trip happens and…
I actually have a module that I built ti loads pages using such an approach (prefetch). In my take, I refined Pre-fetching to be triggered a few different ways. You can fetch on hover, proximity (ie: pointer is x distance from href), intersection or by programmatic preload (ie: informing the module to load certain pages). Similar to Turbo, every page is fetched over the wire and cached so a request in only ever fire…
Earlier quoted context omitted.
> as you reach a more “app like” experience with multiple layers of state control on the front end you need to reach for a front end JS framework I think that if you fully embrace HTMX's model, you can go far further than anticipated without a JS framework. Do you really need to be managing state on the client? Is it really faster to communicate via JSON, or protobuf, whatever, rather than atomic data and returning j…
The slippery slope that scares me (as a React developer) about htmx (or Hotwire.dev, in particular is the one I was looking at), is that you start making the assumption that the client's internet is fast. There was demo that showed it normally takes ~100ms to click a mouse, and if you attach to the on-mouse-down, then by the time the mouse has been released (100ms later), you can have already fetched an updated rende…
htmx doesn't aim to replace _all_ interactions with a roundtrip; in fact the author is developing hyperscript (https://hyperscript.org/) for all the little things happening purely client side.
But in any case even an SPA does round trips to get data stored on the server. The question becomes: is it better to make a backend spout json and then translate it, or make the backend spout HTML directly usable ?
I'm convinced 90% of the stuff we build out there should be built this way. It's so much easier and there's tht nice feeling about not being standing on tons and tons of overengineered tech. The last 10% on which I'd use react or similar are offline first apps or things such as figma, etc.
People forget that React can be used for just the complex components that require it. Your entire page need not be a React app just because you use it for one component. To me it's bonkers that all web sites seem to be moving towards SPA when they don't benefit from it at all and require so much frontend work when a little bit of simple HTML and Javascript could do most of the work. It feels like the whole industry i…
React has a self perpetuating marketing machine. From boot camp courses to YouTube how-tos and frequency plof appearance in job description requirements, people end up hiring React developers who want to build the sites in React.
Earlier quoted context omitted.
I actually have a module that I built ti loads pages using such an approach (prefetch). In my take, I refined Pre-fetching to be triggered a few different ways. You can fetch on hover, proximity (ie: pointer is x distance from href), intersection or by programmatic preload (ie: informing the module to load certain pages). Similar to Turbo, every page is fetched over the wire and cached so a request in only ever fire…
Sounds really good, do you have that code published somewhere? Any plans to get it merged into the official libs?
I developed it to scratch an itch I was having with alternatives (like Turbo) that despite being great are leveraging a class based design pattern (which I don't really like) and others which are similar were either doing too much or too little. Turbo (for example) fell short in the areas pertaining to prefetch capabilities and this is the one thing I really felt needed to be explored. The cool thing with SPX which I was able to achieve was the prefetching aspect and I was surprised no-one had ever really tried it or if they did the architecture around it seemed to be lacking or just conflicting to some degree.
A visitors intent is typically predictable (to an extent) and as such executing fetches over the wire and from here storing the response DOM string in a boring old object with UUID references is rather powerful. SPX does this really efficiently and fragment swaps are a really fast operation. Proximity prefetches are super cool but also equally as powerful are the intersection prefetches that can be used. If you are leveraging hover prefetches you can control the threshold (ie: prefetch triggers only after x time) and in situations where a prefetch is in transit the module is smart enough to reason with the queue and prioritise the most important request, abort any others allowing a visit to proceed un-interruped or blocking.
In addition to prefetching, the module provides various other helpful methods, event listeners and general utilities for interfacing with store. All functionality can be controlled via attribute annotation with extendability for doing things like hydrating a page with newer version that requires server side logic and from here executing targeted replacements of certain nodes that need changing.
Documentation is very much unfinished (I am still working on that aspect) the link in readme will send you to WIP docs but if you feel adventurous, hopefully it will be enough. The project is well typed, rather small (8kb gzip) and it is easy enough to navigate around in terms of exploring the source and how everything works.
Apologise for this novel. I suppose I get a little excited talking about the project.
I'm just so burnt out with new things. How do I combat such burnout? I really don't care about 'Htmx', I think barely any apps need much beyond what was available in ~2006 in terms of web tech. I just feel tired knowing that moving from React to Htmx is an option. Yet another option which will very possibly bring zero commercial value (although it might be a nicer dev experience I guess) to any project I ever work on…
I was hesitant to switch to Hooks, or Context. I only studied them when I was preparing for a new job and interviews for it.
I still feel queasy when I encounter obscure Typescript features (e.g. Omit/Pick, Generic Type Templates ) used in a codebase. Frontend simply does not need this much complexity....But I just google and find out. I don't personally go out of my way to bring new features into my codebases. Perhaps, only time they become unavoidable is when you're interfacing with a library or building a library to be interfaced.
I have done seriously complex computer vision stuff, 3D game development, embedded electronics. I have seen complex code where it had to be. People make frontend development more complicated than it needs to be most of the time. They just end up plastering everything with newest/coolest tech.