The continuous performance improvements in Deno are really impressive. Node compatibility getting better with every release makes the transition a lot easier for existing projects.
Deno 2.8
121–130 of 193 posts
Re: Deno 2.8
#122Earlier quoted context omitted.
Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning. A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install d…
> In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things "Probably"? Are you saying there's a chance he wasn't right? I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.
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 continue to be lazy afterwards by running Deno applications with fewer than the minimum set of restrictions because that's easier.
The more complete way of solving the problem would have been capabilities. Rather than sandboxing the whole application, you instead sandbox each individual function. By default a function can make no requests, access no files, execute nothing, etc. But while the application is running, you can pass individual functions a token that grants them limited access to the filesystem, say. This means that trusted code is free to do what is necessary, but untrusted code can be very severely limited. It also significantly reduces what dependencies can do: if you're using something like `lodash` which provides random utilities for iterating over object keys and the like, and suddenly it starts asking for access to the web, then clearly something is wrong, and the runtime can essentially make that impossible.
It's also great for things like build scripts, which are a common attack vector right now. If your runtime enforces that the build script only has access to the files in the project folder, and can't access arbitrary files or run arbitrary commands, then you're in a much safer position than if your build script can do basically anything.
This concept has been explored before, but JavaScript is basically ready-made for it. The language already has everything you need — a runtime that also acts as a sandbox, unforgeable tokens (e.g. `Symbol` or `#private` variables), etc — and you can design an API that makes it easy to use capabilities in a way that enforces the principle of least privilege. The biggest problem is that there's basically no way to make it backwards compatible with almost anything that works with Node, because you'd need to design all the APIs from scratch. But one of the great things about Deno at the start was that they did try and build all of the APIs from scratch, and think about new ways of doing things.
Re: Deno 2.8
#123Earlier quoted context omitted.
Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.
Wasn't it announced that Anthropic is having their first profitable quarter right now in Q2? From what I've personally seen it's all driven by enterprise adoption. Open source/foreign models are already way cheaper and will work just fine for most use cases but a lot of businesses are already pretty locked in to Claude, and with enterprise costing $240 a year at a 20 seat minimum it's a pretty big investment to make…
Commentary upon Anthropic's profitability propoganda: https://www.wheresyoured.at/anthropics-profitability-swindle...
Re: Deno 2.8
#124Earlier quoted context omitted.
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?
Interpreted that's right, in fact it's super slow and adding types adds up to parsing time. Javascript is jitted. Python types serves no purpose if not for documenting or letting the lsp doing some lightweight type checking. And btw typescript introduced many breaking changes and the spec is managed by microsoft something you don't want for the open web. What we would really benefinit from would be having WASM being able to do more inside the browser, like rendering, managing user input, accessibility, dom manipulation. Then u could compile your favorite static types lang down to wasm. Hell even a strictier version of TS could be made to do that, iirc there's something similar called assembly script
Re: Deno 2.8
#125I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
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.
Re: Deno 2.8
#126I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
It is a language, it doesn't matter to what it is downcompiled to be able to be run in a browser.
Its now 13 years old, not a hard language to have a proper runtime for it and it would just get rid of all the npm stuff.
And for the amount of typescript we now have, it would be worth it to have proper native support.
Re: Deno 2.8
#127Earlier quoted context omitted.
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?
Python containing type hints doesn't get transpiled the way typescript does. The transpiling rewrites the TS to varying degrees depending on the target and the extra TS features being used.
Python "just" (that word is doing a lot of work) updated the interpreter to ignore the type hints. It still runs the same way as code without hints.
There's a bit more going on with TS that you couldn't just have the runtime ignore the types.
Re: Deno 2.8
#128I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
> Because "it doesn't exist". It's just a layer on top of js, ...
C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C.
There is nothing preventing TypeScript from becoming "native" in a similar way.
Re: Deno 2.8
#129Re: Deno 2.8
#130I literally just discovered Deno today. I wish there was Deno for Python / WASM path was really mature. Maybe I'm missing something here, but trying to secure both a Python runtime and JS runtime for AI.