Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Deno Company

deno.com

Post reply on HN
Print view View original

71–80 of 446 posts

Re: The Deno Company

#71

Post by not_knuth »

sbarre wrote: post #28
not_knuth wrote: post #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…

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.

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

I still find it strange that there is no mention of it in the post...

Re: The Deno Company

#72

Post by eatonphil »

iends wrote: post #57
psim1 wrote: post #50

> Of these, the web browser scripting language (JavaScript) is the fastest, most popular, and the only one with an industrial standardization process. Most popular, I can agree. Fastest, & only one with industrial standardization process? Have they met Erlang? edit: you have to be kidding me, downvoted to oblivion for an honest observation. Sorry I hurt javascript's feelings.

Erlang is compiled to bytecode, right? So is it considered a scripting language?

I don't understand the connection being made between having a bytecode compiler and being a scripting language.

Re: The Deno Company

#73

Post by davnicwil »

What I find most exciting here is:

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

Re: The Deno Company

#74

Post by q-big »

bryanrasmussen wrote: post #62
q-big wrote: post #30

Earlier quoted context omitted.

Most people are pathological liars.

no they're not, a large number are - maybe 13% https://www.moneycontrol.com/news/science/13-people-are-path... , what it is is that most people just aren't that self-aware or have a better opinion of themselves than is perhaps warranted. So let me make clear here, if I ever start a company based on open source principles and it looks like I am going to get squeezed out of business by Amazon if I keep sticking to thos…

> So let me make clear here, if I ever start a company based on open source principles and it looks like I am going to get squeezed out of business by Amazon if I keep sticking to those principles I will probably abandon those principles (unless I'm already a billionaire and have something really cool I want to work on anyway) because damned if I would let Amazon beat me. The chance of my abandoning those principles will correlate closely to how bad my finances will be after losing out to Amazon.

If you want to keep this option open, then make no such promises or (perhaps better) formulate the promises in a way that is aligned to the options that you do want to keep open for the company.

Re: The Deno Company

#75

Post by mekkkkkk »

exhaze wrote: post #22
lucacasonato wrote: post #14

Earlier quoted context omitted.

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?

You'll lose your money. Deno will be free. DenoPro won't be though.

Re: The Deno Company

#76

Post by TechBro8615 »

kostarelo wrote: post #8

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

Ryan Dahl (author of the announcement post) is the creator of Node.js, so I think he's got a right to say these things! Also see "10 things I regret about Node" [0]

[0] https://www.youtube.com/watch?v=M3BM9TB-8yA

Re: The Deno Company

#77

Post by prussian »

beaconstudios wrote: post #33
sbarre wrote: post #26

Earlier quoted context omitted.

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?

Node is only just now getting around to adding promise based APIs to the core. Any time you interact with the Node core APIs you have to drop back to using callbacks - that's at least one area where Node is behind the times.

util.promisify() seems to work for many of the node stuff I use a lot, like pipeline(), readFile(), etc. Perhaps require('xyz/promises') is a newer development.

Re: The Deno Company

#78

Post by bob33212 »

franciscop wrote: post #42

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…

Any of the big 10 tech companies wouldn't mind owning this if it becomes the standard way of developing back end JS. It gives them influence and the ability to lock out competitors.

Re: The Deno Company

#80

Post by jen20 »

appleflaxen wrote: post #66

Deno is licensed as MIT. Awesome! But how will they prevent from being freeloaded? My sense is that GPL3 gets a ton of criticism on HN, but isn't it the perfect defense against freeloaders? * 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. I don't understand why this option isn't used more by open s…

> I don't understand why this option isn't used more by open source projects that want to be able to fund themselves.

One possible reason is that such dual licensing requires copyright assignment from external contributors.

Post reply on HN