11 ms·

Deno in 2021

205 points by 0xedb 5y ago

postalrat 5y ago
It would be really cool to see the service worker api supported in deno.
- Miaourt 5y ago
  Why would you need that in a runtime context ?
  - dgb23 5y ago
    Maybe to build custom proxies with the same API.
    - postalrat 5y ago
      Proxy or server
edgyquant 5y ago
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.
- lucacasonato 5y ago
  Try `--no-check` when using `--watch` and you already get type errors from your IDE. Should speed up hot reload and hot restarts significantly :-)
91edec 5y ago
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. Does anyone else have a better solution shared Typescript code?
- AbuAssar 5y ago
  Related: https://github.com/microsoft/TypeScript/issues/42813 https://github.com/microsoft/TypeScript/issues/42813
- piaste 5y ago
  > 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. Still a hack, but perhaps symlinks could be a little simpler?
- makapuf 5y ago
  Yes had the same issue. Had to make deno run js files and import js produced by ts.
- stickyricky 5y ago
  Whats the purpose of sharing types? Define entities on each and leave behavior as a domain consideration. Clients should be disposable and decoupled. If you want to render html on the server that's fine but svelte isn't the best choice for that.
  - afavour 5y ago
    > Whats the purpose of sharing types? Server sends data as JSON to the client. Client parses JSON. Both now have the exact same data shape. Shared TS types let you use the same representation for the same data no matter where.
    - stickyricky 5y ago
      At the expense of coupling which is not a trivial concern. Regardless, the browser is the only platform capable of using those types (even so the types aren't shared but generated). You don't use those types in Swift or Java or Kotlin. You don't use those types in a python client library.
      - danielvaughn 5y ago
nozzlegear 5y ago
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. 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.
- 91edec 5y ago
  If you're using coc you can add the coc-deno extension and initialize the project with `CocCommand deno.initializeWorkspace`.
  - nozzlegear 5y ago
    Thanks! I didn't know about the coc extension, I'll give that a try.
    - choward 5y ago
      I have to believe that you leaving the "-deno" off of "coc-deno extension" was intentional which I find to be pretty funny.
  - phil294 5y ago
    Neovim apparently supports the LSP protocol natively, so could you please explain why CoC is necessary?
    - chana_masala 5y ago
      From the last I saw, coc is still more feature rich than native LSP in Neovim.
- brundolf 5y ago
  It does suck that it can’t use standard typescript tooling because of a couple of small, key, breaking-differences (mainly the import path style, to my understanding). I don’t think they could have done it any differently, and with enough traction the ecosystem support is a solvable problem, but it’s still a shame.
Escapado 5y ago
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).
- egeozcan 5y ago
  In my experience, enterprise Java crowd never spills its managed beans. In my whole career, I couldn't even get any of them admit that JSF may not be the best front end technology in the world. It's a lost cause.
  - rukshn 5y ago
    I have to second this. I worked on a java app which was painful to scale, due to JSF and JPA. I have distanced myself from the project as much as I can. Now, I see another new app for a different purpose being started and I hoped to push for a modern way of building it, but no they just won't give-up using java and JSF. Nothing wrong with java, it's just java and jsf crowd is hard to be converted to something else.
tfsh 5y ago
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.
- tills13 5y ago
  I am very interesting in the performance implications here as their _has_ to be some performance tradeoffs given you have to serialize / deserialize across the bindings. I get that Rust is fast, but at what point does the trade-off no longer make sense?
- searchableguy 5y ago
  https://deno.land/benchmarks https://deno.land/benchmarks is what you are looking for.
- AaronO 5y ago
  On many of our internal benchmarks, Deno's std/http server outperforms Node's http (so express/koa too). There's still some room for improvement on our end and we would like to put together rigorous benchmarks before sharing that broadly.
