re-frame

Jeremy 2024-10-04T15:14:11.979179Z

Hi all, I'm new to clojure and want to use reframe/rum for a mid-side web app. what are the various solutions to SSR for reframe? so far, I've come across https://github.com/pupeno/prerenderer

p-himik 2024-10-04T15:18:41.548169Z

The answer is not as straightforward. I'd suggest searching this channel for SSR and reading a few of the most recent threads on the topic.

Jeremy 2024-10-04T16:54:46.582219Z

The result didn't yield a definitive answer. I guess I'll look for a work-around

Drew Verlee 2024-10-06T17:24:15.927209Z

@olajeremy123 when you say mid-side, do you mean "server-side"? If not, what is a mid-side web app?

Jeremy 2024-10-06T17:38:11.546059Z

oh, it was a typo 😅. I meant "mid-size". as in not a large site. I just need basic rendering on some pages for SEO, while main features can be a full SPA.

p-himik 2024-10-06T18:03:15.052649Z

> can be a full SPA But do they need to? Plenty of people are happy with non-SPA apps when they're made properly. There's also a middle-ground of sorts when you use AJAX requests to fetch HTML fragments instead of data that drives HTML changes. You can search for "htmx" here to get a whole bunch of links and discussions on the topic (doesn't mean you have to use htmx, but discussions about it usually yield alternatives as well).

Jeremy 2024-10-06T19:19:12.558669Z

For what I'm building, it doesn't have to. I just want to do something with reframe

john 2024-10-07T16:34:06.997869Z

Why does SSR make rendering for some pages for SEO easier? You don't want to have to pre-ship some js artifact for a one-off page? Or do you want to be able to change it fast, without changing a deployed artifact?

john 2024-10-07T16:34:52.864409Z

Or is it just cause some spiders can't crawl SPAs as easily?

👍 1
john 2024-10-07T16:39:18.229799Z

I actually like the idea of "mid-side" rendering 😆

john 2024-10-07T16:42:04.679879Z

Something in between SSR and SPA, where you ship widgets as an IR built in clojure data, at a minimum level of definition needed to express the domain of your app. So the front end is still converting the cljs data to js at runtime, but that data is driven by the backend. Have your frontend cake and eat the backend cake too

Jeremy 2024-10-07T16:51:28.664889Z

hmm.. it was my thinking that search engines rank non-SPAs higher, but after few mins of research, it looks like both bing and google can crawl js sites without any issue

Jeremy 2024-10-07T16:52:02.779239Z

I'm still a tiny bit worries about lesser known crawlers

john 2024-10-07T16:52:04.060659Z

Yeah, and there's tools/fixes for where they can't very easily

Jeremy 2024-10-07T16:52:29.652369Z

what tools/fixes? kindly elaborate

john 2024-10-07T16:52:57.920879Z

I'm not an expert on that specific thing, but there's google tutorials on how to make your spa seo friendly

john 2024-10-07T16:53:16.570049Z

Things like doing navigation right

john 2024-10-07T16:53:21.655609Z

with history

Jeremy 2024-10-07T16:53:28.153699Z

ohk, would look them up. thanks

john 2024-10-07T16:53:32.108279Z

and pre-sharing a site map for the spider

Jeremy 2024-10-07T16:54:13.328569Z

btw, ur "mid-side" idea sound interesting. too complex tho

john 2024-10-07T16:54:48.981559Z

Mid side is the future!

john 2024-10-07T16:55:09.207919Z

just sync your front end db to your backend db

john 2024-10-07T16:55:23.501089Z

let your clients do your work for you and just spec the data moving between your clients

john 2024-10-07T16:58:18.471079Z

And then you can drive things from the backend by just updating shared tables/data structures

john 2024-10-07T16:58:56.439739Z

But why pay AWS for what your front ends could be doing? You've got a supercomputer sitting in the collective pockets of your users. It's wild how much they're not yet being used IMO

john 2024-10-07T17:04:43.995849Z

That's what this new InstantDB is doing for you, right? Just syncing a db between your clients

john 2024-10-07T17:06:13.117269Z

Like crdts but without the hassle - your backend is just the hub. Your frontend updates are versioned and your backend just spec checks changes between clients and frontends rollback on conflict

john 2024-10-07T17:45:17.926769Z

I built a thing that does the thing - I just haven't open sourced it yet. But it's trivially easy to build. Just use a diff tool like editscript to scrape minimal diffs off your fe-db changes, send those as updates to a backend data structure that gets spec checked. The history of the app is versioned so you can time travel debug the whole thing from the synced version of the db on the backend. And then let the backend force client side updates. It's very easy to build.

john 2024-10-07T22:52:22.150299Z

Actually, here's a cljs version that's already public: https://github.com/johnmn3/todosync/blob/main/src/server/todosync/server.cljs#L180

john 2024-10-07T22:59:28.975179Z

That's a super minimal reference impl. Not much of a rollback strategy impl'd yet iirc

gaverhae 2024-10-08T16:49:04.720939Z

Going back to your original question - rum works in Clojure (in addition to ClojureScript) specifically to support SSR, so I would not expect much of an issue there.

gaverhae 2024-10-08T16:51:05.138509Z

As long as you know what app-db should look like for your first render, at least, calling the top-level rum component of your app in your server-side code should be pretty much identical to the same call in your client code.