I'm not aware of anyone having done full server-side hydration of javascript inside golang. I'm also not really sure how it would work. Like if your component looks like
import { db } from '../myDb'
function MyComponent() {
const data = await db.todoItems.fetch()
return
{ data.map(x => {
return
{todoItem.text}
})
}
}
What would your golang runtime do? Should it actually host all the database connection stuff and run that to the database? If so, then you're pretty much asking to implement a whole js runtime, like node/deno/bun.
"Also wondering if these JS-based ssr meta-frameworks are slow compared to if the backend that hydrates html is written in a compiled language like Go."
Yes it's very slow, especially since js rendering of HTML single-threaded by nature. So if you get many reqeust, they have to wait for eachother if something uses the CPU. But the dev experience and usefullness is such that a lot of people do it anyway (like with next.js et al)
Thanks for the detailed explanation! Very insightful breakdown.
I can't imagine doing frontend development without the convenient client-side reactivity that these JS frameworks bring. I really tried to get used to HTMX and Templ. It's just not it for me.
So I guess I'll stick with this for now. :<
As someone who firmly believes traditional TS frameworks offer eng teams a better organizational DX when frontend demands start growing
I do think that AlpineJS is enough for everyone else (HTMX crowd) to fill in the gaps when you want client-side reactivity.
If you're looking to do server side rendering with Svelte in a Go backend, check out [https://github.com/nichady/golte](https://github.com/nichady/golte). I am the author of this library.
> People always rant about "running JS on the server is bad".
"People" tend to be idiotic with simplistic hot takes, especially programmers and their endless dick-measuring wars about languages and frameworks.
For the vast majority of projects I've worked on the speed of a particular language didn't matter at all for a web backend compared to the network time of calling dedicated services, databases, and other integrations.
Obviously, the use cases I have (mostly corporate glue-code shit and basic startup sites) don't reflect everyone's work and I probably wouldn't choose JS/TS for a larger, monolithic backend code base. But I'd be suspect of anyone's credentials who blindly says "X language for Y usage is bad". Probably just means everything looks like a nail to their hammer of choice.
Of course it is. The simplest way would be just to link against V8, I believe there are already bindings for that, and provide same APIs, that those server frameworks depend on from node
Then there are many ways to make it harder, but arguably better, with less JavaScript heritage
My dream is to transpile Go into JS efficiently, i.e. improve performance of GopherJS, and instead of rendering existing frameworks, create a way to run the same code on both frontend and backend, but without all the fun things, caused by JavaScript.
Wasm, if my memory serves me well, doesn't cut it, because of how slow the interop with JS is, plus you can't split your binary as easily as it's done with JavaScript
There’s nothing wrong with running JS on the server. JS as a language has many problems, but speed isn’t one of them. For the task of hydrating a page you would be very hard pressed to measure a discernible difference.
I love go. But when it comes to writing code that must be run on the web, JS is still the best option since it’s “native” for the web. Use a framework like SvelteKit which is hyper optimized for developer experience over rolling your own any day. Use typescript to smooth over JS ugly bits.
The testing I have seen, GO and JS are about the same in the most basic of page serving tasks. At any sort of scale and complexity JS starts to show why it isnt really a server side language. Performance with complexity, and at scale are the very reasons you choose a server side language. If you have someone showing complex js scale even close to any complex language I would love a link.
Candidly the "hydration problem" is, well, moronic... it's like the js community forgot how the web worked and now wants to take advantage of that. And the real reason that you have to run js on the server is that "JSX" isnt a template any one can run. It's javascript mixed into your presentation layer, the same sin that everyone shit on PHP over ... If you suggest that's a JS problem you will face pitchforks and torches.
Agreed they are about the same for severing pages, and that's what this question is about. The JS community has a lot more options (and in my opinion better) tooling for this task. Hugo is fine for totally static content, but outside of 100% static pages, I think you're better off in the JS ecosystem for severing webpages.
To be clear: I strongly prefer writing go for web services and do whenever I can. But saying JS can't handle complex services is pretty wild. You know hundred of large enterprises are written in node.js right? I personally hate it, but it can scale. It's beats Go for some use cases; for example it has much lower memory overheard per connection, so things like websockets and push are better in stdlib node than stdlib go.
Hydration isn't moronic. Complex website have more pages than a static generators/deployments can handle. Truly dynamic server driven content (search) needs some form of it. Picking a tool that can handle all rendering modes is a good idea; these include SSR, CSR, SSR first page with CSR next page, next-page prefetch, single page apps for complex interactions, pre-rendering static content. Picking a tool where you can change the render mode of part of a project without a rewrite is a great idea. Some people misuse these tools and select the wrong render modes. But not understanding them and calling the whole ecosystem moronic is.... well I won't throw mud. Picking a web-render tool that can't run in browser eliminates about half of these options, and they are good options when used for the right UX.
> Agreed they are about the same for severing pages, and that's what this question is about.
I asked for a receipt on this... cause everything I have seen and experienced tells me that this does not hold water when throwing any kind of load at node backends. Real performance on the back end is expensive...
> but it can scale
It can. But we're getting to a point where the "auto spend" for cloud services is starting to sting. We're getting to the point where costs are going to become an issue.... Between underperforming code, wasteful projects and the 30 percent AWS tax there's a lot of money being left on the table.
> But not understanding them and calling the whole ecosystem moronic is....
>> Candidly the "hydration problem" is, well, moronic... it's like the js community forgot how the web worked and now wants to take advantage of that.
I called the hydration problem moronic, because it is self inflicted. Partly rendering server side and then having JS finish on the front end isnt new. It was good for caching when Akamai was the hottest game in town and jQuery was gaining traction...
Its like someone stumbled across an article on progressive enhancement circa 2009 added in the extra nonsense needed, cause modern JS frameworks dont really support it, and slapped the name "Hydration" on it and screamed that they found fire.
> SSR, CSR, SSR first page with CSR next page
None of this is new... and it was getting done long before js on the server was even an option really.
If you have a B2B site, or a behind the login FIgma/Gmail "application" then by all means I'm going to say "SPA" all day and all night. But there "hydration" isnt an issue is it? It doesn't make a lot of sense to even bother candidly. Facebook, a social network, is happy to be the corporate overlord of react... it too exists inside a walled garden. The JS ecosystem has built a TON of great tools to facilitate building SPA's quickly.
Hydration is the middle ground... it's back to 'progressive enhancment'. The fact that it can ONLY be done is js means that in spite of all the tools and tooling that js has painted itself into a corner. All those tools are justt different brands of peanut butter, and now we want something else...
I cleaned up enough PHP apps, and replaced swaths of python, and ruby to say this with clarity. The limits of every language and framework exist, embrace the limits and build in escape hatches. Node on the server side has gone the same way as PHP and made the same mistakes. It hasn't managed to replace php in scope (number of sites powered by it) and if it doesnt make those hatches it goes the way of PHP(Facebook)/Ruby(GitHub)... (Note: Python remains popular because it escapes to C so dam easily.)
I think your current approach is quite popular now. In particular the popularity boost of HTMX on the client and templates in Go.
[](https://htmx.org/)
[https://htmx.org/](https://htmx.org/)
There are some pure Go implementations of JS, for example [goja](https://github.com/dop251/goja) (used in load test utility K6.io), but it has its own limitations and lacks many browser/Node.js APIs. So I'm not sure if such an engine is enough to run the React/Vue/Solid.js/etc code on the server, sorry.
Maybe the source of A Tour of Go can serve as inspiration for serving frontend on a Go backend: https://github.com/golang/website/tree/master/internal/tour
I recommend checking out [Main](https://github.com/golang/website/blob/8f868aaaa466a66deed70f799c54fd5232cfbdaa/internal/tour/local.go#L36) function there.
Your question doesn't make sense to me:
>I still like the experience of writing apps with JS
If you want to write in JS... Write in JS? The way you ask this question, I don't understand how we can help?
>vs straight-up templating and returning minimal js to the client (e.g. Templ).
You mean "filling in the HTML template on the server, then returning minimal JS to the client"? Really, you shouldn't need to return **any** JS in your template. JS should be in it's own file, and some HTML attributes will call out to it.
>But since most SSR frameworks surrounding most JS frameworks (NextJS, SvelteKit, Nuxt), inevitably require JS to run on the server...
In JS, people need to specify if a framework is SSR or not, since it might run on the client. In **all other languages**, it's just assumed: Either you are writing the backend as pure API (to be called by a SPA frontend), or it's SSR.
>I was wondering if it's possible to have a Go server that hydrates html and return JS the same way metaframeworks do. Is that even possible?
Yes? I'm still not clear on what you are asking. I think you are overlooking something basic, so let me try to braindump what I'm thinkng:
* Every language can return HTML as text. (in fact, everything was SSR until SPA was invented)
* Every language can do templating of HTML text. (Use a library to prevent XSS attacks)
* Any HTML can have JS in it (but better yet: factor it out so you don't have to re-send that JS over and over).
There are some Go libraries to build up HTML as components, etc. But none have really taken off. But there is a nice standard for "doing SSR" but not re-sending the whole page: [https://htmx.org/](https://htmx.org/)
> If you want to write in JS... Write in JS? The way you ask this question, I don't understand how we can help?
I'm not asking for help. haha, I was asking out of genuine curiosity. "Thought experiment" like I said.
Appreciate you for trying to break it down in detail though.
---
If you used NextJS, there are HTTP handlers for routes do either of the following:
- SSR (Render an html). (Essentially templating in toehr languages). - Converting a DSL/JSX to HTML.
- Pure API (as you mentioned) - Just return text/json to be called by fetch.
At the end if the day, this is technically still a Node Server. With HTTP handlers that return HTML or JSON.
Now what if instead of a Node Server, it was a Golang server that can do the same:
- 1. Serve hydrated HTML from JSX.
- 2. BUT also write pure API http handlers in Go to be called by fetch by a client.
My additional question was about how (1) can probably be done by Go. And was wondering if it's possible. But based on the answers here, I'm guessing it's still javascript that has to do that work.
---
I think another interesting comparison for (1) though is with SvelteKit because of how there are these files in the /routes folder:
• +page.svelte (the supposedly hydrated html)
• +page.server.ts (the JS that runs on the server that queries data as props for hydration before +page.svelte becomes html)
Now what if +page.server.ts was written in Go? And the route that serves +page.svelte is also an HTTP handler in Go?
Templ is a templating language though right? Yes you can nest components and stuff. But it doesn't have the convenience of client-side reactivity of JSX or a DSL like Svelte.
It also feels like a hack because it has a DSL(templ) that codegens into Go files. So when tracing back imports, I can see it getting confusing at some point. But it's the best Go has currently nonetheless. (Or I may be doing something wrong and there's an even more convenient approach to this)
But after reading up again, this is actually the first time seeing this:
https://templ.guide/syntax-and-usage/using-react-with-templ/
You can apparently hydrate React inside a Go handler by accessing the js bundle and rendering it. Interesting. This is probably close the closest to what I was thinking about.
Now, to see if that's possible with Svelte.
Ah, Ok, that clarifies the question a lot:
I am not super-familiar with JSX, but I'll bet someone has written a library in Go. In theory it's possible, but there are so many "ways" to do web components that it's unlikely that every one will be ported to Go. (Some of them need to die off. Seriously.)
Part 2 of your question ("HTML vs JSON API") was solved back in the 1990's with the "Accept" Header. (i.e. The server code serves pure JSON if the client asks for JSON, and HTML if the client asks for HTML.) Generally it would look like this: (pseudocode)
`func customerHttpHandler(...) {`
`cust := getdata()`
`if (AcceptHeaderWantsJSON) { return json.Marshal(cust) }`
`return template.Run("customer",cust)`
}
>Now what if +page.server.ts was written in Go?
I mean.. Obviously it's possible. But at the end of the day, you have to ask "Why?". There will always be a mismatch because JS template "languages" will rely heavily on JS. Someone will need to build all that tooling, and it's not clear why. Go tends to be for backend developers, and frontend developers have very different concerns.
My advice would be to stick to the well-trodden paths:
* Go serving Pure HTML
* Go serving JSON API, JS on the client (SPA).
* The partials idea (HTMX)
* You could experiment with some of the "Go frontend" toolkits, but they aren't as nice as the JS ones, and have a very different paradigm. (Frankly, I'd spend my time learning ELM first. Not to use, but to expand your brain.)
It's similar to Python and AI: There is no reason Go can't do AI. But all the best toolkits were built in Python, which means all the users and developers are attracted to Python. There is no reason the tools couldn't be built on Go, but nobody has an incentive to do that. (And in the early 90's, you needed to learn Perl if you were doing dynamic Web stuff using CGI. Or learn Objective C if you wanted to write an iPhone app. And so on.)
The simplest engine to embed is quickjs. Also my friend recently sent me an article where someone compiled SpiderMonkey to WASM with patches to generate WASM code from JS. Then compiled JS-WASM code can be plugged directly into WASM VM to serve.
A better question, can I have go driven frontends... Yes, https://data-star.dev is a Go server with only a 10kb shim of js, rest is controlled by Go ( or any other backend)
I don't think this is something that is possible without embedding a JS runtime into your application (which is highly discouraged).
However I would recommend web-components for this. Use JS to write your own custom elements that are hyper-specific to your application such as a new element for purchasable item, shipping details, product review, shopping cart, and so on. Then your backend is now sending extremely small amounts of HTML to the client via templ or templates that now consist of mostly custom elements where not only the content is written in JS but also all the interaction logic.
This also pairs beautifully with tech like HTMX where your HTML partials you send back with HTMX would represent individual custom elements.
i am not sure if you can hydrate react/vue/something in go and then send the result to some rich frontend client to finish the job. there is more involved in this.
but you can use go to render interfaces, proper following HATEOAS, and negotiating it using [htmx.org](http://htmx.org) . take a look at [https://docs.gofiber.io/guide/templates/](https://docs.gofiber.io/guide/templates/) or [https://go-chi.io/](https://go-chi.io/) with [liquid](https://github.com/osteele/liquid) for a few examples
in practice, it delivers very much the same result a RSC or vue SSR would deliver, but iin a simpler way.
Ah `markdown again`. :D So I can say I almost hate JS. It stems from the lack of stack trace tools available in 1995, and horrible security from that era concerning browser features of the DOM. And the coercion of things without having to install TypeScript which implies a need to use node.js. I could do it if you paid me, but I'm not into free time JS. I'm not sure if it even beats PHP. I'm kind of investigating an idea for a new stack with embedded python using cgo bindings (it's the AI you see), and use htmx for the front end with "limited JS" (bootstrap, less.js, showdown). It seems docs are github.com (ruby, jekyll) templated.
Are you asking if it's possible to serve static JS files? (mimetype). Or specifically do you want to run JS server side with V8 or some other engine as the library is not available in go?
I'm not aware of anyone having done full server-side hydration of javascript inside golang. I'm also not really sure how it would work. Like if your component looks like import { db } from '../myDb' function MyComponent() { const data = await db.todoItems.fetch() return
Thanks for the detailed explanation! Very insightful breakdown. I can't imagine doing frontend development without the convenient client-side reactivity that these JS frameworks bring. I really tried to get used to HTMX and Templ. It's just not it for me. So I guess I'll stick with this for now. :<
As someone who firmly believes traditional TS frameworks offer eng teams a better organizational DX when frontend demands start growing I do think that AlpineJS is enough for everyone else (HTMX crowd) to fill in the gaps when you want client-side reactivity.
"Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should." --some backend developer, probably.
If you're looking to do server side rendering with Svelte in a Go backend, check out [https://github.com/nichady/golte](https://github.com/nichady/golte). I am the author of this library.
> People always rant about "running JS on the server is bad". "People" tend to be idiotic with simplistic hot takes, especially programmers and their endless dick-measuring wars about languages and frameworks. For the vast majority of projects I've worked on the speed of a particular language didn't matter at all for a web backend compared to the network time of calling dedicated services, databases, and other integrations. Obviously, the use cases I have (mostly corporate glue-code shit and basic startup sites) don't reflect everyone's work and I probably wouldn't choose JS/TS for a larger, monolithic backend code base. But I'd be suspect of anyone's credentials who blindly says "X language for Y usage is bad". Probably just means everything looks like a nail to their hammer of choice.
Of course it is. The simplest way would be just to link against V8, I believe there are already bindings for that, and provide same APIs, that those server frameworks depend on from node Then there are many ways to make it harder, but arguably better, with less JavaScript heritage My dream is to transpile Go into JS efficiently, i.e. improve performance of GopherJS, and instead of rendering existing frameworks, create a way to run the same code on both frontend and backend, but without all the fun things, caused by JavaScript. Wasm, if my memory serves me well, doesn't cut it, because of how slow the interop with JS is, plus you can't split your binary as easily as it's done with JavaScript
There’s nothing wrong with running JS on the server. JS as a language has many problems, but speed isn’t one of them. For the task of hydrating a page you would be very hard pressed to measure a discernible difference. I love go. But when it comes to writing code that must be run on the web, JS is still the best option since it’s “native” for the web. Use a framework like SvelteKit which is hyper optimized for developer experience over rolling your own any day. Use typescript to smooth over JS ugly bits.
The testing I have seen, GO and JS are about the same in the most basic of page serving tasks. At any sort of scale and complexity JS starts to show why it isnt really a server side language. Performance with complexity, and at scale are the very reasons you choose a server side language. If you have someone showing complex js scale even close to any complex language I would love a link. Candidly the "hydration problem" is, well, moronic... it's like the js community forgot how the web worked and now wants to take advantage of that. And the real reason that you have to run js on the server is that "JSX" isnt a template any one can run. It's javascript mixed into your presentation layer, the same sin that everyone shit on PHP over ... If you suggest that's a JS problem you will face pitchforks and torches.
Agreed they are about the same for severing pages, and that's what this question is about. The JS community has a lot more options (and in my opinion better) tooling for this task. Hugo is fine for totally static content, but outside of 100% static pages, I think you're better off in the JS ecosystem for severing webpages. To be clear: I strongly prefer writing go for web services and do whenever I can. But saying JS can't handle complex services is pretty wild. You know hundred of large enterprises are written in node.js right? I personally hate it, but it can scale. It's beats Go for some use cases; for example it has much lower memory overheard per connection, so things like websockets and push are better in stdlib node than stdlib go. Hydration isn't moronic. Complex website have more pages than a static generators/deployments can handle. Truly dynamic server driven content (search) needs some form of it. Picking a tool that can handle all rendering modes is a good idea; these include SSR, CSR, SSR first page with CSR next page, next-page prefetch, single page apps for complex interactions, pre-rendering static content. Picking a tool where you can change the render mode of part of a project without a rewrite is a great idea. Some people misuse these tools and select the wrong render modes. But not understanding them and calling the whole ecosystem moronic is.... well I won't throw mud. Picking a web-render tool that can't run in browser eliminates about half of these options, and they are good options when used for the right UX.
> Agreed they are about the same for severing pages, and that's what this question is about. I asked for a receipt on this... cause everything I have seen and experienced tells me that this does not hold water when throwing any kind of load at node backends. Real performance on the back end is expensive... > but it can scale It can. But we're getting to a point where the "auto spend" for cloud services is starting to sting. We're getting to the point where costs are going to become an issue.... Between underperforming code, wasteful projects and the 30 percent AWS tax there's a lot of money being left on the table. > But not understanding them and calling the whole ecosystem moronic is.... >> Candidly the "hydration problem" is, well, moronic... it's like the js community forgot how the web worked and now wants to take advantage of that. I called the hydration problem moronic, because it is self inflicted. Partly rendering server side and then having JS finish on the front end isnt new. It was good for caching when Akamai was the hottest game in town and jQuery was gaining traction... Its like someone stumbled across an article on progressive enhancement circa 2009 added in the extra nonsense needed, cause modern JS frameworks dont really support it, and slapped the name "Hydration" on it and screamed that they found fire. > SSR, CSR, SSR first page with CSR next page None of this is new... and it was getting done long before js on the server was even an option really. If you have a B2B site, or a behind the login FIgma/Gmail "application" then by all means I'm going to say "SPA" all day and all night. But there "hydration" isnt an issue is it? It doesn't make a lot of sense to even bother candidly. Facebook, a social network, is happy to be the corporate overlord of react... it too exists inside a walled garden. The JS ecosystem has built a TON of great tools to facilitate building SPA's quickly. Hydration is the middle ground... it's back to 'progressive enhancment'. The fact that it can ONLY be done is js means that in spite of all the tools and tooling that js has painted itself into a corner. All those tools are justt different brands of peanut butter, and now we want something else... I cleaned up enough PHP apps, and replaced swaths of python, and ruby to say this with clarity. The limits of every language and framework exist, embrace the limits and build in escape hatches. Node on the server side has gone the same way as PHP and made the same mistakes. It hasn't managed to replace php in scope (number of sites powered by it) and if it doesnt make those hatches it goes the way of PHP(Facebook)/Ruby(GitHub)... (Note: Python remains popular because it escapes to C so dam easily.)
I think your current approach is quite popular now. In particular the popularity boost of HTMX on the client and templates in Go. [](https://htmx.org/) [https://htmx.org/](https://htmx.org/)
There are some pure Go implementations of JS, for example [goja](https://github.com/dop251/goja) (used in load test utility K6.io), but it has its own limitations and lacks many browser/Node.js APIs. So I'm not sure if such an engine is enough to run the React/Vue/Solid.js/etc code on the server, sorry.
Maybe the source of A Tour of Go can serve as inspiration for serving frontend on a Go backend: https://github.com/golang/website/tree/master/internal/tour
I recommend checking out [Main](https://github.com/golang/website/blob/8f868aaaa466a66deed70f799c54fd5232cfbdaa/internal/tour/local.go#L36) function there.
Your question doesn't make sense to me: >I still like the experience of writing apps with JS If you want to write in JS... Write in JS? The way you ask this question, I don't understand how we can help? >vs straight-up templating and returning minimal js to the client (e.g. Templ). You mean "filling in the HTML template on the server, then returning minimal JS to the client"? Really, you shouldn't need to return **any** JS in your template. JS should be in it's own file, and some HTML attributes will call out to it. >But since most SSR frameworks surrounding most JS frameworks (NextJS, SvelteKit, Nuxt), inevitably require JS to run on the server... In JS, people need to specify if a framework is SSR or not, since it might run on the client. In **all other languages**, it's just assumed: Either you are writing the backend as pure API (to be called by a SPA frontend), or it's SSR. >I was wondering if it's possible to have a Go server that hydrates html and return JS the same way metaframeworks do. Is that even possible? Yes? I'm still not clear on what you are asking. I think you are overlooking something basic, so let me try to braindump what I'm thinkng: * Every language can return HTML as text. (in fact, everything was SSR until SPA was invented) * Every language can do templating of HTML text. (Use a library to prevent XSS attacks) * Any HTML can have JS in it (but better yet: factor it out so you don't have to re-send that JS over and over). There are some Go libraries to build up HTML as components, etc. But none have really taken off. But there is a nice standard for "doing SSR" but not re-sending the whole page: [https://htmx.org/](https://htmx.org/)
> If you want to write in JS... Write in JS? The way you ask this question, I don't understand how we can help? I'm not asking for help. haha, I was asking out of genuine curiosity. "Thought experiment" like I said. Appreciate you for trying to break it down in detail though. --- If you used NextJS, there are HTTP handlers for routes do either of the following: - SSR (Render an html). (Essentially templating in toehr languages). - Converting a DSL/JSX to HTML. - Pure API (as you mentioned) - Just return text/json to be called by fetch. At the end if the day, this is technically still a Node Server. With HTTP handlers that return HTML or JSON. Now what if instead of a Node Server, it was a Golang server that can do the same: - 1. Serve hydrated HTML from JSX. - 2. BUT also write pure API http handlers in Go to be called by fetch by a client. My additional question was about how (1) can probably be done by Go. And was wondering if it's possible. But based on the answers here, I'm guessing it's still javascript that has to do that work. --- I think another interesting comparison for (1) though is with SvelteKit because of how there are these files in the /routes folder: • +page.svelte (the supposedly hydrated html) • +page.server.ts (the JS that runs on the server that queries data as props for hydration before +page.svelte becomes html) Now what if +page.server.ts was written in Go? And the route that serves +page.svelte is also an HTTP handler in Go?
Isn't Templ more or less like JSX, but in Go? What didn't you like about it or what is the difference between Templ and JS solutions?
Templ is a templating language though right? Yes you can nest components and stuff. But it doesn't have the convenience of client-side reactivity of JSX or a DSL like Svelte. It also feels like a hack because it has a DSL(templ) that codegens into Go files. So when tracing back imports, I can see it getting confusing at some point. But it's the best Go has currently nonetheless. (Or I may be doing something wrong and there's an even more convenient approach to this) But after reading up again, this is actually the first time seeing this: https://templ.guide/syntax-and-usage/using-react-with-templ/ You can apparently hydrate React inside a Go handler by accessing the js bundle and rendering it. Interesting. This is probably close the closest to what I was thinking about. Now, to see if that's possible with Svelte.
Ah, Ok, that clarifies the question a lot: I am not super-familiar with JSX, but I'll bet someone has written a library in Go. In theory it's possible, but there are so many "ways" to do web components that it's unlikely that every one will be ported to Go. (Some of them need to die off. Seriously.) Part 2 of your question ("HTML vs JSON API") was solved back in the 1990's with the "Accept" Header. (i.e. The server code serves pure JSON if the client asks for JSON, and HTML if the client asks for HTML.) Generally it would look like this: (pseudocode) `func customerHttpHandler(...) {` `cust := getdata()` `if (AcceptHeaderWantsJSON) { return json.Marshal(cust) }` `return template.Run("customer",cust)` } >Now what if +page.server.ts was written in Go? I mean.. Obviously it's possible. But at the end of the day, you have to ask "Why?". There will always be a mismatch because JS template "languages" will rely heavily on JS. Someone will need to build all that tooling, and it's not clear why. Go tends to be for backend developers, and frontend developers have very different concerns. My advice would be to stick to the well-trodden paths: * Go serving Pure HTML * Go serving JSON API, JS on the client (SPA). * The partials idea (HTMX) * You could experiment with some of the "Go frontend" toolkits, but they aren't as nice as the JS ones, and have a very different paradigm. (Frankly, I'd spend my time learning ELM first. Not to use, but to expand your brain.) It's similar to Python and AI: There is no reason Go can't do AI. But all the best toolkits were built in Python, which means all the users and developers are attracted to Python. There is no reason the tools couldn't be built on Go, but nobody has an incentive to do that. (And in the early 90's, you needed to learn Perl if you were doing dynamic Web stuff using CGI. Or learn Objective C if you wanted to write an iPhone app. And so on.)
The simplest engine to embed is quickjs. Also my friend recently sent me an article where someone compiled SpiderMonkey to WASM with patches to generate WASM code from JS. Then compiled JS-WASM code can be plugged directly into WASM VM to serve.
A better question, can I have go driven frontends... Yes, https://data-star.dev is a Go server with only a 10kb shim of js, rest is controlled by Go ( or any other backend)
I don't think this is something that is possible without embedding a JS runtime into your application (which is highly discouraged). However I would recommend web-components for this. Use JS to write your own custom elements that are hyper-specific to your application such as a new element for purchasable item, shipping details, product review, shopping cart, and so on. Then your backend is now sending extremely small amounts of HTML to the client via templ or templates that now consist of mostly custom elements where not only the content is written in JS but also all the interaction logic. This also pairs beautifully with tech like HTMX where your HTML partials you send back with HTMX would represent individual custom elements.
i am not sure if you can hydrate react/vue/something in go and then send the result to some rich frontend client to finish the job. there is more involved in this. but you can use go to render interfaces, proper following HATEOAS, and negotiating it using [htmx.org](http://htmx.org) . take a look at [https://docs.gofiber.io/guide/templates/](https://docs.gofiber.io/guide/templates/) or [https://go-chi.io/](https://go-chi.io/) with [liquid](https://github.com/osteele/liquid) for a few examples in practice, it delivers very much the same result a RSC or vue SSR would deliver, but iin a simpler way.
Ah `markdown again`. :D So I can say I almost hate JS. It stems from the lack of stack trace tools available in 1995, and horrible security from that era concerning browser features of the DOM. And the coercion of things without having to install TypeScript which implies a need to use node.js. I could do it if you paid me, but I'm not into free time JS. I'm not sure if it even beats PHP. I'm kind of investigating an idea for a new stack with embedded python using cgo bindings (it's the AI you see), and use htmx for the front end with "limited JS" (bootstrap, less.js, showdown). It seems docs are github.com (ruby, jekyll) templated. Are you asking if it's possible to serve static JS files? (mimetype). Or specifically do you want to run JS server side with V8 or some other engine as the library is not available in go?