Okay I've now written enough Elixir+Phoenix to ship something modestly spiffy, and I'm reaching the point of framework fatigue, I think. In particular, the breaking point in Phoenix is the second you have to make a form that doesn't match the shape of your data model, things suddenly get pretty unpleasant.
Not unmanageable, just... enough to make me pine for Go again, and less frame/more work.
@danderson have you considered doing the transformation between form shape and database shape behind the API, rather than in the rendering/client layer?
There was at least one YouTube app transition while I was at Google where the big win was basically making the homepage load be a single denormalized API call for all the different content.
@evana Yeah, that's how you build stuff by default in Phoenix, there's no client-side validation. And it has a changeset abstraction for managing mutations to base objects and producing validation errors and such. It's just the transformation between multiple schemas that ends up ugly. No particular reason, you just lose access to the magic and need to do a bunch more typing.
Also a major lesson for Phoenix specifically is that it leans hard in the direction of letting you not write Javascript, so you get a bit of an htmx-style universe for client-side logic, and nothing else.
This means that when you do want to do anything in JS on the client (e.g. a form input that's just fancy enough to need a bit of JS lube), it's a jarring gear change.
Phoenix is also still more niche than others, which means those components you end up wanting... don't already exist. You can't just grab Tailwind UI, or DaisyUI or whatever and plug a ready made combo-box into your app. If you need those, you stop being an application programmer and become a front-end UI programmer.
None of these are fatal, of course, and if you want htmx-like client side that comes with automagic streaming state updates and client<>server coprocesses for state management, Phoenix is pretty amazing. And Elixir is a reasonably nice language to work in.
But, for my needs... I feel like I'm stuck between something as basic as htmx not being quite enough, the full SPA things like React/Vue being way too much, and Phoenix being very powerful in the ways that don't matter for my current project.
tbh I would probably do this almost entirely in Go with something very light like htmx+tailwind on the frontend, if it wasn't for forms. HTML form lifecycle is a bit of a tire fire to deal with, what with having to adapt between the browser and backend data models, do round-trips with validations, present the validations in the right places, and all that jazz. I've not found anything in Go that even comes near to doing that well, and I don't know how to make it nice myself.
But, if I could figure out a plan for dealing with form submissions... I think I could see myself trying to do this with Go. Single binary server, sqlc for database interaction, htmx for a tiny bit of client side fanciness, tailwindcss/daisyui for styling, maaaybe a teeny bit of vanillajs for further client enhancement...
I'd also be very curious to try and build what I've done in Phoenix so far, but in full on React or Vue, to get a feel for what this looks like in the full-on-SPA world. What I'm not sure of there is what to do about client vs. server state management, I can't tell if there's any known practice for that or if you're expected to bring your own from your existing experience (which I lack)
@danderson Big fan of tanstack query in vue and react for remote data management. State management pinia or zustand, but thats small when tanstack query does most of the work you would need state managers for.
@danderson I have been noodling around with https://github.com/a-h/templ a bit, as a potential answer to what seems like an inevitable Gordian knot at the heart of every so-called declarative framework.
So far it seems like a fair compromise between letting me program in a real language rather than some weird library API, while integrating decently with UI helper libraries.
I haven't done anything super crazy with it, but it hasn't made me hate my life yet.
@danderson stipulated, this is a much lower level than what you've been describing, but I find the Total Institution style always comes back to bite me in the ass, so for me at least that's a feature.
@creachadair Interestink. That would help with my not loving the stdlib template language for HTML things, and also does plug in gracefully to htmx and web components... Interesting! Thanks for the pointer!
@danderson yeah. That's what drew me to it as well—the stdlib template engine is ok for very basic stuff, but pretty quickly gets overwhelmed and kind of awful to use. I set about trying to write more or less this, only to find it already written (and better than I'd have managed).
@creachadair It's interesting, as I dig further templ's template syntax and Phoenix's are very close to each other. Phoenix's uses elixir as the inner language and is much less constrained on control structures, being lisp-ish, but aside from that... It's nearly a 1:1 translation.
@danderson Yeah. My approach was going to be basically building a baby Lisp to compile down into Go, it's certainly not a new idea. I feel like the template forms fit pretty nicely into the existing code.
@creachadair fwiw, I feel like Elixir provides a decent idea of how to smuggle a lisp through to the masses with a more palatable syntax. If you need any inspirations :)
@creachadair Of course, coming back up for air a few hours later, I've been trying to learn how to make a treesitter-based major mode for emacs, so that I can haz full templ support 😂
Add comment