deno_sdl2 VS deno

sdl2 gets around the first problem by downloading a CLI service & starting it, that speaks JSON over a TCP socket. It's a limited surface of the API, and missing some pretty basic stuff, but I could see it working ok. It's not canvas, so I'd have to translate those sort of calls to it. I discussed that a bit here and it sounds like I could blit images of the canvas to sdl2 surface, but since it doesn't support in-memory images, I'd have to implement that in sdl2, or save a "frame" image to a file, for every blit. Either way, I have the overhead of redrawing every frame as a complete image. This seems incredibly jenky, and I assume will not perform very well, but I haven't tested.

For me, I liked Deno’s indie charm. Building a Deno project felt more like a craft, and less like a job. Plus, their domain is cute. https://deno.land

I think it is https://github.com/denoland/deno/blob/main/ext/http/lib.rs

Our ops system is becoming ever more optimal - interfacing directly with V8 Fast API for speedy calls from JS into native code. Likewise our foreign-function interface (FFI) is seeing updates that place it second to none. We aren't optimizing for a handful of edge cases, but for overall real world performance. You'll be experiencing these improvements for yourself before the summer is over.

The "npm:" import does not appear to have even started development, although it has been planned for a long time: https://github.com/denoland/deno/issues/13703

Core features for npm compatibility though (like implementing most of the npm api, including require(), and its special globals) has been making progress for a long time.

There is even a near complete project to support Node's native api (which bun also supports): https://github.com/denoland/deno/pull/13633

Relative to the the existing node compat efforts, the url import (and accompanying package download code) will be fairly small. The most difficult part is probably the extra stuff that node throws in the global namespace. How to handle that without having to pollute the global namespace for all programs (even those that do not import from node) is unclear.

Ideally these globals would be visible only from code in modules imported from npm. But the spec does not really allow for this unless the npm code is loaded in a different realm, but cross realm code causes a lot of headaches, which could only be avoided by having the realms share most globals and intrinsics (and sharing intrisics is not allowed by the spec).

There may be some other way to hack this into working, or perhaps programs with such imports that actually use NPM specific objects will need to be run with the "--compat" flag. It is really unclear at the moment.

You overestimate many of these difficulties. The --compat mode can already run quite a bit of the node ecosystem, including programs like npm.

Imports don't need to be written in typescript. They could have manually written type definitions (which is how people using typescript in the node ecosystem already handle this), and packages without type definitions will have the imports typed as `any`. Sure that makes them a bit annoying to handle especially in strict mode, but it entirely possible to use such packages.

Deno is actually working on adding the native node API (https://github.com/denoland/deno/pull/13633), so the website was a bit overoptimistic when saying "Deno will never support Node plugins". However it is possible for some plugins to be incompatible still, for example if they try to use node internals rather than just the API, or if they try to use utilize the libuv event loop, since deno is not libUV based.

Deno

Bun is the newest addition to the JavaScript runtime family. It has been making waves that rival those made by Deno when it came out in 2018. Bun sits in the space between Node and Deno. Bun, like Deno, supports TypeScript out of the box and offers developer-friendly features such as top-level awaits and built-in Web APIs. But, unlike Deno, Bun is intended to be a drop-in replacement for Node, Webpack, Babel, Yarn, and PostCSS — all in one neat package.

deno install -f -q --allow-read --allow-write --allow-net --unstable https://deno.land/x/[email protected]/opine-cli.ts

While I was developing lole-lisp I happened to create a tool to generate C FFI bindings for Deno.