search

maxence-charriere / go-app

A package to build progressive web apps with Go programming language and WebAssembly.
https://go-app.dev
MIT License
7.91k stars 363 forks source link

Server-Side Rendering not only for robots #844

Closed thejezzi closed 1 year ago

thejezzi commented 1 year ago

I know there were similar questions to mine and I know the answer for the current state of go-app is that there is pre-rendering for SEO purposes. Anyway, are there any plans to implement true server-side rendering and hydration?

Keep up the awesome work, I really like your framework! :)

maxence-charriere commented 1 year ago

Hi,

I really appreciate your kind words about the framework.

When you mention 'true server-side rendering and hydration,' could you elaborate a bit more on your expectations or specific requirements? The terms server-side rendering and hydration can be interpreted in different ways depending on the context. So, your additional input would help me respond more accurately.

Thanks for helping me understand your question better!

thejezzi commented 1 year ago

Thanks for the blazingly fast reply! :)

I agree that the term "true server-side rendering" is a bit arbitrary, but what I mean by that is that the server-side rendering you have already implemented is not overwritten once the app is loaded. Instead, wouldn't it be possible to leave the pre-rendered HTML in place and distinguish between client-side and server-side components?

Greg Johnston, the creator of leptos (a similar rust framework) described it pretty well: "rather than returning an empty tag, return an initial HTML page that reflects the actual starting state of your app or site, so that while JS/WASM are loading, and until they load, the user can access the plain HTML version."

maxence-charriere commented 1 year ago

Thank you for your thoughtful inquiry. It really helps to clarify your perspective on the matter!

In the current go-app architecture, server-side pre-rendering indeed builds an initial HTML page that encapsulates the app's starting state. This pre-rendered page, although hidden behind a loader, is immediately visible to users during the loading phase of the app's WebAssembly binary. Importantly, this mechanism enables effective indexing by web crawlers.

Given that go-app is a WebAssembly application coded in Go, it generates its own state representation. Consequently, upon loading, the pre-rendered HTML generated server-side is superseded by the app's components. You can see a pre-rendered page in action by appending the following query parameter to your URL: ?wasm=false.

The methodology articulated by Greg Johnston suggests a scenario where client-side components acknowledge and 'hydrate' the existing HTML, thereby fostering a seamless user transition. This would necessitate distinguishing between server-side and client-side components or, alternatively, designing client-side components capable of parsing and assuming command of existing HTML.

It's an intriguing concept, one that I've explored in the past. However, the results didn't quite match my expectations, particularly when considering the innate characteristics of Go and its interaction with HTML.

I hope this further clarifies the mechanism of server-side pre-rendering within go-app. I truly value your ideas and suggestions for enhancement, and I'm thankful for your contribution to this enlightening discussion.

thejezzi commented 1 year ago

Unfortunately the query ?wasm=false does not work as you described.

Anyway, thanks for the detailed answer. If it does eventually meet your expectations I would be very happy if this feature makes it into go-app, as it would save me a lot of work especially regarding the permission checking of my API.