<3 Deno

Interesting to see a different side to the benefits of Deno.<p>Personally, I find direct Typescript interpretation to be one of the best features. Typescript is not necessarily a simple type system, but it is an expressive one:<p>- It has great type inference avoiding Java style codespam<p>- It has gradual typing, enabling &quot;risky&quot; type casts<p>- It has fully functional types, enabling the productivity and readability improvements from functions as data<p>- It is 10 seconds away from having dependent types<p>Typescript took most of the best programming language research from the past 20 years and popularized it in a way that actually makes js hackers <i>more</i> productive without getting too much in the way.<p>The only hard thing has been that js interpreters don&#x27;t understand typescript, requiring an awkward transpilation step with weird symlinks and other hidden complexity that works 99% of the time, but wastes a lot of time when it doesn&#x27;t work just right.<p>If Deno could just solve that, it would be a great improvement. If it&#x27;s also faster (as claimed) that&#x27;s even better. This article shows a lot of other ways in which small, simple improvements add up to a much better product.<p>Can&#x27;t wait until it&#x27;s production ready.

I recently built a full-stack app with Deno (and their Fresh framework <a href="https:&#x2F;&#x2F;fresh.deno.dev" rel="nofollow">https:&#x2F;&#x2F;fresh.deno.dev</a>) called Invo (<a href="https:&#x2F;&#x2F;invo.ee" rel="nofollow">https:&#x2F;&#x2F;invo.ee</a>) and the whole experience was delightful. I was able to move really fast and I never had to touch a configuration file, which also immensely helped with my motivation of actually building something - far too often I get stuck in a pile of config (I do Clojure mostly) and lose any motivation I had.

This argument is so interesting, essentially it&#x27;s &quot;there is no other Deno, so you don&#x27;t have to worry about using a slightly incompatible implementation and getting bugs&quot;.<p>But a lot of people think that multiple implementations and specs are good things (I personally don&#x27;t know which way I go on this one). And thinking about it, I kind of don&#x27;t buy the argument. There are specs for JavaScript and TypeScript, and multiple standalone JS and TS engines: node, QuickJS, duckjs, Bun, etc.<p>I also don&#x27;t buy the &quot;minimal, practical&quot; take on dependency management. It sounds like they just built a package manager into Deno itself and put versions in the URL, which feels like the opposite of minimal and more like &quot;batteries included&quot;. Again not saying this is bad--the Python ecosystem suffers pretty badly from not having their dependency story totally mapped out--just quibbling over the characterization.<p>On the other hand, I <i>do</i> buy the security thing. AFAIK this is the first scripting runtime to essentially integrate pledge [0], which is real interesting.<p>[0]: <a href="https:&#x2F;&#x2F;man.openbsd.org&#x2F;pledge.2" rel="nofollow">https:&#x2F;&#x2F;man.openbsd.org&#x2F;pledge.2</a>

It&#x27;s a step in a positive direction that Deno makes you explicitly grant a script permission to do some things, but that&#x27;s not at all what is meant by capabilities, and that&#x27;s absolutely the wrong word to use to describe it. A capability is a first-class concept that exists at runtime, and is a value you must pass to dependencies that need it. You should also be able to use it to create new, dependent capabilities with fewer rights, and they should in general be much finer-grained than &quot;can access the internet&quot; to be of real use.

&gt; <i>The only big drawback of Deno is the language</i><p>Ooft. Although TypeScript does have a bit of a learning curve, and a lot of gotchas, I still have to say it&#x27;s my favorite language to use. If you combine the delicious syntax-sugar of ES6 (and beyond) with a sprinkling of tasteful types, the language leaves you full and energized without feeling bloated.

I love deno so much and all of its ideas highlighted in the article (dependency management, security, performance) so much that I&#x27;ve build an entire framework around making scripting enterprise grade that is centered around deno support. The project is open-source [1], we even expose a web monaco editor and made the lsp support available using websocket and json-rpc. The goal here is to build enterprise-grade one-off script and workflows in deno, that can benefit from permissioned credentials, autogenerated UI (by parsing the main function parameters), a workflow engine similar to airflow&#x2F;temporal, etc ...<p>We have a hub [2], centered around deno, that serves as our library of integration. An integration for us, is just a script that uses the right dependency to do an atomic action like fetching data or doing a POST.<p>We are betting big on deno, and are hoping with windmill to be the framework to make it enterprise-ready for other things than webservers (which most of the deno framework currently focus on).<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill">https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill</a> [2]: <a href="https:&#x2F;&#x2F;hub.windmill.dev">https:&#x2F;&#x2F;hub.windmill.dev</a>

It&#x27;s great to see other JS runtimes progressing, I have a continued frustration with the lack of decent TS tooling and ESM support in Node.js.<p>Jest and Mocha both do not support ESM very well out of the box and there is an expectation that you are using babel to transpile to CommonJS for everything to work nicely. (See Jest&#x27;s _experimental_ support for ESM mocking!). Node.js is only starting to build out a testing framework, and it has a way to go yet until it has any level of feature parity with the established libraries.<p>Then you have the naive assumption that any package written in JS works with TS. Which is true, they do work, but the missing types will always lead you to look for a TS-first alternative. A good example of this is Joi vs Zod for validation, with the latter performing type inference based on your validation parameters, which is great. But it really does feel like you have a subset of a package ecoystem lurking on NPM.<p>I am not that confident Deno is the answer, but I would say those are my biggest frustration writing production grade JS&#x2F;TS code today.

I tried Deno and really liked it. The pros:<p>- It uses the v8 engine so you&#x27;ve got the same APIs you know and love for the browser like fetch() - Something that nodejs is just catching up to now<p>- It&#x27;s not nodejs, the whole name means &#x27;destroy node&#x27;. You can get a lot done without being buried in dependencies. Well-maintained core libraries.<p>- Server-Side WASM is a really interesting idea for encapsulating and integrating stuff written in, say, C++<p>The cons:<p>- Some of the third party ecosystem seems to be suffering from a lack of recent maintenance<p>- Server-side WASM is limited to 32-bit until they figure that out, which also limits whatever you do with it to a 4GB memory ceiling<p>Other than all that though it&#x27;s probably not a bad choice for anyone not bothered by those limitations and just wants everyone who speaks typescript on the frontend to be able to grasp what&#x27;s on the server side end of things too.<p>I think it could probably thrive with more usage traction.

As a frequent js&#x2F;ts avoider currently using deno and deno deploy for a few bits and pieces, I&#x27;ve found both truly pleasant to use. My needs are simple (cut to fit my js ecosystem ignorance) but given those limits, the only problems I&#x27;ve had so far are with some npm deps that don&#x27;t work (&amp;&#x2F;or I don&#x27;t know how to make work). No big issue as there&#x27;s often some deno-proper equivalent, or if not, some other npm package that&#x27;s OK.<p>Usually when I do anything in the node&#x2F;npm world I have to steel myself. But Deno &amp; Deno deploy are actually fun.

I&#x27;m a big Deno fan and use it whenever I can. I think tasks are great and they solve the most common needs.<p>In my experience, however, as soon as my tasks section got large enough that a separate file was needed, it became long-running enough that I wanted a generic file dependency-aware builds which required a make-like solution. What should large projects do that need to build assets or perform long-running work as part of a build process without dipping into another clunky tool?<p>I have similar issues with threading development-only import maps that reference local modules in a polyrepo during development and sharing common Deno configs. Customization doesn&#x27;t scale well to task one-liners even though I want it to. Do folks know of open-source polyrepo reference that serve as a paradigm for patterns that scale?

&gt; Deno comes with a built in deno vendor command, which fetches all of the dependencies of the current project and puts them into a subfolder, making production deployments immune to dependencies’ hosting failures.<p>While this is certainly nice, should third-party code be actually committed in your version control system? I always treated it like a bad idea. Adding node_modules to gitignore is second nature now.

What is wrong with<p><pre><code> [&quot;10&quot;,&quot;10&quot;,&quot;10&quot;].map(parseInt) ?</code></pre>

I fully agree with the author here.<p>The good old Unix philosophy of designing simple tools that are doing only one thing right has proven extremely useful in the context of using the Shell as a scripting interface.<p>Composability is paramount to be able to glue small cogs together to quickly build a larger machine for ones needs.<p>But this way of thinking should not apply to everything, especially not when the tool itself is designed to be used a direct interface with the user (like a Shell).

A lot of complexity in computer science stems from duplicating functionality due to developers not wanting to learn the best tools. The best tool when it comes to implicit dependencies are nix&#x2F;guix. These have solved the issue across languages for almost two decades. Unfortunately, they have a reputation of being &#x27;hard&#x27;, so instead of someone attempting another try at the actual problem (cross language implicit dependencies), what we have here is yet another javascript runtime that &#x27;solves&#x27; this problem, but only if you&#x27;re using javascript.<p>Deno sounds well thought out, but the article realistically presented no compelling reason to try it.<p>And realistically, it presented many reasons not to. Javascript is a horrendous language. Not because of the syntax, not because of the library support, but simply because even self-dubbed javascript &#x27;experts&#x27; are often confuddled by its standardized behavior. We could probably count on several fingers the number of people who can accurately describe javascript&#x27;s semantics. As the rest of the computing world moves towards sane languages, this seems like backwards &#x27;progress&#x27;.

Really nice. I&#x27;ve only seen Deno as something hard to adopt for very little reason but this gives really great reason!

Still waiting on <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;1739">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;1739</a>

Making things harder for developers “because it’s better for them” rarely works out.

At this point, I would love to see a compiler for a strict subset of TypeScript with a threading model similar to that of Go.<p>The biggest thing holding back TypeScript is the awkward transpilation dance, a weak standard library in Node and relatively poor performance - none of which are the fault of the language.<p>Break free TypeScript, you gotta move out of your parents&#x27; place eventually

&gt; [&quot;10&quot;, &quot;10&quot;, &quot;10&quot;].map(parseInt)<p>[ 10, NaN, 2 ]<p>what... the... fuck...<p>I have seen the WAT video but forgot about this example.

Tried out Deno recently! Having a super powerful REPL is really important to me, so I was trying chrome:&#x2F;&#x2F;inspect connecting to Deno. But I guess that when you do this, you have a JS REPL rather than a TS REPL, is that right? What do people usually do for that?

After reading this, if anything, it made me appreciate containers more.

I&#x27;ve recently been playing with Deno. It&#x27;s early days yet but for all the general scripting tasks I might use Python for, I find Deno a better fit. First class typescript is a killer feature, as is the fact that there is a semblance of stdlib which node simply doesn&#x27;t have.<p>My two main quibbles about Deno are:<p>1. The rather pointless security model that seems about as relevant as it did for PowerShell.<p>2. It&#x27;s quite young, there&#x27;s still some pointy edges.

I would like Deno or Bun to be easier to compile than Firefox or Chromium: Less resource-intensive. Less CPU, less memory, less storage space and less time required to compile.<p>The present: Use an enormous, complex, sometimes closed source, omnibus program containing a Javascript engine to remotely source and run Javascript files, i.e., other peoples&#x27; programs, listed in webpages (sometimes cascades of them as dependencies) in a way that is non-transparent to the user, allowing selected access to certain features of the the user&#x27;s computer, all mediated and controlled by Big Tech with its dependence on advertising and associated data collection and surveilllance and conflict of interest with respect to users.<p>The future: Use a standalone Javascript engine to remotely source and run other peoples&#x27; Javascript programs in a way that is transparent to the end-user, with all access to the user&#x27;s computer, if any, under the full control of the user, with no dependence on advertising and no need for data collection and surveillance.<p>&quot;Javascript&quot; might be replaced with some other language. Typescript, WASM, whatever. In the earlier days of the web before Javascript, people tried to use &quot;Java applets&quot;. Back in those days when an applet was encountered the browser would ask the user for permission to run it. As I remember it, this was about as annoying as cookie permission popups, another idea that was implemented in the earlier web then disappeared, but has now been re-implemented due to emrging privacy laws.

From all of the quirks JS has, I think<p>[&quot;10&quot;, &quot;10&quot;, &quot;10&quot;].map(parseInt)<p>is the sanest. Taken in isolation, the parameters of both Array.prototype.map and parseInt makes sense, and a typed language wouldn&#x27;t help there too much. All hope is on ESLint rules to not let you do shortcuts which could burn you.

As usual, a bit of a love-hate relationship with TypeScript. What TS has done to JS, though, is absolutely incredible. I wonder if it&#x27;s possible to abstract the engine, somehow, and apply it on top of a new language. I would love TS without all the warts of JS.

One of the frustrating thing with npm-scripts is the mandatory one-liner script. It is not possible to write a script on several lines.<p>I would really appreciate if deno-task-shell could be used in a shebang for writing scripts that expands on several lines in dedicated files.

this was an interesting read, although the beginning was a bit confusing.<p>I laughed a little when I saw the author hinting at TS creating complex structures. A reason I never adopted it. A great use of TS would be to type the external interfaces though!

Definitely this is a weird take to me because most web developers just use a Mac and then setting up an environment is fairly easy with brew and nvm. I haven’t tried but I imagine linux is also pretty straightforward. If you’re doing web dev on Windows I think it would behoove you to use WSL rather than mess around with the weirdness around path limits and the like.<p>However, the security issues are valid but not necessarily an issue solved by the framework. Ultimately some kind of package manager that had a manual review step before packages could go out would be a nice step, and would work at scale as well.<p>Manually listing permissions for an application works for security until people get tired, or are just so used to saying yes. Its also very bold of deno to assume their sandbox is impossible to escape. It’s much more likely that no one cares to really try.

What Deno features are tied to TS? Can you eg use the &quot;vendor&quot; feature (or hook it) if you wanted to use it with other languages that compile to JS or Wasm, like ClojureScript or Rust?

&gt; post ES6 [...] has some really good parts, like injection-proof template literal semantics.<p>What is injection-proof template literal? Any link about that? Thanks :)

