Nice to see! How do they plan to monetize? I either became blind or missed it somehow. The article does say how they DON'T plan on monetize:
"Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno."
There are some hints though:
"If you watch our conference talks, you will find we've been hinting at commercial applications of this infrastructure for years. We are bullish about the technology stack we've built and intend to pursue those commercial applications ourselves. Our business will build on the open source project, not attempt to monetize it directly."
Does anyone have some insight into those? I haven't watch any Deno talk (maybe one actually?) so it feel a bit strange to make people watch technical talks to find hints of the monetization strategy.
PS, if I was a rich investor I'd throw money at this project even as a donation, so no complain at all, but I'm very curious on the monetization plan.
I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use.
The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.
Peeking at sparks.land I see that you're serving .ts files, I assume that's what you mean by using sucrase, you're transpiling "live" instead of building/deploying bundles offline?
I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?
> Our infrastructure makes it possible to... create custom runtimes for different applications [like] Cloudflare Worker-style Serverless Functions
Fascinated to see what happens here. The serverless / edge compute paradigm fits Javascript hand-in-glove philosophically, but until now it's always felt quite clunky to me. When I've tried it out, I've always been left thinking "but this would just be so much easier with a server".
Reading this has made it click for me why that is. A new paradigm needs a new set of tools native to that paradigm.
The entire server-side JS ecosystem is currently structured around Node, a fundamentally stateful-server paradigm. You can try to abstract over it, but only so far. It's not the serverless paradigm that's clunky, per se, it's that the tools right now were built for another way of doing things.
As a concrete example - Deno has an import system based on URLs, rather than on-disk node_modules. I thought that was a cool feature for convenience, less overhead, more open and sharable packages, etc. But now I realise the full intent of it. It's much more than all that, it's a fundamental shift in the paradigm: no implied dependency on stateful disk in the runtime itself.
There's lots of things going on this this space. It seems every other day I discover another Cloudflare Workers-like implementation (granted, most of them are for testing/development). I'm cataloging them here for anyone who's interested: https://workers.js.org
Yep, that will be something to follow. It will be really interesting to see what kind of market emerges here by allowing new custom runtimes to compete, with specializations for a different niches and environments.
Their comparison to Cloudflare workers doesn't seem right. The benefit of cloudflare workers is that they run on the edges of a CDN. Putting Deno on one server wouldn't achieve that.
> Extending web programming beyond the browser is not a novel idea. Indeed, we have done that with moderate success in our “Node.js” project. But over a decade later, we find server-side JavaScript hopelessly fragmented, deeply tied to bad infrastructure, and irrevocably ruled by committees without the incentive to innovate. As the browser platform moves forward at a rapid pace, server-side JavaScript has stagnated.
wow lots of bold statements there. And another one for the usual "JavaScript is fragmented, let's create another tool to fix 'em all.".
Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effort).
Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes.
I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), client side bundlers (eg webpack), serverside frameworks (eg express), etc. But because Deno is solving some of the issues for those who run sensitive code in production (eg Lambda functions) it'll most likely gonna become another VM on the public cloud providers' list.
All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.
The issue with Deno, personally, is that it feels like it doesn’t deviate enough from NodeJS to even make it worth taking the time to learn/migrate projects over to it. From what I recall, the only really new and nice features are:
a) sandboxed by default
b) no need for a node_modules folder since you can directly import from a URL
And is that really worth dumping loads of money into developing further? I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.
The standard library will be a killer feature. Even for people that know the existing ecosystem (as I do), as more libraries fall out of fashion or become abandoned, and people have to pick up (several) new libraries from scratch for basic tasks, they'll realize (as I did) its not actually any different than just using Deno. I don't know if that will be enough, but that's one of the angle's I'm watching closely now. I'm partly biased because I like playing with streams, and those can be a nightmare in Node.
Hard pass. There are globs of features and design changes that make it worth the switch immediately if your use context can allow for it. I've now done a handful of apps and libraries in it, and given the option, I'd never look back to node. I don't say that lately. Node's was the best. These new designs are more than marginally overcoming the shortcomings of node. The motivation for migration is strong, and if best proven through experimenting. If you are TS saavy, do yourself a favor and try it out.
> I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.
It depends on migration effort. Take typescript for example, it's very similar with JS that migrate the codebase is not that painful. If the standard library and package manager can prove to highly useful, we'll see two possible scenario that aren't mutually exclusive:
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?
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.
I know this sounds crazy on the surface level, but I really wish I could do data engineering and machine learning with TypeScript instead of Python. TypeScript's type system is so good, it makes refactoring large projects so easy. Python's typing module leaves a lot to be desired, and on top of that PyCharm doesn't properly support everything. Perhaps I should switch to VSCode--but I do like IntelliJ, and it works really well for TypeScript.
I've only dipped my toes in the water with Deno, but it solves a few pain points I've felt with Node. Direct deps via url vs npm as middleman, a standard library (thank goodness!), and single binary distribution. Types are great too, but these other things would be enough for me.
Excited to see a commercial company centered around the TypeScript ecosystem (both server and client) and betting on WebAssembly. Any successful Open Source must provide commercial value to become sustainable. Funnily enough that assures its longevity long term.
Keep up the great work Ryan, Bert & team.
Exciting times!
It seems there are many toothing problems with Deno. I just tried stuff from their blog (https://deno.com/blog/v1.8):
$ deno run --unstable --allow-write=output.png https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/hello-triangle/mod.ts
Download https://crux.land/2arQ9t
Download https://crux.land/api/get/2arQ9t
error: Import 'https://crux.land/api/get/2arQ9t' failed: 404 Not Found
at https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/deps.ts:4:0
(A dependency got removed?)
Another one:
$ deno run https://deno.land/v1.8/permission_api.ts
error: An unsupported media type was attempted to be imported as a module.
Specifier: https://deno.land/v1.8/permission_api.ts
MediaType: Unknown
(The site is a 404 returning status code 200... just... why?)
You can write in other languages beyond JavaScript or TypeScript and generate WebAssembly. This means that say someone wrote a nice library or utility in C# you can compile that C# down to WebAssembly and use that library or utility in JavaScript or TypeScript (or anything else that can access WebAssembly).
This is analogous perhaps to C# and F# within .NET currently. C# and F# have the same BCL (base common layer) so you can use C# code in F# and vice versa. WebAssembly is like that and much more.
I believe it's a very poorly written description in the newer GitHub App permission system. My understanding it describes something akin to "can act on your behalf, but only in the scope of what other permissions are being requested" but it's overall very unclear wording.
Few days ago, there was new version released (87). In certain situations, when silent upgrade had been made during using the browser it displays an "Oops, something went wrong" notification with a button to refresh. If you will close and reopen the Firefox the problem will vanish. It is less kind of crash but more likely as problem to free/monkeypatch resources.
I have run into the same problem on Linux but I have quite complicated Firefox configuration with at least few extra profiles (about:profiles).
I understand that the authors have very strong pedigree in their field, but given a lot of the motivation stems from regretted node design decisions, is the rust etc expertise on the project deep enough to not make equivalent mistakes that will be rued in another few years?
Genuine question (I assume it is, but presumably it was before with c++) - it just strikes me that once something becomes as successful as node, and given that nothing is ever perfect it might be useful to clarify why the technical insight might be better this time around - at least regarding the idioms of the underlying tech; the added experience at the architectural and implementation side a given.
> Of the myriad ways to program computers, scripting languages are the most effortless and practical variety. Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process.
I haven't fully investigated in a few years, but isn't it still true that LuaJIT is is faster than V8 JavaScript? The last I saw it was outperforming V8 by a lot. The practical use of LuaJIT is still very niche though. The lack of a comprehensive standard library, and being forever stuck on Lua 5.1 makes it even less generally appealing. I still love it for programming Nginx though..
[+] [-] franciscop|5 years ago|reply
PS, if I was a rich investor I'd throw money at this project even as a donation, so no complain at all, but I'm very curious on the monetization plan.
[+] [-] elisee|5 years ago|reply
I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use.
The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.
[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: https://twitter.com/MasterOfTheGrid/status/13757583007179735... - https://sparks.land
[+] [-] iends|5 years ago|reply
[+] [-] sbarre|5 years ago|reply
I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?
[+] [-] samjmck|5 years ago|reply
[+] [-] tin7in|5 years ago|reply
[+] [-] cozuya|5 years ago|reply
[+] [-] davnicwil|5 years ago|reply
> Our infrastructure makes it possible to... create custom runtimes for different applications [like] Cloudflare Worker-style Serverless Functions
Fascinated to see what happens here. The serverless / edge compute paradigm fits Javascript hand-in-glove philosophically, but until now it's always felt quite clunky to me. When I've tried it out, I've always been left thinking "but this would just be so much easier with a server".
Reading this has made it click for me why that is. A new paradigm needs a new set of tools native to that paradigm.
The entire server-side JS ecosystem is currently structured around Node, a fundamentally stateful-server paradigm. You can try to abstract over it, but only so far. It's not the serverless paradigm that's clunky, per se, it's that the tools right now were built for another way of doing things.
As a concrete example - Deno has an import system based on URLs, rather than on-disk node_modules. I thought that was a cool feature for convenience, less overhead, more open and sharable packages, etc. But now I realise the full intent of it. It's much more than all that, it's a fundamental shift in the paradigm: no implied dependency on stateful disk in the runtime itself.
[+] [-] qwtel|5 years ago|reply
[+] [-] resonantjacket5|5 years ago|reply
[+] [-] dgellow|5 years ago|reply
[+] [-] unityByFreedom|5 years ago|reply
[+] [-] kostarelo|5 years ago|reply
wow lots of bold statements there. And another one for the usual "JavaScript is fragmented, let's create another tool to fix 'em all.".
[+] [-] sublimefire|5 years ago|reply
Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes.
I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), client side bundlers (eg webpack), serverside frameworks (eg express), etc. But because Deno is solving some of the issues for those who run sensitive code in production (eg Lambda functions) it'll most likely gonna become another VM on the public cloud providers' list.
All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.
[+] [-] ravenstine|5 years ago|reply
- Typescript as a first class citizen
- An actual `window` global with familiar browser APIs
- Sandboxing w/ permissions
- URL-based imports (no need for NPM)
- Bundling into self-contained binaries
- Things like top-level-await which Node.js still treats as experimental.
- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks)
To me, those aren't just minor details. This has the potential to create a new epoch in server-size JavaScript.
[+] [-] kibleopard|5 years ago|reply
And is that really worth dumping loads of money into developing further? I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.
[+] [-] cloverich|5 years ago|reply
[+] [-] cdaringe|5 years ago|reply
[+] [-] fendy3002|5 years ago|reply
It depends on migration effort. Take typescript for example, it's very similar with JS that migrate the codebase is not that painful. If the standard library and package manager can prove to highly useful, we'll see two possible scenario that aren't mutually exclusive:
1. People migrating to Deno
2. Newer nodejs version follow what Deno has
In the end it's good for us
[+] [-] not_knuth|5 years ago|reply
> 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|5 years ago|reply
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.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] qbasic_forever|5 years ago|reply
[+] [-] denkquer|5 years ago|reply
[+] [-] why_Mr_Anderson|5 years ago|reply
[+] [-] munro|5 years ago|reply
[+] [-] breck|5 years ago|reply
[+] [-] searchableguy|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] madjam002|5 years ago|reply
[+] [-] kizer|5 years ago|reply
[+] [-] oauea|5 years ago|reply
[+] [-] gorjusborg|5 years ago|reply
[+] [-] syrusakbary|5 years ago|reply
Keep up the great work Ryan, Bert & team. Exciting times!
[+] [-] alfl|5 years ago|reply
We were consultants scaling node to production for a major international bank, circa 2016.
Love the security improvements in deno, will have to give it a look.
[+] [-] turadg|5 years ago|reply
The leading app framework for that is Nextjs and I hope the Rauch Capital investment sígnals Vercel will be supporting Deno.
Anyone know?
[+] [-] Woung1938|5 years ago|reply
Another one:
(The site is a 404 returning status code 200... just... why?)[+] [-] wperron|5 years ago|reply
[+] [-] kostarelo|5 years ago|reply
> But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common.
Why is WebAssembly a key concept here? How does Deno uses it?
[+] [-] lucacasonato|5 years ago|reply
[+] [-] tsujp|5 years ago|reply
This is analogous perhaps to C# and F# within .NET currently. C# and F# have the same BCL (base common layer) so you can use C# code in F# and vice versa. WebAssembly is like that and much more.
[+] [-] jedahan|5 years ago|reply
Clicking on 'Learn more about Deno Deploy' leads to https://github.com/apps/deno-deploy , which does not tell me more.
What does 'act on your behalf' mean for Deno Deploy?
[+] [-] jacobwg|5 years ago|reply
See https://news.ycombinator.com/item?id=26485844
[+] [-] huhtenberg|5 years ago|reply
Anyone else is running into this?
[+] [-] pqb|5 years ago|reply
Few days ago, there was new version released (87). In certain situations, when silent upgrade had been made during using the browser it displays an "Oops, something went wrong" notification with a button to refresh. If you will close and reopen the Firefox the problem will vanish. It is less kind of crash but more likely as problem to free/monkeypatch resources.
I have run into the same problem on Linux but I have quite complicated Firefox configuration with at least few extra profiles (about:profiles).
[+] [-] jetrink|5 years ago|reply
[+] [-] mellosouls|5 years ago|reply
Genuine question (I assume it is, but presumably it was before with c++) - it just strikes me that once something becomes as successful as node, and given that nothing is ever perfect it might be useful to clarify why the technical insight might be better this time around - at least regarding the idioms of the underlying tech; the added experience at the architectural and implementation side a given.
[+] [-] VWWHFSfQ|5 years ago|reply
I haven't fully investigated in a few years, but isn't it still true that LuaJIT is is faster than V8 JavaScript? The last I saw it was outperforming V8 by a lot. The practical use of LuaJIT is still very niche though. The lack of a comprehensive standard library, and being forever stuck on Lua 5.1 makes it even less generally appealing. I still love it for programming Nginx though..
[+] [-] gutino|5 years ago|reply
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[+] [-] spion|5 years ago|reply