r/javascript • u/der_gopher • 6d ago
How to drive your frontend from the backend
https://packagemain.tech/p/golang-datastar2
u/IAmSteven 4d ago
I don't know why all the comments are negative. No one is saying you have to build this way. It's an interesting way to go about building something. Sometimes it's nice to just see something someone built just for the fun of it.
1
1
u/Merry-Lane 6d ago
This is horribly inefficient.
Why bother with a go backend?
You should have driven your frontend straight from the database.
Pretty sure it’d be easier to do with good ol’ PostgreSQL. And as a bonus, you could store the frontend’s templates directly in the db.
-3
u/dronmore 5d ago
I know that you wanted to be sarcastic, but your joke didn't land.
We do not give users direct access to the database for many reason. One that it is important here is that generating html with Postgres is not very convenient, and at the end of the day you need to generate html to display data in a browser. You can either convert the data to html on the backend (single step, easy), or convert it to JSON on the backend, and later convert the JSON to html on the frontend (2 steps, also easy).
The first approach is faster than the second one. I've seen a big online shop using this approach, and responses to filtering, selecting and alike were instant. When you say that this approach is "horribly inefficient" you are factually wrong, or you talk about a metric that is not obvious to me.
3
u/Merry-Lane 5d ago edited 5d ago
If you understood I was totally sarcastic, why do you need to correct me?
Also, we dont need to give users direct access to the database (for security reasons mostly not because of efficiency). We just gotta serve them after auth as long as they have the permission to access the ressources.
Generating html with Postgres isn’t that inconvenient, especially compared to OP’s example. Anything he’ll build will either be extremely simplistic UI/UX/feature-wise, either at the cost of an utterly slow development speed.
Especially when you consider the fact that OP wanted to rely heavily on websockets and stuff like that. You would do the same with a database : you’d just publish stuff somewhere automatically, templates included with the topics/queues included to follow up (for instance after a click) and the queues/topics would serve as cache to lower the load on the db.
Anyway, I was sarcastic. Yet I still believe his example is barely less insane/niche/useless than db-first.
2
-2
u/dronmore 5d ago
In terms of feature-wise there's not that much of a difference between generating html on the frontend and on the backend. The only meaningful difference is that if you do it on the frontend, you can have an additional state that is local to the frontend. If you do it on the backend, you need to keep your session state on the backend. Other than that the difference boils down to the format of your api responses. In one case the api responds with
{"content":"data"}in the other it responds with<span class="content">data</span>. Both approaches are comparable feature-wise. I wouldn't call the backend one "extremely simplistic".2
u/Merry-Lane 5d ago
The biggest difference is the ecosystem and the language/framework/library paradigms.
jquery, for instance, was alright, but everything got complex and messy quickly. Which is why it almost disappeared within a decade.
OP’s 3 libraries/frameworks don’t have a good ecosystem. Anything built with them will either remain simplistic or at the cost of a slow development speed. Hell, you can’t even expect scaling up correctly by adding more devs to it.
•
u/cosmokn0t 17h ago
jquery wasn’t alright, it was a horrible tool that we had to use because the browsers are also horrible tools.
1
0
u/Ronin-s_Spirit 5d ago
You could have JS devs do frontend and backend at the same time and be fine - makes development simpler since everything looks the same, code would have a 1:1 relationship anywhere you look. You could also build you backend in Seed7 if there's a reason for wanting more performant, systems languages - like not having a DB (main bottleneck) and instead just doing a lot computation.
If you're explaining a framework for slowly loading responsive parts of the page, I don't see why you would stray from something like preact. You're not doing anything new...
8
u/No_Neighborhood_1975 6d ago
> that we can develop a fully interactive web application driven by Go backend
I’m sure there’s some narrow use cases for this but it sounds like pure hell to develop and maintain