13 ms·

State of the Web: Deno

147 points by markhaslam 5y ago

eyelidlessness 5y ago
> V8 is a sandboxed language False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime. > that makes it impossible False, breaking out of the sandbox is trivial in environments which allow native addons.
- cookiengineer 5y ago
  Technically correct. Also related: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... Most Browser exploits these days use Heap Spraying attacks that try to corrupt the state of the sandbox in between bindings and native libraries (or their data structures that are transferred between contexts). So technically, a JIT VM always leads to possibilities for breakouts when there is a discrepancy between the optimizer and deoptimizer's assumptions (e.g. in regards to callstack, garbage, memory ownership etc). Also: There's a legacy navigator.plugins C-Bridge based API which hasn't been maintained or redesigned/refactored since the late 90s yet it is still active in most Browsers.
- nexuist 5y ago
  I am very interested in this. Are there existing exploits for deno? Using a stock out of the box configuration, can you execute some code that breaks its permission model? Has deno undergone some kind of security audit to verify its claims irt security? EDIT: I see some referenced issues in comments down below involving the --allow-read/write flag. I'm not interested in that. I'm interested in if anyone can prove that with no permissions granted at all, they can break out of the sandbox and achieve ACE.
  - eyelidlessness 5y ago
    I think you’d need to either grant permissions (eg allow-ffi) or find a privilege escalation bug in V8 or Deno’s Rust bindings. The latter is less likely for sure. But being realistic, most people using Deno are granting some privileges, because most use cases at minimum do some I/O. I’m academically interested if there are other such exploits, too. But I’d expect if they’re found they’ll be patched before they’re disclosed (or they’ll be exploited in the wild).
deleted 5y ago
[deleted]
Kiro 5y ago
I prefer CommonJS. It's so simple. You assign the dependency to a variable and that's it. I still need to look up the syntax every time I use ESM.
- afiori 5y ago
  it is simple to write, it is not simple at all how strings are converted into paths. honestly tough, esm is more complex than it should (especially regarding how live exports happen)
- tehbeard 5y ago
  > You assign the dependency to a variable and that's it erm, how is that any simpler than `export const/function/class $defintion` ? I guess if you only touch JS once in a blue moon it's difficult to remember? Also CommonJS has some acknowledged issues around cyclic dependencies, and being incredibly fudgeable at runtime that makes static analysis and linting a pain.
galaxyLogic 5y ago
Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly? I find sync is often simpler to code for.
- eyelidlessness 5y ago
  Because the ESM standard specifies that modules are loaded by URL and themselves might initialize async. Once anything is async the whole call stack into it is. See also various discussions of “colored functions” which have made the rounds again recently.
  - wruza 5y ago
    Why doesn't nodejs just make modules async? // main.js const fs = require("fs") const foo = await require_async("foo") await foo.sleep(1000) // other.js require("./main.js") // RequireError: main.js returned an unsettled promise, use require_async() Wouldn't that be better of both worlds?
    - eyelidlessness 5y ago
      Node did make modules async (just ESM modules). They can’t/won’t make CJS async because their synchronous semantics are a guarantee they determined not to break well before ESM. If you want async modules, ESM is the solution for that.
      - wruza 5y ago
        ESM will be the solution to that, when all the major toolchains catch up. I wouldn't sell this future short, but we aren't there yet either.
        eyelidlessness 5y ago
        I agree but I think we’re there (if kicking a bit and screaming a bit).
  - 5y ago
