Deno is a new implementation of a runtime environment by the original creator of Node. v1 came about roughly a year ago and it’s basically a redo of Node with all the insights gained and the newest proven technologies at its core. Deno is implemented in Rust and sports TypeScript as a native and first class citizen. By default Deno has no local access, it has to be given explicitly which is the right way to secure things. It has integrated tooling such as a bundler and a formatter and it loads external components via URI, so it’s basically SOA-ready by nature.
If you’re a Node person and are exhausted by the endless stream of *config.js files and flaky Node & Container setups and build-chains taxing your nerves with their need for perpetual babysitting, Deno might just be the relief you need.
As far as I can tell Deno has a real chance to be a true gamechanger in modern web development with the potential to bring complete and universal client/server transparency and integration to the Web and contemporary projekts. I do PHP/LAMP most of my day and like countless stacks before and despite the usual initial boasting, I’ve seen Node failing just like many before in being a real competitor in terms of cost/benefit, time-to-market and delivering results. I’m not betting on Deno to get any further just now, for that I’m too aware of PHPs benefits for most everyday requirements. However, as war as modern web-centric service/daemon runtimes go, Deno is a notable step-up from anything we’ve seen so far. The Jamstack camp is still hesitant to use Deno in production, but I wouldn’t be. To me the Jamstack as we know it seems like a prototype to Deno. Or, in other words: If I would be in charge of implementing JS/TS/V8 on the server-side, Deno would be a good resemblence of the results I’d be aiming for.
Bottom line: If you’re planning a fresh non-trivial web-centric PWA these days and need minimal fuss for managing your stack, my money would be on a Backend based off Deno.