Deno Deploy Thoughts

This is some old draft article that I didn't want to trash, so I'll try to at least partially salvage it.

I played a bit with Deno deploy a while back, and I must say quite impressive that using Deno deploy is very easy to fast spawn a serverless worker, similar to a Cloudflare worker.

If I were to deploy something on a large scale where serverless workers could be a suitable environment as a replacement for a different backend set-up, and I had to choose a paid service, I would probably go with Cloudflare only because it allows the worker to be written in several languages, and thus gives you better flexibility. 

The problem with serverless workers is that there are invariably pretty limited. But since I first wrote this draft, big shots like Cloudflare, Deno Deploy, Netlify, and Vercel made strives to improve and expand on serverless computation, which partially demonstrates that only in a few months something that seems limited can "magically" and quickly evolve.

Still, in some cases, you can have hard-time CPU limit restriction, missing STDLIBs, unflexible runtime environments, and removed functionality, and to this enumeration, I am sure anyone can append other examples.

But there are cases when serverless workers are the way to go, and it seems recently that's the case if you want to gain an edge. (pun intended)

There are instances and cases where serverless workers can be unbeatable in response time. 

If the functionality is simple enough, they can substitute microservices. In a way, they are micro-microservices, with the keynote difference being that resource orchestration is done by someone else. 

And here is the compelling case for a small side project, Deno Deploy is one of the easiest ways to get something running, the quota for fair use is far more generous, so if you are willing to play with a Deno that's a bit restricted and not the latest version to build some small backend Deno is clearly a better choice than CF workers. 

I like to thrash and joke about Deno sometimes, but I think it pushed and inspired Node to not get stuck in the past, in fact, the next version of node LTS will have some features that Deno premiered first.

Here's a popular list of things that Deno has out of the box, and ok Deno is slower than the new kid on the block: Bun, but one first criticism of Deno is: "not mature enough," and if you think that about Deno then I have a story to tell you about Bun.

Anyway, here is the list: 

•  Deno runs Typescript files without needing ANY extra library/installation/package.json .... nothing. Just execute "deno run file.ts" and you are good to go.
• No need to install and configure Eslint as deno comes with a linter baked-in.
•  No need to install and configure prettier as deno comes with a formatter baked in exactly like in Golang.
•  No need to set up tsconfig and configure eslint/prettier/TS to work well in harmony as Deno does all of this for you without needing any dev to create a single config file which you need to do in the Node.js ecosystem. All the errors are just hidden behind Deno errors and not one line shows three errors "eslint", "prettier" and "TS error" which is prevalent in the Node.js codebase. You only see "Deno" errors be it formatting, linting, or TS as everything is deeply integrated with Deno and abstracted from the developer.
• No need to install jest (or mocha/chai/sinon) as Deno comes with all the bells and whistles to do proper testing which requires third-party modules in the Node.js world.
• No need to install nodemon as "deno watch" will already do the reloading for you on file changes and run typescript files directly.
• No need to install ts-node/ts-jest and configure it to make typescript tests work well with jest as deno inbuilt testing covers all of that for you.
• No need to install socket.io or any WebSocket library as you do in Node.js as Deno comes with built-in support for WebSocket. In Node.js there is no inbuilt support for WebSocket.
• No need to install commander npm module (for the most part) like you need in Node.js as Deno already supports confirm/prompt and all the APIs which browsers already support.
• Deno compiles to a single executable binary "deno compile" command (again exactly like golang) so containerizing deno apps is extremely easy and it's perfectly suitable to create CLI apps as you can easily distribute the binary and no extra need to install anything on the user device. In Node.js you would need to install either "nexe" or "pkg" third-party module and configure them to achieve the same which deno compile give you for free out of the box.
• Top-level await, fetch, etc. just works. In Node.js fetch API (similar to browser) is added but to use top-level await a file extension needs to be either ".mjs (or .mts)" or one needs to create a package.json file in the same folder where the file with top-level await exists and add "type": "module" entry in package.json if you don't want to use .mjs extension.
• Web API compatibility with as many of the same APIs which work in the browser (including localstorage/sessionStorage/crypto etc.) and has kept the same function signature in Deno.js whereas in Node.js either many of those web APIs have no equivalent and don't exist or they need a lot of workarounds to get it implemented (ex renaming to ".mjs" to get top-level await working or their difficulties implementing proper "ESM" support etc.)
• Import works smoothly and no messing with module/common.js resolutions etc.
• ALL the Deno APIs are modern and built with async/await from the ground's up so no need for "fs/promises" or "promisify" anything. Moreover, all the APIs feel very modern in syntax and easier to use than Node equivalent including their HTTP server, reading from the command line, etc.
• Recently Deno announced that "the next release of Deno will include a new HTTP server. It is the fastest JavaScript web server ever built." So Deno.js HTTP server will be faster and lighter than Node.js and Bun.js according to them. Source here on their official blog post.
• In the same update, they also mentioned "*We've been working on some updates that will allow Deno to easily import npm packages and make the vast majority of npm packages work in Deno within the next three months". Source here on their official blog post.
• Their latest release comes with a bunch of performance improvements, npm compatibility, improved DX, Cache API implementation in Deno as well, and support for the latest typescript. so they are very exciting.
• Deno deploy and their support for cloud/edge function looks pretty sleek to get up and running quickly without much effort.