dmitriid 5y ago
Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"
- afiori 5y ago
  there is not really a difference between a url to a registry and a npm package name. the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it
  - greggman3 5y ago
    There is one difference. I know npm keeps published versions. I don't know that random URL keeps versions. Caching locally doesn't help. I expect my code to work for others. Of course using any source is nice. node also allows this, just put a git URL as your dependency.
    - afiori 5y ago
      URLs to a registry keep published versions if the registry keeps published versions. Your argument is that npm is more trustworthy than another random registry, this is likely true but also a matter of opinion.
      - dmitriid 5y ago
        > URLs to a registry keep published versions if the registry keeps published versions. Yes. Have you've ever heard of running your own registry? It' quite easy to do and most companies do it prcisely because they want to a) keep published versions and b) prevent things like colors/fake.js Literally no one who promotes Deno has yet shown how to do the same with Deno beyond "yeah, you check in all your node_modules dependencies into Git".
  - dmitriid 5y ago
    > there is not really a difference between a url to a registry and a npm package name. There is. For starters, I can run my company's registry and make sure all npm packages are downloaded from there since resolution mechanism for npm/yarn is well known. How do I tell deno to download <random-url> from my own registry? Looking at how deno "solves" this I can't stop laughing [1] --- start quote --- In Deno there is no concept of a package manager as external modules are imported directly into local modules. This raises the question of how to manage remote dependencies without a package manager. In big projects with many dependencies it will become cumbersome and time consuming to update modules if they are all imported individually into individual modules. The standard practice for solving this problem in Deno is to create a deps.ts file. All required remote dependencies are referenced in this file and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies... With all dependencies centralized in deps.ts, managing these becomes easier. --- end quote --- Are you for real? [1] https://deno.land/manual/examples/manage_dependencies https://deno.land/manual/examples/manage_dependencies
bartkappenburg 5y ago
Offtopic but this webpage disables my bottom navigation bar on mobile safari, their own navigation on top re-enables this. Has anyone else experienced this?
- dmitriid 5y ago
  I experienced the same issue
pjmlp 5y ago
Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.
- tmikaeld 5y ago
  I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.
  - pjmlp 5y ago
    My relevant stars are what IT decides to install on devenvs or is part of RFPs technical requirements.
  - Griffinsauce 5y ago
    > smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. This isn't necessarily enforced by Deno itself right? That seems like more of a side-effect from the self-selection of its users. Once the ecosystem grows and the all the "normies" come in, this doesn't seem guaranteed at all.
    - tmikaeld 5y ago
      Right, like I wrote, it's up to each developer, but i really do hope the trend continues.
  - forty 5y ago
    My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.
u-rate 5y ago
Love Deno. So much much more intuitive and simple than Node. I highly recommend you giving it a try, if you used Node before, Deno will be a super easy to learn tool.
- numlock86 5y ago
  > So much much more intuitive and simple than Node. Can you elaborate?
  - u-rate 5y ago
    - No package.json or other config files - web compatible where possible (es6 import, fetch…) - native ts/js/tsx/jsx Overall, it just makes sense. It feels like you’re using one syntax for front and backend instead of having to use two different ones.
goldsteinq 5y ago
Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” makes no sense without checking the integrity of the binary, controlling the environment for LD_PRELOAD-like hacks and evaluating the code of this command for possible escape hatches. If you want to isolate a program, you need to do it on the OS level.
- killingtime74 5y ago
  As a non-js dev, is it better than Node?
  - goldsteinq 5y ago
    It’s arguably worse than Node because Node doesn’t pretend to provide any security. With Deno you may be tempted to think that permission to run specific command actually means that program can’t run some other command (it can, and doing this doesn’t even require _clever_ hacks: Deno uses binary name instead of the full path in it’s permission system, so you only need to change $PATH for the child process).
    - lucideer 5y ago
      The Deno docs say: > make sure you carefully consider if you want to grant a program --allow-run access: it essentially invalidates the Deno security sandbox Saying Deno shouldn't "pretend" (or attempt) to provide more security because a non-default flag invalidates the sandbox (as stated clearly in the docs for that flag) seems slight hyperbole. It would admittedly be cool if we could use this flag securely (though I'm sure the implementation complexity would be significant, and more code surface area is never nice to audit).
- keyKeeper 5y ago
minroot 5y ago
Wanted to install deno via cargo. It failed due to having low amount of memory while building V8.
- lucacasonato 5y ago
  How much memory do you have? It should use a prebuilt version of V8 by default to speed up the build process.
  - minroot 5y ago
    My laptop has 4GB of memory and 4GB of swap space on a 1TB of harddisk.
  - minroot 5y ago
    I think it did that, if i remember correctly, the error message was from the linker.
