Community
Chat Logs
Sunday, May 17, 2026
- phalethno flash!
- phalethnot even on epiphany
- phaleth16 files changed
- bluephaleth: hi. how did you do that?
- blueI'm working on markdowndb btw
- blueI think markdown as a traditional frontend. really makes no sense. it doesn't get props, and it doesn't have logic
- blueinstead, we're going to have a store-like interface around it that queries the data in real time in dev, and in prod inlines everything
- bluethe inline part is hard, because that possibly requires access to app, and dbs don't partake in the app lifecycle
- bluephaleth: dreamreal: https://dpaste.com/3QSFU543W
- bluethen on `BlogPost.get("primate-39"), you're gonna get { html, toc, path, body, frontmatter }
- bluethe only tricky part is to have this operation loads from the fs in dev, and from memory, as part of the bundle, in prod
- blueload*
- bluebut markdowndb is the key to unlock full cms capabilities
- phalethblue: hi
- phalethcan you check the last PR on primate repo?
- phalethI'm looking for a post-build handler or something like that
- phaleth*latest PR
- phalethwhy is it called db if it's not overridable?
- blueI'll check it phaleth
- bluewhat do you mean with no overridable?
- bluenot(
- bluenot*
- phalethmarkdown files are static I guess
- bluethe problem is we want different behaviour during dev and prod. in dev it's acceptable to load / transform the mds on the fly, in prod it isn't
- blueplus, primate/website has different addons like transforming snippets which makes everything more complicated
- blueI wish I had a good solution for it, I currently don't
- phalethso the db is like a cache for md files?
- phalethmight was well just transform them to html and let the site be static
- phalethbtw, the PR I opened is getting towards that, just need to figure out a build step, I could slap something together after build, but I'm wondering if there is something primate specific
- bluethere is `app.done`. I don't like it, but you can use it
- bluehttps://github.com/primate-run/primate/blob/master/packages/native/src/private/module.ts#L29
- bluethat's essentially a postbuild
- bluethe thing is that I want something in between "fully static, separate HTMLs" and "load/transform mds in dev mode"
- blueI do like the fact the current solution bundles everything into one server.js
- blueforcing you to otherwise always do --target=static could be a regression
- blue(or copy the .mds to production and load them on demand)
- bluealso we reason about the mds in some routes
- bluehttps://github.com/primate-run/primate/blob/master/apps/website/routes/llms.txt.ts
- bluehttps://github.com/primate-run/primate/blob/master/apps/website/routes/llms-full.txt.ts
- bluethese two would be a catastrophe without caching
- phalethcaching server side you mean?
- blueyes
- blueobviously in a world of --target=static, you just build llms.txt into llms.txt.html once and you're done
- phalethjust take a look at the response time here, it's not so bad https://grafana.repopack.app/public-dashboards/ce90d22ed104477ea945d2c35aa8d3d7
- blueit's not bad right now because it's all precompiled in memory
- phalethif the website gets busy then you can bother yourself with that, but then SSG and running the site on nginx would solve all those problems
- phalethyeah, and memory is fast
- blueyes but @primate/markdown is just for apps/website, I'm trying to rethink it as a general cms-like solution
- blueisn't just*
- phalethdid you see the response time? :)
- phaleththere is not much to gain
- blue9 ms?
- phalethyeah, deno is kinda slow, but still acceptable
- blueno let's optimise it to 0.5 ms </sumner>
- phalethheh, then that means it's nginx
- blueyeah I was joking, 9 ms is totally acceptable for now
- blueso my point is
- blueapps/website is actually not the issue here. it'll get --target=static and be happy with its htmls. especially with your colourscheme work
- bluethe issue here are other apps. I have this small apps where I keep notes, like obsidian, and the 'load from fs' is fully acceptable for it at least in dev mode
- bluesmall app*
- blueso essentially this is a caching problem
- blueyou don't want to run the expensive md > html pipeline on every request
- blueyou ideally only want to run it when the source has changed
- bluefor the fs, you could do a small `stats` check I suppose and compare against what you last saw
- phalethok, so then it's a store, it's not a db
- blueyes it is a store, it'll be exposed as markdown.store
- blueand you'll have programmatic access to the frontmatter and also partitioning
- blue(say if you have i18n)
- phaleththe github experience https://images4.imagebam.com/6a/e8/8a/ME1D55XF_o.png
- blueoh wow, that looks like garbage
- blueI think what we need is
- phalethyeah
- blue@primate/markdown.store becomes the new way to use markdown, and --target=static is how we solve the caching problem for apps/website
- blueI still don't know how to tell --target=static though how it should generate pages based on a parameterised route
- bluebut yeah, all of this still doesn't solve my major conundrum during dev which is that apps/website takes way too long to start up, and recreate the bundle
- phalethyeah, primate website takes a while to startup in dev mode
- bluemaybe, markdown.store runs all the pipeline on startup (or if you don't care, you can pass in lazy: true).
- bluein dev mode I'd generally go lazy, I think
- blueand the website would start up immediately
- blueso every docs page is converted on the fly, and then cached until stats has changed
- blueand in production, --target=static takes over, so laziness isn't relevant, everything gets produced during build
- bluemaybe I don't even need lazy: true and it's always lazy, and always cached
- blueI think this is a good compromise
- bluebut this requires markdown stores and --target=static to arrive in the same commit
- blueotherwise we can't meaningfully deploy the website, it'll be slow on first requests and you'd need to copy .md files and the snippets directly and what not
- phalethcool, looking forward to static target
- blueya
- phalethI have a FileRef to a text file, now I need to replace contents inside the file behind the FileRef, how to do that with rcompat?
- phalethnpm install replace
- phalethomg
- phalethwrite method exists
- blueyes
- blueif it's an object you want to write you also have writeJSON
- bluethat will write it out as a JSON string you can later load with #json
- phalethit's a JS file
- phalethplain text
- bluecool, then just #write
- phalethwrite works, I just don't know how to read the file
- bluetext()
- phalethah, ok
- bluedo you want to read it, or import it?
- phalethnice, that worked
- bluecool
- phalethblue: any clue why is the browser getting the unminified file? https://images4.imagebam.com/61/fe/8d/ME1D57VH_o.png
- phalethI've just pushed the changes, but why is that JS file served unminified and with the correct filename containing the hash is a total mystery
- bluephaleth: where is that file located, in static?
- blueit looks like esbuild chunked it
- blueit should be minified though
- blueoh, it's in static
- blueare the js/css minified?
- phalethyeah, I guess that file being in static dir is the problem, so I'm gonna run it through the bundler even for dev
- bluewhat I'm wondering aobut is how come this didn't land in app.js. it should
- phalethno, it should not, that's actually the goal
- blueoh, ok
- blueshould still be minified
- phalethit's supposed to be it's own chunk
- phalethyeah, everything is minifed, it's just that one file originaly from static dir is served verbatim
- bluehow did you achieve chunking?
- phalethI'll just make it a ts file and make it part of the build for dev
- phalethmagic :D
- bluelol
- phalethtake a look at app.html on the PR
- blueoh
- blue<script src="scheme-storage.js"></script>
- phalethlooks like I can have a client dir as part of the project
- bluehm, I still believe primate scans the static dir for js/css and incorporates it
- phalethok, then I should move that to client dir
- bluewhat does that client dir do?
- blueI'm discovering things about primate I never knew existed :P
- bluethat's fairly wonderous, given I've written nearly 100% of it myself, haha
- phalethI hope if I put the file in client dir it will end up in build/client
- blueI don't know what that hope is based on
- blueis that documented?
- phalethit's a flat out hope
- blueoh
- blueprobably not gonna work
- phalethI don't tend to look into documentation
- blueya
- bluesame
- bluedocs are for idiots
- phalethso what should I use instead of the static dir?
- bluewell generally speaking, %head% is your friend
- blueyou shouldn't hard-encode scripts into <head>
- bluelet me see what's the way to latch onto %head%
- blue .replace("%head%", render_head(this.#assets, head));
- bluelet's see how #assets is populated
- phalethI can get FileRef to app.html
- blueok, AppServe#publish does that
- phalethbut you know the app.html ends up being in server.js when in the post build phase
- phalethnot sure if the %head% thing is still in place there, but let me see
- blueya
- bluehmpf, I don't see anyone calling publish really
- blueis this mechanism even in use anymore
- blueI think esbuild completely replaced it
- phalethah ok, the %head% is still there
- phalethyeah, so that means esbuild has put the scheme-storage-blahblah.js into head and that's why it's served verbatim
- phalethbut I need to chunk it out, so how to tell AppServe.publish or whatever to not include that?
- blueso I think publish is dead code
- bluelook at ServeApp#start
- bluethat generates the assets
- phalethyeah, but that's in core
- blue Object.entries(this.#serve_assets.client)
- bluelet me see who populates that
- phalethor not? I was hoping there would be a handler I could hook up to from within Website.ts
- phalethisn't there onServe?
- phalethI think I've deleted that one
- bluethere is, yes
- phalethI have no clue what to do
- bluewhat are you trying to achieve
- phalethexactly what's on that picture, but the response for scheme-storage-blahblah.js should be minified as you see in the text editor above
- bluepull it into the bundle then
- blueplace the file in static, esbuild will pull it in
- bluedon't worry about the rest of the stuff
- phalethno, the bundle is too big and that's why there is a flash
- phaletheven currently, there is a flash
- blueyes but in --target=static, the bundle won't contain much
- phalethnah, it will always be tens of KBs at least and that's enough to flash
- phalethalso this tiny JS is loaded before css
- phalethand that huge bundle should not be loaded before css and should not stop css for loading either
- bluebut in the future, that bundles should be basically only scheme-storage,js
- bluebundle*
- phalethbut since there is at least the content hash, I'm fine with what's currently on that PR
- blueeverything else falls away, the components, the fetch navigation, etc.
- blueyou can simulate it now by turning off CSR
- bluesvelte({ csr: false })
- phalethwell, that'd mean full reloads on navigation
- bluewait, that's what we *want* to do with target static, no?
- phalethI think the proposal says something different, but hold on that thought now
- phalethI'll log into github and mark the PR as ready
- phalethand let you test that change
- phalethon brave
- blueyeah the proposal is a bit more contrived
- bluesomething like, there's a JSON file for the mds or smth
- phalethyeah, but don't worry about that
- phalethfirst please check if whatever I did works in brave
- phaleththe file is like 1.27 kBs unminifield vs 717 Bs minified
- phalethwhich is not much
- phalethno need to rewrite primate cause of that :D
- phalethcause if that works then full page reloads are fine
- blueya
- blueyeah, this markdown redo is overdue anyway
- blueand --target=static, too
- phalethfor primate website I'm gonna work on making the JS bundle size smaller, but first I need to make sure everything happens client side
- phalethand this light/dark thing is being tricky
- blueya
- phalethwhat does FileRef.debase do? gives you the filename?
- phalethor I think it's more like fs.debase
- phalethah, it expects args
- bluegive /tmp/a/b being the 'base', and tmp/a/b/c/d.js being the fileRef, it allows you get c/d.js,
- bluegiven*
- phalethah, ok, seems like it always returns the subpath with starting forwardslash
- blueya, that's unfortunate, I wanted to fix that annoying forward slash
- blueotherwise just do .slice(1)
- phaleththis this.#serve_assets.client that you've mentioned is being populated out of nowhere and only during production not serve but build I guess
