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

31–40 of 446 posts

Re: The Deno Company

#31

Post by yulaow »

gorjusborg wrote: post #23
oauea wrote: 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.

Honestly a standard library was needed since a decade but... I would have preferred a coordinated effort between browsers and node/deno. At this point even if just the browsers and deno get two different stdlib we risk _a_lot_ of useless fragmentation and headaches.

Re: The Deno Company

#32

Post by why_Mr_Anderson »

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…

Javascript embedded scripting for databases .../shivers

Re: The Deno Company

#33

Post by beaconstudios »

sbarre wrote: post #26
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.…

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.

Re: The Deno Company

#34

Post by sbarre »

elisee wrote: post #15

Happy to see Deno get some financial backing! 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…

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?

Re: The Deno Company

#35

Post by sbarre »

yulaow wrote: post #25
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.…

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

Wasn't that more of an ideological than technical split?

Deno is more of an ecosystem reboot than a fork, I would think.

Re: The Deno Company

#37

Post by hobofan »

gorjusborg wrote: post #23
oauea wrote: 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.

> a standard library (thank goodness!)

Then what are all these modules, if not a standard library? https://nodejs.org/api

Re: The Deno Company

#38

Post by yulaow »

sbarre wrote: post #35
yulaow wrote: post #25

Earlier quoted context omitted.

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

Wasn't that more of an ideological than technical split? Deno is more of an ecosystem reboot than a fork, I would think.

Yeah, with the use of "it feels" this time I was literally trying to express the feeling of "oh no, another big divergence in js" like it felt at the time (even if it was indeed ad "ideological split" as you say, I remember clearly at the time a lot of blog posts about how it meant that in the long run we COULD have different ways of doing things / calling apis / build frameworks / etc... )

Re: The Deno Company

#39

Post by sbarre »

why_Mr_Anderson wrote: post #32
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…

Javascript embedded scripting for databases .../shivers

Why?

I think the point being made here is that it will be easier to create purpose-built runtimes that only provide needed bindings, making them more secure and possibly also more performant?

JS/TS as languages are here to stay, so let's give them the best possible ecosystem.

Re: The Deno Company

#40

Post by FunnyLookinHat »

gorjusborg wrote: post #23
oauea wrote: 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.

The built-in Typescript support is amazing, but the selling feature for me was the ability to generate static binaries. Shipping is much easier when your built process can produce a single output!
Post reply on HN