wruza 5y ago
I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config.ts fail because typescript is not ready for type:module until 4.6. I can't even recall now what's with Babel, I guess the same issue, since I'm using it to strip types in development builds. And then there are modules from ESM movement which are incompatible with this state of things. I understand their idea that nothing will move if not kicked further, but I hate it in real production where I can't upgrade because the author said so. Once ESM transition will be done, Deno will get much more modules, I believe. But right now the friction is unbelievable. Idk why they can't just allow all of the things like imports, requires, sync/async, side effects thing at least for a while, to cooperate. It's a matter of a form, not of a content. And there is no reason seemingly why nodejs couldn't make main.js async by default — sync modules would return a resolved promise. There is so much circus in all of that, which makes you pull hairs for weeks of a setup process. ^ I'm bundling server-side for hmr/watch functionality in a monorepo with many cross-side shared code/modules.
- jcelerier 5y ago
  Reading that makes me so happy to just have to open QtCreator, hit "new project" and get rolling
  - wruza 5y ago
    You can do that with nodejs too, e.g. edit package.json and main.js in vscode, hit hotkey to npm install hit hotkey to run node ./main.js. This is what I'm doing at the day job. What I'm trying to do there is to have a client and server in the same ./src, hot-reloaded module-wise on "save" only when a relevant part changes, and vscode to typecheck both at the same time. The language similarity is also a goal. It's a little more than just a traditional lazy-compile-restart cycle. Non-monorepo non-ts-only guys do not experience my issues, because they only have one environment per project (or per src-<target>), and don't try to make their build configs incompatible with other parts of a build system. I tried to push it as far as it could go to evaluate the state of things for writing non-standard slightly different web apps. To make a ts-react app, they just use CRA, for a backend they just use node main.js. But anyway this shows how interdependent this ecosystem is, instead of being full of orthogonal possibilities.
_jplc 5y ago
Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary. Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode. Packages are obtained (and heavily cached) from any URL instead of relying on a centralized repository. Obtain your dependencies as you want, whether it's Deno's proxy, directly from raw.githubusercontent.com, your own http server, or any other thing accessible thru an URL. At the end, the permission system is the least interesting part of the project imho. It's useful, because if you're doing a CLI that just receives stdin, processes it, and prints to stdout, you can block any disk and network access, but apart from that it's really limited because the nature of JS itself. (Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model) The thing I value the most is consistency and having a fully working development environment out of the box to be productive.
- andrew_ 5y ago
  That built in linter leaves a lot to be desired. If you're a big big fan of being told how your code should be formatted, then it's a good fit. however, if you're the slightest bit opinionated, you still have to implement ESLint and jump through those hoops.
  - _jplc 5y ago
    Right. Personally, I don't think any opinion is more correct than any other in regards to code formatting, so, consistently and collectively choosing one and going forward with it is the way.
- Zababa 5y ago
  > Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model There is an object-capability model in the upcoming OCaml 5.0, however it's only in the Eio library, that deals with IO https://github.com/ocaml-multicore/eio#design-note-object-capabilities https://github.com/ocaml-multicore/eio#design-note-object-ca.... There's also Emily, a subset of OCaml based on POLA (Principle of Least Authority) https://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf https://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf. I'm unaware of any plain to extend OCaml in that direction though.
Waterluvian 5y ago
Deno’s import system is near at first until you are repeating yourself everywhere, so you do what they suggest and make a file of import URLs and now you have your own package.json format.
andrewmcwatters 5y ago
Now instead of npm packages abusing SemVer unless you use non-default --save-exact behavior as an attack vector, we can import modules from URLs without subresource integrity unless you use non-default lock file behavior! Great! We learned nothing!
- Soremwar 5y ago
  Hence why developers always recommend to use immutable sources when importing modules
  - andrewmcwatters 5y ago
    The web isn't immutable.
    - Soremwar 5y ago
      "Immutable" in the sense that packages can't be taken down or modified by authors If you wanna take it a step further, you can always opt in to that lock file with various degrees of strictness as you yourself mentioned
a99c43f2d565504 5y ago
Node.js fully supports ECMAScript modules as they are currently specified and provides interoperability between them and its original module format, CommonJS. Authors can tell Node.js to treat JavaScript code as ECMAScript modules via the .mjs file extension, the package.json "type" field, or the --input-type flag.

