4 ms·
My longest running web app[1] is also my most complex. Although I do use HTMX, I use it very sparingly.[2] 90%+ of what you need for a web app that you're buil
by bsnnkv 2y ago
My longest running web app[1] is also my most complex. Although I do use HTMX, I use it very sparingly.[2]
90%+ of what you need for a web app that you're building as a one-person show can be handled by storing state in the URL - people these days can be quick to forget that this is how large and complex web apps like GitHub have run for many, many years.
With regards to complexity in templates, I find that you can cut down on a lot of that complexity if you enforce type constraints in your templating engine's context object.
Getting in a habit of doing this early gets you thinking about ways to shift things that require conditional logic to the pre-templating stage, and more often than not it leads you to breaking down bigger templates into smaller partials and using them to compose different template variations for different views. I like this and it makes a lot of sense to me, but I'm not sure how it would feel to people who have only ever written JS SPA web apps.
[1]: https://notado.app https://notado.app
[2]: Example of the only place I use HTMX in Notado (to show search results as you type): https://www.youtube.com/watch?v=KMxmf132-8k https://www.youtube.com/watch?v=KMxmf132-8k
- em-bee 2y agoi think your approach is orthogonal to SPA. first of all, it is my understanding that react in particular favors small templates or partials. and second, with the traditional server side frameworks i have always used full page templates, and i tend to write SPA the same way. i would only break up a template if it contains selfcontained sections that could potentially be used in different places. my point is that this is not because all i ever did was SPA, but because i did things like that already for years before that.