Chat Logs

  1. blue_hi phaleth
  2. phalethhi blue
  3. blue_so I had a discussion with my brother yesterday about how clankerdom stifles innovation
  4. phaleththere will be less and less people learning all sorts of skills, not just software development
  5. blue_like, why do people keep using next despite its terrible record with rsc (cve of 10.0!) and the general fact that it's a terrible piece of software
  6. blue_because the clanker recommends it
  7. blue_basically at this point you're better off using vanilla js and html than next
  8. phalethand php and raw sql
  9. phalethall in a single php script
  10. phaleth:)
  11. blue_yes, perfect
  12. phalethin any case nextjs got picked up by many because it had exquisite docs
  13. blue_anything better than this clanker infested nonsense
  14. phalethone does really have to think like a junior dev and describe things that way
  15. blue_look at this nonsense
  16. blue_phaleth: https://dpaste.com/BZWAEHADJ#wrap
  17. blue_this is what a vanilla next installation produces
  18. blue_you can't argue that's sane
  19. blue_phaleth: https://dpaste.com/GP9BAKEET#wrap
  20. blue_that's what a comparable primate (+react) installation produces
  21. phalethlooks like they use tailwind
  22. blue_and the bulk of those bytes are just nonsense headers that my dumb browser sends
  23. blue_that's why primate takes <0s to load on comp, whilst next is around 2-3s
  24. phalethnowadays next is obviously able to hide a lot of important details behind their easy to use framework
  25. blue_if someone has any shred of understanding of security, he would never let rsc run in any of his apps
  26. blue_the complexity of that is terrible
  27. blue_and for no gain
  28. phaleththey probably just state next is blazing fast due to having all those rendering strategies and that it
  29. blue_I don't even understand this chunking nonsense that next does
  30. blue_the esbuild approach is easier: you chunk only on dynamic imports
  31. blue_it's kinda funny it's 2026 and people still use subpar software for everything
  32. blue_anyway, I'm gonna upgrade the RP repo to primate 0.38
  33. blue_it's still on primate .36 and I wanna continue dev
  34. phalethit's 2026 and people just want an exe
  35. blue_phaleth, did you see this
  36. blue_https://github.com/primate-run/primate/commit/485cba0b86144c60cff81802353156310ae44158
  37. nevetmove to tsgo · primate-run/primate@485cba0
  38. phalethdrag and drop it into the browser and it deploys
  39. blue_lol
  40. phalethyeah, I did
  41. phalethI assume that's also not breaking the primate website deployment from master branch
  42. blue_you assume correct
  43. blue_in fact, you overassume. apps/website does not use typescript directly
  44. blue_none of the apps does
  45. blue_typescript in the primate monorepo is used for two things: compiling packages, which is increasingly rare because I'm using live TS during, and type-checking in the editor
  46. blue_when you build apps/website, what happens is that esbuild pipes all of the TS into a single JS file
  47. phalethok, can you take a look at the PRs then?
  48. blue_I could, but I wanted to ask you. you've fixed this woff thing a few times, do I keep changing things that it keeps regressing?
  49. blue_I anyway wanted to find some solution for woff because I keep needing custom code for it and it's annoying me
  50. blue_https://github.com/primate-run/primate/blob/master/apps/website/config/Website.ts#L18-L28
  51. blue_I have 100% the same piece of code on repopack's website repo
  52. blue_I was thinking of maybe adding {loaders": Record} to the config
  53. blue_so you'd just do {loaders: {woff2: "file"}}
  54. blue_but that feels like circumventing the module API a bit
  55. blue_maybe the best way is providing a primate helper
  56. blue_`import loader from "primate/loader"; ... export default config({ modules: [loader("woff2", "file")] })
  57. blue_translates interally to a Module, but without all the boilerplate
  58. blue_but anyway your first PR only makes sense if woff2 is used
  59. blue_and a part of me feels back about hardcoding woff2 support into the code
  60. blue_feels bad*
  61. blue_what does the patch do, create a preload script tag for woff2?
  62. blue_do we need this? esbuild inlines woff2 with the module I just showed
  63. phalethyou can move that from the core if you want to, that's totally up to you
  64. phalethI'm just fixing it again, but it's not really a regression
  65. phaleththis time the problem is in a different place
  66. blue_it just adds a preload script tag, or what does it do?
  67. phalethyeah, the code for adding that preload tag is fine
  68. phaleththe bug is not there
  69. phalethI mean the preload tag creation was already there :)
  70. blue_oh, so what is the bug
  71. phaleththe bug is that woff2 files are ignored by that magical thing dynamically processing assets
  72. phalethI also think that the build system should take care of pre-rendering the tags, but that'd mean lot of rework
  73. blue_the script tags?
  74. phaleththink header at least
  75. blue_it does create script tags
  76. phalethat build time?
  77. blue_oh, you want at build to create html files with the script tags already baked in?
  78. phalethyeah, but don't worry about that now
  79. phalethit's fine as it, cause it just works
  80. blue_lol, I just did `npx primate build`, and build/server.js isn't minified
  81. blue_when did that get lost
  82. phalethheh