Used by the likes of Netflix, Uber, and PayPal, Node.js is one of today’s hottest technologies. Its versatility, scalability, and event-handling abilities quickly earned applause (and heavy use) from developers worldwide.
Created by Ryan Dahl in 2008, Node.js solves several problems simultaneously. It enables programmers to use Javascript on the backend and the frontend, removing the need for workarounds. Additionally, its single-threaded architecture allows for a lightweight, rapid framework that can easily handle real-time events — critical for any app in an increasingly connected world.
Recently, Dahl released Deno, another Javascript-based framework that improves on Node.js in areas like speed, efficiency, ease of use, testing, and packaging. Intrigued by this promising new product, Michael Lynn, Principal Developer Advocate at MongoDB, sat down with Jesse Hall, Senior Developer Advocate at MongoDB, to talk all things Deno, including strengths, structure, scenarios for use, and much more.
Below are some highlights from their discussion. To listen to the full episode, check out the MongoDB Podcast here.
The successor to Node.js
Michael starts off the podcast with the question we’ve all been waiting for: What’s so special about Deno? After all, Deno is a runtime for Javascript and Typescript — similar to Node.js, at least superficially.
“Why would we want to use Deno over a standard Node.js implementation?” Michael asks.
“By default it’s secure,” Jesse replies, especially in contrast to Node.js. “That is one of the big selling factors, because you have to specifically tell it to open your network in order to allow access to read or write files.”
In essence, Jesse explains, Deno is “set up to be the successor to Node.js.” As such, it includes a number of helpful features and attributes, such as blazing-fast speed (thanks to its Rust-based architecture), support for ES modules, and built-in asynchronous functions (removing the need to create your own).
Better package handling = increased efficiency
Deno also streamlines the development process in various ways — particularly when it concerns packages.
Unlike Node, which requires a NPM package manager, Deno simply “downloads [packages] globally and caches them,” Jesse says, removing the need for a Node modules folder in your project. Because Deno pulls packages in through URLs, this removes the bloat associated with having a Node modules folder in a project.
Michael wants to know if this affects development negatively — especially when it comes to offline development. Even if the files are located locally, surely Deno must require some sort of cached folder or module structure?
That’s not necessarily the case, Jesse replies. “You do have a local cache of those modules, and when you actually import them in the URL string, you can specify what version (if you wanted a different version).”
Deno x MongoDB
Of course, given that both Michael and Jesse work at MongoDB, the million-dollar question remains: compatibility. “What does the support for MongoDB look like in Deno?” Michael asks.
For now, Jesse explains, support comes in the form of third-party, community-supported modules only — specifically a Deno module called Mongo, easily accessible through the Deno website. As an alternative, Jesse suggests the MongoDB Atlas Data API, “which will allow you to bring your MongoDB data into basically anything, because it doesn’t require drivers at all.”
And much more...
For more detail, listen to the full podcast here. For a detailed walkthrough on using the Atlas Data API to import your MongoDB data into Deno, check out Jesse’s article here.