Reasons I'll never use Deno

Since the release of Deno, people keep posting about their experience with this new runtime. I'll never install this piece of software and this is why:

TypeScript

For some, TS in Deno is the reason they're going to try it. For others, it's the curse. A person's attitude towards this language is located in the following general spectrum ->

• the ignorant: those who just started picking up JavaScript and are happy with it.
• the curious: those who's had some experience with JS and are very curious about TS because of all the information online and many posts about it.
• the experimenters: those who started their transition into TS and seem to like it because they enjoy their "type safety", but not sure if they're going to pursue it.
• the prevented: people who realised that the value of "type safety" is overblown, reduces their productivity and takes them further away from the purity of JS.
• the converted: in parallel to the above, these are the developers who've accepted the benefits of autocompletions brought by TS and really enjoy writing code this style.
• the extremists: those who hate TS's guts and understand how overblown the concept of type-checking is for web-development.

Dare I say, I'm in the ranks of the latter. This is because type safety is not a thing in a dynamic runtime which JS is. Static program will not be compiled if there's a type error, and your TS project won't either. The problem is that it will be executed dynamically, and possibly people who use your library will pass data of incorrect data type to your API. Thus, type safety is only for your private code, which very much can be ensured by unit testing.

Secondly, the type system on JS can be enforced by JSDoc. There's no problem with adding @param comments to your functions, and then hitting that . to get your autocompletions. You don't need to create a new language when all you have to do is to annotate your code with an optional type system.

Thirdly, apart from Flow and TS, there's Google Closure Compiler, which I use to type check my programs. But at the very last, when I've worked a few hours on a new feature, or a few days on refactoring. And after I've written tests. This brings my program from 80% perfect to 90% perfect. There's no program that can't be written without type semantics so why use a language that enforces it.

The reason why is for autocompletions. This is why so many people are into it. And because it can compile modules. But there are other ways, as I said, with JSDoc + GCC.

But it's not the approach to types that I dislike the most, but the hype around it. People learn to say how good it is, learn the "type safety" cliche and keep repeating it, without understanding the real problem. The problem of autocompletions. And it's been abused by MS to enforce the logic that "TS" is scalable whereas JS is not.

Just Another Runtime

Therefore, I strongly believe that TypeScript is "synthetic" and not "professional" like many would want you to believe. It's a toy. If you really want your type safety, switch to Go. Go compiles to native code and is extremely fast. Go is like metal to plastic TS. Go doesn't have a runtime and will properly compile code into executables for Win, Linux and Mac. Node, on the other hand, like all other dynamic programming languages, provide runtime. Runtime to run JS on the server. So why another runtime?

Enough of runtimes. Software has to meet business needs. People build software to satisfy requirements. Software Engineering process is about understanding those requirements, designing the new system, implementing it, testing against functional and stakeholder requirements and maintaining it. Yet nobody knows that.

People call themselves "devs" and jump straight into implementation and then complain that JS is not scalable. JS is a tool to provide your implementation. It's only part of the picture. You need to design a new system in such a way as it can be implemented quickly and coherently by a team, and is flexible enough to adjust to business requirements. TS isn't scalable per se. In fact, it's less scalable than JS because all you're doing is locking yourselves into interfaces. It's not software engineering. Maybe for making websites, but not for making software.

The runtime that Ryan created anew, is nothing new. Nobody needs a new runtime. Even now, Node is starting to fall behind Go and other old blokes like Java because of their stability and 'enterpriseability'. The industry needs tools to solve business requirements and be confident in them. Go is backed by Google and is a proper language. Deno is just TypeScript over V8.

Ryan's Toy

A real language that can invoke trust and security feeling, is a major feat. Only because the web provides an opportunity for people to try out programming, without attending lectures in Software Engineering at university, doesn't mean that there aren't professional Software Engineers left. Software industry's in crisis of misunderstanding its purpose largely because true specialists have lost their voice and value because for people of today, software development is about installing react and TS, and not about requirements engineering and project management.

Everybody will clap to Ryan saying "I first made Node, and then quit it and put TS in my new language!", but how many will see that all he's done is just the same thing, but made it more complex, by:

• adding .ts extension to every import. Really, like WAT? why you can't resolve the name of the file if there's only one file. He also wanted make all paths absolute but I see that didn't quite work out.
• removing package.json and scripts... I mean, ...
• passing flags to access certain scopes. Does it really make your program more secure? You write programs to interact with your computer. If you want it to be secure so you introduce flags, why don't you just throw out your PC and downshift to India.
• having a central store for downloaded packages. pnpm already does that. it's not the task of runime but of package manager.

