Hi, I'm new to Fritz2, and I'm evaluating whether ...

# fritz2

[Prag]

Hi,
I'm new to Fritz2, and I'm evaluating whether it is something that I could use for a project, a public facing website. Because of SEO requirements, the chosen solution should be able to render plain HTML on the server side.
Is it possible to render a Fritz2 page as a string containing HTML on the JVM?

[Big Chungus]

Nope. Fritz2 is fully client side rendered

[Big Chungus]

You might want to look at kotlinx.html

[Christian Hausknecht]

Because of SEO requirements, the chosen solution should be able to render plain HTML on the server side.

Sounds a bit weird in 2021 😉

You could still deliver a good template, but of course the pure content (and therefore links to other sites) is rendered at client side.

I am by far no expert in this topic, but I would assume google and others will analyse rendered sites nowadays. If not, practically the majority of site would not be indexable at all in a meaningfull way 😄

[Prag]

@Christian Hausknecht You would expect that search engines like Google would have no problems indexing JavaScript sites, but unfortunately that's not the case. Search engines still have problems with it. Sometimes it also depends on the JS framework used. Also Google can give penalties because SEO parameters, such as FCP (First Contentful Paint) etc are less optimal.
For example, the KVision website isn't indexed at all by Google: https://www.google.com/search?q=site%3Akvision.io

[Prag]

@Big Chungus It would be nice if users could reuse a template defined in Fritz2 both on the client and the server side, without writing it a second time in kotlinx.html

Client side JS frameworks like React, Vue and Angular also support server side rendering for reasons like SEO.

[Prag]

For example, NuxtJS (a Vue framework) says this:
https://nuxtjs.org/

Server Side Rendered

The most popular mode for Nuxt. With SSR, also called "universal" or "isomorphic" mode, a Node.js server will be used to deliver HTML based on your Vue components to the client instead of the pure javascript. Using SSR will lead to a large SEO boost, better UX and more opportunities (compared to a traditional Vue SPA).

Because implementing SSR on your own can be really tedious, Nuxt.js gives you full support out of the box and will take care of common pitfalls.

[Big Chungus]

While it would be nice for sure, don't forget that those other frameworks have corporations backing them for constant fliw of dmbudget and dedicated devs. Fritz2 on the other hand is just a couple of brilliant people flexing their skills on their free time while also having a day job I'd imagine

[Big Chungus]

And you'll find that the same applies to any other kotlin.js framework until jb finally publish compose-web

[Prag]

It it possible with multiplatform Kotlin, using Kotlin.js and JVM and kotlinx.html, demonstrated by Jetbrains in

https://www.youtube.com/watch?v=afc5PUs_EPE▾

https://github.com/yole/kxhtml-isomorphic

But I understand your point.

I haven't heard about compose-web yet. I'll look into it. Thanks

[Big Chungus]

There are couple MVPs already in #compose-web

[napperley]

Note that Compose Web uses the Canvas instead of HTML.

[pabl0rg]

it would be awesome if fritz2 and kotlinx.html were interchangeable or it were somehow possible to do SSR. sites/pages often start simple and later need some client-side magic.

[pabl0rg]

kweb is also a cool concept (akin to elixir's liveview or vaadin) it would be awesome to have a standard that would allow combining the best of all three worlds.

[Christian Hausknecht]

If SEO is the main feature you need to pay attention, then fritz2 (currently) isn't a good choice I must admit.

(I have a strong opinion to such disfunctional requirements probably made by non technical bull**** bingo stakeholders 😄 But of course this is totally biased by my experience with such stakeholders, you know this one?

https://www.youtube.com/watch?v=BKorP55Aqvg▾

)

As I searched a bit about this topic, I stumbled upon this guide by google:
https://codelabs.developers.google.com/codelabs/making-a-single-page-app-search-friendly#0

So it definitly is possible to make SPAs search bot friendly obviously.

I believe that we might try to follow those guidelines as far as possible with our limited developer time in the core team, instead of trying to implement some server side rendering. (I have no idea at all, how this could ever be realized, as you would habe to drop all interaction from a fritz2 app and "magically" replace those with some ``<a href="...">``) I think the guide shows pitfalls, we could try to avoid.

That said: We are always open for ideas and also for pull requests with some integration ready solution 🙂

[Prag]

I have a strong opinion to such disfunctional requirements probably made by non technical bull**** bingo stakeholders

The need for SEO depends on the type of website. If it's a webapp like Gmail or an internal website or website with a login required, then it doesn't really need SEO/SSR. But if it's a webshop, then SEO is crucial for business survival. SE bots hate JS, because they need to use headless browsers to render it. It requires more resources, so such websites are often less crawled, or crawled superficially, or put on low priority.

Google says for example:
https://developers.google.com/search/docs/guides/dynamic-rendering

Currently, it's difficult to process JavaScript and not all search engine crawlers are able to process it successfully or immediately. In the future, we hope that this problem can be fixed, but in the meantime, we recommend dynamic rendering as a workaround solution to this problem. Dynamic rendering means switching between client-side rendered and pre-rendered content for specific user agents.

Dynamic rendering is an alternative to SSR. Dynamic rendering uses pre-rendering. In pre-rendering a headless browser renders the page, and then stores the generated HTML in a cache. Which is then served to search engines and/or normal clients. (Normal clients can benefit from it by the reduced FCP (First Contentful Paint time). (There exist external commercial services that provide pre-rendering solutions.)

(I have no idea at all, how this could ever be realized, as you would habe to drop all interaction from a fritz2 app and "magically" replace those with some ``<a href="...">``)

SSR is basically the ability to render the content on the server as a string containing HTML. Once this HTML is generated by the server and send to the client (browser), the client renders the HTML producing visible content. After this, JavaScript kicks in, and synchronized the HTML with the JS framework by attaching event handlers. This synchronized is called hydration. After hydration, the client basically doesn't need to be hydrated anymore, not even when switching pages, unless the client performs a hard page refresh or opens a link by opening it in a new tab.

An alternative to hydration is the use of html in a noscript tag. This is done for example in Discourse forum (check the html source).

So if SEO is important, then currently the best solution for Fritz2 users is to use those Google guidelines, and a pre-rendering solution.

[Christian Hausknecht]

I have opened an issue in the meanwhile in order to make fritz2 more friendly towards SEO: https://github.com/jwstegemann/fritz2/issues/354

Sorry for having forgotten to announce this to you :-)