171–180 of 193 posts
Earlier quoted context omitted.
> Plus, bought by Anthropic. Who thinks this is a positive?!
That wasn't a value judgment on the acquisition. I was just pointing out that it made the project more sustainable.
I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
Earlier quoted context omitted.
Because standardization is a political process that takes time and consensus to achieve? https://github.com/tc39/proposal-type-annotations
TypeScript is now 13 years old. They could have, by now, made it a lot easier to be able to use Typescript in a browser out of the box without magic behind it.
Before eg 2020 it still wasn't clear if TS was another CoffeeScript.
Earlier quoted context omitted.
I doubt it would work out. The engineering cultures could not be any different.
well bun could 'gradually become deno': 1. add 'enhanced security mode' that's actually 'deno-compatible/like' (permissions, etc) 2. mark libs/executables/etc as 'enhanced security compatible' 3. ...merge by buying out deno?
A Bun team willing and able to execute your plan is not one willing to merge a vibe-coded rewrite in a couple weeks.
Deno is a JavaScript and TypeScript runtime, for those who don't recognize the name. Here's a review of Deno 2.6 vs competitors Bun 1.3 and Node.js 25: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...
It's surprising to me that bun is so much faster serving web requests. The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node? Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?
Earlier quoted context omitted.
Why do you consider URLs a problem?
One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.) Also, if multiple dependencies…
Also, URLs didn't have to mean "exact version". A script provider might use a URL scheme with exact versions in it such as `/packagex/2.18.3/main.js` or could do semver-floating symlinks like `/packagex/2.18/main.js` for latest patch and `/packagex/2/main.js` for latest minor. You could even have hosts that just used the classic top-level `/packagex.js` for whatever is the latest.
I think the real problem with URL dependencies wasn't so much "exact versions", it was the confusing flexibility that versioning schemes were dependent on the package host because URLs are orthogonal/agnostic to version numbering and different package hosts can do whatever they wanted. (Naming conventions you'd have to look up for each/every host versus semver-aware package management code.)
Earlier quoted context omitted.
I think the biggest issue with Deno is that it fixes real issues but in the wrong way. Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will c…
Are there languages and runtimes which have done stuff at this low-level before ? Sandboxing at the individual function level ?
Earlier quoted context omitted.
I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node. Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier…
> Node always felt immature compared to stuff like go or java. Not enough boilerplate and EnterpriseBeanFactorySingleton?
This software is a beast to build and package. On first compilation, it spent like ~5-6 hours just pulling Rust crates. This time thankfully was significantly reduced once the relevant packages were in cargo caché; only the changed/added ones were picked up.
But the second problem is even more annoying. Building Deno happily consumes about ~16-20 GB of precious disk space on space-constrained SSDs. This is too much.
I think we should go back to more efficient software, both in object code formats (the product) as well as in the build process. Why would a single JS runtime need 20 GB storage to be built? This is wasteful.