Seems like going in to more of a .NET land....

One issue that&#x27;s been bothering me about Deno is this one:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;14244">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;14244</a><p>You have to use a third-party Docker container if you want to use Docker locally and develop on an M1 Mac (I use Docker to separate my different dev environments). And the issue was just ignored and became stale.

Looks great, I just hope they get to release an arm64 version for linux soon as well.

I&#x27;d love them if they fixed the import require module mess

I don&#x27;t know, Deno seems to be a solution looking for a problem. For example, the built-in bundle command works for Deno, and &quot;might&quot; only work for the web, other solutions as esbuild are recommended instead.

That kind of import, means private package is not allowed ? So no more private package in Deno ?

fresh.deno.dev reviews ?

Fun fact: I remember when I was at Google in 2017.<p>Ryan Dahl was there as well as a junior engineer (L4).<p>L4 typically are engineers who graduated for 1-2 years.<p>Meanwhile Ryan has built a programming engine that has been used worldwide and widely popular on the same scale of Ruby, Java, Python... But he was slotted as an L4.

Deno #_#

Deno is awesome but I&#x27;m not satisfied with implementation. I wrote very simple web server which listens for GitHub CI notifications (with deno I implemented it all including crypto with 0 dependencies, wow). We&#x27;re tiny company so notifications are like once an hour or something like that. It eats like 50 MB of RAM and eats like 6m CPU all the time. Simple Go server eats around 20-30 MB of RAM and eats &lt; 1m CPU all the time. I just don&#x27;t understand what does deno do all the time with its 6m idle CPU. Hopefully it&#x27;ll be improved in the future.<p>Also I think this whole granular access thing is weird. I never wanted it, container isolation is more than enough. Hopefully it does not add much drag to deno progress.