3 ms·
The core thing is a lot of nice UX patterns are harder with server side rendering. Multi-page forms? Now you’re juggling around state. “Form has N rows”? Now th
by rtpg 3y ago
The core thing is a lot of nice UX patterns are harder with server side rendering. Multi-page forms? Now you’re juggling around state. “Form has N rows”? Now that’s a thing. “Form has N heterogenous rows” is another thing.
Then you get into things like how no server side rendering strategy has the equivalent to React “just write an inline helper function for this page”, so you need to create partials in files all over. And what if you’d like to statically verify that your templates have all the content in place? Proper typing? Who hasn’t had a page fall over because there was some missing context variable 3 layers deep.
The thing with the API based flow and client side rendering (with React at least) when you have it set up nicely is “add a list view with pagination and search with a modal to create a resource if needed, and some inline editing” can be done by opening a single file and getting there with 2 dozen lines. Server side rendering strategies in practice tend to buckle a bit if you try to be modular enough, and in many cases you need to open one file per checklist on your project. Code locality issues are real IMO
Disclaimer: I’ve done both, messing around with HTMX on a project and think it’s pretty cool. But it’s mainly because I don’t have all of the nice patterns from work projects that I’m tying this. If startup costs weren’t a thing I’d go with a client side system most days of the week.
- halfcat 3y agoI wouldn’t say we’ve hit the center of the bullseye quite yet, still experimenting with the exact patterns of organizing and structuring a project using this approach. But so far we’ve landed on using the django-components library [1] to build something akin to Vue’s single file components. HTML, CSS, JavaScript, and Python “business logic”, all in one file. That component is then used in the Django templates, or in other component’s HTML, and it all seems to work very React-like in terms of an organized structure of composable components. Combined with HTMX the traditional SSR challenges you mention seem fairly straightforward to handle. > what if you’d like to statically verify that your templates have all the content in place? Proper typing? Can you say more about this? Would this be using TypeScript in React to verify types, or something more involved? I’m trying to understand this and what the equivalent might be in this “dynamic SSR” scenario. [1] https://github.com/EmilStenstrom/django-components https://github.com/EmilStenstrom/django-components
- rtpg 3y agoYeah I'm talking mainly about React + Typescript as a combo. With more gnarly Django templates sometimes it's hard to even know what we are looking at in a template, whereas inside a React component I'm going to be a "jump to definition" away, not just for components (or template tags in the case of Django, I know PyCharm offers good jump to def there, including for stuff like Angluar!), but for variables and the like as well. I think django-components only has part of the story there, because even if that helps writing out your page, you're still looking at going to the other side of the frontend/backend wall to add, at the very least, an endpoint using that template. And if you're following this whole "hypertext API and data API as separate things", you'll need to also code handling of submitting any data, and routing involved. I'm not against this stuff entirely, because I think there's a bit of a Go-like niceness to how it's "at worst" boilerplate (that you can abstract over on a per-project basis). But if you have a comfortable, well designed API all that work spread over you templates and controllers might actually all just be in one place.
- BiteCode_dev 3y agoIt's absolutely ok to have alpine handle a big form, you don't have to never use js with htmx.