ByteCode.NewsSubmit
Use quotes for an exact word.

Subscribe

RSSPodcast
Log in

Chat Logs

  1. blue🐕
  2. bluedreamreal: dog is coming
  3. dreamrealwhat breed? :D
  4. blueyou know the answer, dreamreal :P
  5. dreamrealI, uh, might have a guess
  6. jreicherBasenji.
  7. dreamrealprobably a shih-tzy?
  8. dreamrealschnauser? dachshund?
  9. bluejust to be clear, I'm not getting a dog (yet)
  10. dreamrealmaybe a rottweiler?
  11. blueI'm working on a js runtime/engine called Dog
  12. dreamrealhaha
  13. blueWB jreicher.
  14. dreamrealnew mastheads online :D
  15. dreamreala colorized mondrian, colorized harmonizer, and two new life variants
  16. bluewow
  17. dreamrealblue: where's rcompat's site?
  18. bluedreamreal: nowhere
  19. dreamrealwhy
  20. dreamrealit needs one on primate.run at least
  21. blueidk, it was never needed I guess
  22. bluedo you need one?
  23. dreamrealhave a friend who's migrating from deno to bun, I'm like "crikey, rcompat, then you get node and bun without having to target them any more" but I have nowhere to POINT HIM
  24. bluehm
  25. bluedreamreal: give me 10 mins
  26. bluedreamreal: https://rcompat.repopack.app/
  27. nevetrcompat — JavaScript standard library
  28. blueI think this should be enough for his purposes, I don't have a bespoke domain for it atm
  29. bluein the future it'll be under std.flog.run or so
  30. bluedreamreal: you can tell him, but he probably knows, that going forward, deno support in rcompat will be sunset roughly 6 months after deno itself is discontinued
  31. blueso technically he can move now and continue to use deno, and test with bun/node
  32. bluemoving is anyway most effective, will spare a future rewrite
  33. dreamrealHe doesn't WANT deno support, but he's moving to other runtime environments, and porting TO them
  34. dreamrealso rcompat actually addresses his actual needs
  35. dreamrealbut he doesn't know that and I can't SHOW him because you don't show ME
  36. blueI just sent you the docs website dreamreal
  37. dreamreal(and showing me is pointless: show him!)
  38. bluewht do you need showing else?
  39. dreamrealwhere
  40. blue18:22 < blue> dreamreal: https://rcompat.repopack.app/
  41. nevetrcompat — JavaScript standard library
  42. bluehere, 14 minutes ago
  43. dreamrealoh, sorry
  44. dreamrealmissed it, was AFK
  45. blueno worries
  46. dreamrealSwnt to him
  47. bluegreat
  48. bluercompat itself doesn't have a suppotr channel. but he can use the primate discord or this channel for rcompat support
  49. blueI make the same promise as I do for primate, which is, I will at least look at the issue within 48h
  50. bluethe rcompat website is now triggered to redeploy on master advances :P
  51. bluetakes 22s to redeploy. hm, still too long, but then again it's using pnpm, I should move to flog
  52. dreamrealwhy is it r/compat and not rcompat?
  53. blueyou mean designwise? it's jsut what clanker came up, and I like it. I mean it is "runtime compat"
  54. dreamrealIt was a question from the guy I was talking to, he was like "was it reddit inspired of course it was"
  55. dreamrealI told him I severely doubted it :D
  56. blueyou can tell him that clanker came up with it, and the human operator approved
  57. dreamrealI'll let you do that if he ever joins
  58. blueI mean, up until 30 minutes ago, rcompat had no logo. now clanker proposed, and I didn't disagree
  59. bluewe all have to remember that rcompat is not yet eden. it is upon the gates of eden. eden is "std:*", but for that we need runtimes to hop on, and I don't have traction for that
  60. blueone of the reasons for dog is to challenge runtimes to get into that eden
  61. blueI have long pondered how it's even possible to get this done. and the only way I see forward is to use "std:", publish source TS to npm, and have `flog publish` rewrite "std:*" to @rcompat/*" for js. since node doesn't respect the "source" runtime key, it would still work for node, but anything that supports std:* + "source" runtime key, would benefit from the new world
  62. bluesystemfault: ^
  63. systemfaultHmm, so rewriting imports is the cleanest way?
  64. systemfaultWouldn't be possible to use something like require hooks or similar to allow it? (I guess the node devs don't want that...)
  65. bluesystemfault: the problem is that if I want to change primate to use "std:" imports instead of "@rcompat/", then the next version I publish like that, would stop working under node (and bun)
  66. systemfaultRight :/
  67. blueso my idea was, to publish both src (TS) and lib (JS). src contains "std:, lib contains the same imports, but flog rewrites them to "@rcompat/". and package.json uses a "source" runtime key for "src/". node ignores "source" unless you write --conditions=source
  68. blueif node ever supports std:, it would need to support the "source" runtime key...
  69. blueit's a complicated way, but it's the only way I can see to run things under node/bun until/if they add support for "std:"
  70. blueand also I've been wanting to publish TS to npm for a while. node not loading TS from node_modules is such a stupid and unnecessary limitation
  71. blueTS is the source.. why should I build it when publishing? building/type-stripping should be the user's responsibility
  72. blueI heard such weird arguments against publishing TS to npm. like, you'd have to publish a tsconfig and version it... I don't think that's a real argument. node can strip TS today and it doesn't need a tsconfig for that...
  73. bluethe only problem with publishing TS is if you use non-erasable syntax.. and you shouldn't. maybe flog could check that as well when publishing
  74. blueI think that's an elegant way forward systemfault...
  75. systemfaultThe only logic argument I can find is that they want the Node ecosystem to remain JS.
  76. bluewhy? TS is superior...
  77. systemfaultSome people just don't like TS... some people are "omgomg MS is EVIL, can't use TS"
  78. bluewell I used to be anti-TS as well, but then I gave it a chance, and it's just better. especially erasable TS is amazing...
  79. blueit's irrelevant if it comes from MS or whatever... it's good software/language
  80. bluewell, I'm gonna go back to watching die hard... I'm out of codex for now
  81. systemfaultThe first one?
  82. blueDie Hard with a Vengeance.. I think it's the third?
  83. dreamrealI don't like TS because it's TS, not because it's MS
  84. dreamrealTS types would be great if they were consistently enforced but it can use JS so it lies
  85. bluewell, it's a superset dreamreal, how do you mean, "it can use JS"?
  86. dreamrealWell, TS adds a lot of useful things like "type enforcement," for example, but types are lost once you go to JS
  87. dreamrealthis is just a generalized gripe about JS as an ecosystem, so ignore me
  88. bluethen you should be reading what I've written above; if you publish TS to npm, the only time it gets lost is when the runtime runs, stripping the types
  89. blueunless you're concerned with runtime types in your criticism
  90. dreamrealthe runtime is when I care :D
  91. dreamrealbut it's not a severe care, I write JS very rarely so I just shrug now
  92. dreamrealwhen I lived in JS-land I cared a LOT
  93. blueya