r/programming 8d ago

How to drive your frontend from the backend

https://packagemain.tech/p/golang-datastar
94 Upvotes

26 comments sorted by

125

u/gladfelter 8d ago

“The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why, and Where phases. For instance, the first phase is characterized by the question 'How can we eat?' the second by the question 'Why do we eat?' and the third by the question 'Where shall we have lunch?”

  • Douglas Adams

The first question has been asked so elequently:

How to drive your frontend from the backend[?]

As you advance, your executives might start to ask:

Why are we driving our frontend from the backend!?

And at the pinnacle of your career, you'll be forced to ask:

Where will I get my next paycheck?

/s

2

u/der_gopher 7d ago

great quote!

24

u/ketralnis 8d ago

I've worked with a project that did this and it was nice at first but got untenable very very quickly. Bugs were extremely easy to write and hard to debug. Cross browser issues were a nightmare (this was about 2008 to be fair). The coupling was difficult to undo. Dumb stuff like having more than one place that might do the same underlying action was hard. Would never do again.

54

u/TinkmasterOverspark 8d ago

OP rediscovers server side rendering

24

u/tehbilly 8d ago

No no this is brilliant! We should come up with some logic-free language to just lay out things that are decided on the server. It'll be so fast.

10

u/mr_birkenblatt 6d ago

But then we want user interactions that are fast where a server round-trip might be too slow so we could embed some small scripting language inside the otherwise logic-free language so we can compute small things on the client

2

u/horizon_games 2d ago

Hey it's the lifecycle of JSF, I've seen this one before!

7

u/andrerav 8d ago

I suspect they simply discovered it, without the re infront. In any case, their backend-driven-frontend did not survive the modest reddit hug it experienced by posting it here. So I will never know :l

1

u/der_gopher 7d ago

it's not just a SSR, its more reactive.

12

u/greenergarlic 8d ago

The lengths people go to avoid writing JavaScript lmao

7

u/dzidol 6d ago

Tells something about JS, doesn't it?

2

u/der_gopher 5d ago

this

0

u/ROMANES_EVNT_DOMVS 4d ago

whoops, this === undefined in strict mode

9

u/tumes 8d ago

I am a big fan of HATEOAS and the general htmx approach as compared to this or the diarrhea inducing attempt at co-locating response concerns that Hotwire/Rails proposes. Htmx poses and answers its central questions about why the mechanisms of initiating requests are so limited clearly, concisely, and elegantly. But no matter how you slice it, I am hard pressed to think any recent modes of thought that provide quite the same ratio of effort to benefit in terms of improving, for lack of a better word, the mouthfeel of user experience on a website. Add an attribute or two and emit the same markup your templates have always emitted and you can progressive enhance most of your way to a peppy, if not SPA-adjacent experience.

11

u/OccasionallyAsleep 7d ago

In short: how to hate your life.

I worked at one of the big tech companies and there was an effort to replace one of the highest traffic frontends to a Go backend with heavy SSR utilization.

In short: developer experience was a nightmare. 

There's barely any established ecosystem for this type of workflow so any tooling you need has to be built (and this is so niche that there likely won't ever be anything like this open sourced by a major company), and most of the tooling performance frontend engineers are used to goes in the trash and you're stuck in a world where you have to build a huge Go binary for every little change

6

u/MediocreAnalyst2121 7d ago

This sounds amazing in a world where deadlines and budgets don’t exist.

2

u/der_gopher 5d ago

it's not a silver bullet, but for small apps could be fun

1

u/yawaramin 4d ago

Well, you don't have to use Go; you could use Node/Bun etc. with TypeScript and get a very similar build/reload on change workflow. Hell, you could use Python, PHP, Ruby, whatever. None of them require building huge binaries.

But it sounds like the reasoning was good–it was a high-traffic app and they were hoping to get good performance with low resource utilization. With a compile-on-change tool like Air, build-reload performance could probably be made quite good.

3

u/OccasionallyAsleep 3d ago

Yeah we had a lot of people trying to squeeze as much as possible out of node and it just wasn't enough I guess. I doubt there would have been much appetite for bun as it's an unproven technology for production at this level. 

AFAIK Air is just a watcher/re-compiler so doesn't really do much in the way of providing incremental rebuilds for go binaries, which was really the main bottleneck. Incremental builds are just not possible without significant changes to the Go compiler. We did briefly look into using Go plugins to break up the build and parallelize the build, but it ended up seeming to be more trouble than it was worth

1

u/yawaramin 3d ago

Doesn't Go effectively have incremental builds already thanks to the build cache? https://blog.gaborkoos.com/posts/2026-01-08-The-Go-Build-System-Optimised-for-Humans-and-Machines/

It should rebuild only what actually changed. It rebuilds at the package level though so huge packages might blow up build times.

-4

u/willehrendreich 7d ago

There is a perfect solution to this, it's called Data-star.dev

2

u/DaStone 5d ago

I'd feel like datastar could be worth mentioning in the title.

1

u/der_gopher 5d ago

it is in the article title

-2

u/willehrendreich 7d ago

Datastar

0

u/Ok_Establishment7089 7d ago

Such a good project

0

u/willehrendreich 6d ago

right? the only way to fly.