ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Community

Chat Logs

Saturday, November 7, 2026 (America/New_York)

  1. bluehi phaleth
  2. phalethhi blue
  3. bluephaleth, dog can now run jsc in addition to v8 and qjs
  4. phalethcan it already run primate?
  5. blueI doubt that
  6. phalethor at least some of the flog workloads
  7. bluefirst the dog std needs to reach parity with rcompat
  8. blueand the dog std is implemented natively, in cit
  9. blueso some of that requires cit std capabilities
  10. blueI assume dog will be able to run primate by the end of the year, phaleth
  11. bluedog 0.1 will only release once it can run repopack, anyway
  12. blueand then we can try running repopack with `dog --engine v8` or `dog --engine jsc` or even `dog --engine qjs`
  13. phalethah, yeah, but rcompat will not cease to exist, right? it's just with dog one won't have to install rcompat
  14. phalethor any of it's packages
  15. blueyes. with dog you won't need to install rcompat at all
  16. blueand primate/repopack/etc. will just use std:
  17. bluewith flog/dog, primate's dependencies will shrink to basically only the frontends. @primate/core will likely stop having any dependencies at all
  18. bluewhich is the goal
  19. phalethwell, I guess for example primate website uses only a small portion of the rcompat APIs
  20. blueyes
  21. phalethand so I'd suggest focusing only on that first, then deploy primate website on dog
  22. phaleththen observe
  23. phalethalso I thought @primate/core only depends on pema, for some odd reason
  24. bluepema + esbuild + @rcompat/*
  25. bluepema is workspace
  26. phalethbut primate 0.43 took care of server side JS being sent to client, so that does not matter
  27. blue@rcompat/* will drop in dog
  28. bluethe only thing we'd need to replace is esbuild. flog will likely replace esbuild at some point, but not right now
  29. bluethe dream stack in 2027 will be just flog/dog
  30. phalethoh really
  31. blueyes
  32. bluewe'll be running purely on our own gears
  33. phalethyeah, but esbuild is just a bundler and it has good enough APIs
  34. blueyes but flog will already contains everything it needs to create bundles
  35. bluecontain*
  36. bluebecause it has stick for `flog format` and `flog lint` etc.
  37. blueI don't dislike esbuild, but also I don't need a thousand tools all doing the same thing
  38. bluethe lesson that esbuild taught us is that Go is a bad language to write engines, but a great language to write tooling, even if they include interpreters
  39. phaleththere is not much to gain there, also mostly if it's only going to be primate specific
  40. phalethall these esbuild alternatives exist for pretty much no reason and one way or another they were either bundling or copying esbuild anyway
  41. phalethalso the goal should really be to run TS as is and be able to optimize based on types
  42. phalethbut that isn't of course going to happen cause of moving web standards
  43. phalethand you know vite is somehow holding on cause of venture capital, but once these investors bail the org behind vite all the projects depending on it will have to look for something else
  44. phalethblue: btw, take a look into aspen https://github.com/reason-machines/aspen
  45. nevetGitHub - reason-machines/aspen: A self-hostable Git server for agent-scale traffic: packs in object storage, per-branch history in Postgres. Pre-alpha.
  46. phalethI mean at lest the readme
  47. blueyeah I heard about aspen
  48. bluewe're building a git alternative as well
  49. bluehttps://repopack.com/project/repopack/tasks/850
  50. phalethheh, yeah, single file change with so many rebases
  51. liolocyou're making a git alternative??
  52. liolochi btw :D
  53. phalethhi
  54. phalethgit as a client will remain
  55. liolocbtw created https://repopack.com/project/primate/tasks/357, with it you can use primate to build to an ios simulator or ios device. Haven't actually tried notarising the app or anything like that, so this is mostly for building. I tested with a simple primate app with a react shadcn button
  56. liolocphaleth: hey! so what did blue mean by "we're building a git alternative as well"?
  57. lioloci'm confused lol
  58. phalethclassic git is just openssh on the server side, but the problem with that approach is that it abuses filesystem a lot, and also keeping files and database records in sync is difficult, so we've already thought about moving everything into postgres to keep the data in one place in the past
  59. liolocso git would just be used to push to the repo?
  60. liolocbut not for tracking actual changes?
  61. liolocno uhh that doesn't make sense
  62. liolocvery cool idea I'm just not smart enough to follow what you mean
  63. phalethnope, the functionality should remain, just the disk load and maintainability of the system server side will differ
  64. liolocah ok
  65. phalethwell I also don't understand exactly how repopack works right now
  66. phalethbut I find it kinda dumb to just slam the harddrive, so I don't care
  67. liolochaha
  68. phaleththere is openssh server and some sh scripts in the system using curl and what not, it's kinda overcomplicated
  69. liolocwow i didn't know it was so confusing
  70. liolocare you guys using any agentic framework when building? I'm trying to build workflows that I can use to create code in a controlled way, curious if you guys have any tips / ideas on that
  71. lioloci'm going to test flowise right now
  72. liolocnvm flowise sucks