Chat Logs

  1. phaleththere's gonna be a police lurking and banning startups for life in the cyberspace https://freebsdfoundation.org/blog/getting-ready-for-the-cyber-resilience-act/
  2. blueheh
  3. bluethe biggest security risk for freebsd is probably having been infiltrated by woke activists
  4. bluebtw phaleth
  5. bluehttps://nevet.repopack.app/features
  6. blueI got it working
  7. phalethcool, it responds with a json, no clue what the data is about
  8. phalethfreebsd foundation is just posting about that on their blog
  9. phaleththe message is that companies will be required to make their SBOM public, but still, might wanna read that blogpost anyway
  10. blueyeah
  11. blueisn't publishing SBOM good though?
  12. bluelike, it shows you're up to date on your supply chain
  13. phalethnot sure, possibly it could required also for websites
  14. blueis that bad?
  15. blueanyway I always try to use as few deps as possible, I doubt that's gonna affect us greatly
  16. blueit's only gonna affect the deps-narcos :P
  17. phalethme too, but the thing is that software still decays
  18. bluetrue
  19. phalethmaybe a good time to start thinking about SSG for primate? at least for Svelte so that primate website can be processed
  20. phalethand markdown and the other few deps
  21. bluewhat's your understanding of SSG? producing only HTML at build time, instead of a .js bundle?
  22. blueit's probably better from a security POV...
  23. phalethproducing a jamstack site, where html, css and js are separate
  24. phalethjs should still leverage the dynamic import trickery client side and also fetch APIs and all the other relevant browser APIs
  25. blueyeah but what's the advantage of that versus the default monothilic build target?
  26. bluemonolithic*
  27. phaleththe advantage is that everything happens client side and all responses from APIs and other resources are merely static and always predictable, there is no database, no session, no anything on a remote place
  28. phalethand so there is no possibility to compromise the remote site
  29. phalethcause you know the remote site has dependencies to do all of it's dynamic processing
  30. bluebut the current primate website doesn't have any session/database anyway
  31. phalethand those can decay and so become compromised
  32. bluehm, fair
  33. phalethwell, but it still requires a server side runtime for dynamic processing
  34. blueyeah, I agree, the only thing here is that the server side runtime is basically almost an nginx replacement at this stage
  35. bluethere's almost no dynamism happening
  36. phalethif the website was static and ran only on say caddy then there are two deps, caddy and golang
  37. bluemhm, true
  38. blueso you want a --target=static for primate that generates an HTML file for every route?
  39. bluethese HTML files all embed the same JS and CSS
  40. phalethdon't remember how the primate cli works, but yeah
  41. bluethe only real question is how fetch-browsing then works. currently when you click a link in primate, it'll get you JSON for the next page
  42. phalethhtml should not embed anything if possible, it's a waste of cache opportunites for browsers
  43. bluewhat if we generated *one* html file, but that would contain embedded json?
  44. bluehm, still wouldn't work for search engines
  45. phalethsince the json is static it's fine and json should not be cached anyway, but js and css and images are different story and should be separate
  46. blueso what about this
  47. bluewe generate many html files, one per page. they contain all the HTML needed to show the page + js (for example, for switching between light/dark scheme)
  48. phalethbut consider adding content hashes to json filenames as well and then it makes sense to cache those
  49. bluebut in addition, we generate a content.json containing all the content, again
  50. blueso that when you click, it can replace it
  51. phalethcontent-1489g47sdf8.json
  52. blueonly problem is that json file would be huge
  53. bluesince we don't have svelte anymore in this scenario, we have no way of saying "this is the dynamic part"
  54. phalethwell, I'd say smaller than html
  55. phalethby about 30%
  56. bluehow? it would contain the HTML for every page
  57. phalethah, I thought it'd only have the data, but that's fine too
  58. phaleththen it's equal to the size of current html
  59. blueso my question is how do you do fetch browsing in this scenario. or well in this case client-based browsing, no additional requests after the first one
  60. phalethhmm, nope
  61. phalethjamstack is about making aditional request for anything via say fetch API, but only as long as that anything is not dynamically processed
  62. phalethit can be a static pre-rendered json file
  63. phalethwith response headers so the browser can aggresively cache it: content-4gf59d4sg8.json
  64. blueyeah but how do you see this working. I access primate.run/docs, I get the full HTML. then I click on /docs/quickstart, what happens?
  65. phalethhtml loads js file in the header and js fetches json
  66. phalethin the header to avoid layout shifting
  67. blueso the js fetches content-quickstart-somehash.json?
  68. blueand what does that contain?
  69. phalethyup, only when on that page
  70. phalethcould be html
  71. phalethmight as well ditch svelte and use htmx at this point
  72. blueindeed
  73. blueif you're getting the whole HTML, you'll lose things like scrolling state on the left bar
  74. blueI'm not sure SSGs have thought this through properly
  75. blueif you collapse the svelte world into a dumb html world, you can't replace custom nodes anymore
  76. bluewell you could, but you'd again need some js logic for that
  77. phalethcan manage the state client side using other means than just js if needed
  78. blueso you're building a UI again
  79. phalethI think htmx has that figured out too
  80. bluehm, I have a different proposition. we keep svelte, but it's running only on the client
  81. phalethbut anyway, it's not a problem of svelte, cause originally svelte was a client side only framework
  82. phalethyeah, svelte is fine
  83. blueand instead of fetching JSON for every click, it fetches a combined all-data.json on the first request. after that there is no subsequent request to the server, at all
  84. phalethmight as well ditch it and use poly again, cause of svelte 5's server side stuff
  85. bluethis combined json contains per data for the list of components and their data
  86. blueper page*
  87. phalethyeah, but that's a lot of data and you'll see SEO penalties
  88. bluewhy? the SEO doesn't need the JSON file
  89. bluethe SEO sees the html, the json can be loaded lazily
  90. blueand primate.run can work completely offline, too
  91. phaleththose tricks you describe used to work in the past, but not anymore, bots are way more clever nowadays
  92. blueyou just need the original request, then you're done
  93. phalethand of course any documentation site should work completely online and be servable using: python -m http.server
  94. phalethoriginal request?
  95. blueyes
  96. blueI do GET /docs, I get the HTML for docs, and also the /data.json which contains all component data I need for every other page
  97. blueso the website can work completely offline after the first request
  98. phalethyeah, but again that data.json combined is huge
  99. phalethah, you mean if the server goes down
  100. phaleththat scenario is not possible
  101. blueI mean if I'm offline
  102. blueI can also literally save the HTML file and it works
  103. phalethwell then get better interwebz and do not browser primate.run when going through the tunnel or something
  104. blueheh
  105. phalethalso if you go offline
  106. blueI wonder how big that data.json would get: you know, it only references a list of components and their data. it just contains the inner HTML for docs, and the data for the navbar
  107. bluemaybe 1-2 MB?
  108. phalethand the site is properly split as I described above, and you have visited the page you navigate previously, you will get a cache hit
  109. phalethso the page should load for you
  110. blueyes, that would work under the scenario I'm proposing jsut the same
  111. phalethand if you are in doubt you can always employ what some jamstack sites do, that is a service worker
  112. blueyes
  113. phaleththe bigger the site grows the bigger the data will get
  114. bluelet me ask chatccp
  115. phalethclanker will tell you to use hugo
  116. blueI'm not using hugo, hugo is dumb
  117. blueall SSGs are total garbage. there's no way to edit posts in an editor in the browser and they all expect you to have nvim
  118. bluethat's why I'm building priss, so I can edit primate blog posts in the browser and get direct feedback on how it looks
  119. bluethose SSGs aren't able to separate mentally the build phase from the run phase
  120. bluewhat I want is wordpress comfort during/before build phase, and SSGs comfort during run phase
  121. bluesomehow nobody had that idea until now
  122. phalethheh, yeah, hugo is just re-doing everything and depends on many things so it has to be run from within docker build
  123. phalethI think only the zig SSG framework checks if a page is already rendered using some sort of hashing tricks, but prolly not
  124. phalethbut I don't remember it's name
  125. phalethzine
  126. blueso the idea of priss is, you have dev mode. like `npx primate`. during that, you can access an in-browser editor that allows you to create content (pages/posts). you also get immediate feedback when editing their markdown (splitscreen).
  127. blueduring build though, this whole /admin area doesn't exist, like at all. we just generate those HTML pages. so unlike wordpress it's not possible to edit pages while the site is running
  128. phalethyou mean edit the page from devtools of the web browser?
  129. blueno, I mean edit the page inside your browser
  130. phaleththat'd be cool, just no idea how it'd work
  131. phalethok, but then you need some kind of editor like wordpress has
  132. phalethi forgot the name of that react thing
  133. bluesplit screen: textarea on your left, preview on your right
  134. blueyes that's no problem. this component is only used in the /admin area. the /admin area doesn't get bundled into the built website
  135. blueyou mean tinymce or whatever
  136. phalethsounds too complicated, someone like me would just use IDE to edit markdown and have esbuild to reload in the web browser
  137. phalethI think wordpress calls their editor gutenberg
  138. phalethbut it's a huge pile of react code
  139. blueyeah but someone like you isn't the target audience
  140. phaleth:)
  141. phalethI mean for starters it's fine to just use a code editor and have esbuild wrapper run in a console
  142. blueit's fine, but I wanna do more than that with priss
  143. bluebtw chatgpt said it's better to split the jsons
  144. blueyou win :(
  145. bluesomething something prefetching
  146. phalethyeah, well, jamstack is a super old concept that just works
  147. blue`You can keep “SPA feel” by prefetching the next page’s JSON on hover/viewport and caching in-memory (and/or Cache Storage).`
  148. phaletheven nowadays with all the nextjs or whatever bullshit rendering strategies
  149. phalethyup, browser already know what to do, just setup the HTTP server properly is the answer
  150. bluefor fully offline, it said it's better use a serviceworker and add --target=static:offline
  151. blue`Generate a service worker that precaches all HTML + page-data + assets (or a configurable subset)`
  152. phalethalso prefetching on hover is an old trick at this point
  153. blueyeah it sounds dumb to me though
  154. phalethand service workers also work well in all browsers
  155. phalethyeah, I'd not do prefetching on hover, thinking of mobile, anyway
  156. blueyeah that's dumb
  157. phalethusing on hover is dumb
  158. phalethexcept for changing colors slightly
  159. blueso I guess we'll do --target=static, and that generates docs/index.html, docs/start/index.html, and docs.json and docs-start.json
  160. bluesvelte becomes clientonly
  161. bluethe only thing I need to consider is if I move primate website to priss, what's the frontend of choice for priss
  162. blueideally should be chooseable
  163. phalethI'd recommend doing just svelte for now and bother with something else when somebody asks
  164. bluek
  165. bluephaleth: https://github.com/primate-run/primate/issues/253
  166. nevetProposal: `--target=static` (SSG output + client-only runtime) · Issue #253 · primate-run/primate
  167. blueI went over it and removed most of the ai slurp
  168. blueit had some interesting ideas like 4)
  169. bluethe proposal is mostly aligned with your suggestion, anyway
  170. phalethheh, nice
  171. phalethyeah, if json is embeded to html then there is no need to configure the HTTP server to add cache headers to json mimetype
  172. bluewell yeah, it's just the current page
  173. phalethright
  174. phalethwhat's weird that it suggest to use script tag for the json with type="applicaton/json", I'd recommend to use template tag https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template
  175. nevet<template>: The Content Template element - HTML | MDN
  176. bluebut template doesn't contain data, I think that's the difference
  177. phalethhmm? I mean the json could be inside template tag instead of the script tag
  178. phalethscript element will get evaluated by the browser
  179. bluehow does that help you? I thought <template> should be reused
  180. bluein combination with <slot>
  181. phalethhmm, nope, you can put template on the page as a data container for say JS to grab the data later
  182. phalethslot is a webcomponent tag I think
  183. phaleththe purpose of template tag is that it's not being rendered
  184. phalethand so browsers don't bother with it too much, except putting it to DOM
  185. blueah, that's cool
  186. bluecould you add a comment about that at the issue?
  187. phalethI can try logging into github, yeah
  188. bluecool
  189. blueawesome
  190. bluephaleth: I need to prioritise stuff for 0.37
  191. blueperhaps you can help
  192. phalethwell, that's easy, use primate for anything and whenever you run into a bug or something that you need then just update primate, rcompat or the rest
  193. phalethlike for example the thing we ran into yesterday that package.json is required at runtime for a prod app
  194. blueya