Getting Svelte

As I prepare Slowpoke for general availability, I've decided to make an architectural shift in my front-end framework and move to Svelte.  If you've been following along with my architectural decisions, I originally used Alpine.js for client-side work, then migrated to htmx and _hyperscript for their simplicity.

I'm still a fan of all three, but I have (ostensible) logical reasons for switching.  I moved to htmx and _hyperscript to help tamp down on some of the state management that Alpine employs, which bloated my code more than I'd hoped and, as a result, made it a bit harder to maintain.  

This succeeded to a reasonable extent, but there were two glaring problems with my change of framework - 1) Astro (my main server-side framework) is built to communicate with other JavaScript-based tools and return JSON during API calls.  htmx prefers to handle HTML snippets directly, so there were a few oddities in the API structure. 2) The documentation for htmx and (especially) _hyperscript is sparser than for other front-end frameworks.  The agents we rely on do much better when they've either been trained on extensive documentation for given systems or, at least, have access to that extensive documentation for reference.

Svelte helps mitigate both of those problems.  It has 1st class support in Astro, and its documentation across the web is far more extensive than htmx or _hyperscript.  Plus, I've always liked Svelte.

If backed into a corner, I would've been happy with my previous decisions, since there is no perfect selection for a stack (though software engineers often convince ourselves that the next thing we rewrite our app in will smooth all of the edges), but if I can better define the intersection of commodity tool vs. ease-of-use that works for me before everything gets ossified, the longer I can run this experiment as a solo developer/solopreneur.

Until next time, my human and robot friends.

Comments

Popular Posts