Deno in 2023(deno.com) |
Deno in 2023(deno.com) |
Shout out to all my fellow hang gliders.
so we know::
- it is not about a discussion of deno being new, relevant or modern in 2023, and
- avoid thinking that the article is from 2023?
Why did he feel the need to build a competitor to his own product? Whatever features are supposed to make Deno "better" than Node...why didn't he just work on integrating them into Node?
I understand that sometimes changes to software can be infeasible, especially if they are large fundamental/foundational changes, but this is still a bit of a head scratcher to me.
Sometimes you do need to reset the foundations, then build compatibility on top.
He also can't unilaterally change them in NodeJS because at that point it wasn't a solo project of his anymore.
You can do this using containerization technology, no need to invent this per language runtime.
Not sure what's available on Windows.
With Slint [1] we're working on a framework which allow to make a desktop GUI in Javascript/Typescript, without bringing a browser/webview. Currently, we do it by using binaries through napi-rs so we can bring in a window using the platform native API. And then we do some hack to merge the event loops.
But if Deno supports bringing up a window directly, this means we can just ship wasm instead of native binary for all platform. And also I hope event loop integration will be simplified.
Although we'd also need more API than just showing a window (mouse and keyboard input, accessibility, popup window, system tray, ...)
Edit: I got excited a bit too early. The WebGPU feature doesn't include the API to launch a Window. One still need to rely on an extra library binary.
Also why would you want to make a GUI even more bloated by integrating a browser to get webgpu and webasm (and why webgpu instead of just webGL?). That might be easy for library makers but why would someone want a giant library to make a GUI when they already have electron if they don't care about 350MB binaries to pop up a window.
Webgpu and wasm without a web browser would be a nice way to distribute portable sandboxed code.
The reason for Webgpu is that it it has semantics closer to modern modern apis like Metal or Direct X.
They're working on a project called Dioxus Blitz; from what I'm told, they're trying to implement a minimal browser target, that provides some basic DOM-like features and renders with wgpu.
It's not exactly what you're hoping for, but you might find common ground.
https://github.com/DioxusLabs/blitz
(Also, the Linebender project is working on Masonry, with FFI as a medium-term goal.)
The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than Node.js's pkg solution by a decent margin.
I was forced to start coding again in JS some weeks ago and I wanted to try Deno. I must say it's been a very smooth and fast experience so far. Very well done!
Alternatively, like in my ~/bin, I'll put a shell script without a file extension to make it easier on myself.
I'm curious on what the Deno team is building here.
I thought their whole thing was to maintain backwards compatibility, not introduce new, redundant standards?
Why Choose JSR? A True TypeScript-First Environment: Efficient type checking and no transpilation hassles—write in TypeScript and deploy directly.
Performance and Usability at the Forefront: With integrated workspaces and seamless NPM integration, JSR puts usability first.
Secured and Accessible Modules: All modules in JSR are exposed over HTTPS, ensuring your code is always secure.
Open Source, Community-Driven: Built by developers, for developers, JSR is shaped by the real-world needs and contributions of the JavaScript community.
I love this! At the same time, who would want to do this, given Python's excellent support for numbers and mathematics? And what about Haskell?
I'm writing a JavaScript bundler and need a Node.js runtime to execute plugins. Deno's executable has fantastic Node support (at least, good enough for my use case) however the deno-core crate is super barebones and difficult to embed.
At this stage I can't simply add the deno runtime into my Rust application, I need to copy/paste internal crates from the Deno executable and wire them up myself (without documentation on how).
I'd love to see expansion for my use case - Deno could become the "plugin runtime" for the JS tooling world if it had a nice embed story.
Right now I am just going with a Nodejs child process that I talk to from the Rust host process using stdio. In my tests, the stdio approach has 10x the communication latency when compared to an embedded Deno runtime (that adds ~1 second per round trip message in a project with 100k assets)
Though they’re also selling a developer ecosystem. A lock-in. Are you willing to bet your company’s own software tools on a vendor that could go bankrupt from their other (hosting) business? The question is if Deno hosting dies, will Deno as a platform still thrive?
If it's a startup looking for growth then definitely. Future prospects may no longer signup because the needed region isn't available.
The fact that for the next iteration they are prioritizing view transitions and not CSS bundling is baffling.
If node.js decided to include functionality similar to what is available on Bun/Deno, both projects would probably lose traction quickly.
Deno Deploy just works, albeit the cold start can be slow but I'm now using an hybrid setup with Fresh routes backed by a CDN.
The dev experience is great. I've used a couple of other solutions similar (Next, Nuxt and vite-ssr-plugin) and I sometimes I need to do somethings manually that would already exist on other platforms but in the end my projects stay simpler.
I love saaskit [1] and Netzo [2]
[1] https://deno.com/saaskit [2] https://github.com/netzo/netzo
Why should I choose Bun over Deno or vice versa?
Is it just a side-effect of using V8 engine for the heavy lifting, or is it some part of the ECMAScript specification which forbids multithreaded implementations of the language?
Cons: All your async code becomes full of data races.
I suppose adding multithreading to the Node ecosystem would be as hard (if not harder) than removing GIL from Python. At least Python has locking primitives. Node, as far as I know, has none.
I feel like most performance intensive nodejs modules drop down to c++ where real concurrency already exists. (e.g. sharp - https://sharp.pixelplumbing.com/api-utility#concurrency)
In all of them - JavaScript is mostly used for asynchronous programs, which are easily parallelizable. There's no reason not to want multi-threading.
It's a bit low-level compared to a SQL database; you're building your own indexes and need to write transactions to update them atomically along with the main record. (But it does have transactions, so it's reasonable.) It reminds me of App Engine datastore, back in the day.
There are some fairly tight limits. (64k for records.) I wouldn't use it for storing images or larger files.
Not sure what I'm going to do for full-text search. But I've built simple search engines from scratch before.
I would love for this year to see the runtime support for either Google Cloud Functions or AWS Lambdas
It's amazing to see Deno mature so fast while staying well-thought-out, and I'm excited to use it in as many projects as I can now.
I like to run my shit on the metal and without Docker and it feels like Deno was designed to run on Docker or some other kind of virtual containerized environment.
However, you can run it on node thanks to pm2, but I guess why even run on Deno in the first place?
In my view, deno compile is more about shipping command line tools to people with all sorts of personal environments (which may not have deno at all)
I do wish there was support for Linux distributions based on musl (Alpine) directly for smaller containers.
In general I like the Deno approach better than Node. Would be cool to see the UI tooling flushed out. A material or fluent based component library where Deno can be used like Flutter would be very cool indeed.
If you really are pressed for space, you could use upx, or store 7z compressed code and embed the 7z library to decompress before passing it along to QuickJS.
Here's a proof of concept: https://github.com/ijustlovemath/jescx
While I agree with you that it's not optimal and should get fixed, 90MB doesn't sounds like it can stop you from deploying it either.
If reach one of my scripts was a separate build output from Deno that would be several GB of space.
I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.
Updates for games are large because they aren't "just updated files", but a giant blob that can't be rearranged since it's optimized for loading order later.
Giant self-contained deploys like that are bad because their use case is CLI/GUI tools shipped to the end user. To give you context: my /usr/bin is ~900 binaries and total size is 109mb.
That and that's likely 100MB that's going to be competing for memory now* , in FaaS environments especially that's a ton of resources and you increase latency to load that especially over network storage. This also inflates container sizes and just becomes a pain in general.
*Server environments you often don't want to be using swap, and the OS will likely consider it high priority anyway.
I could only agree with you if you have a single monolithic server, don't use containers, don't need to distribute it to others, and don't frequently need to run a CI/CD pipeline. Only then are there not a ton of downsides to a 10mb vs 100mb executable.
> When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript.
People have been complaining about game sizes for years. "You complain about a 100GB game, I don't know why you also complain about a 100mb self-executable for a javascript runtime" doesn't really make sense.
TypeScript and esm/cjs usage without crazy syntax (writing modules, consuming cjs at least).
Lintinng and formatting in the box.
Can do shell scripts without package.json and nom install, just a shebang line at the top.
These are some of the things I like better.
I am not sure if I'll have the chance to exploit other features it has (besides the built-in dotenv support).
Not so many years ago, even installing npm wasn't straight forward.
It has mostly been sorted out by all package managers. The node_modules debacle is still a hotly contested topic, it creates a lot of problems, but it also solves a lot of them compared to alternative approaches.
Then you have install performance which is mostly fine by now in all package managers, but if you really have problems with it you can use pnpm or yarn2.
As the python ecosystem grows and dependency trees move away from "django only" you can see they having the same types of problems that JS used to have.
Anyway you're certainly not alone in your opinion, but I think that a lot of the bad reputation with Node and NPM comes from the amount of "change management" you need to do to "limit" the vast amount of freedom the tools give you into something that will be workable for your team. Once you get there, however, I've found it to be a much to work with than things like Nuget and dotnet, requirements.txt and python, Cargo and Rust and a lot of others. I do have a personal preference for yarn, but I guess that's mostly for nostalgic reasons. I also very much appreciate that things like PiPy are going down what is similar to the NPM route.
Deno has members in Ecma TC39, so they take part in the development and standardization of JS.
Deno brings a new mentality to development focused on simplifying things, whereas Bun aims to be an improved Node.
Deno aligns with web APIs: you can use the same APIs in the browser and in Deno. Many packages work in both platforms. Deno is even in the compatibility tables in MDN.
Deno simplifies DX greatly. It's very easy to work with Deno. Easy to install things and set up a project, easy to deploy, no config files etc.
Deno is written in Rust, which allows them to move faster and more safely. Contributing to and extending Deno is a breeze. You can add Rust crates to the runtime and use them from JS.
I feel like the Bun team has been too pressured by executives and marketing. They announced 1.0 when Bun was clearly not stable enough, giving lots of segfaults. Even their readme had a huge statement right in the beginning saying that Bun was not production ready yet, despite 1.0 being hyped all over the place.
Most of Deno's code is actually V8 in C++
They also kinda have different goals. Bun seeks to be more of a drop-in replacement from Node whereas Deno, being spearheaded by the same person who made Node, seeks to move the industry forward and fix mistakes Deno made. However Deno, out of necessity, has also highly valued backwards compatibility with the Node ecosystem
If they aren't able to evolve Node.js to overcome the mistakes (e.g. because they're technical in nature, or momentum of install base, or they don't have the leadership ability), I am worried that they might repeat the same pattern with Deno, since it isn't possible to NOT make any mistakes.
OTOH, having a clean slate that's learned from mistakes and you can bring a lot of your code along doesn't seem like a major impediment.
Is code written for any of the 3 runtimes generally transferrable? I realize some won't (e.g. Deno has WebGPU support, which is attractive to me), but generally?
You probably meant "node" here.
If you don't, focus on pointless things like Bun vs Node vs Deno, get some dopamine hits and fool yourself into thinking you are being productive.
It would have been nice if I had realized this aspect of technological evolution earlier in my career. I might have spent more time learning about marketing than about the actual technology.
The ultimate killer argument is always "does it improve my CV?"
CV driven development is usually the reason for questionable technology choices
So the old-timers remind us, "Choose boring technology." Reliable and boring is a good thing.
On the other hand, I recently started learning Bun, and oh what a breath of fresh air, it makes things fun again. I love that its codebase is so readable and small still, and everything is freshly designed with the insights of experience and hindsight. It doesn't have the accumulated cruft, years of decisions and compromises.
So, sometimes it's great to shed the old and grow with the new generation.
Brand reflects a project's philosphy. Deno is thought to be easy and simple, and the "childish" branding reflects that.
So you may not be wrong at all in your criteria. Subjective human communication can be more effective than objective communication sometimes ;). It just works at a different level.
Hopefully it will be closer to how Go does it.
> Stability: 1 - Experimental: This feature is being designed and will change.
— https://nodejs.org/api/single-executable-applications.html
Deno, on the other hand, has it as a supported, complete feature that’s very easy to use:
Atomics are probably the closest. https://v8.dev/features/atomics
(It's a bit trickier than that since the SQLite database holding the KV store would need to be backed up, but it seems doable with Litestream?)
that I am unsure about, a large part of the appeal at least for me is the deno deploy.
URL imports are a bit of a hassle when you are trying to get them from say a private github repo.
It's be tough, but going the other way to Node as a transition is entirely possible with relatively minor effort.
And we were not talking about js, we were talking about Deno specifically. And about binary growing year to year notably.
>Pretty much all cloud services offers way more than that for free
More than what? The question is always about difference in %. The number of services\instances can grow faster than you can rewrite your conde in go\c++\rust of whatever (not to mention you will have to hire people for the task). And all of a sudden this x3-x4 difference matters.
Would like to see more runtime independent JS project such Hono. Although I'm not sure if it supports QuickJS.
You would use deno as base layer, your dependencies in another layer, your code is in the last layer.
The NextJS team should be working on making NextJS run better with Deno, not the other way around. If the NextJS team doesn't want to do the heavy lifting with that support, thats on them. I think its perfectly reasonable that the Deno folks have an approximate alternative to NextJS. After all, NextJS won't use native Deno idioms for example, it'll always be tied to Vercels' proprietary cloud infrastructure.
If size is such a big deal, then don't use Deno, Node or Bun.
My issue is that most people that are working in restricted environments would never touch javascript since it's not well suited for those kinds of environments. People that complain tend to be haters that just want something to hate upon.
It used to be about php, now it's about javascript.
I apologize for this being so besides the point of your post, but I hate this trend so much.
Also, the first thing the project website (https://www.a11yproject.com) has to do is explain what the '11' stands for. So they must have some awareness of how inaccessible their name is.
The irony with this example is people with screen readers will hear something like “aEleveny” and it looks like “ally”.
Seems like good acronym semantics no?
People doing hardware accelerated GUIs have been using openGL for almost as long. This doesn't need to be a science project or a rabbit hole, drawing a GUI quickly is well worn territory.
JavaScript is one of the most popular programming language. But a JavaScript dev who needs to make a desktop GUI will usually need to use Electron to bring up a browser for the GUI. This means actually two JavaScript engine (Node and Chromium)
The reason it has to do with Deno is that you need a JavaScript/TypeScript runtime. But you may not need a browser. So you can develop your application in JavaScript using a framework that doesn't use the DOM but show a native window instead.
This is more lightweight and more secure (no risks of HTML injection and the browser is a big attack vector)
Not to mention that development has been stagnant for 15 years since it's flagship application (Nuke), was ported to QT.
What's the obstacle to using it via FFI (which Deno seems to support)?
> What does it have to do with Deno
can we at least try to give people the benefit of the doubt instead of pretending like everyone is out to get you? if you read the change-log, it spells it out well:
> Our goal is to provide a windowing solution for WebGPU without linking to native windowing systems like X11
> This is a low level API that can be used by FFI windowing libraries like sdl2, glfw, raylib, winit and more to create a WebGPU surface using native window and display handles.
do you get it yet?
> People doing hardware accelerated GUIs have been using openGL for almost as long. This doesn't need to be a science project or a rabbit hole, drawing a GUI quickly is well worn territory.
i suggest talking to other graphics professionals to get a better understanding of why opengl is not _the_ solution. for a tldr[0]:
> regular OpenGL on desktops had Problems. So the browser people eventually realized that if you wanted to ship an OpenGL compatibility layer on Windows, it was actually easier to write an OpenGL emulator in DirectX than it was to use OpenGL directly and have to negotiate the various incompatibilities between OpenGL implementations of different video card drivers. The browser people also realized that if slight compatibility differences between different OpenGL drivers was hell, slight incompatibility differences between four different browsers times three OSes times different graphics card drivers would be the worst thing ever. From what I can only assume was desperation, the most successful example I've ever seen of true cross-company open source collaboration emerged: ANGLE, a BSD-licensed OpenGL emulator originally written by Google but with honest-to-goodness contributions from both Firefox and Apple, which is used for WebGL support in literally every web browser.
also, openGL is deprecated on macOS.
[0]: https://cohost.org/mcc/post/1406157-i-want-to-talk-about-web...
My comment here is explaining exactly why I don't agree, no digging required.
Your quote is also about browsers implementing the webGL API, it has nothing to do with using basic openGL for GUIs, which again, is not required, because CPUs have been rendering GUIs for decades.
They create some riff, make the key incumbent improve itself, and then the world moves on as if nothing happened.
I believe this too. The big appeal for me is not having to install typescript, eslint, jest AND then set up all the configs.
deno has nice defaults, though the importing via URLS and browser compatible API do make deno very tempting
Whereas with Deno you can compile to a single binary and let them install that if they trust you. Or they can `deno install https://raw.githubusercontent.com/.../cli.ts`, or clone the repo and just run `deno task install` or `deno task run`. For those they need to install Deno, but nothing else.
So Deno is better at small scripts written in Typescript than Node. Then, the question becomes, if you're going to have Deno installed and if it works well enough to replace Node, why keep Node?
> how hard is it actually?
> can you really not use, e.g. for react, the typical vite starter and it's done?
I have to install that stuff everytime I'm starting a new project, switching to a new project, or creating a one-off script.
It's hard when creating a new project where there's always at least one flag that needs to be found and set different from a previous project for some random reason, every single time.
It's hard when switching to a new project, because you have to figure out which version of node you're supposed to be running because each version runs the dependencies differently between different versions of node, and different computers. It might even silently work for you without being on the right version, meaning you continue working on it, then your commits don't work for yourself later or others now or later. This leads to one of two possibilities:
1. A longer job either unwinding everything to figure out what the versions should have been the whole time.
2. A lot of trial and error with version numbers in the package and lock files trying to figure out which set of dependencies work for you, work for others, and don't break the current project.
We also can't use the typical community templates because they always become unmaintained after 2 years or so.
---------------------------
Why I like Deno:
- Stupid easy installation (single binary) with included updater
- Secure by default
- TS out of the box (including in repl making one-off-scripts super easy to get started)
- Settings are already correct by default.
-- and if you ever need to touch settings for massive projects, they all sit in one file, so no more: tsconfig/package.json/package-lock/yarnlock/prettier/babel/eslintrc/webpack/etc... And since the settings are already sensible by default, you only need to provide overrides, not the entire files, so the end result for a complex project is usually small (example link: https://docs.deno.com/runtime/manual/getting_started/configu...)
- Comes with builtin STD meaning I don't need to mess-around with dependencies
- Builtin utilities are actually good so I don't need to mess-around with the rest of the ecosystem. No jest/vitest, no webpack/rollup, no eslint/prettier/biome (but you can keep using your editor versions just fine).
- Since it came after the require -> import transition, basically everything you're going to be doing is already using the more sensible es modules.
I rather have pure JavaScript, or use the Typescript from source, without having to figure out if a type analysis bug is from me, or the tool that is catching up to Typescript vlatest.
Deno uses regular Typescript for static type checking, it's just built-in. Bun also doesn't do type checking by itself, they recommend using tsc [2].
[1] https://docs.deno.com/runtime/manual/advanced/typescript/faq...
with node + TS, it is straightforward (and common) to generate JS output at publish time for distribution. then, using the CLI tool or whatever is only a `npm install -g <pkg>` away, no extra steps.
sure it's not a single binary, but I'd argue _most_ users of a general CLI utility don't necessarily care about this.
i was excited about bun too, until v1's "drop-in node replacement"
that was in no way a drop-in node replacement. using that would be the fastest way to kill a business with its terrible bugs and rough edges.
i used to be really excited about deno, but now i think the tradeoffs aren't going to be worth it for mass adoption. i sometimes write servers in go. now that i have go installed, should i use it for all my servers? no, it's just another tool with different trade-offs. most times, node will suit my project better.
And then you still have to ship an extra binary in addition to Deno itself.
It is like tracking down if a C bug in GCC relates to developer, or GCC understanding of ISO C documentation.
Just this alone proves it isn't the same thing,
=> Deno tries to keep up to date with general releases of TypeScript, providing them in the next patch or minor release of Deno.
Reading again, is the trend you detest...abbreviations that have a number representing letter count? Based on the existence of k8s and a11y?
Didn't we just have a thread the other day about the meaning of "MDN" - which also many people didn't know.
I see on this site "IMO" "FWIW" "IANAL" "TLDR" all the time. You generally can't tell what these mean either without looking them up or just knowing already because of them being so engrained in culture.
Like, for example, I recently found out that there are 3 separate ReadbleStream objects in NodeJS, one from "stream" (older one used in Request), one from "stream/web" (W3C standard, used by global.fetch()) and another one I forgot where it comes from. It doesn't help that two of them have the same name and you run into errors like "ReadableStream is not of type ReadableStream".
I assume the one from "stream/web" directly calls into V8 APIs because since it is a standard it would be implemented in V8 (it is used in the browser's window.fetch() after all). While the one from "stream" is built and maintained by NodeJS Foundation.
It is not really reasonable to expect the NodeJS Foundation to have enough resources to optimise all this modules to the max. And the W3C doesn't seem interested in building standards for server-side only things.
Those API could be thought as from the "environment" in which JavaScript run. For example we often call web-only APIs "DOM API": `fetch`, `xmlHttpRequest` and so on.
Node.js also has its own environment. For example both `setTimeout` and `setInterval`, though present in both web and node.js, are implemented differently by browsers and node.js (it's just that node.js decided to go with roughly the same API - see below for code examples for both).
Taking requests as examples there are both declared in blink, the rendering engine and not v8 again because they aren't JS:
- fetch (https://source.chromium.org/chromium/chromium/src/+/main:thi...)
- XMLHttpRequest (https://source.chromium.org/chromium/chromium/src/+/main:thi...)
For the fun of looking even more at some code of reputable projects: for setTimeout / setInterval, I would guess they are declared here in blink: https://source.chromium.org/chromium/chromium/src/+/main:thi...
And maybe here for Node.js: https://github.com/nodejs/node/blob/8a41d9b636be86350cd32847...
To note that "filesystem" API also exist in web world: https://fs.spec.whatwg.org
Again, this API is completely different than in Node.JS