Big Changes Ahead for Deno

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Appwrite - The Open Source Firebase alternative introduces iOS support
  • talent.io - Download talent.io’s Tech Salary Report
  • Scout APM - Truly a developer’s best friend
  • SonarLint - Clean code begins in your IDE with SonarLint
  • deno

    A modern runtime for JavaScript and TypeScript.

    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.

  • deno-lambda

    A deno runtime for AWS Lambda. Deploy deno via docker, SAM, serverless, or bundle it yourself.

    As I had mentioned, it requires using a Lambda Layer. See: https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e...

    Using your own image (i.e. without using the base AWS image with the layer) you'd get even worse cold start times.

  • Appwrite

    Appwrite - The Open Source Firebase alternative introduces iOS support . Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!

  • bun

    Incredibly fast JavaScript runtime, bundler, transpiler and package manager – all in one.

  • esbuild

    An extremely fast JavaScript and CSS bundler and minifier

    What you're looking for is ESBuild: https://esbuild.github.io/

  • patch-package

    Fix broken node modules instantly 🏃🏽‍♀️💨

    Does something like patch-package: https://www.npmjs.com/package/patch-package exists for Deno? If yes/no how does it work/would work?

  • xgboost-node

    Run XGBoost model and make predictions in Node.js

    This chips away at one of the showstoppers for Deno for me, which is good.

    But while "the vast majority" of npm packages don't require a gyp build step for native addons, some of those modules are pretty important, and I see no indication in the announcement that they're also going to be implementing the Node C API or the gyp build process.

    Right now I'm working with a machine learning project, and XGBoost [0] is a direct Node.js extension [1] through the binary interface.

    So this does bring things a step closer to being generally usable, but there are still significant roadblocks.

    A WebAssembly build of XGBoost could work with Deno, but aside from some guy's unsupported side project/proof-of-concept for use in a browser, I'm not seeing an XGBoost WebAssembly build. And generally when deploying something like a machine learning model I'd rather use well-supported tools than to need to dive into the rabbit hole of maintaining my own.

    And yes, XGBoost will likely eventually have that kind of support for Deno, but then the next bleeding-edge project will come along and only support Node.

    Even assuming Deno eventually hits a tipping point in popularity where everyone wants to release Node _and_ Deno support in their bleeding-edge projects, there are still things that I miss from package.json that don't seem to exist in the Deno ecosystem.

    Things like the "scripts" block: A nice centralized place to find all of the things that need to be done to a project, plus auto-run script entries that can trigger when a project is installed. And inheritable, overridable dependency maps (see the yarn "resolutions" block).

    I'd love to jump into Deno, but I think there has been far too much "baby thrown out with the bathwater" to its design. It's the classic development problem of looking at a system and seeing a ton of complexity, but not really understanding that all of that complexity was there for a reason. Maybe when it re-evolves 80% of Node's and npm's features I'll be convinced to make the jump. I'm a huge TypeScript fan after all. But it still strikes me as a violation of "As simple as possible, but no simpler."

    [0] XGBoost is a _very_ promising approach to machine learning, training models much faster and with much more accuracy than traditional approaches.

    [1] https://github.com/nuanio/xgboost-node

  • tsup

    The simplest and fastest way to bundle your TypeScript libraries.

    One option is to do type checking with tsc (or in your unit tests). And build into a single file with tsup.

    https://tsup.egoist.dev/

  • talent.io

    Download talent.io’s Tech Salary Report. Median salaries, most in-demand technologies, state of the remote work... all you need to know your worth on the market by tech recruitment platform talent.io

  • swc

    Rust-based platform for the Web

  • license-checker

    Check NPM package licenses

    I don't care whether it's all in one file or in a dozen files, but I want all of that information to be available programmatically in a text file (unlike in a readme or on Github) in a standardized location in a project.

    In that respect, package.json is a strict win. Your lack of willingness to use `git blame` to see why you added a line, or lack of reasonable git comments, is not to be blamed on the file.

    Complexity is unavoidable. How could you write a tool like license-checker [1] for a Go-based project without having license information in a standardized location? Without the scripts section, how can you create a tool like husky [2] that automatically installs git hooks for a project? Every single part of package.json is there for a good reason; at best you could argue that putting some of it in other files would be aesthetically superior, but that's just bikeshedding.

    Complexity isn't de facto bad. Some complexity is required if you want a certain level of functionality to become available. Deno (and Go) are slowly accumulating that "cruft" as people realize that those functions are actually useful or even critical to a mature ecosystem.

    [1] https://www.npmjs.com/package/license-checker

    [2] https://www.npmjs.com/package/husky

  • node-gyp

    Node.js native addon build tool

    I assume it's use of node-gyp, the native plugin system.

    https://github.com/nodejs/node-gyp

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts