ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Saturday, March 14, 2026

  1. phaleth2 ms response time https://images4.imagebam.com/b1/b5/16/ME1BAQWY_o.png used to range from 6-20 ms couple weeks ago
  2. bluephaleth: hi, did it go done since you reverted to node?
  3. bluego down*
  4. phalethblue: nope, the website didn't go down
  5. bluephaleth: no, I mean the response time
  6. bluephaleth: https://github.com/rcompat/rcompat/commit/f0499af05fe0148a0cd150e36073143f7b81fd7f
  7. nevetenv: remove deps, streamline · rcompat/rcompat@f0499af
  8. blue@primate/env (future std:env) 0.15 is out
  9. bluesorry, @rcompat/env, I mean
  10. bluethe new version is necessary for this https://github.com/primate-run/primate/issues/251
  11. nevetProposal: Add `AppFacade#env(key: string)` · Issue #251 · primate-run/primate
  12. phalethyeah, bun was less responsive than node
  13. bluepema schemas btw are generally closed, this will require having the ability to specify an open pema schema, because process.env will otherwise always kill it
  14. phalethpema reminds me I should go drink my lemonade
  15. phalethAppFacade sounds very strange
  16. blueoh nvm, pema schemas are open, I should change that
  17. blueit's not stranger than a RequestFacade :P
  18. bluehm, well, 'open' is a weird way to put. it does ignore unknown values, but doesn't through on them
  19. bluethrow*
  20. bluewell the idea of a Facade is that you don't expose everything
  21. blueso a primate RequestFacade doesn't give everything that a WHATWG Request has. it has a few things extra, and hides some ugly impl details
  22. bluean AppFacade is the same. you don't want/need the entire App object
  23. blueit's jst an abstraction. but calling it just Request or App is confusing. especially in the case of Request where the type is already held by WHATWG Request and we'd be shadowing and confusing people
  24. phalethwhy would there be an App type in rcompat?
  25. blueit's a primate proposal
  26. blue13:39 < blue> the new version is necessary for this https://github.com/primate-run/primate/issues/251
  27. nevetProposal: Add `AppFacade#env(key: string)` · Issue #251 · primate-run/primate
  28. phaleththen call it server?
  29. blueit's not a server, you can't stop. it's really app info
  30. bluestop it*
  31. blueit's a very limited facade atm, anyway
  32. phalethwhat about Config then?
  33. bluehttps://github.com/primate-run/primate/blob/master/packages/core/src/private/app/Facade.ts
  34. blueso it has: config(path: string), which gives you access to the config using a path
  35. blueview(name: string), which gives you programmatic access to a compiled view file
  36. blueand get root
  37. bluehttps://github.com/primate-run/primate/blob/master/apps/website/routes/docs/%5B...page%5D.ts
  38. blueyou see how view() is used there?
  39. blueconst { html, toc, md } = app.view<Component>(`docs/docs/${$page}.md`);
  40. blueI need to embed the markdown file's data within the svelte component
  41. blueand I need to do it dynamically, based on the path
  42. phalethso it's some sort of a root class
  43. blueyeah. and in 0.37 it will get a useful env object
  44. blueso you'll be able to do app.env.STRIPE_SECRET and you get automatic typing, as a string
  45. blueor app.env.PORT and it comes as a number
  46. bluethis will be based on the schema you provide in app/config.ts
  47. phalethok, then I guess env should be a thing of it's own as not in all cases the whole env should be queried at the root of the app
  48. bluethe schema will do a runtime check so the app won't start with a STRIPE_SECRET
  49. phalethI mean some frameworks do that, but it can bring in bloat
  50. blueI actually debloated this, in @rcompat/env 0.14 I used dotenv
  51. bluein 0.15 I just wrote a parse myself, it's like 20 lines
  52. blueparser*
  53. bluethere's not a lot of bloat going on here
  54. bluethe two key advantages to this proposal is: hard failure when you didn't configure a required env key, and strong typing for those keys, if you need it
  55. phalethby bloat I mean a lot of env vars that can be in the current shell or whatever
  56. blueI think the former is important, becaus you could get silent weird failures when some env vars aren't configured. the latter one is aesthetics
  57. blueyes but these get loaded anyway by node into process.env
  58. blueyou can't really avoid that
  59. phalethok, well, if process.env just works, then I'd not bother with any of that
  60. blueit does but you have .env files + as I said, runtime validation
  61. blueapp#env just gives you a nice centralised way to access those env vars in a controlled way, otherwise env vars are too loose
  62. blueof course as a user you can completely ignore it and go with process.env
  63. bluebut I don't see a lot of advantage
  64. blueso one of the things that annoyed me the most deploying nevet (looking at you, dreamreal) is that I had no idea what's up with the env vars. some of them weren't documented. and this stupid framework just starts up without checking if the envs are set, that's terrible
  65. dreamrealWhich ones aren't documented? The user docs and deployment docs should cover every one of them. If there's one that isn't described, it should DEFINITELY be filed as a bug, because that's the author screwing up
  66. phalethyeah, but it's dev's responsibility to warn or error when some input is missing
  67. phalethand I think that obscure error was because of some jdbc whatever thingy
  68. dreamrealand blue: when you have content for primate.run, let me know - I want to write it up on bytecode.news (the site's coming together)
  69. phalethwhich is a library itself and if the library is bad well then everything with that library is bad
  70. dreamrealwhat?
  71. phaleththat was meant for blue, and I agree that there should be as much compile time checking as possible
  72. phalethbut env vars are used for all sorts of crap, not just configs
  73. dreamrealone of the things I'm gonna have to figure out for nevet is how to provide access to more LLMs: right now it's anthropic and that's it, you can't "configure openai and not anthropic" and get openai, and you can't combine them
  74. bluephaleth: the BEST way is self-documenting code. nothing beats: `host: p.string.url({ protocol: "jdbc" })`
  75. bluethis is the angle provided by AppFacade#env
  76. blueI'm so tired of writing @rcompat/*, I wanna finish up flog so I can start using std:
  77. bluetbht, I have no idea how I'd keep primate compatible with node/deno/bun then :(
  78. bluefor node you can rewrite imports, but it's black voodoo magic and doesn't work deno/bun
  79. bluewould be cool if the runtimes supported rewrite rules in package.json
  80. bluebut I can also see how that leads to absolute catastrophes
  81. blue@rcompat/* will always stay aligned with std:*, so if I could rewrite std: onto @rcompat/* for non-flog runtimes, that'd be supreme. unfortunately I'm not sure that's possible
  82. phalethif somebody uses primate to develop their apps then they will use whatever feature the runtime offers and if clanker tells the use this shiny bun feature, they will use that bun specific feature and think it's very convenient, clueless about rcompat being already there
  83. blueya, but that's not the point. I'd like to use std: *myself* in primate code
  84. blueand I can't do that as-is since it wouldn't run on any runtime
  85. bluefor that, the runtime needs to know what "std:" is. and no runtime supports that atm
  86. phaleththat's the burden of being a library author
  87. bluefor node, you can register loads so I could simply map "std:*" to "@rcompat/*
  88. blueloaders*
  89. bluewhy is the js landscape such unregulated dumpster fire
  90. bluehaving a sane std is like the absolute basics in every language out there
  91. phalethlet me bring you some news
  92. blueexcept, uh, js
  93. phalethhah, this looks very retarted https://dev.to/gabrielenache/vite-8-is-here-and-it-changes-everything-about-frontend-builds-45ci
  94. blueyes, that's totally dumb
  95. phalethvite brought it's rust tools to the stable version couple days ago, replaced esbuild and rollup with rolldown
  96. bluerolldown achieves nothing over esbuild
  97. bluehaha
  98. phaleth"The JavaScript ecosystem has been plagued by fragmented tooling for years. Vite 8 is a serious step toward ending that era."
  99. phaleththat totally sums up the bullshit post
  100. bluevite is a dumpster fire I would never touch for the life of me
  101. blueall you really, ever, need, dot, end of sentence, is esbuild
  102. phalethyeah, webpack is better
  103. bluebtw I'm pretty sure this post was clankered
  104. blueit sounds like chatgpt wrote it
  105. phalethyup
  106. blueI keep getting too many requests on gh
  107. bluethe site is literally unusable