> htmx supports the hx-confirm attribute to provide a simple mechanism for confirming a user action. This uses the default confirm() function in javascript which, while trusty, may not be consistent with your applications UX....In this example we will see how to use sweetalert2 to implement a custom confirmation dialog.
It's implementing a custom confirmation dialog. Customized, non-default UI/UX usually means custom-written code in any framework I'm aware of. Maybe React has implemented magical customizations since the last time I checked.
React doesn’t require you to both abandon the principles of the library and write an inline string of code to run something slightly custom when you click a button.
htmx doesn't require you to write inline code in strings either, it's just a convenient compact way to do it in a demo. Also, it's not 'abandoning' any 'principles' because the 'principle' is to leverage small bits of JavaScript in a high-impact way. Eg, https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
So where else will you put this code? A separate file? Multiple files? Maybe specific files for specific bits of UI? Maybe then you’ll need to handle bundling, transpiling, minification? Oops, we’re back to an evil pile of JS code that needs to be built.
Not really? HTTP/2 and ES Modules exist now, lol. And so does brotli compression done by my CDN. Bundling/transpiling/minification are basically obsolete technologies.
> htmx supports the hx-confirm attribute to provide a simple mechanism for confirming a user action. This uses the default confirm() function in javascript which, while trusty, may not be consistent with your applications UX....In this example we will see how to use sweetalert2 to implement a custom confirmation dialog.
It's implementing a custom confirmation dialog. Customized, non-default UI/UX usually means custom-written code in any framework I'm aware of. Maybe React has implemented magical customizations since the last time I checked.