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:<p><pre><code> "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."
</code></pre>
There are some hints though:<p><pre><code> "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."
</code></pre>
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.<p>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.
Happy to see Deno get some financial backing!<p>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.<p>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.<p>[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: <a href="https://twitter.com/MasterOfTheGrid/status/1375758300717973508" rel="nofollow">https://twitter.com/MasterOfTheGrid/status/13757583007179735...</a> - <a href="https://sparks.land" rel="nofollow">https://sparks.land</a>
What I find most exciting here is:<p>> <i>Our infrastructure makes it possible to... create custom runtimes for different applications [like] Cloudflare Worker-style Serverless Functions</i><p>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".<p>Reading this has made it click for me why that is. A new paradigm needs a new set of tools <i>native</i> to that paradigm.<p>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, <i>per se</i>, it's that the tools right now were built for another way of doing things.<p>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.
> 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.<p>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).<p>Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes.<p>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.<p>All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.
A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why:<p>- Typescript as a first class citizen<p>- An actual `window` global with familiar browser APIs<p>- Sandboxing w/ permissions<p>- URL-based imports (no need for NPM)<p>- Bundling into self-contained binaries<p>- Things like top-level-await which Node.js still treats as experimental.<p>- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks)<p>To me, those aren't just minor details. This has the potential to create a new epoch in server-size 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<p>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.
If I understood correctly this is how they intend to make money:<p>> 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.<p>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 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 have never used Deno, but I just wanted to say that I really love the branding and graphics on the website, especially <a href="https://deno.com/deploy" rel="nofollow">https://deno.com/deploy</a>
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.<p>Keep up the great work Ryan, Bert & team.
Exciting times!
I met Bert in the StrongLoop days after the IBM acquisition. Good guy and good luck to him.<p>We were consultants scaling node to production for a major international bank, circa 2016.<p>Love the security improvements in deno, will have to give it a look.
Deno seems well poised to replace Nodejs for isomorphic Web programming.<p>The leading app framework for that is Nextjs and I hope the Rauch Capital investment sígnals Vercel will be supporting Deno.<p>Anyone know?
It seems there are many toothing problems with Deno. I just tried stuff from their blog (<a href="https://deno.com/blog/v1.8" rel="nofollow">https://deno.com/blog/v1.8</a>):<p><pre><code> $ 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
</code></pre>
(A dependency got removed?)<p>Another one:<p><pre><code> $ 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
</code></pre>
(The site is a 404 returning status code 200... just... why?)
From the last paragraph:<p>> But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common.<p>Why is WebAssembly a key concept here? How does Deno uses it?
Trying to signup for Deno Deploy, it asks for the 'Act on your behalf' github permission to make an account.<p>Clicking on 'Learn more about Deno Deploy' leads to <a href="https://github.com/apps/deno-deploy" rel="nofollow">https://github.com/apps/deno-deploy</a> , which does not tell me more.<p>What does 'act on your behalf' mean for Deno Deploy?
Woah. Clicking on this link crashes Firefox. Version 86 on Windows. I don't remember seeing FF crash in several years now.<p>Anyone else is running into this?
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?<p>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.<p>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 <i>a lot</i>. 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..
>>> Our investors are Dan Scholnick from Four Rivers Ventures, Guillermo from Rauch Capital, Lee Jacobs from Long Journey Ventures, the Mozilla Corporation, Shasta Ventures, and our long-time collaborator Ben Noordhuis.<p>Why is the Mozilla Corporation an investor in a Chrome based technology startup ?
From a distance I think Deno has a lot of promising features going for it. Expressing modules as URLs seems like a small difference but I believe it has big ramifications. With clever use of DNS resolving and caching I wonder how fast new instances will be able to spin up. I'm guessing it'll be fast!<p>My only gripe with the Deno company is that taking investor funding is a double-edged sword. Yes, they'll get to hire very skilled developers. However naturally the investors want a tidy exit, and I wonder if that would be to be bought out by Amazon, Microsoft or Google.<p>Edit: Just realized that there's a key difference in that Deno does not have something like NPM to be bought and sold because dependencies are URLs and thus decentralized. Also, Deno itself is open-source.
I'm excited about Deno, but I'm finding that the docs still need to be improved. For example, I'm trying to build a tcp server. I'm not able to get information on how back-pressure is handled.<p>I can see that Deno.listen returns an object which implements reader and writer interfaces, but it isn't clear to my how to look for events, such as disconnect or that new data is available.<p>I wish there were examples showing how to correctly parse frames or implement protocols.<p>I'm sure these things will be expanded over time, partly by programmers in the community, but from the outside, things are still a bit rough.
This is probably unpopular here, but I wish people would just stop using Javascript on the server.<p>Well, I wish they would stop using it period, but at least in the browser it makes some sense.<p>Edit: to be clear, I have no beef with Typescript, Dart, Clojurescript, and the many other languages that compile into JS. It's JS itself I have issue with. I feel like it gives too much flexibility to young programmers to screw things up. There don't seem to be enough safeguards or training wheels. On large projects its my nightmare.
> The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.<p>I know this might be hard to see, but Rust is actually in the same domain. It is also, among other things, enabling product/frontend/web engineers to build backend/native/browser-less applications.<p>I'd bet Rust will be more successful here, especially given its amazing ability to change itself and innovate.
> Many developers, we think, prefer web-first abstraction layers.<p>Many developers, I think, <i>don’t look past</i> web-first abstraction layers.<p>I can’t tell you how many times I’ve seen CLI tools which are huge chunks of node wrapping a thin bash command. They are multiple files, orders of magnitude larger than they need to be, and require external dependencies because these developers are fixated on their proverbial hammer.
If you want hot-deployed distributed Java VM HTTP app. server + JSON database you can use my open-source alternative: <a href="http://host.binarytask.com" rel="nofollow">http://host.binarytask.com</a><p>It uses comet-stream instead of WebSockets.<p>But it's fully "joint" parallel on all cores.
> To provide a modern, productive programming system that adheres to browser APIs.<p>In my opinion, the best part of node is (or was) that it didn't adhere to the browser APIs. That brought in some fresh air, and gave us buffers, native bindings, streams etc.
This is cool and exciting to see. I've mostly watched Deno from the sidelines, only playing with code a little bit, but it's clear Ryan and co. are serious about applying the lessons learned from Node. Best wishes to him and the team.
This is a great news!<p>Ryan and the team should be capturing some of the value produced by their creation. And because of Deno's a developer tool, it's actually capturing the far minor part of the whole value and enable a much bigger value creation!
>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.<p>Trying to sell something based on FUD is always a bad sign.
Article left me wondering what the plan is for them here - why is it becoming 'The Company Deno'... other than they have a bunch of investors. Is it just to get a team in to properly manage the project as a whole?
It's the absolutely right move to get investors. Deno has substantial advantages over NodeJS.<p>However, I personally would prefer Go or .NET Core for my backend any day. We need to wait and see where it's going ...<p>Good luck and success anyway!
Deno is licensed as MIT. Awesome! But how will they prevent from being freeloaded?<p>My sense is that GPL3 gets a ton of criticism on HN, but isn't it the perfect defense against freeloaders?<p>* license the code for proprietary use in your stack
* use GPL3 if you have a non-commercial use, and are willing to accept the requirement to open source your own code.<p>I don't understand why this option isn't used more by open source projects that want to be able to fund themselves.<p>Can anyone explain? (Even better if there are examples / case studies)
I hope that Deno can maximize TS performance. Right now they compile TS internally, but especially with this new financially-backed focus I hope that they can perhaps modify V8 or fork it to create a TS engine that takes advantage of type information for optimization. That's really what's needed; in a "no implicit any" application performance would near native.<p>Also, it's nice that they're using Tokio for the HTTP server instead of a JS implementation (from what I understand). I want to see Deno near the top of the TechEmpower benchmarks.
I'm very pleased Javascript / Node evolves. But thanks, too late, I'll skip it as soon as possible. It has so many unpleasant surprises. I'll move the ladder up, to something which compiles to Javascript, or whatever else, but no Javascript anymore please.
> Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process<p>Haha, this made me laugh hard, stopped reading
> Many are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. Bash and Zsh scripts calling into native code will never go away. But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common. Many developers, we think, prefer web-first abstraction layers.<p>Every time I read something like this I realize how much in the minority I am. I am not a web developer. I have never written JavaScript before in my life. I hate working with “web-first abstractions”. I feel like it is just massive bloat on top of true native application. But given the popularity of things like electron, react-native, Node, and Deno I don’t speak for the majority.<p>And the thing is, I don’t know if I just learned web dev if I would love this new approach to software that is eating the world and I would “get it”. Or if it just exists because JavaScript developers don’t want to learn something new.
> Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process.<p>Most popular, I can agree. Fastest, & only one with industrial standardization process? Have they met Erlang?<p>edit: you have to be kidding me, downvoted to oblivion for an honest observation. Sorry I hurt javascript's feelings.
Sounds like total bullshit. Deno hasn't put any dint in nodejs and never will because nobody is rewriting all of their stuff for the new API. It is just that all the scummy founders and rockstars of silicon valley have found that offering higher level services is a great way to scam people of their money because it is the only way the new "average" programmer can even make anything. The only problem is long-term the people using these services will need to find actual programmers.