Live data from Hacker News

The Deno Company

deno.com

21–30 of 446 posts

Re: The Deno Company

#21
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?

Re: The Deno Company

#22
post #13

Earlier quoted context omitted.

It is matter of time until they release a proprietary version which is better than the MIT version. Chrome vs chromium etc

The blog post specifically says that that will not happen

Let's make a gentlemens' bet. If Deno is still completely free in 5 years, I'll give you $500. You up for that?

Re: The Deno Company

#23
post #7

I've always been very skeptical of the value-add of Deno over Node, and this only increased my skepticism. Good luck making money, I guess.

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.

Re: The Deno Company

#24
post #13

Earlier quoted context omitted.

It is matter of time until they release a proprietary version which is better than the MIT version. Chrome vs chromium etc

The blog post specifically says that that will not happen

Most people will do things when in difficulties that they swear they would never do if asked while comfortable.

Re: The Deno Company

#25

> 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.…

It feels like the old IO.js vs node.js. I hope this time too the two ecosystems get merged, but this time it feels much harder to happen

Re: The Deno Company

#26

> 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.…

Yeah, no kidding.. shots fired...

As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression of that process..

Is Node really that bad compared to how JS/ES is innovated on in the browser?

Re: The Deno Company

#28

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…

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.

Re: The Deno Company

#29

> 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.…

I hear you, but I'll also give them some credit—you can't create anything worthwhile without a clear vision which basically requires an opinionated sense of purpose.
Post reply on HN