Reasons I'll never use Deno

4r7d3c0 — Mon, 18 May 2020 01:46:30 +0000

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".

DEV Community: 4r7d3c0

Reasons I'll never use Deno

TypeScript

Just Another Runtime

Ryan's Toy

Less Secure (upd)

Conclusion