From these points, it's clear to me, that all he wanted, is to just make another Node, but to make it different, he introduced "features" that are only there so that people don't say that Deno is another Node. Sure, it's his choice, he can go for it, each to his own, but it's not serious. Businesses and enterprises will never adopt this.

Less Secure (upd)

In this post, I can see that you can import like

import * from "https://deno.land/std/testing/asserts.ts";

That doesn't seem so secure to me since there's no sha512 record that guarantees integrity, that can be crucial for security. Not sure how that supposed to work but the idea isn't bad actually :{.

Conclusion

I love my Node and I've dedicated years of development time to it to build my packages. I don't use it because it's Node, but because it's the only solution that allows to run JS on the server. What I really want to see, is the native Node compiler into machine code to skip the runtime and distribute my software without telling people to go get Node. It should be made possible. What I don't want, is a runtime in TS, that removes package.json and forces me to specify the file extensions.

Moreover, Ryan is a Mathematician, and on top of that he dropped out. Sure, it's his massive achievement to be the first to put V8 on a server in the event loop, but it was meant to happen. I don't mean to bully anyone who's not a Computer Scientist and I'm not saying they shouldn't do programming or development. But all people specialise in something. I specialise in Software Engineering, and I understand that software = design + documentation + implementation + testing + project management. It is used to solve business needs. This is the scope we need to think within. I'm sorry if I offended anyone I honestly didn't mean it. I just want to convey my point across that I'm not going to install Deno because of what it represents, i.e. the state of the world where the value of SE is reduced to "somebody famous making a new runtime".

Comments

[Mikael Gramont]

I don't use TS. I think I will but I have not made the transition yet, and at this point it frustrates me because it makes it hard to read source code on Github haha. Deno, I'll wait a year for it stabilize before I try it.
I don't much care for the JS celebrities and the drama, so I don't have any skin in this game. But take a look at these bits:

• the prevented: people who realised that the value of "type safety" is overblown
• the extremists: those who hate TS's guts and understand how overblown the concept of type-checking is for web-development

I'm saying this in case you don't realize it, but those words don't position you as a fair and balanced writer. You're stating your conclusions as facts. It's like you're putting words in my mouth when I read it. And even though you explain your train of thought later, it was infuriating when I first read it.

And then you say:

• all he's done is just the same thing, but made it more complex
• Moreover, Ryan is a Mathematician, and on top of that he dropped out

This is my constructive feedback: if you want to state facts, do so. But dressing opinions and personal judgments as facts will only go well with those who agree already and are looking for confirmation.

And you end with:

• I'm sorry if I offended anyone I honestly didn't mean it.

I don't know for sure, but it sounds like you knew some of this was unnecessarily inflammatory.

[Michiel Hendriks]

I agree with you.

Stating somebody's previous failed attempt to do something might be stating facts, but it's nothing but a logical fallacy. It's Ad Hominem.
I could list a whole bunch of people who created brilliant technology but flunked various degrees. But it feels like wasted time to list them after reading a article like this.

[leob]

I'm also not convinced, neither by TS nor by Deno.

The problem I see with Deno is that it's yet another distraction and yet another bandwagon that people are jumping on and wasting time on.

From what I've seen, Deno isn't advancing the "state of the art". The decision to dump package.json and simply use "import" to pull in all of your dependencies (and then having to use an ugly URL syntax if you want to specify versions) seems a step back. Npm, Yarn, package.json and so on are useful tools and proven technology, why throw it out the window and reinvent the wheel?

Most of all, I just see it as a distraction and a waste of time, which takes away people's focus from doing useful things. It's yet another toy to play around with, to learn the ins and outs of, and to waste time on instead of doing something productive (as in, create apps or useful software).

Less is more. Enough is enough. We don't need yet another way to do essentially the same thing.

Hats off and kudos big time to Ryan for inventing Node.js, but no I don't see the point of Deno.

[4r7d3c0]

