4 ms·

If I understood correctly this is how they intend to make money: > Not every use-case of server-side JavaScript needs to access the file system; our infrastruc

If I understood correctly this is how they intend to make money: > Not every use-case of server-side JavaScript needs to access the file system; our infrastructure makes it possible to compile out unnecessary bindings. This allows us to create custom runtimes for different applications: Electron-style GUIs, Cloudflare Worker-style Serverless Functions, embedded scripting for databases, etc. So it's basically more of a Redhat approach to making money from open source? They intend to build tailored services on top of Deno for companies that request them?

sbarre 6y ago
I'm not sure that they meant those specific runtimes would be premium products. My read was that anyone could more easily configure a runtime to expose (or not expose) the underlying bindings that it requires, vs. just having them all in there by default. I think "us" in that statement is the Deno community, not Deno the company. But maybe I'm wrong.
- not_knuth 6y ago
  Clicking around the website and reading more comments leads me to believe that this is the product they intend to monetize with: https://deno.com/deploy https://deno.com/deploy I still find it strange that there is no mention of it in the post...
  - sbarre 6y ago
    That makes sense... So if you're up for it, you can still roll your own deployment infrastructure and tailor your builds as needed etc.. and support all of that internally. Or you can pay Deno to handle it for you and you can focus on building your apps.
why_Mr_Anderson 6y ago
Javascript embedded scripting for databases .../shivers
- sbarre 6y ago
  Why? I think the point being made here is that it will be easier to create purpose-built runtimes that only provide needed bindings, making them more secure and possibly also more performant? JS/TS as languages are here to stay, so let's give them the best possible ecosystem.
- qbasic_forever 6y ago
  Stuff like CouchDB have been around for a decade now, it's fine. All of NPM still runs on it...
denkquer 6y ago
I recall Ryan regreting nodes full-permission approach. Not every script should be able to access the fs for securities sake.
- Griffinsauce 6y ago
  Deno's permissions are per-process though, it's a big jump for sure, but also still leaves the door wide open for abuse by dependencies of any serious project.
  - tannhaeuser 6y ago
    How is that different from Node.js which also runs in a single process? Or does Deno create per-request processes (or v8 "isolates" etc) like CGI does?
    - zastrowm 6y ago
      I think the point was that it's not different from Node.js - and thus not much of a benefit. If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.
      - Griffinsauce 6y ago
        Yes, this was my point. It's only trivially better in practice since you'll have to open all the doors nearly all the time. We have so many dependencies that really only need to work in-memory and have zero IO needs. That part is not solved in Deno at all.
  - e12e 6y ago
    It does allow for some coarse grained improvements for certain services, though. You might write an smtp daemon that only delivers email on to another service via LMTP - thus without ability to write to (or read from, depending on configuration) the file system, for example. Yes, you can accomplish this via containers, too - but it's nice to get as much out of process isolation as possible, not to mention it is likelier easier to test and debug the closer to the surface of the runtime limitations are implemented.
deleted 6y ago
[deleted]
qbasic_forever 6y ago
That's a description of a command line flag or feature of the runtime, not a business model.

sbarre 6y ago

I'm not sure that they meant those specific runtimes would be premium products. My read was that anyone could more easily configure a runtime to expose (or not expose) the underlying bindings that it requires, vs. just having them all in there by default. I think "us" in that statement is the Deno community, not Deno the company. But maybe I'm wrong.

not_knuth 6y ago
Clicking around the website and reading more comments leads me to believe that this is the product they intend to monetize with: https://deno.com/deploy https://deno.com/deploy I still find it strange that there is no mention of it in the post...
- sbarre 6y ago
  That makes sense... So if you're up for it, you can still roll your own deployment infrastructure and tailor your builds as needed etc.. and support all of that internally. Or you can pay Deno to handle it for you and you can focus on building your apps.

why_Mr_Anderson 6y ago

Javascript embedded scripting for databases .../shivers

sbarre 6y ago
Why? I think the point being made here is that it will be easier to create purpose-built runtimes that only provide needed bindings, making them more secure and possibly also more performant? JS/TS as languages are here to stay, so let's give them the best possible ecosystem.
qbasic_forever 6y ago
Stuff like CouchDB have been around for a decade now, it's fine. All of NPM still runs on it...

denkquer 6y ago

I recall Ryan regreting nodes full-permission approach. Not every script should be able to access the fs for securities sake.

Griffinsauce 6y ago
Deno's permissions are per-process though, it's a big jump for sure, but also still leaves the door wide open for abuse by dependencies of any serious project.
- tannhaeuser 6y ago
  How is that different from Node.js which also runs in a single process? Or does Deno create per-request processes (or v8 "isolates" etc) like CGI does?
  - zastrowm 6y ago
    I think the point was that it's not different from Node.js - and thus not much of a benefit. If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.
    - Griffinsauce 6y ago
      Yes, this was my point. It's only trivially better in practice since you'll have to open all the doors nearly all the time. We have so many dependencies that really only need to work in-memory and have zero IO needs. That part is not solved in Deno at all.
- e12e 6y ago
  It does allow for some coarse grained improvements for certain services, though. You might write an smtp daemon that only delivers email on to another service via LMTP - thus without ability to write to (or read from, depending on configuration) the file system, for example. Yes, you can accomplish this via containers, too - but it's nice to get as much out of process isolation as possible, not to mention it is likelier easier to test and debug the closer to the surface of the runtime limitations are implemented.

deleted 6y ago

[deleted]

qbasic_forever 6y ago

That's a description of a command line flag or feature of the runtime, not a business model.