147 points by markhaslam 5y ago

> V8 is a sandboxed language False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime. > that makes it impossible False, breaking out of the sandbox is trivial in environments which allow native addons.

cookiengineer 5y ago
Technically correct. Also related: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... Most Browser exploits these days use Heap Spraying attacks that try to corrupt the state of the sandbox in between bindings and native libraries (or their data structures that are transferred between contexts). So technically, a JIT VM always leads to possibilities for breakouts when there is a discrepancy between the optimizer and deoptimizer's assumptions (e.g. in regards to callstack, garbage, memory ownership etc). Also: There's a legacy navigator.plugins C-Bridge based API which hasn't been maintained or redesigned/refactored since the late 90s yet it is still active in most Browsers.
nexuist 5y ago
I am very interested in this. Are there existing exploits for deno? Using a stock out of the box configuration, can you execute some code that breaks its permission model? Has deno undergone some kind of security audit to verify its claims irt security? EDIT: I see some referenced issues in comments down below involving the --allow-read/write flag. I'm not interested in that. I'm interested in if anyone can prove that with no permissions granted at all, they can break out of the sandbox and achieve ACE.
- eyelidlessness 5y ago
  I think you’d need to either grant permissions (eg allow-ffi) or find a privilege escalation bug in V8 or Deno’s Rust bindings. The latter is less likely for sure. But being realistic, most people using Deno are granting some privileges, because most use cases at minimum do some I/O. I’m academically interested if there are other such exploits, too. But I’d expect if they’re found they’ll be patched before they’re disclosed (or they’ll be exploited in the wild).

deleted 5y ago

[deleted]

Kiro 5y ago

I prefer CommonJS. It's so simple. You assign the dependency to a variable and that's it. I still need to look up the syntax every time I use ESM.

afiori 5y ago
it is simple to write, it is not simple at all how strings are converted into paths. honestly tough, esm is more complex than it should (especially regarding how live exports happen)
tehbeard 5y ago
> You assign the dependency to a variable and that's it erm, how is that any simpler than `export const/function/class $defintion` ? I guess if you only touch JS once in a blue moon it's difficult to remember? Also CommonJS has some acknowledged issues around cyclic dependencies, and being incredibly fudgeable at runtime that makes static analysis and linting a pain.

galaxyLogic 5y ago

Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly? I find sync is often simpler to code for.

eyelidlessness 5y ago
Because the ESM standard specifies that modules are loaded by URL and themselves might initialize async. Once anything is async the whole call stack into it is. See also various discussions of “colored functions” which have made the rounds again recently.
- wruza 5y ago
  Why doesn't nodejs just make modules async? // main.js const fs = require("fs") const foo = await require_async("foo") await foo.sleep(1000) // other.js require("./main.js") // RequireError: main.js returned an unsettled promise, use require_async() Wouldn't that be better of both worlds?
  - eyelidlessness 5y ago
    Node did make modules async (just ESM modules). They can’t/won’t make CJS async because their synchronous semantics are a guarantee they determined not to break well before ESM. If you want async modules, ESM is the solution for that.
    - wruza 5y ago
      ESM will be the solution to that, when all the major toolchains catch up. I wouldn't sell this future short, but we aren't there yet either.
      - eyelidlessness 5y ago
        I agree but I think we’re there (if kicking a bit and screaming a bit).
- 5y ago

dmitriid 5y ago

Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"

afiori 5y ago
there is not really a difference between a url to a registry and a npm package name. the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it
- greggman3 5y ago
  There is one difference. I know npm keeps published versions. I don't know that random URL keeps versions. Caching locally doesn't help. I expect my code to work for others. Of course using any source is nice. node also allows this, just put a git URL as your dependency.
  - afiori 5y ago
    URLs to a registry keep published versions if the registry keeps published versions. Your argument is that npm is more trustworthy than another random registry, this is likely true but also a matter of opinion.
    - dmitriid 5y ago
      > URLs to a registry keep published versions if the registry keeps published versions. Yes. Have you've ever heard of running your own registry? It' quite easy to do and most companies do it prcisely because they want to a) keep published versions and b) prevent things like colors/fake.js Literally no one who promotes Deno has yet shown how to do the same with Deno beyond "yeah, you check in all your node_modules dependencies into Git".
