Why I haven’t switched to Deno. Yet…

I would like to start this article off by declaring I am a big fan of Ryan Dahl. I think what he managed to achieve with the creation of Nodejs was incredible for the Javascript world. It changed so much for Javascript developers and opened up so many possibilities. I also respect Ryan as a developer. He works hard, he follows his instincts and he’s not afraid to go against the grain.

When Ryan did his presentation on ’10 things I regret about Node.js’:

I thought he was being a little harsh on himself. I get the intent behind the presentation but for me the lasting taste I came away with after watching this speech was that Ryan was being overly critical of himself.

I also respect Ryan as a developer. He works hard, he follows his instincts and he’s not afraid to go against the grain.

Introducing Deno

However, Ryan being the ever industrious developer that he is, presented a new and exciting project — Deno. Initially I was super excited and immediately went into trying it.

Rocky Start

My initial impression of Deno was that it wasn’t ready. I also quickly realised the importance of a good ecosystem and community around any code product and Deno didn’t seem to have that.

Why I change libraries

In any project I am working on, if I am thinking about changing a certain library I am using there are two main reasons why I would do that:

1. There is a significant problem with the current library I am using.
2. The new library I am looking at brings in significant improvements.

I realise the word ‘significant’ here is subjective so I will try to give an example.

Before using react-query (now tanner query) to assist in data fetching I used to use useState and useEffect to help manage loading and errors when making api calls. This previous way worked and was fine but when using react-query for the first time it was a significant improvement. Suddenly less code, consistent way to call apis, sensible default cache settings out of the box and very easy to handle loading and errors.

There is nothing significantly wrong with Nodejs

This is the first massive hurdle for Deno in my opinion. Nodejs is used extensively through the Javascript community on projects ranging from individual all the way up to enterprise. It is robust. It is mature. It is thoroughly battle tested and it continues to prevail. There is nothing significantly wrong with it so why would developers jump ship? Especially when their codebases are so invested in it.

Deno doesn’t bring any significant improvement

It really pains me to say this (as I hope Deno succeeds into a mature runtime environment) but from everything I’ve see it doesn’t really bring any significant improvements to the table.

Looking at the Deno Homepage it lists the following as reasons to use Deno

• Native support for TypeScript and JSX
• Backwards compatible with Node.js and npm
• Hassle-free deployment
• Avoid installing dependencies
• Web-standard APIs
• Best in class HTTP server speeds
• Secure by default
• High performance async I/O with Rust and Tokio
• Comprehensive standard library

The two that jump out at me here are:

• Native support for Typescript and JSX
• Backwards compatible with Node.js and npm

These sound great and tempting but is it enough? Is it enough for me to go through the rigmarole of incorporating this into my daily development cycle and replace Node? The backwards compatibility with Node.js and npm is an interesting one. This seems like a concession on Deno’s part as originally it seemed Ryan wanted a complete separation from Node.

However, sadly the answer is No (at the moment).

Convincing my team to switch

I would say at the moment I just wouldn’t have the arguments to convince my team mates that we should switch our codebase over from Node to Deno. We work on apps that are used by many many people and to replace the underlying foundation just seems too risky at the moment. There are so many unknowns:

• Will it run fine on AWS?
• Will it be compatible with our current npm libraries we use?
• How do we switch over?
• What changes will we have to incorporate into our day to day working?
• Will the testing run the same?
• Do we need any special configs or anything?

TBH I could probably find all these answers in the docs or online but the motivation for me to do this just isn’t there as I don’t see clearly the benefits it will bring.

Conclusion

Deno does still seem to be maturing and it’s come a long way since it’s first introduction. However, I don’t see myself switching anytime soon as the significant gains are just not there for me. Maybe in time all the little improvements will add up to make the switch justifiable but at the moment I don’t see that happening. I will however keep a close eye on the Deno development and maybe one day I’ll make the jump.

About me

I am a Frontend Developer working mainly with React and Typescript in my day to day professional life. I love exploring new tools and libraries and love the Javascript Ecosystem.

I like to write blog posts that share exciting new tools I’ve discovered, how-to articles and also the occasional opinion post.

I live in Prague in the Czech Republic with my family.

Check out the original blog post on my blog here.