If there's something new to invest time to learning, then it's only Dart and Flutter (or Go, but it doesn't have the web app framework like Flutter, not that I know of).

[leob]

You're right ... Rust is also a good one

[Basti Ortiz]

Although I definitely agree that Deno is simply a "reboot of Node.js" (so to speak), I feel as though your "general spectrum of TS users" underrepresents those who truly value from the tooling TS provides.

For me, my main use case for TypeScript is the tooling for IDEs. Debugging JS-powered web applications is much easier with type-checking because of some "contractual guarantees". I must concede that it doesn't solve all bugs, but the contracts do provide some helpful autocompletion suggestions during development.

In response to your suggestion of using JSDoc instead, I would agree to this to some extent because it is indeed a nice substitute for the "JS purists" out there who also want a piece of the TS tooling's cake.

I tried JSDoc myself before migrating my side projects to TypeScript, but I found the comments to be a bit too verbose and cumbersome for my liking. Furthermore, the JSDoc tooling for IDEs (such as in VS Code) is vastly inferior to actual TypeScript. Basic support for types are included, which is good for small projects, but I would imagine that larger projects would simply be better off using TS altogether instead of JSDoc.

And just to add a few more bits of information here, TypeScript also powers the JavaScript "language servers" for many IDEs. At least in VS Code, TypeScript powers the autocompletion for JavaScript and JSDoc. To say that TypeScript is just a fad misrepresents the value of JS tooling we have nowadays.

Sure, one can opt to write pure JS, but at the end of the day, many of our tools (for JS) depends on TypeScript to provide rich developer experiences.

In defense of Deno, Deno simply supports this kind of tooling "out-of-the-box" without the hassle of installing a plethora of NPM packages. That, to me, is the main selling point of Deno. Perhaps not the runtime itself, but the native support for the incredible tooling of the TS ecosystem.

[4r7d3c0]

you're

"the converted" (these are the developers who've accepted the benefits of autocompletions brought by TS and really enjoy writing code this style.),

i genuinely didn't mean it in derogatory sense, i do appreciate the value TS provides for many people. sorry for any harsh feelings i do see that on the background of other points it might have looked negatively

[Basti Ortiz]

No offense taken at all! 😉

This is a great discussion about what Deno really provides to the community. I just plopped in my two cents to the table.

[4r7d3c0]

yeah thanks for your comments they're really useful. as i said there are (and many) people who find salvation in ts and for the right reasons, like contractual obligations.
ah it's true ts provides jsdoc support for us so sure it deserves 👍 on that but it might have been just anything else. it's just because MS give vs code for free nobody wants to or needs to do that job because they won't be able to compete with the IDE. I don't know what webstorm uses for example, it might be TS it might not be, but sure it's possible to perform static analysis without TS isn't, so the implementation can be anything.
it's true jsdoc is pain for larger projects and your comment about it is very much appreciated. i don't use blank jsdoc i use a type manager that generates jsdoc on top of types, so that the types model is actually decoupled from implementation. that also hides away all those bulky /** */ comments in the implementation source code. It's true there's a lot of junk, and Go uses a different format and /// natural language to describe [attributes], but once you put it away, it doesn't get in a way and one can focus on writing code. Finally, personally I'm doc maniac and want every public API param to be documented. I know in TS, you can type params to functions(s: string), but if you want to describe it, you still need to write jsdoc.

[Basti Ortiz]

I totally agree, man. I see what you mean. 👍

For me, the "bulkiness" of JSDoc comments is what threw me off the first time. The two code blocks below are semantically equivalent, but TypeScript frankly does it more elegantly.

// JSDoc Style
/** @type {Error[]} */
const errors = [];

// TypeScript
const errors: Error[] = [];

But relating back to Deno, the whole point of my comment earlier was to shed some light on the perspective that Deno's goal as a runtime is to provide native support for what used to be a cumbersome process of installing and configuring various NPM packages. It's basically the best of JS, but in one neat executable.

As a disclaimer, though, I am certainly not advocating for it's production use yet, but it really is an interesting "toy" to look out for.

[4r7d3c0]

how do you mean various npm packages? what would you need apart from actual typescript? aren't packages compiled into js with types.d.ts provided so that you don't really need anything.

// JSDoc Style
/** @type {Error[]} */
const errors = [];

// TypeScript
const errors: Error[] = [];

this i get 100% it's more natural to flow types like that (for PRIVATE code). Yet I still don't mind to write the first kind if it spares me installing 50mb binary :P

yet when you come writing APIs, in both cases you need

/**
 * Returns an example.
 * @param {string} s The first part of the string.
 * @param {string} t The second part of the string.
 */
export default function example(s, t) {
 return `${s}.${t}`
}

I mean you could've do

export default function example(s: string, t: string) {
 return `${s}.${t}`
}

But then you're not generating full doc. Maybe it's not needed to have full docs with description of params, but I like it. In any way, I believe that documentation CAN be decoupled from code altogether so that you have your types defined completely independently of implementation, and can convert them into an interface in any language, be it js, ts, dart, go... the design stage i mentioned in the post involves object modelling, which can be split into Conceptual (business stakeholders), logical (db entities) and physical (data types). So that types are not even part of implementation. By taking a step back, we can take those out of the actual source code, and design "abstract" types. This means that we can then distribute those designs between members of the team, and they can communicate and work on them in their own time, such that the front-ender will do his job in JS/TS, and back-ender can work with the same data types in say Go or anything else and they'll be consistent with each other. there are many times web development is a one-man job, but for larger, and truly scalable projects we need a better approach :)

[Basti Ortiz]

I can't really argue against your separation of concerns (as in documentation and implementation). I actually agree with it. Unfortunately, it's really just a matter of taste when it comes to the discussion of syntax.

In regard to the "NPM packages" I mentioned, I will particularly note Webpack and Babel for more advanced TypeScript projects. Testing TypeScript is a whole other beast in and of itself, too. That's what I mean by TypeScript being a hassle in the default Node environment (compared to Deno).

[Richard Schloss]

NodeJS is still really cool, I appreciate you taking the time to provide your perspective on this new topic.

[Richard Schloss]

I personally wish Ryan would've stuck with Node and just iterated on the project instead of resorting to a complete rewrite. I'm still happy with Node.

[Damian Cipolat]

Nice! I'm 100% agree with you.

[ajv]

Whilst I enjoyed this article because of your writing skills, I couldn't agree with almost any of your points. As Mikael mentioned in his comment, it seems you were inflammatory on purpose and just wanted to vent (and not make actually valid arguments against Deno). But to each their own.

The biggest controversy to me here was that you have issues with Deno's take on package management and at the same time preach how great Go is (which handles its dependencies the same way).. Anyone else see the irony? 🙄

Thank you for the write-up though

[Peter Street]

I look at coding as the right tools for the right job. I'm not sure about Deno — my job doesn't involve a lot of JavaScript on the server or client at the moment; I also feel that servers are better handled by closer-to-the-metal structures. However, I disagree on TypeScript for one fundamental reason: It's easier to fail-safely.

Development is hard. Debugging and testing is hard. This is why we can command significant salaries for what is basically turning requirements into machine-langauges. If it was easy, there'd be an automated way to do that translation, but because of the inevitable number of moving parts, it needs a lot of thought, attention to detail and consideration before a simple requirement statement can become something that runs on a client or a server; and that's before you start looking at OWASP or other security requirements.

TypeScript makes it harder to make stupid mistakes. Type Security makes it harder to make stupid mistakes, is a better way of saying things. The default is to go, "Oh — this is wrong, did you really mean that?" I want that in my life, because I want to have the 'easy' to check stuff checked for me, I don't want to have to remember to write a unit test just to make sure that internal movements are right. That's the equivalent of contract testing, and should be automateable. TypeScript gives me that.

I don't really have an opinion on the other parts — I approve of more tools, but I don't see TS or JS as server-side suitable tools at their heart. They've been used that way, and they make amazing utilities and tooling, which constantly impresses me.

[Julian Pufler]

Really good article!! We share the same opinion on TS and Deno! :)

[István Pató]

"Design Doc: Use JavaScript instead of TypeScript for internal Deno Code"
docs.google.com/document/d/1_WvwHl...

Ryan Dahl:

"So - to make a long story short - we're removing the types from internal code and making it pure JS
this reduces complexity and helps us ship a faster product."

[danneu]

Condescending, hot garbage.

[Regan Koopmans]

I think the claim that deno is less safe than node is intellectually dishonest. The only reason malware hasn't killed npm is because it has spent enormous amounts of money on tooling to keep track of possible vulnerabilities, and bitcoin miners still exist. Deno is sandboxed, and does not need to pull dependencies from a single authority. Someone deleting left-pad should not bring down the internet.

[Sergio]

Would you travel on an airplane developed in JS? Highly productive Dynamical Safety 😂 Ups, I forgot some unit test...

FYI, parsing and serializing inputs are performant-killers but for a great safety in runtime. Check Zod.