Deno is striving for more unified APIs with browsers, so while they are moving away from the "platform" of internal use only V8 APIs, they are moving toward the "web platform", which seems an admirable goal to me. One of my biggest complaints for a while has been how drastically different some Node APIs are from the way any actual "web platform" APIs work in 2021 (Promises for filesystem APIs in Node are still "experimental", and meanwhile there's an actual filesystem API standardized in the "web platform" that is entirely incompatible but Promise-based). You can polyfill some of the "web platform" libraries back on top of Node in many cases, but Deno seems sensible to me in trying to better unify such things from the start.
One of Deno's value props is to have a tighter and more explicit trust model.
And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.
However, there is nothing stopping you from using Node or integrating V8 and go wild with it! (In fact I would argue that this is a solid strategy for some types of projects, where you can get the best of both (static/dynamic) worlds.
And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.
Sounds rather obscure actually. Still somewhat confused why this would be useful in Deno. Looks like it's just a repeat of what happened with Java's SecurityManager, which is now being deprecated and removed.
Comments
Isn't there a compatibility layer available, or are there reasons that in principle make this impossible?
There is a compatibility layer but it is not complete.
One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port
Who doesn't love being removed even further from the platform they're running on?
Deno is striving for more unified APIs with browsers, so while they are moving away from the "platform" of internal use only V8 APIs, they are moving toward the "web platform", which seems an admirable goal to me. One of my biggest complaints for a while has been how drastically different some Node APIs are from the way any actual "web platform" APIs work in 2021 (Promises for filesystem APIs in Node are still "experimental", and meanwhile there's an actual filesystem API standardized in the "web platform" that is entirely incompatible but Promise-based). You can polyfill some of the "web platform" libraries back on top of Node in many cases, but Deno seems sensible to me in trying to better unify such things from the start.
One of Deno's value props is to have a tighter and more explicit trust model.
And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.
However, there is nothing stopping you from using Node or integrating V8 and go wild with it! (In fact I would argue that this is a solid strategy for some types of projects, where you can get the best of both (static/dynamic) worlds.
Sounds rather obscure actually. Still somewhat confused why this would be useful in Deno. Looks like it's just a repeat of what happened with Java's SecurityManager, which is now being deprecated and removed.
It is how cloudflare workers work
Yes, something very obscure. Maybe a handful of companies in the world have a need to operate something like that.