- dmitriid 5y ago
  > there is not really a difference between a url to a registry and a npm package name. There is. For starters, I can run my company's registry and make sure all npm packages are downloaded from there since resolution mechanism for npm/yarn is well known. How do I tell deno to download <random-url> from my own registry? Looking at how deno "solves" this I can't stop laughing [1] --- start quote --- In Deno there is no concept of a package manager as external modules are imported directly into local modules. This raises the question of how to manage remote dependencies without a package manager. In big projects with many dependencies it will become cumbersome and time consuming to update modules if they are all imported individually into individual modules. The standard practice for solving this problem in Deno is to create a deps.ts file. All required remote dependencies are referenced in this file and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies... With all dependencies centralized in deps.ts, managing these becomes easier. --- end quote --- Are you for real? [1] https://deno.land/manual/examples/manage_dependencies https://deno.land/manual/examples/manage_dependencies

bartkappenburg 5y ago

Offtopic but this webpage disables my bottom navigation bar on mobile safari, their own navigation on top re-enables this. Has anyone else experienced this?

dmitriid 5y ago
I experienced the same issue

pjmlp 5y ago

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

tmikaeld 5y ago
I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.
- pjmlp 5y ago
  My relevant stars are what IT decides to install on devenvs or is part of RFPs technical requirements.
- Griffinsauce 5y ago
  > smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. This isn't necessarily enforced by Deno itself right? That seems like more of a side-effect from the self-selection of its users. Once the ecosystem grows and the all the "normies" come in, this doesn't seem guaranteed at all.
  - tmikaeld 5y ago
    Right, like I wrote, it's up to each developer, but i really do hope the trend continues.
- forty 5y ago
  My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.

u-rate 5y ago

Love Deno. So much much more intuitive and simple than Node. I highly recommend you giving it a try, if you used Node before, Deno will be a super easy to learn tool.

numlock86 5y ago
> So much much more intuitive and simple than Node. Can you elaborate?
- u-rate 5y ago
  - No package.json or other config files - web compatible where possible (es6 import, fetch…) - native ts/js/tsx/jsx Overall, it just makes sense. It feels like you’re using one syntax for front and backend instead of having to use two different ones.

goldsteinq 5y ago

Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” makes no sense without checking the integrity of the binary, controlling the environment for LD_PRELOAD-like hacks and evaluating the code of this command for possible escape hatches. If you want to isolate a program, you need to do it on the OS level.

killingtime74 5y ago
As a non-js dev, is it better than Node?
- goldsteinq 5y ago
  It’s arguably worse than Node because Node doesn’t pretend to provide any security. With Deno you may be tempted to think that permission to run specific command actually means that program can’t run some other command (it can, and doing this doesn’t even require _clever_ hacks: Deno uses binary name instead of the full path in it’s permission system, so you only need to change $PATH for the child process).
  - lucideer 5y ago
    The Deno docs say: > make sure you carefully consider if you want to grant a program --allow-run access: it essentially invalidates the Deno security sandbox Saying Deno shouldn't "pretend" (or attempt) to provide more security because a non-default flag invalidates the sandbox (as stated clearly in the docs for that flag) seems slight hyperbole. It would admittedly be cool if we could use this flag securely (though I'm sure the implementation complexity would be significant, and more code surface area is never nice to audit).
keyKeeper 5y ago

minroot 5y ago

Wanted to install deno via cargo. It failed due to having low amount of memory while building V8.

lucacasonato 5y ago
How much memory do you have? It should use a prebuilt version of V8 by default to speed up the build process.
- minroot 5y ago
  My laptop has 4GB of memory and 4GB of swap space on a 1TB of harddisk.
- minroot 5y ago
  I think it did that, if i remember correctly, the error message was from the linker.

wruza 5y ago