Epskampie 5y ago
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. 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.
- nllsh 5y ago
  If you are concerned about security in one of your imported dependencies (or in user code) you can run that code in a sandboxed worker (See: https://deno.land/manual@v1.18.0/runtime/workers#specifying-worker-permissions https://deno.land/manual@v1.18.0/runtime/workers#specifying-...). Beyond this it is still very useful to limit your runtime for software to only access specific directories, network addresses, etc. So the sandbox/security is definitely not useless.
- brundolf 5y ago
  Running TypeScript directly is a great part, but there’s a bigger, little-discussed aspect: Deno has a built-in, prescribed, standardized, - Testing framework - Linter - Bundler - Formatter It’s like having Cargo or Go’s CLI for JavaScript/TypeScript. It eliminates so much fiddling and breakage, gets everyone in the ecosystem on the same page, etc. Even for a solo project it’s been a dream to use, compared with the hodgepodge of a Node project.
- sondr3 5y ago
  At least for me one of my favorite things is how integrated it is, after having used Rust for a while, having the compiler, linter, lightweight testing and formatting all in one bundle is an amazing time saver and a major boon for me. No more fiddling with ever growing configurations for ESLint, or having to install Jest/Ava/uvu/tap for testing and their ESLint rules and then Prettier which may also require ESLint... I realize not everyone cares enough to configure it, but the approach of Deno (and Rust, and Go, and so on) is such a weight of my shoulders when starting a project. Just open Neovim, create a TypeScript file, write some tests, all without having to do any kind of configuration or installation of packages.
- 5y ago
andrewstuart 5y ago
If you'd like the Amazon JavaScript SDK to support Deno then make your support known on this thread: https://github.com/aws/aws-sdk-js-v3/issues/1289 https://github.com/aws/aws-sdk-js-v3/issues/1289
jbirer 5y ago
Deno came too late, there is Go and Rust now
- esjeon 5y ago
  Yeah, that's kinda sorry state of Deno right now. We have more than pure JS/TS ecosystem that NPM used to thrive on. The backend market is already leaned toward Go. It's the best language for microservices. We also have WASM entering the scene on the frontend side, which allows mixing other languages, especially Rust. Hell, I heard some people ported a whole C++-based UI engine to make it cross-platform. We're already entering the next generation.
u-rate 5y ago
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.
userSumo 5y ago
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.
deleted 5y ago
[deleted]
brundolf 5y ago
I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel https://github.com/brundonsmith/bagel). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here. 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). 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): - 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. - 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. - It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs. - 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. 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.
- ravenstine 5y ago
  Yeah, I've seen worst API documentation, but their docs site is needlessly weird. Documentation is something that should be solved by now. No project needs whatever custom thing Deno uses. I don't get it. Leaving out details, for the most part, is the right approach for now, I think. Only Node/JavaScript veterans should probably be using Deno for the time being. But I definitely hope Deno can eventually take over and make Node obsolete. > 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) At this point, I've kind of given up on VS Code language/runtime extensions in general. Virtually none of them work with the slightest variation in toolchain configuration, whether it's C++ or Typescript or even ESLint. You're lucky if they don't slow the heck down over time. Import paths are the worst! Somehow that's something I inevitably run into, again, no matter the language. I kinda want to blow all this stuff up and start over. Maybe Deno is a part of that equation. haha
kentor 5y ago
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.
- ipnon 5y ago
  Deno seems ideal for the now common use case of serverless JavaScript, erm, servers. It's hard to imagine the project superseding the prior art in other domains, however. Deno is a little too weird.
simonw 5y ago
The FFI interface looks very neatly designed. Here's how the SQLite module is implemented using it: https://deno.land/x/sqlite3@0.3.0/src/ffi.ts https://deno.land/x/sqlite3@0.3.0/src/ffi.ts
DrFell 5y ago
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.
chana_masala 5y ago
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. [1] https://github.com/ljharb https://github.com/ljharb
atonse 5y ago
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.
justshowpost 5y ago
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. 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! 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.

Deno in 2021

205 points by 0xedb 5y ago

postalrat 5y ago

It would be really cool to see the service worker api supported in deno.

Miaourt 5y ago
Why would you need that in a runtime context ?
- dgb23 5y ago
  Maybe to build custom proxies with the same API.
  - postalrat 5y ago
    Proxy or server

edgyquant 5y ago

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.

lucacasonato 5y ago
Try `--no-check` when using `--watch` and you already get type errors from your IDE. Should speed up hot reload and hot restarts significantly :-)

91edec 5y ago

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. Does anyone else have a better solution shared Typescript code?

AbuAssar 5y ago
Related: https://github.com/microsoft/TypeScript/issues/42813 https://github.com/microsoft/TypeScript/issues/42813
piaste 5y ago
> 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. Still a hack, but perhaps symlinks could be a little simpler?
makapuf 5y ago
Yes had the same issue. Had to make deno run js files and import js produced by ts.
stickyricky 5y ago
Whats the purpose of sharing types? Define entities on each and leave behavior as a domain consideration. Clients should be disposable and decoupled. If you want to render html on the server that's fine but svelte isn't the best choice for that.
- afavour 5y ago
  > Whats the purpose of sharing types? Server sends data as JSON to the client. Client parses JSON. Both now have the exact same data shape. Shared TS types let you use the same representation for the same data no matter where.
  - stickyricky 5y ago
    At the expense of coupling which is not a trivial concern. Regardless, the browser is the only platform capable of using those types (even so the types aren't shared but generated). You don't use those types in Swift or Java or Kotlin. You don't use those types in a python client library.
    - danielvaughn 5y ago

nozzlegear 5y ago

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. 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.

91edec 5y ago
If you're using coc you can add the coc-deno extension and initialize the project with `CocCommand deno.initializeWorkspace`.
- nozzlegear 5y ago
  Thanks! I didn't know about the coc extension, I'll give that a try.
  - choward 5y ago
    I have to believe that you leaving the "-deno" off of "coc-deno extension" was intentional which I find to be pretty funny.
- phil294 5y ago
  Neovim apparently supports the LSP protocol natively, so could you please explain why CoC is necessary?
  - chana_masala 5y ago
    From the last I saw, coc is still more feature rich than native LSP in Neovim.
brundolf 5y ago
It does suck that it can’t use standard typescript tooling because of a couple of small, key, breaking-differences (mainly the import path style, to my understanding). I don’t think they could have done it any differently, and with enough traction the ecosystem support is a solvable problem, but it’s still a shame.

Escapado 5y ago

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).

