First impressions with Deno from building PlanetTypeScript.com
Tags: deno, typescript
Published: 2021-06-07 20:18:27

---
title: First impressions with Deno from building PlanetTypeScript.com
published: true
description: First impression with Deno after using it to build PlanetTypeScript.com
tags: deno, typescript
canonical_url: https://www.geekabyte.io/2021/06/first-impressions-with-deno-from.html
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u0q271dr2p48wsu4avhv.png
---

[PlanetTypeScript.com](https://www.planettypescript.com) is a content aggregator for all things TypeScript. It regularly polls RSS feeds for TypeScript related content, which it then list on the site, send out as a tweet via [@planetypescript](https://twitter.com/planetypescript), and also as a weekly digest to subscribers.

Back when I used to write a lot of Java-related content on this blog, I found out that my blog ended up on www.topjavablogs.com/, which is a site that aggregates Java contents. So when I decided to play around with Deno, I thought a nice little idea would be to build something similar to topjavablogs.com, but for TypeScript. And that is how [PlanetTypeScript.com](https://www.planettypescript.com) was born.

In this post, I will share some of my first impressions with Deno. The things I enjoyed and the bits I found inconvenient. Let's start with the cool stuff.

### Native TypeScript Support
I find it super convenient that I could just write TypeScript without worrying about setting up a build chain that would take care of the _transpilation_ to JavaScript. This is really nice and it makes TypeScript feel more like a standalone language in its own rights. This has to be one of the top-selling points of Deno for me.

### Built-in utilities
The deno CLI comes with a whole lot of useful utilities and just comes in handy. For example `deno info` to check the dependencies. `deno fmt`: a code formatter,  `deno bundle` for bundling modules and dependencies into a single file, `deno compile` for creating a self-contained executable, etc.

I personally find dealing with build pipelines within the JavaScript ecosystem to be a tiring chore. Having something like `deno bundle` or `deno compile`, built-in is super useful, as it takes care of most of the heavy lifting when it comes to deployment.

### Web API
Deno seeks to provide implementations of Web API, and this I found to be really handy. For [PlanetTypeScript.com](https://www.planettypescript.com), I need to make HTTP requests and also run background tasks. I could use `fetch` and `web workers` for this. API's I am already familiar with coming from the Web, hence no need to install third-party libraries. This is super convenient.

### Good Standard Library
In the course of building [PlanetTypeScript.com](https://www.planettypescript.com), I needed to have logging, base64 encoding, use hash functions, and generating UUIDs. I was able to find modules within the Deno standard library that I could use for all of these. The Deno standard library is quite decent and has a battery-included feel to it. You can peruse the available modules here.

### IDE Support
I primarily use Jetbrains IDEs. When not within a full-blown IDE environment, I use Microsoft Code. Both of these tools have plugins that implement support for Deno and they work very well. I was able to use the visual debugger in IntelliJ, which was quite handy.

So these are some of the cool things that made a good first impression on me with Deno. Below are some of the things that were a bit of a hassle.

### No Registry and Package Manager.
Deno does not have any well-known central registry from which a package manager manages dependencies. Instead, Deno works with plain URLs. This setup leads to certain consequences which I believe hamper the developer experience. 

For example, there is no central file to look into, to see all the dependencies of a project. To work around this, the convention in the Deno community is to re-import all dependencies from a file called `deps.ts` - basically recreating some sort of `package.json` as you have it in `npm`.

Also, there is no easy way to quickly see if there are new versions of any of my project's dependencies. Or even better still, no command I could run from the command line that updates dependencies. 

I later learned about [Trex](https://github.com/crewdevio/Trex) and [dmm](https://github.com/drashland/dmm) which could be used to achieve some of these tasks. I can't comment on them now as I have not gotten around to try them out yet.

From the perspective of the developer, I am yet to see the advantage the Deno model brings to the table. Instead, it feels to me more like a philosophical design decision, rather than a pragmatic one.

### Nascent Library Ecosystem.
The inability to find needed third-party libraries proved to be one of the main inconveniences.

I had issues finding a third-party library to deal with OAuth. I tried [Dashpart](https://github.com/oslabs-beta/dashport), but it has become incompatible with recent versions of Deno and [Oak](https://oakserver.github.io/oak/) (the HTTP middleware library I used). I tried using Firebase-auth, but there is no support for Deno.

I use MailChimp for sending the Weekly digests. Since the content of the emails would be different weekly, I needed to build the message dynamically. This involves interacting with MailChimp via its API. Unfortunately, MailChimp does not have an API client library for Deno, so I ended up having to directly call the needed HTTP endpoints.

Deno does have a compatibility layer that makes it possible to use Node/npm modules from within Deno. There are also CDN's like Skypack that make it possible to import npm modules for use within Deno. What I quickly realise is that these workarounds, work best for the simplest of libraries. It does not work for anything slightly complicated. For example, I could not use any of these methods to get the Node library for Firebase-auth nor Mailchimp client library to work.

This nascency is strictly not a structural issue with Deno and something to be expected, given how new Deno is. This is also the sort of thing that would improve with time.

### Conclusion.
I enjoyed using Deno. Having native TypeScript support, various CLI utilities, and a battery included-standard library, makes it easy to get productive real quick. The main inconveniences I encountered can be chucked up to Deno still being relatively new, but even with that, it is still a hell of a lot usable/productive for a 3 years old project.