wrongcarwhy's comments

wrongcarwhy | 2 years ago | on: BiomeJS 2024 Roadmap

Yeah...but why? Like zero-dependencies is one of those things that gets you praise on HN, but it means you spend a lot of time building...terminal console abstractions and not actually shipping stuff to users.

wrongcarwhy | 2 years ago | on: BiomeJS 2024 Roadmap

For TypeScript specifically there is some justification in that the TypeScript compiler is rather slow, so any speed benefits of Biome would go away if it relied on TypeScript for type information.

But as a whole, not-invented-here syndrome has plagued Biome/Rome for the entire lifespan of the project. Like take a look at their error reporting code[1]. They made their own markup abstraction with their own Display trait and Write trait and a proc macro on top of it. It's cool code and probably does produce very nice error messages, but they could have easily used off the shelf crates like miette or ariadne and moved on to more important tasks.

Or even their JS parser. It's a really nice JS parser! Maybe the best in terms of error reporting and AST resolution. But they could have easily used swc and maybe shipped the actual end-user products a little faster.

[1]: https://github.com/biomejs/biome/blob/main/crates/biome_cons...

wrongcarwhy | 3 years ago | on: Why we added package.json support to Deno

Reading the reasons...I could have told you this when Deno was released. Oh wait, pinned package versions are too specific??? Maybe you want some sort of tool where you can give it constraints on package versions and it'll find the minimal set that fits these constraints. Some sort of...package manager? And big url imports are kind of ugly no? If only there was a way to resolve them via a manifest that this package manager could also read. Some sort of package...file, like a package.json.

I dunno man, this feels like stuff the Deno people could have predicted. I don't understand why people treat packages like the boogeyman. You need a way to share and reuse libraries. Then you need a way to version these libraries. Then you need a way to reuse versions of said libraries. Then you need a manager to handle the reusing and constraint solving of libraries. It's a pretty logical sequence of events. I know it seems icky and gross and we should all just be real programmers and write our own dependencies, but you don't get paid to write dependencies.

I guess that's the issue. The people who write stuff like Deno or Node do indeed get paid to write dependencies. And it's too easy to listen to the people complaining about straw men like is-odd when in fact, for all the messiness, developers get a lot of utility out of packages.

page 1