ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Tuesday, May 19, 2026

  1. bluehi phaleth
  2. blueI just pushed out a few things, amongst which: reverting markdown db, adding entrypoints and converting the website to use that
  3. blueyour pr might be obsolete by that
  4. blueyou can redeploy the website, and the memory footprint should go back to normal
  5. bluethis was a bad pivot on my part
  6. blueit's two different use cases: a docs website benefits immensely from bundling in the mds. and will later use target=static. a dynamic website can just save the .mds in a db, render them on request and/or cache the rendered out if necessary
  7. blueI'm standing down from the markdown db, at least for now
  8. phalethhi blue
  9. phalethoh, right, there are conflicts
  10. phalethwow, everything is gone
  11. blueI'm not sure your pr is needed
  12. blueya
  13. blueyou don't need to copy snippets/docs anymore, so you can revert the Containerfile to how it was before
  14. phalethoh, you've added entrypoints, that's why
  15. blueyes
  16. phaleththat's cool, lets try that
  17. blueworks locally
  18. phalethgetting these errors with npm run serve
  19. phaleth[ERROR] Markdown document backend not found
  20. phaleth[ERROR] Markdown document index not found
  21. phalethpages are not showing
  22. phalethyeah, so I should rebuild core and so on
  23. bluethat's old stuff
  24. bluethat's markdown db
  25. bluenpm run build:packages
  26. phalethnice, the site works quite well
  27. blueyes
  28. blueand memory hogging should be gone
  29. bluemarkdown db was a majorbutt time waste
  30. bluewell, at least perf metrics caught it
  31. phalethyeah, I mean that's fine, you have to experiment
  32. blueI don't mind experimenting, but the empirical data was clear. a 3x memory increase isn't acceptable, and also I don't like shifting stuff from build to serve
  33. bluebuild should be the heavylifter, serve should be optimising for memory consumption
  34. blue158MB was *already* much for serving what is essentially a static website
  35. blueunacceptable, really. should be in the lower 10s
  36. blueI really need to work on dog/flog because all modern js runtimes are memory hogs to no end
  37. phalethat least now you know a little more about how to get closer to having most of everything done at buildtime
  38. phalethalso me, I know that primate is very flexible :D
  39. bluewell, I'm glad this detour birthed entrypoints, because we were missing flexibility there
  40. blueso, good job there
  41. bluestatic is now a dumbed-down dir
  42. blueso we got less magic
  43. blueat some point, we'll arrive in reality :P
  44. phalethyeah, just wondering if there is anything else where primate website really needs a dynamic server
  45. bluenot really at this stage. it's essentially a static website, we just need target=static to be spitting out html pages
  46. blueentrypoints might getting extended syntax with { in: "file.ts", inline: true }, just to make sure that colorscheme stuff is processed as quickly as possible, those bytes are't a huge price to pay per html
  47. phalethinline into html? prolly a good idea, yeah
  48. phalethalso if you could add defer attribute that'd be great, cause the other app js bundle might need that
  49. blueso { in: p.string, defer: p.boolean.default(false), inline: p.boolean.default(false) }, ya?
  50. phalethI think there is one more attribute to the script tag that could be useful
  51. phalethlet me dig
  52. phalethasync https://javascript.info/script-async-defer#async
  53. phalethmaybe you could make those two referable by script.async and script.defer
  54. bluemhm
  55. phalethso there is also a smaller chunk of css with colors, that's cool
  56. phaleththat means there should really be no flash even when the website opens on a toaster
  57. blueya