4 ms·

I (a novice) have been toying with web apps for a little bit now with Axum, Tera/Askama, and HTMX. I'm doing something very similar. I find that it works well f

by mlsu 2y ago

I (a novice) have been toying with web apps for a little bit now with Axum, Tera/Askama, and HTMX. I'm doing something very similar. I find that it works well for my simple apps but then complexity gets tough when I start to have a lot of template logic. This is when I realize that frontend web dev is actually full of interesting complexity... Obviously managing complexity in templates is something I'm sure people solved years and years ago, but of course now with 99% of frontend resources (blog posting, video content, courses, etc) being SPA focused, resources on doing it "the old school way" are scant. Do you know of any resources for designing web-apps of intermediate complexity with SSR templates? Or even just good resources from the HTMX + SSR camp, aside from the HTMX fellas?

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 ago
  i 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.
merely-unlikely 2y ago
Recently I've also been using Axum and HTMX but instead of writing templates I've been using Maud to write the dynamic bits inside the handlers themselves. Then I just serve a static .html file containing everything that can be static with HTMX requests to fetch the rest. The downside is Maud isn't proper HTML but the benefit is I can use normal Rust to format my variables, etc into whatever string format I need rather than deal with a constrained templating language. It feels like writing an API that happens to serve HTML instead of JSON. I debate using Askama to avoid the extra requests but there's something nice about just serving static HTML files.

by mlsu 2y ago

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 ago
i 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.

merely-unlikely 2y ago

Recently I've also been using Axum and HTMX but instead of writing templates I've been using Maud to write the dynamic bits inside the handlers themselves. Then I just serve a static .html file containing everything that can be static with HTMX requests to fetch the rest. The downside is Maud isn't proper HTML but the benefit is I can use normal Rust to format my variables, etc into whatever string format I need rather than deal with a constrained templating language. It feels like writing an API that happens to serve HTML instead of JSON. I debate using Askama to avoid the extra requests but there's something nice about just serving static HTML files.