I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config.ts fail because typescript is not ready for type:module until 4.6. I can't even recall now what's with Babel, I guess the same issue, since I'm using it to strip types in development builds. And then there are modules from ESM movement which are incompatible with this state of things. I understand their idea that nothing will move if not kicked further, but I hate it in real production where I can't upgrade because the author said so. Once ESM transition will be done, Deno will get much more modules, I believe. But right now the friction is unbelievable. Idk why they can't just allow all of the things like imports, requires, sync/async, side effects thing at least for a while, to cooperate. It's a matter of a form, not of a content. And there is no reason seemingly why nodejs couldn't make main.js async by default — sync modules would return a resolved promise. There is so much circus in all of that, which makes you pull hairs for weeks of a setup process. ^ I'm bundling server-side for hmr/watch functionality in a monorepo with many cross-side shared code/modules.

jcelerier 5y ago
Reading that makes me so happy to just have to open QtCreator, hit "new project" and get rolling
- wruza 5y ago
  You can do that with nodejs too, e.g. edit package.json and main.js in vscode, hit hotkey to npm install hit hotkey to run node ./main.js. This is what I'm doing at the day job. What I'm trying to do there is to have a client and server in the same ./src, hot-reloaded module-wise on "save" only when a relevant part changes, and vscode to typecheck both at the same time. The language similarity is also a goal. It's a little more than just a traditional lazy-compile-restart cycle. Non-monorepo non-ts-only guys do not experience my issues, because they only have one environment per project (or per src-<target>), and don't try to make their build configs incompatible with other parts of a build system. I tried to push it as far as it could go to evaluate the state of things for writing non-standard slightly different web apps. To make a ts-react app, they just use CRA, for a backend they just use node main.js. But anyway this shows how interdependent this ecosystem is, instead of being full of orthogonal possibilities.

_jplc 5y ago

Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary. Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode. Packages are obtained (and heavily cached) from any URL instead of relying on a centralized repository. Obtain your dependencies as you want, whether it's Deno's proxy, directly from raw.githubusercontent.com, your own http server, or any other thing accessible thru an URL. At the end, the permission system is the least interesting part of the project imho. It's useful, because if you're doing a CLI that just receives stdin, processes it, and prints to stdout, you can block any disk and network access, but apart from that it's really limited because the nature of JS itself. (Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model) The thing I value the most is consistency and having a fully working development environment out of the box to be productive.

andrew_ 5y ago
That built in linter leaves a lot to be desired. If you're a big big fan of being told how your code should be formatted, then it's a good fit. however, if you're the slightest bit opinionated, you still have to implement ESLint and jump through those hoops.
- _jplc 5y ago
  Right. Personally, I don't think any opinion is more correct than any other in regards to code formatting, so, consistently and collectively choosing one and going forward with it is the way.
Zababa 5y ago
> Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model https://en.wikipedia.org/wiki/Object-capability_model There is an object-capability model in the upcoming OCaml 5.0, however it's only in the Eio library, that deals with IO https://github.com/ocaml-multicore/eio#design-note-object-capabilities https://github.com/ocaml-multicore/eio#design-note-object-ca.... There's also Emily, a subset of OCaml based on POLA (Principle of Least Authority) https://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf https://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf. I'm unaware of any plain to extend OCaml in that direction though.

Waterluvian 5y ago

Deno’s import system is near at first until you are repeating yourself everywhere, so you do what they suggest and make a file of import URLs and now you have your own package.json format.

andrewmcwatters 5y ago

Now instead of npm packages abusing SemVer unless you use non-default --save-exact behavior as an attack vector, we can import modules from URLs without subresource integrity unless you use non-default lock file behavior! Great! We learned nothing!

Soremwar 5y ago
Hence why developers always recommend to use immutable sources when importing modules
- andrewmcwatters 5y ago
  The web isn't immutable.
  - Soremwar 5y ago
    "Immutable" in the sense that packages can't be taken down or modified by authors If you wanna take it a step further, you can always opt in to that lock file with various degrees of strictness as you yourself mentioned

a99c43f2d565504 5y ago

Node.js fully supports ECMAScript modules as they are currently specified and provides interoperability between them and its original module format, CommonJS. Authors can tell Node.js to treat JavaScript code as ECMAScript modules via the .mjs file extension, the package.json "type" field, or the --input-type flag.