12 ms·

Deno 1.10 Release Notes

274 points by caspervonb 5y ago

8K832d7tNmiQ 5y ago
I'm still waiting for abortable fetch feature, since I have to deal with some services that have unstable network connection and often got stuck and never drop their connection. Is there any progress over this one? Last time I heard, they still have to wait till rusty_v8 got matured enough for this feature to be available.
- lucacasonato 5y ago
  We are still working on it, it just requires some work deep inside of Deno internals.
- e12e 5y ago
  Oh, what happens now - resources not collected until next deno restart? Or just a non-adjustable timeout?
CraigJPerry 5y ago
I didn’t know what deno was. It’s a typescript native alternative to nodejs that adopts the browser security model, replicates the golang standard library rather than node’s and is written in Rust.
- adamsvystun 5y ago
  Not only adopts the browser security model, but more broadly adopts browser APIs.
- otabdeveloper4 5y ago
  V8 is written in C++, not Rust.
  - thegeekpirate 5y ago
    They're talking about deno, which _is_ written in Rust. https://github.com/denoland/deno https://github.com/denoland/deno
    - Manozco 5y ago
      Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. So it's probably a rust wrapper around a C++ project (unless they reimplement V8 in rust... )
      - kigiri 5y ago
        Yeah the communication with V8 and all the API are in rust, V8 is still in c++
      - vesche 5y ago
        Yup, it uses rusty_v8 which are Rust bindings for V8's C++ API - https://github.com/denoland/rusty_v8 https://github.com/denoland/rusty_v8
  - CraigJPerry 5y ago
    Sure, although the rust v8 bindings don’t appear to support FreeBSD as i just found out when i tried to install deno on FreeBSD 13: > cargo install --locked deno Compiling rusty_v8 v0.22.2 error[E0308]: mismatched types --> /home/craig/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.22.2/build.rs:157:18 | 157 | fn platform() -> &'static str { | -------- ^^^^^^^^^^^^ expected `&str`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. error: could not compile `rusty_v8` To learn more, run the command again with --verbose. warning: build failed, waiting for other jobs to finish... error: failed to compile `deno v1.10.1`, intermediate artifacts can be found at `/tmp/cargo-installwrTFWi` Caused by: build failed
    - josephg 5y ago
      That looks like a pretty simple problem. Deno probably doesn’t work on FreeBSD simply because nobody has done the work of making it compatible yet. Rust, V8 and nodejs all run great on FreeBSD. If you care about FreeBSD support, I bet the community would be delighted to receive some pull requests patching the problem.
      - CraigJPerry 5y ago
        I gave it a whirl: > git clone https://github.com/denoland/deno.git denoland/deno > git clone https://github.com/denoland/rusty_v8.git denoland/rusty_v8 > cd denoland/deno > vi Cargo.toml ... [patch.crates-io] rusty_v8 = { path = "../rusty_v8" } ... > cargo build --release ... as expected same failure - good ... Make rusty_v8 build.rs aware of freebsd > vi ../rusty_v8/build.rs ... #[cfg(target_os = "freebsd")] { "freebsd" } ... Have a quick squizz to see where this is used: > rg "platform\(\)" ../rusty_v8 build.rs 157:fn platform() -> &'static str { 180: .join(platform()); Attempt to fix... and bang! It's using the platform() result to call a python script that pulls binaries from here: https://github.com/denoland/ninja_gn_binaries/ https://github.com/denoland/ninja_gn_binaries/ And there's no FreeBSD build there. To much yak shaving for idle curiosity on my part.
  - Cthulhu_ 5y ago
    I'm pretty confident we'll see a JS engine written in Rust at some point in the future, it'll just take a very long time to get parity with V8 and will likely introduce its own slew of issues.
    - dajonker 5y ago
      Parts of the Firefox JS engine (SpiderMonkey) are written in Rust (although nothing really significant I believe).
    - e12e 5y ago
      I rather imagine we'll see a wasm vm/runtime in rust, and a typescript/js to wasm compiler written in typescript...
      - nindalf 5y ago
        > I rather imagine we'll see a wasm vm/runtime in rust Like Wasmtime? https://github.com/bytecodealliance/wasmtime https://github.com/bytecodealliance/wasmtime
        e12e 5y ago
        Yes, but we would also need an event loop I guess. As I understand it nodejs is essentially a (c++) js runtime inside a c++ event loop. But I think we already have a rust event loop (or two?)
    - littlecranky67 5y ago
      I don't see any benefits (for me, the user) if its written in Rust. Yes, Rust has nice features for more security+stability for the developer, but just because a JS Engine would be written in Rust wouldn't mean its automatically better than V8. It's not the programming language that gives the edge in this case, it is the amount of time, sweat and grease that went into V8. And other engines would have a long way to come.
    - jmull 5y ago
      I don't know about a JS engine written in Rust. Well, I'm sure it will be attempted (no doubt it's being done right now), but I don't see a path to success. Like you say, it would take a long time for a Rust JS engine to reach parity with V8. But long-running projects need real use-cases to succeed... they drive support and provide direction/feedback. How much will a half-baked Rust JS engine be adopted when a mature, stable V8 or SM is available? Will the projects that do so be successful themselves? A pure Rust JS engine might be destined to peter-out well before becoming viable. A better approach (though less satisfying) might be to convert an existing engine incrementally. But even there, there probably needs to be continuous, compelling benefits along the way to justify the increased complexity and large amount of additional work. Imagine release after release where the main item in the release notes is "rewrote another subsystem in Rust"... followed by a bunch of bugs in the previously stable subsystem. I know SM has some Rust bits, but I'm not sure how far that is really going to go.
echopom 5y ago
Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of having 1000+ dependency from NPM you'll have 1000+ dependency from remote URL with everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process... The way Ryan managed Node and how the ecosystem as turned to chaos because of is lack of vision and strategy make me not want to try any of it's tech again. Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly. I don't think that's how you manage a language , when I look at Zig I'm way more confident of what's being done that the current state of Deno... Node.JS is one of my main language , but the ecosystem around it is an absolute disaster.
- kigiri 5y ago
  But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem
  - rapsey 5y ago
    Just because they are attempting to address it does not mean they will succeed.
    - HatchedLake721 5y ago
      So what? Should we all give up now and stop doing whatever we're doing now, just because we might not succeed? That's how people learn, advance and improve the world around us - through failure and mistakes.
    - valtism 5y ago
      Yes but let’s not get that cynical about it. People are working hard on these problems.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
okhuman 5y ago
Here's our token-based (JWT) user management server using Deno - if you want to see an example. https://github.com/pmprosociety/authcompanion https://github.com/pmprosociety/authcompanion
davnicwil 5y ago
The addition of sandboxed storage (i.e. access to localStorage and sessionStorage APIs without requiring disk permission) is really interesting. It seems very in line with the model of deno as an edge compute runtime - esentially ephemeral cache on the edge - I wonder what usecases will emerge for this?
intellix 5y ago
How is the built in testing? I'm a bit wary because Jest is so good and wonder if it can compete on every front it's baking in. It reminds me of Angular coming with it's own Router, Forms, Animations and then since they're provided officially, alternatives don't get created and then the half of the team leaves and the packages are abandoned.
- azangru 5y ago
  > How is the built in testing? Much more minimalist than Jest. Very similar to Node's built-in testing [0]. - I don't believe the test environment is recreated between test files - No way to mock imported modules, as far as I understand. I don't believe the built-in testing has any mocking or spying functionality at all - No describe/it/expect syntax that Jest inherited from Jasmine (I am not sure where it came from initially — was it from RSpec?) - The above means that there is no nesting of test blocks - No setup or teardown functions (beforeAll, beforeEach, afterAll or afterEach) On the other hand, it's fast. And it doesn't swallow up console logs, like Jest can do. No magic to it at all. [0] - https://nodejs.org/dist/latest-v14.x/docs/api/assert.html https://nodejs.org/dist/latest-v14.x/docs/api/assert.html
  - KyleJune 5y ago
    There are third party modules for providing many of those things. I created 2 modules for testing. This module has describe/it functions with setup/teardown hooks. It supports nesting test blocks. I think the built in assertion functions are quite good so I didn't bother creating an expect function although there are other third party modules that provide that functionality. https://deno.land/x/test_suite https://deno.land/x/test_suite I had difficulty getting sinon to work earlier on so I wrote a similar module in TypeScript for creating spys, stubs, and faking time. https://deno.land/x/mock https://deno.land/x/mock
- andrew_ 5y ago
  I know a fella working on a Deno port of Ava (https://github.com/avajs/ava https://github.com/avajs/ava). When that and Koa are ported or compatible, I'll be giving Deno a legitimate go.
the_duke 5y ago
I was interested in Deno from the start. It has a few very nice features. Notably the sandboxing model, native Typescript support and browser based API surface. But I also was quite skeptical of their dependency model with plain url imports. With the current implementation you end up with a half-baked import map that's essentially a poor mans package.json, but without any of the tooling that you'd expect. (like npm upgrade, npm outdated) It recently dawned on me what they are going for: a "cloud native" computing platform that doesn't require builds and packaging. Targeting both Javascript and WASM. I do believe there is quite a lot of promise in the project. The tooling can improve. It'll be interesting how things evolve.
- Soremwar 5y ago
  IMO this is a terrible idea. If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long run. I can't stress how many times I had to review and undo automated dependency bumps because my app suddenly stopped working, and the times I was forced to I had to bump said dependencies in the lock file myself In a compiled language, where code is compiled once and valid there 'til the end of times this is not even a problem. In an interpreted language where all code is evaluated every time you run your program, this makes automated dependency management an impossible task
redleader55 5y ago
I like the ideas behind Deno, but I'm wondering if testing should be so included in the standard library, unless it is extremely flexible. Each team will have different problems when it comes to scaling, running tests in parallel - sometimes on the same machine, sometimes on multiple machines, e2e tests vs unit-tests, etc. This looks like a problem you solve in a library, not something to add in the core.
- uhhhhhhhhhhhhhh 5y ago
  Legit concern but it's also possible they evolve a great general solution where everyone looks back and says "oh yeah that's what that api ought to be like"
- Soremwar 5y ago
  There have been multiple test runners built on top of Deno's vanilla testing (through the JSON output feature), those may fit your use case better The current multi threaded and module isolated model however I think it's good for the great majority of projects, so I'm glad it's built in
sanxiyn 5y ago
It's Deno 1.10, not Deno 1.1.
- dang 5y ago
  Fixed now! Our mistake.
caspervonb 5y ago
Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.
- tarruda 5y ago
  It seems the person responsible for this edit mistook Deno's version with a decimal number.
- whalesalad 5y ago
  Isn’t that the normal behavior of JavaScript numbers? Just do your own thing sometimes? Heh.
  - osrec 5y ago
    While it may be, in this case, we're dealing with strings.
  - andrew_ 5y ago
    It's become somewhat the norm that JavaScript projects have adopted semver (https://semver.org/ https://semver.org/) for releases.
- Macha 5y ago
  For context, this 11-month old github release <https://github.com/denoland/deno/releases/tag/v1.1.0 https://github.com/denoland/deno/releases/tag/v1.1.0> is the Deno 1.1 release notes, not the linked post here which is for the 1.10 release notes.
- dang 5y ago
  Fixed now. Sorry!
domano 5y ago
SemVer != Decimal
Graffur 5y ago
Has Deno failed to get adoption? I haven't seen it used anywhere to be honest.
- yepthatsreality 5y ago
  ...it’s only been around ~3 years.
  - Soremwar 5y ago
    Wrong, 1.0 released exactly one year ago, before there was mostly destabilization of the runtime and not really development features
    - yepthatsreality 5y ago
      Okay great. It was announced 3 years ago. Regardless of which version (pre/post 1.0), there really hasn’t been enough time for Deno to take hold. My point stands.
sam_goody 5y ago
Node is amazing, but it was Electron that really made Node something that every school kid had to learn. As long as Electron has no plans to support Deno, it will be WAY behind in traction. /useless prediction
- Soremwar 5y ago
  We may have WebGPU powered desktop applications in the near future though. Let's see how things play out, as you daid
  - paxys 5y ago
    Canvas is already a thing, but ultimately the biggest advantage of HTML-based UI is the layout engine. People want to throw together some <div>s and a stylesheet and call it a day.
ledgerdev 5y ago
What's the status of grpc both as client and server? I seem to recall reading somewhere that some features(trailing headers?) needed to call grpc as client were out of the fetch spec and thus would to be implemented. It's also not clear from this issue either. https://github.com/denoland/deno/issues/3326 https://github.com/denoland/deno/issues/3326
kumarvvr 5y ago
Somehow, Deno doesn't excite me. I love to explore new stuff in programming. Have done with Python, Java, JS (Node), React, Angular, Vue, etc. Deno just doesn't cut it.
DrFell 5y ago
As an old webdev who was full-stack before Node even came out, and avoided it completely, all I can say is; Have fun, kids! jingle jingle
jimmont 5y ago
Great to see Deno going from good to better and better steadily over the past year. It is such a pleasure when compared with Nodejs projects. Always appreciate products that make life easier.
paxys 5y ago
I have been following the progress of Deno for a little bit, and slowly but surely the project is evolving from a full-scale Node.js replacement to a serverless/edge compute platform. I get that it's the hot thing in tech these days, but to me that just isn't very appealing.
ralusek 5y ago
Demo is awesome but ironically I haven't been able to use it because I always want something from npm
- ecmascript 5y ago
  You can probably use the package using https://www.skypack.dev/ https://www.skypack.dev/

274 points by caspervonb 5y ago

I'm still waiting for abortable fetch feature, since I have to deal with some services that have unstable network connection and often got stuck and never drop their connection. Is there any progress over this one? Last time I heard, they still have to wait till rusty_v8 got matured enough for this feature to be available.

lucacasonato 5y ago
We are still working on it, it just requires some work deep inside of Deno internals.
e12e 5y ago
Oh, what happens now - resources not collected until next deno restart? Or just a non-adjustable timeout?

CraigJPerry 5y ago

I didn’t know what deno was. It’s a typescript native alternative to nodejs that adopts the browser security model, replicates the golang standard library rather than node’s and is written in Rust.

adamsvystun 5y ago
Not only adopts the browser security model, but more broadly adopts browser APIs.
otabdeveloper4 5y ago
V8 is written in C++, not Rust.
- thegeekpirate 5y ago
  They're talking about deno, which _is_ written in Rust. https://github.com/denoland/deno https://github.com/denoland/deno
  - Manozco 5y ago
    Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. So it's probably a rust wrapper around a C++ project (unless they reimplement V8 in rust... )
    - kigiri 5y ago
      Yeah the communication with V8 and all the API are in rust, V8 is still in c++
    - vesche 5y ago
      Yup, it uses rusty_v8 which are Rust bindings for V8's C++ API - https://github.com/denoland/rusty_v8 https://github.com/denoland/rusty_v8
- CraigJPerry 5y ago
  Sure, although the rust v8 bindings don’t appear to support FreeBSD as i just found out when i tried to install deno on FreeBSD 13: > cargo install --locked deno Compiling rusty_v8 v0.22.2 error[E0308]: mismatched types --> /home/craig/.cargo/registry/src/github.com-1ecc6299db9ec823/rusty_v8-0.22.2/build.rs:157:18 | 157 | fn platform() -> &'static str { | -------- ^^^^^^^^^^^^ expected `&str`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. error: could not compile `rusty_v8` To learn more, run the command again with --verbose. warning: build failed, waiting for other jobs to finish... error: failed to compile `deno v1.10.1`, intermediate artifacts can be found at `/tmp/cargo-installwrTFWi` Caused by: build failed
  - josephg 5y ago
    That looks like a pretty simple problem. Deno probably doesn’t work on FreeBSD simply because nobody has done the work of making it compatible yet. Rust, V8 and nodejs all run great on FreeBSD. If you care about FreeBSD support, I bet the community would be delighted to receive some pull requests patching the problem.
    - CraigJPerry 5y ago
      I gave it a whirl: > git clone https://github.com/denoland/deno.git denoland/deno > git clone https://github.com/denoland/rusty_v8.git denoland/rusty_v8 > cd denoland/deno > vi Cargo.toml ... [patch.crates-io] rusty_v8 = { path = "../rusty_v8" } ... > cargo build --release ... as expected same failure - good ... Make rusty_v8 build.rs aware of freebsd > vi ../rusty_v8/build.rs ... #[cfg(target_os = "freebsd")] { "freebsd" } ... Have a quick squizz to see where this is used: > rg "platform\(\)" ../rusty_v8 build.rs 157:fn platform() -> &'static str { 180: .join(platform()); Attempt to fix... and bang! It's using the platform() result to call a python script that pulls binaries from here: https://github.com/denoland/ninja_gn_binaries/ https://github.com/denoland/ninja_gn_binaries/ And there's no FreeBSD build there. To much yak shaving for idle curiosity on my part.
- Cthulhu_ 5y ago
  I'm pretty confident we'll see a JS engine written in Rust at some point in the future, it'll just take a very long time to get parity with V8 and will likely introduce its own slew of issues.
  - dajonker 5y ago
    Parts of the Firefox JS engine (SpiderMonkey) are written in Rust (although nothing really significant I believe).
  - e12e 5y ago
    I rather imagine we'll see a wasm vm/runtime in rust, and a typescript/js to wasm compiler written in typescript...
    - nindalf 5y ago
      > I rather imagine we'll see a wasm vm/runtime in rust Like Wasmtime? https://github.com/bytecodealliance/wasmtime https://github.com/bytecodealliance/wasmtime
      - e12e 5y ago
        Yes, but we would also need an event loop I guess. As I understand it nodejs is essentially a (c++) js runtime inside a c++ event loop. But I think we already have a rust event loop (or two?)
  - littlecranky67 5y ago
    I don't see any benefits (for me, the user) if its written in Rust. Yes, Rust has nice features for more security+stability for the developer, but just because a JS Engine would be written in Rust wouldn't mean its automatically better than V8. It's not the programming language that gives the edge in this case, it is the amount of time, sweat and grease that went into V8. And other engines would have a long way to come.
  - jmull 5y ago
    I don't know about a JS engine written in Rust. Well, I'm sure it will be attempted (no doubt it's being done right now), but I don't see a path to success. Like you say, it would take a long time for a Rust JS engine to reach parity with V8. But long-running projects need real use-cases to succeed... they drive support and provide direction/feedback. How much will a half-baked Rust JS engine be adopted when a mature, stable V8 or SM is available? Will the projects that do so be successful themselves? A pure Rust JS engine might be destined to peter-out well before becoming viable. A better approach (though less satisfying) might be to convert an existing engine incrementally. But even there, there probably needs to be continuous, compelling benefits along the way to justify the increased complexity and large amount of additional work. Imagine release after release where the main item in the release notes is "rewrote another subsystem in Rust"... followed by a bunch of bugs in the previously stable subsystem. I know SM has some Rust bits, but I'm not sure how far that is really going to go.

echopom 5y ago

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of having 1000+ dependency from NPM you'll have 1000+ dependency from remote URL with everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process... The way Ryan managed Node and how the ecosystem as turned to chaos because of is lack of vision and strategy make me not want to try any of it's tech again. Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly. I don't think that's how you manage a language , when I look at Zig I'm way more confident of what's being done that the current state of Deno... Node.JS is one of my main language , but the ecosystem around it is an absolute disaster.

kigiri 5y ago
But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem
- rapsey 5y ago
  Just because they are attempting to address it does not mean they will succeed.
  - HatchedLake721 5y ago
    So what? Should we all give up now and stop doing whatever we're doing now, just because we might not succeed? That's how people learn, advance and improve the world around us - through failure and mistakes.
  - valtism 5y ago
    Yes but let’s not get that cynical about it. People are working hard on these problems.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

okhuman 5y ago

Here's our token-based (JWT) user management server using Deno - if you want to see an example. https://github.com/pmprosociety/authcompanion https://github.com/pmprosociety/authcompanion

davnicwil 5y ago

The addition of sandboxed storage (i.e. access to localStorage and sessionStorage APIs without requiring disk permission) is really interesting. It seems very in line with the model of deno as an edge compute runtime - esentially ephemeral cache on the edge - I wonder what usecases will emerge for this?

intellix 5y ago

How is the built in testing? I'm a bit wary because Jest is so good and wonder if it can compete on every front it's baking in. It reminds me of Angular coming with it's own Router, Forms, Animations and then since they're provided officially, alternatives don't get created and then the half of the team leaves and the packages are abandoned.

azangru 5y ago
> How is the built in testing? Much more minimalist than Jest. Very similar to Node's built-in testing [0]. - I don't believe the test environment is recreated between test files - No way to mock imported modules, as far as I understand. I don't believe the built-in testing has any mocking or spying functionality at all - No describe/it/expect syntax that Jest inherited from Jasmine (I am not sure where it came from initially — was it from RSpec?) - The above means that there is no nesting of test blocks - No setup or teardown functions (beforeAll, beforeEach, afterAll or afterEach) On the other hand, it's fast. And it doesn't swallow up console logs, like Jest can do. No magic to it at all. [0] - https://nodejs.org/dist/latest-v14.x/docs/api/assert.html https://nodejs.org/dist/latest-v14.x/docs/api/assert.html
- KyleJune 5y ago
  There are third party modules for providing many of those things. I created 2 modules for testing. This module has describe/it functions with setup/teardown hooks. It supports nesting test blocks. I think the built in assertion functions are quite good so I didn't bother creating an expect function although there are other third party modules that provide that functionality. https://deno.land/x/test_suite https://deno.land/x/test_suite I had difficulty getting sinon to work earlier on so I wrote a similar module in TypeScript for creating spys, stubs, and faking time. https://deno.land/x/mock https://deno.land/x/mock
andrew_ 5y ago
I know a fella working on a Deno port of Ava (https://github.com/avajs/ava https://github.com/avajs/ava). When that and Koa are ported or compatible, I'll be giving Deno a legitimate go.

the_duke 5y ago

I was interested in Deno from the start. It has a few very nice features. Notably the sandboxing model, native Typescript support and browser based API surface. But I also was quite skeptical of their dependency model with plain url imports. With the current implementation you end up with a half-baked import map that's essentially a poor mans package.json, but without any of the tooling that you'd expect. (like npm upgrade, npm outdated) It recently dawned on me what they are going for: a "cloud native" computing platform that doesn't require builds and packaging. Targeting both Javascript and WASM. I do believe there is quite a lot of promise in the project. The tooling can improve. It'll be interesting how things evolve.

Soremwar 5y ago
IMO this is a terrible idea. If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long run. I can't stress how many times I had to review and undo automated dependency bumps because my app suddenly stopped working, and the times I was forced to I had to bump said dependencies in the lock file myself In a compiled language, where code is compiled once and valid there 'til the end of times this is not even a problem. In an interpreted language where all code is evaluated every time you run your program, this makes automated dependency management an impossible task

redleader55 5y ago

I like the ideas behind Deno, but I'm wondering if testing should be so included in the standard library, unless it is extremely flexible. Each team will have different problems when it comes to scaling, running tests in parallel - sometimes on the same machine, sometimes on multiple machines, e2e tests vs unit-tests, etc. This looks like a problem you solve in a library, not something to add in the core.

uhhhhhhhhhhhhhh 5y ago
Legit concern but it's also possible they evolve a great general solution where everyone looks back and says "oh yeah that's what that api ought to be like"
Soremwar 5y ago
There have been multiple test runners built on top of Deno's vanilla testing (through the JSON output feature), those may fit your use case better The current multi threaded and module isolated model however I think it's good for the great majority of projects, so I'm glad it's built in

sanxiyn 5y ago

It's Deno 1.10, not Deno 1.1.

dang 5y ago
Fixed now! Our mistake.

caspervonb 5y ago

Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.

tarruda 5y ago
It seems the person responsible for this edit mistook Deno's version with a decimal number.
whalesalad 5y ago
Isn’t that the normal behavior of JavaScript numbers? Just do your own thing sometimes? Heh.
- osrec 5y ago
  While it may be, in this case, we're dealing with strings.
- andrew_ 5y ago
  It's become somewhat the norm that JavaScript projects have adopted semver (https://semver.org/ https://semver.org/) for releases.
Macha 5y ago
For context, this 11-month old github release <https://github.com/denoland/deno/releases/tag/v1.1.0 https://github.com/denoland/deno/releases/tag/v1.1.0> is the Deno 1.1 release notes, not the linked post here which is for the 1.10 release notes.
dang 5y ago
Fixed now. Sorry!

domano 5y ago

SemVer != Decimal

Graffur 5y ago

Has Deno failed to get adoption? I haven't seen it used anywhere to be honest.

yepthatsreality 5y ago
...it’s only been around ~3 years.
- Soremwar 5y ago
  Wrong, 1.0 released exactly one year ago, before there was mostly destabilization of the runtime and not really development features
  - yepthatsreality 5y ago
    Okay great. It was announced 3 years ago. Regardless of which version (pre/post 1.0), there really hasn’t been enough time for Deno to take hold. My point stands.

sam_goody 5y ago

Node is amazing, but it was Electron that really made Node something that every school kid had to learn. As long as Electron has no plans to support Deno, it will be WAY behind in traction. /useless prediction

Soremwar 5y ago
We may have WebGPU powered desktop applications in the near future though. Let's see how things play out, as you daid
- paxys 5y ago
  Canvas is already a thing, but ultimately the biggest advantage of HTML-based UI is the layout engine. People want to throw together some <div>s and a stylesheet and call it a day.

ledgerdev 5y ago

What's the status of grpc both as client and server? I seem to recall reading somewhere that some features(trailing headers?) needed to call grpc as client were out of the fetch spec and thus would to be implemented. It's also not clear from this issue either. https://github.com/denoland/deno/issues/3326 https://github.com/denoland/deno/issues/3326

kumarvvr 5y ago

Somehow, Deno doesn't excite me. I love to explore new stuff in programming. Have done with Python, Java, JS (Node), React, Angular, Vue, etc. Deno just doesn't cut it.

DrFell 5y ago

As an old webdev who was full-stack before Node even came out, and avoided it completely, all I can say is; Have fun, kids! jingle jingle

jimmont 5y ago

Great to see Deno going from good to better and better steadily over the past year. It is such a pleasure when compared with Nodejs projects. Always appreciate products that make life easier.

paxys 5y ago

I have been following the progress of Deno for a little bit, and slowly but surely the project is evolving from a full-scale Node.js replacement to a serverless/edge compute platform. I get that it's the hot thing in tech these days, but to me that just isn't very appealing.

ralusek 5y ago

Demo is awesome but ironically I haven't been able to use it because I always want something from npm

ecmascript 5y ago
You can probably use the package using https://www.skypack.dev/ https://www.skypack.dev/