The HTML template is the core of all front end vs. back end problems

5 pointsposted 3 months ago
by fullstacking
(elixirforum.com)

11 Comments

mikece

3 months ago

"At compile I produce a “contract” that informs the back end what I “the front end” wants for the initial HTML response."

Wouldn't that be like a ViewModel in MVVM?

fullstacking

3 months ago

I dont know, maybe it instead is seen as a map of the model to native resources in that system and a language agnostic template with tokens that can be hydrated given they map to the model.

fullstacking

3 months ago

I almost look at this like its a model / template but the model is a map and the template is universal

fullstacking

3 months ago

maybe its more of a "how do we create a standard template" vs this is how I do this in x, y or z.

fullstacking

3 months ago

Ignore this post, I delete my message in the elixir forum. That community has too many trolls and I'm done with them.

pestatije

3 months ago

decades have been spent trying to couple front and back ends when in reality they should be as decoupled as possible

fullstacking

3 months ago

This frame of mind is what lead to this issue. How do you do that when they both have a concern for producing html. SSR is not fad, its a real issue. If SSR is a real issue than that means the server must produce the initial hydrated html. How do you do that if not with a shared template or duplicated template? Even JS front end still does not deal with this any different. You still have node compiling the front end code server side to address that very issue.

Maybe we need to acknowledge that you can't seperate them as they both exist with a need to produce HTML. But instead position the html closest to who it best serves and let them inform the other side. IE JS is most concerned with html as it interacts with it more where as the server only needs to really produce it once.

IMO your take is the worst take on this issue.

pestatije

3 months ago

take desktop apps...do you see any effort in the tooling world to generate UI from the back end? not in a hundred years...we got the SSR idea to solve the real issue of distribution, but all went south from there

fullstacking

3 months ago

Did you really just compare this to desktop apps? Stop playing games.

Ok I will bite. in the realm of desktops, what is the "backend"?....

But also lets assume you are talking about c/rust what ever code. Then you saying that because qt/gtk does not generate something for that code that is equivalent? This is such a reach. First The c code does not need to render a initial output before qt or gtk kicks in for starters. sounds like you just want to boil the ocean. F it, lets reinvent TCP everyone...

Also just gonna put this out there, what is your web agent if not a desktop app...

But really I can't even with this. I'm looking for sensible solutions to this real problem. I guess throwing your hands up and saying everything sucks is an option but I don't have time to think like that.

pestatije

3 months ago

yeah sorry to waste your time...i didnt RTFA in the first place, but im pretty lucid mixing distribution and rendering is a no-go

fullstacking

3 months ago

Your not wasting my time, I'm trying to do something about it. I'm just not gonna agree that what lead us to this issue in the first place in also the solution and no your comparison is not apples to apples.

Calling the server distribution is an over simplification of the issues. To this point we should only use the browser in the terminal, but even when its just text it still has to "format" it's content.

this the problem, who owns the "formats" for the content in a system where many sub systems needs to be aware of "formatting"

If the server didn't have to be aware of the html at all and it was only ever just raw data I would agree with your view.