One reason Next.js does not work perfectly on Bun right now is that they override 'Module.prototype.require', aka the "require" function for all CommonJS modules.
@thorstenball
i like to think of it in frames. 16ms is one frame on a 60hz display. if you can do an action in under that time, it is quite literally instant.
you can import "bun:test" in any file now. it lets you do some useful things but also you can be really silly. i wonder if setSystemTime has any non-test applications.
@bunjavascript
oh btw, huge internal changes to help the upcoming windows build. for example, youll notice that "node:path/win32" module actually works now. lot of other subtle things changed too but i think the rest arent too clearly visible
fixing up lot of bunx edge cases on windows. dont have a good screenshot that will wow anyone, but i will be able to say it works as expected.
it has a lot of special paths to do things faster. alot of which are only doable on windows. some are because windows forces me.
@imUnsmart
@jarredsumner
it's nearby a "fixes ..." comment and the issue i mention is related. the full line is
"Does not fix
#4660
but this probably lays out most of the work for it to work."
i started working on a really nice TS library to interface with
@OpenAI
's new chat + functions api. the defined "weather" function gets called in order to respond, since the prompt is asking for it.
also supports streaming with async iterators. will publish tomorrow or so
@Joshument
@uwukko
its a result of css modules or similar techniques that allows you to have per-component styles where the actual class names might be the same, but when compiled theyre mapped to something else to not conflict with each other (). its a better dev experience.
@jarredsumner
its always annoyed me that the process already recieves sigint -- meaning in almost every case answering no to "terminate batch job" still terminates the application.
the more software i see that claims it is fast *because of* the language it's written in, the more i want to never write any software ever again. the reason fast software is fast is because of technical decisions made along the way writing it.
been doing some frontend stuff and for simple projects, i do not see the need to use anything complicated.
this project is single page and i am going to fit the entire frontend under 10kb before gzip.
@wojtekmaj91
@jarredsumner
way earlier when i was testing this, i ran an http stress test benchmark on the dev server (not really a realistic thing) and it was something like twice as fast.
(this is off memory so don't quote me)
instead of using node version manager, i have a ten line shell script which re-downloads and installs such program. anything more complicated than this is silly.
I'm making a web framework with
#reactjs
(server components support) and bun (
@oven_sh
). here's an HMR demo with the first build in 20ms, and client components reloading in ~5ms per change.
very experimental
i hate that the price to recover my data is quite literally an order of magnitude above the cost to buy cloud storage for the entire time i've been alive.
this thing i'm going to pay for is the biggest waste of money in my life for the stupidest mistake ever: forgetting backups
Fun Fact: powershell can copy directories without -r, but it will only copy the directory without the contents. On unix, trying to do this fails. Didn't realize till now that I pushed a build without headers.
to keep my password manager safe, i store it's password in a different password manager. i think i have 3 or 4 of them, storing each other's passwords.
migrating from yarn and pnpm will come later; most of the work for that is going to be on writing parsers for their lockfiles, and then reusing this 'package-lock.json' -> 'bun.lockb' code.
They also override 'Module._resolveFilename' which is an observable node internal that is sort of the internal implementation of 'require.resolve'. I knew about this one for a while, but somehow I didn't see the require override until just now.
@uncentr
yes it is technically how let works but this in the context of a repl:
- always reporting undefined is often unhelpful
- once you declare a let you can no longer put another let, which means you cant uparrow+enter a command you typed.
been kinda on a spiral of being mad because people say that LLMs do way more than they really do. every use case seems to be a demo, but applying it into larger tasks falls apart in subtle or explosive ways.
probably gonna cancel chatgpt+, humans can create better art
@iddar
@jarredsumner
I'm going to be spending most of my time tomorrow before the release trying as many vite plugins and configurations to make sure everything works. i know there is one bug still preventing sveltekit but it's being worked on already.
@jarredsumner
can be fixed by uninstalling coreutils
i don't think we should be using them in our windows tests, especially considering we implement almost all of the apis exposed there within bun.exe
it would be funny if typescript autocomplete had a list of every function from every npm package so you could just autocomplete any package, like if you typed `init`, you would get like a million completions for every function named `init()`
These issues aren't hard to fix, but they cause slowdowns considering our module resolver is entirely in native code. It's also funny to see the ways that people hack into node internals (footnote: in node you can override 'fs.readFileSync' to alter how require loads source code)
@thorstenball
still waiting for better zig support, the `gq` vim binding to reflow text, auto-save, and maybe some more light themes.
currently it's at the point that in non-zig programs i flip between vscode and zed depending on the action.