I started a project with a Deno backend and Svelte front end last week and it was painful trying to share types between the projects. Deno not allowing imports without file extensions '.ts' and the Typescript tsserver not allowing imports with a '.ts' extension is really annoying, and neither group seems to want to budge. I ended up having to create a shared types folder and a script that copies the files to each project stripping out file extensions for non-Deno projects.<p>Does anyone else have a better solution shared Typescript code?
I don't really get the point of Deno anymore. First they were all about their sandbox/security system, but since you couldn't specify that per module it turned out basically useless.<p>Then they had "url" imports, but now they're adding npm compatibility. At that point people will just keep publishing on npm, so I don't see why I should go to the trouble of switching to Deno.
I've recently used Deno to implement a couple of bots for a small discord channel, namely webhook handlers for Discord Slash Commands and Twitch's EventSub. It's honestly been amazing. Next to no configuration and deployments are dead simple. Just set up some env vars and push to github to deploy.
About 3 months ago I got my feet wet and fiddled around with it for a bit. Eventually I used it to deploy(using deno deploy) a small script which would forward calls to an unofficial API of some App. It turned out chrome would not let me set a Cookie header (which the API required) due to some security policy in my axios calls so my script would proxy the request and inject it when calling the API.
I was pretty amazed by how easy the whole process was. I can see myself using it more often for side projects and even recommending it at work (If I get the enterprise java crowd to try something new).
I had attempted to use Deno not long ago, but I learned that (apparently, I might be wrong) you can only get proper intellisense/error checking support if you're using a VS Code extension. I write my code in Vim/Neovim almost exclusively, and the import declarations really screwed up my TypeScript plugin; it didn't know how to handle the URLs and so I had no intellisense/error checking.<p>I gave up after searching around for a few minutes and learning that for now I'd need to use VS Code to write Deno code, if I want those features.
The FFI interface looks very neatly designed. Here's how the SQLite module is implemented using it: <a href="https://deno.land/x/sqlite3@0.3.0/src/ffi.ts" rel="nofollow">https://deno.land/x/sqlite3@0.3.0/src/ffi.ts</a>
I love the current version of Deno for smaller hobby projects. But using it in a full blown production env with actual paying customers depending on it is a whole different story.
Deno is a lot simpler and more cohesive than node. But the simplicity is what currently stops me from attempting any big projects with it. Yes, having no package.json files is great - but on the other hand it hinders me from configuring my project in one file.
If you like Deno because of TypeScript, you're gunna love this: Imagine the jump from JavaScript to TypeScript, only taken to a whole new level! It's free, open source, cross-platform, really fast, has an enormous ecosystem, and is great for games and native apps! It's called C#.NET.
Anyone have more info on this concept of Isolates-as-a-service? (or know of an open source platform that lets you host it, kind of your own lambda but with isolates?) I'd love to use something like that locally (in our environment) to execute user-generated code in a sandbox away from our code so that we can allow customers to write custom functions.
I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (<a href="https://github.com/brundonsmith/bagel" rel="nofollow">https://github.com/brundonsmith/bagel</a>). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here.<p>1) The documentation for the standard APIs is extremely wanting. The main, and weirdest, problem is that it seems almost impossible for search engines to index (or at least DDG). I can search for very very specific things, and still get kicked to the home page and have to manually navigate to the part I’m looking for (and the navigation is also pretty difficult; I often can’t find the thing at all and have to rely completely on editor hover-overs for documentation). It can also be confusing- some things like certain standard APIs appear to have multiple conflicting reference-manuals? And it can be hard to know which one is current or correct. Even getting past all the obfuscation, the docs are just ok. They often leave out deeper details (this last part is less of a problem and more understandable, this being a young project).<p>2) The VSCode extension still needs work. It’s usable, and better than nothing, and it’s better than it used to be, but (ordered from most to least significant):<p>- When I open certain files - usually bundles or something; maybe files outside of the project directory? - the language server crashes over and over and over, each time popping the terminal back up to show the output and distracting from what I’m trying to look at. This doesn’t happen with my normal, in-project Deno files at least.<p>- It doesn’t have auto-import as you’re typing like normal TypeScript does; you can auto-import by clicking the lightbulb, so I assume it’s a relatively short hop to plug that in. Makes a significant difference in flow.<p>- It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs.<p>- It has caching issues sometimes. I’ll change some type in one file and other files won’t get the updated type until I close and re-open them, or sometimes the whole editor. This is uncommon so it’s not a huge deal.<p>I list these criticisms because I want to see Deno succeed. Switching from using TypeScript on Node (with the build steps/configuration, ad-hoc testing and linting, and Node’s pathological legacy APIs) to Deno was a huge quality of life improvement, even with all these problems. Brought to its full potential, I think Deno could be a revolution.
Ryan seems to be a brilliant engineer that takes (only) two attempts to get something right. The cost of such remarkably rapid learning is that he often gets it completely backwards the first time.<p>Inventing Node before Deno. Creating a compatibility mode in Deno to run Node scripts instead of a tool to port Node scripts to Deno. They even maintain a tool to convert Deno scripts to Node. You really can’t get it more backwards!<p>I sometimes look at his GitHub issues and PRs and wrong ideas are not rare. Thankfully he assembled a good team that double checks him and catches most of those wrong ideas. But they can only catch so many, and it’s likely more difficult for the executive decisions of the Deno company since money is directly involved like creating a Node compat mode.
If you'd like the Amazon JavaScript SDK to support Deno then make your support known on this thread:<p><a href="https://github.com/aws/aws-sdk-js-v3/issues/1289" rel="nofollow">https://github.com/aws/aws-sdk-js-v3/issues/1289</a>
I’ve recently started a new personal project and I’m using Deno. I’m really happy with it as my main complaint about typescript currently is the transpile process slows down development when you’re used to all the bells and whistles of modern JavaScript. Things like hot reloading take 3x as long.
It's interesting to see the intersection between Deno TypeScript code and native Rust libraries, e.g the native HTTP library [1], however it would be interesting to see a performance evaluation between this and a regular express app.
I also dont get the point of Deno. when i was looking into it seemed to me that was presented as a modern NPM alternative. Yet, it is completely unusable for any kind of frontend work. Which is wierd, since javascript is a frontend language. You cannot use it to write anything that uses DOM API. Not sure if that is supposed to change. Would be nice if it was clearer that it is a solution for back-end only.
I had a weird experience on Libera.chat #node - I asked if anyone knew of an official #deno channel and ljharb's [1] reply was (something like) "deno is repeating all of the mistakes that JS has made in the browser" and the sentiment was that "deno sucks." I found it to be a strange comment.<p>[1] <a href="https://github.com/ljharb" rel="nofollow">https://github.com/ljharb</a>