I think I finally understand the core of my front end vs back end frustrations.
It’s the html template. The “who defines the html” and where does that live.
If you look at any JS front end framework, they want you to use JS server side so that it can inform the server how the template should be hydrated. This is done by literally compiling the very same front end code but via the back end with some hooks for data / resource reconciliation where needed.
Overall I think most back end systems have largely rejected this idea because we don’t want to deal with JS server side. I agree, running JS server side to solve this problem feels like a work around and not a solution.
Or at least not at run time.
I’m gonna write this essay as my argument to why we should try to allow the front end tell the back end how to hydrate its initial HTML response.
Lets try to create context in the context of Phoenix.
Where does it best serve to define the HTML template?
To answer this question we need to break down the concerns for the front end vs the back end.
When I say the front vs back I mean JS vs Elixir/Phoenix.
It all starts with the initial HTTP request.
The back end needs to route the request to their controller because the controller is who knows what data is required for what template to hydrate so that it can return the responding HTML/JSON.
This maybe an over simplification but it would seem this is the easiest way to rationalize the extent of how much the back end cares about the HTML template which honestly feels very minimal and not that extensive.
The hand off to the browser.
This is where most of our conflicts happen as web developers.
If we don’t have something in place to create that initial HTML than we will have to load JS that in turn makes more requests to hydrate it’s state. This is why “who owns the HTML template” is the core issue.
We have created many different attempts to solve this problem. I’m not here to argue their validity and I don’t want to conflate this post with their solutions as it becomes a “this vs that” conversation.
I will acknowledge all these solutions so that you don’t feel compelled to:
- LiveView
- Hologram
- Ash
- LiveSvelte
- LiveVue
- LiveState
- Inertia JS
I feel like there are even more I’m likely missing.
This proves one main thing:
The core issue is not a well solved problem.
Instead hashing out who does that best, I want to try to present a conceptual idea and see if I or others can implement it.
Why did all these JS frameworks want to keep the HTML template in their front end?
This is very much a rhetorical question but I wanted to highlight that it’s valid in that the server could be limited to just caring about returning HTML. The front end cares about interacting with HTML in a much more intimate way and its because of this strong coupling JS needs to own template.
The template does more to aid JS than it does to aid any agnostic server side langs.
This is the core of my conceptual solution.
If this is true than we need something to help inform the back end how to honor and respect the contract and that there even is a contract with the front end.
The procedure
So that above was really just about the initial context. What does that look like in theory?
- I make a front end app in js or even just static files. It could be any front end app.
- At compile I produce a “contract” that informs the back end what I “the front end” wants for the initial HTML response
- This contract is consumed by the back end which is used to inform the back end how it maps its resources to data/tokens that should be hydrated in a provided template which was provided by the contract.
The point of this is that we give up control of the template on the back end and instead build a tool that translates the front end template into something the back end can consume / reconcile and do something with.
If we can harden this pattern its even agnostic to elixir and could help solve this problem in other langs.
The main point is we need a standard to inform the back end what the front end is expecting.
I wrote this in this forum in hopes that we can lead this solution via phoenix and elixir as I think its best positioned to solve this issue.
