Earlier quoted context omitted.
According to the article we're commenting on, the programming model is not the sole reason for switching from React to Htmx. Look at the executive summary's bullet points. Four of them are related to performance (build time, time to interactive, data set size, and memory usage). Performance might not be the reason you personally use Htmx, but it's certainly put forward as an advantage in the article which we're comme…
Validating data on the client and not doing it again on the server will lead to security vulnerabilities. At the very least you will end up duplicating that validation code.
Moving from React to htmx
81–90 of 326 posts
Re: Moving from React to htmx
#82Some years ago, a bright guy created something called 7 GUIs. It’s a collection of seven problems that all UI systems must successfully implement, and it was intended to act as a guide for comparisons. Unfortunately I think the author has passed away, but it would be interesting to see it rekindled and used for baseline comparisons like these. https://eugenkiss.github.io/7guis/
Re: Moving from React to htmx
#83Re: Moving from React to htmx
#84Earlier quoted context omitted.
What security issues does server rendering solve? I resent that every website needs to be an SPA, but from a security perspective I’ve concluded that the clearer line in the sand that SPA application architectures creates is better than the security challenges that can result from server side rendering. Navigating the risks around the NPM supply chain is another story, but I suspect it will be solved by large / popul…
I think anywhere you introduce more complexity, more ways for things to interact, it's inherently less secure without the additional work checking for both the App + the API being secure on their own.
When your website is the actual complex application SPA makes very much sense and is actually less complex. And no you do not have to download all of it into a browser. Load parts replacing some inner html with the other and scripts on on need basis. Works like a charm. I am using couple of JS libs but no framework and there is no need to "build".
As for security - JS app talks to my own C++ backend using some JSON based RPC so I just have to validate the API only which is way less work as well.
Re: Moving from React to htmx
#85I'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…
Re: Moving from React to htmx
#86TLDR: - Took 2 months (21K LoC, mostly JavaScript) - No reduction in user experience - Reduced LoC by 67% (21,500 LoC to 7200 LoC) - They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS - Reduced JS dependencies by 96% (255 to 9) - Reduced web build time by 88% (40s to 5) - First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds) - Much larger data sets we…
> Much larger data sets were possible than react could handle I find this one difficult to believe. I'm not calling BS necessarily, but I doubt it applies in the general case. I have a Django app that's server-side rendered, the largest page is very large (~200kb of content ). Django on a low-tier VPS took about 500ms just to render that page. Django templates aren't faster than React. And Python isn't faster than JS…
Historically, server-rendered React has been painfully slow compared to Django (I’ve been doing SSR with React since 2014, using Django since 2006, experienced the pain first hand multiple times). Usually at least an order of magnitude slower. That said, I haven’t benchmarked in a while, perhaps the worst of it has since been addressed.
Re: Moving from React to htmx
#87I'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…
If you don't want to deep dive on htmx-as-a-tool due to burn out, I completely understand. But, at some point, it might make sense to read up on the philosophy behind it (hypermedia as an archiecture) because that is an area where it is different than most front end frameworks today.
I have a collection of essays here:
Re: Moving from React to htmx
#88I'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…
2006 tech in frontend = COBOL level stuff
Re: Moving from React to htmx
#89The hoops people will jump through to avoid learning HTML/CSS/JS. I say this as a Python/Django dev who resisted learning web tech for 20 years: It's time to just learn this stuff. You can slap on a mound of band-aids and watch the wound bleed forever. Or, you can go in, get three stitches, suffer a little pain, and let the healing process begin.
One of the bullet points was "They reduced their total JS dependencies by 96% (255 to 9)". That's an enormous support burden that simply vaporized.
Re: Moving from React to htmx
#90Htmx is great for developers who need client side interactivity, but would rather not write any js. If you don't mind writing a bit of js however, you can't go wrong with Preact. Same api as React, but at a fraction of react-dom's bundle size. It looks like the minified source is even smaller than htmx (which is already very minimal) [1][2]. They've also packaged Preact in such a way that you don't need to add a buil…
I was just picking technology for my new landing page and was looking into Preact first. I wanted basic SSR and things like that. Preact has a library called preact-cli for this. The last commit is from Aug 17. I ended up with SvelteKit. It just felt much more alive. I don't love learning a new technology just for a landing page, but that was kinda fun.