egeozcan 5y ago
In my experience, enterprise Java crowd never spills its managed beans. In my whole career, I couldn't even get any of them admit that JSF may not be the best front end technology in the world. It's a lost cause.
- rukshn 5y ago
  I have to second this. I worked on a java app which was painful to scale, due to JSF and JPA. I have distanced myself from the project as much as I can. Now, I see another new app for a different purpose being started and I hoped to push for a modern way of building it, but no they just won't give-up using java and JSF. Nothing wrong with java, it's just java and jsf crowd is hard to be converted to something else.

tfsh 5y ago

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.

tills13 5y ago
I am very interesting in the performance implications here as their _has_ to be some performance tradeoffs given you have to serialize / deserialize across the bindings. I get that Rust is fast, but at what point does the trade-off no longer make sense?
searchableguy 5y ago
https://deno.land/benchmarks https://deno.land/benchmarks is what you are looking for.
AaronO 5y ago
On many of our internal benchmarks, Deno's std/http server outperforms Node's http (so express/koa too). There's still some room for improvement on our end and we would like to put together rigorous benchmarks before sharing that broadly.

Epskampie 5y ago

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. 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.

nllsh 5y ago
If you are concerned about security in one of your imported dependencies (or in user code) you can run that code in a sandboxed worker (See: https://deno.land/manual@v1.18.0/runtime/workers#specifying-worker-permissions https://deno.land/manual@v1.18.0/runtime/workers#specifying-...). Beyond this it is still very useful to limit your runtime for software to only access specific directories, network addresses, etc. So the sandbox/security is definitely not useless.
brundolf 5y ago
Running TypeScript directly is a great part, but there’s a bigger, little-discussed aspect: Deno has a built-in, prescribed, standardized, - Testing framework - Linter - Bundler - Formatter It’s like having Cargo or Go’s CLI for JavaScript/TypeScript. It eliminates so much fiddling and breakage, gets everyone in the ecosystem on the same page, etc. Even for a solo project it’s been a dream to use, compared with the hodgepodge of a Node project.
sondr3 5y ago
At least for me one of my favorite things is how integrated it is, after having used Rust for a while, having the compiler, linter, lightweight testing and formatting all in one bundle is an amazing time saver and a major boon for me. No more fiddling with ever growing configurations for ESLint, or having to install Jest/Ava/uvu/tap for testing and their ESLint rules and then Prettier which may also require ESLint... I realize not everyone cares enough to configure it, but the approach of Deno (and Rust, and Go, and so on) is such a weight of my shoulders when starting a project. Just open Neovim, create a TypeScript file, write some tests, all without having to do any kind of configuration or installation of packages.
5y ago

andrewstuart 5y ago

If you'd like the Amazon JavaScript SDK to support Deno then make your support known on this thread: https://github.com/aws/aws-sdk-js-v3/issues/1289 https://github.com/aws/aws-sdk-js-v3/issues/1289

jbirer 5y ago

Deno came too late, there is Go and Rust now

esjeon 5y ago
Yeah, that's kinda sorry state of Deno right now. We have more than pure JS/TS ecosystem that NPM used to thrive on. The backend market is already leaned toward Go. It's the best language for microservices. We also have WASM entering the scene on the frontend side, which allows mixing other languages, especially Rust. Hell, I heard some people ported a whole C++-based UI engine to make it cross-platform. We're already entering the next generation.

u-rate 5y ago

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.

userSumo 5y ago

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.

deleted 5y ago

[deleted]

brundolf 5y ago

I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel https://github.com/brundonsmith/bagel). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here. 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). 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): - 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. - 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. - It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs. - 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. 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.

ravenstine 5y ago
Yeah, I've seen worst API documentation, but their docs site is needlessly weird. Documentation is something that should be solved by now. No project needs whatever custom thing Deno uses. I don't get it. Leaving out details, for the most part, is the right approach for now, I think. Only Node/JavaScript veterans should probably be using Deno for the time being. But I definitely hope Deno can eventually take over and make Node obsolete. > 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) At this point, I've kind of given up on VS Code language/runtime extensions in general. Virtually none of them work with the slightest variation in toolchain configuration, whether it's C++ or Typescript or even ESLint. You're lucky if they don't slow the heck down over time. Import paths are the worst! Somehow that's something I inevitably run into, again, no matter the language. I kinda want to blow all this stuff up and start over. Maybe Deno is a part of that equation. haha

kentor 5y ago

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.

ipnon 5y ago
Deno seems ideal for the now common use case of serverless JavaScript, erm, servers. It's hard to imagine the project superseding the prior art in other domains, however. Deno is a little too weird.

simonw 5y ago

The FFI interface looks very neatly designed. Here's how the SQLite module is implemented using it: https://deno.land/x/sqlite3@0.3.0/src/ffi.ts https://deno.land/x/sqlite3@0.3.0/src/ffi.ts

DrFell 5y ago

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.

chana_masala 5y ago

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. [1] https://github.com/ljharb https://github.com/ljharb

atonse 5y ago

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.

justshowpost 5y ago

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. 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! 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.