Are there any kobweb templates, libraries, or sample projects which support "blog" style content? i....

# kobweb

[Seri]

Are there any kobweb templates, libraries, or sample projects which support "blog" style content? i.e., something which would bootstrap the following:

1. Date and tag-based content directories
2. Date-based page routing
3. Content rendering from an intermediate format like Markdown
4. Truncating content for previews or directory listings

[David Herman]

Bootstrapping, no, but https://bitspittle.dev and https://kobweb.varabyte.com/docs are sites driven by markdown

[David Herman]

A blog template is a good idea though

[David Herman]

The main issue (that I've kicked the can down the road on a bit but I hope to revisit before or right after 1.0) is that Kobweb sites bundle all pages into a single output JS file. So if you plan to have a blog site with thousands of articles, that is currently a problem.

[Seri]

I'm about to start building my own static site with portfolio and blog entries, so it's great to see what's already out there

[David Herman]

Sure!

[David Herman]

A site that I want to make very soon is a simple "submit your Kobweb project with screenshot, description, and link" place

[Seri]

I'm also interested in making a blog-engine library! If I'm already putting in the work to create it, I may as well disambiguate it and see what makes sense to reuse

[David Herman]

I'd be happy to work with you on how best to do that!

[David Herman]

Probably to start check out https://bitspittle.dev and let me know what you generally think about it

[Seri]

I guess I'd start by asking if there are any other "content engine" libraries, and if that even makes sense in Kobweb

[David Herman]

And then look at the site/buid.gradle.kts file to see how it works

[David Herman]

Seeing the sort of soltions that people reach out to in other frameworks is a nice idea

[David Herman]

and whether it would work in Kobweb as it is today or not is something we'd have to see

[S.]

What specifically do you mean with content engine?
Most rich text editors or markdown processors support exporting content as html

[Seri]

Some library that abstracts out the vertical of page routing, directory generation, etc in a way that makes sense for a specific type of content

[Seri]

i.e. to build my ideal site, I'd plug in a "portfolio engine" and a "blog engine" which would support rendering out Project and Post data types. Actual HTML rendering would be left to the user, but these content engines would ease the setup burden

[S.]

I assume you want a fully static product in the end? because for more extensive blogs I have them stored in a db along with metadata. then I can create as many routes and filters with my ktor backend as I want

[David Herman]

Yes, dynamic routes and markdown in a DB can be a great way to write an extensive blog site. Although SEO could be tricky

[David Herman]

Also you lose access to being able to embed Kotlin code inside your markdown

[David Herman]

In the future I'd like to play with per file compilation and see if that can give Kobweb users the best of both worlds

[mbonnin]

Came to this channel wanting to ask that exact question. Currently on the market for something that takes a bunch of .md blog post files alongside .jpeg images and generates static HTML from that, including pagination, RSS, images optimization, etc... But looks like this is not really Kobweb strong suit at the moment?

[David Herman]

Hey Martin! Are you talking about dynamic content generation at runtime? Or compile time?

[mbonnin]

Compile time

[mbonnin]

I don't want to run a server, I want to drop a bunch of .html files in Firebase static hosting or whatever

[David Herman]

Ah, you want to put the md files inside a db?

[David Herman]

My first thought would be to drop the md files into your project somewhere and process them in your build script

[mbonnin]

I don't want a db either, my local filesystem would be the db 😃

[mbonnin]

build script being Gradle here?

[David Herman]

Correct

[David Herman]

Here's an example in the kobweb site of me processing docs articles:

https://github.com/varabyte/kobweb-site/blob/78e2dc58a2f82755dfb55c110ce134393105b595/site/build.gradle.kts#L194

See also: https://kobweb.varabyte.com/docs/concepts/foundation/markdown#iterating-over-all-markdown-files

[David Herman]

Now in this case, I'm generating additional Kotlin based on the existing markdown files (creating a listing file), but you may be asking about something a bit different.

[mbonnin]

I'm not sure 😅 , I'll dig more

[mbonnin]

Thanks for the pointers!

[mbonnin]

Just built the docs website and it gives me a bunch of static files

./docs/community/index.html
./docs/community/articles.html
./docs/community/testimonials.html
./docs/community/connecting-with-us.html
./docs/community/contributors.html
./docs/community/submitting-issues-and-feedback.html
./docs/community/supporting-the-project.html

So looks like this is what I was looking for, thanks!

[David Herman]

That's post export yeah?

[mbonnin]

yes

[David Herman]

Yep, if that's what you want then Kobweb is a good fit actually

[mbonnin]

Gradle APIs being involved make me a bit itchy though

[mbonnin]

Can I do this

kobweb {
    app {
        index {
            head.add {
                link {
                    rel = "stylesheet"
                    href = "/prism/prism.css"
                }
                script {
                    src = "/prism/prism.js"
                }
                link {
                    rel = "stylesheet"
                    href = "<https://cdn.jsdelivr.net/npm/@docsearch/css@3>"
                }
            }
        }
    }

But outside Gradle?

[David Herman]

At the moment Kobweb boilerplate generation is tied pretty tightly to Gradle. That information is processed by a Gradle task which is used to generate index.html (you can search for that under the site/build folder).

[S.]

you can still edit head elements in your normal code

[David Herman]

Some day, Kobweb could migrate all that logic over to a different build system -- that's the power of leaning on a CLI, it abstracts away that layer. But today? I wouldn't expect you could

[S.]

@Layout
@Composable
fun ClassroomsLayout(ctx: PageContext, content: @Composable () -> Unit) {
    val data = ctx.data.getValue<PageLayoutData>()
    LaunchedEffect(data.title) {
        document.title = data.title
        document.querySelector("""meta[name="og:title"]""")?.setAttribute("content", data.title)
        document.querySelector("""meta[name="description"]""")?.setAttribute("content", data.description)
        document.querySelector("""meta[name="og:description"]""")?.setAttribute("content", data.description)
        document.body?.style?.setProperty("--${scrollbarColor.name}", Theme.secondary.toString())
        document.querySelector("""link[rel="icon"]""")?.setAttribute("href", "/classrooms.ico")
    }
}

[David Herman]

you can still edit head elements in your normal code

See also: https://kobweb.varabyte.com/docs/concepts/foundation/page-metadata

[David Herman]

(That article is focused more on setting metadata for a page but it's based on the same underlying mechanism)

[S.]

actually I'm not sure if I should put this inside a LaunchedEffect as it won't update instantly

[David Herman]

The gradle build script is good for embedding stuff that should always be present. Doing things inside code may result in a microscopic delay. I think, not 100% sure, but I think doing a kobweb export will still be fine and pick up your launchedeffect changes.

[S.]

yeah it does, site is already up. but while navigating pages there is a slight delay until the title is changed (meta tags aren't visible to the user so I never noticed)