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

Deno 1.9

deno.com

Post reply on HN
Print view View original

51–60 of 245 posts

Re: Deno 1.9

#51

Post by maga »

monocasa wrote: post #37
FractalHQ wrote: post #32

Earlier quoted context omitted.

What do you mean by reuse of web apis? I’m curious to read up on this feature.

Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.

This. I started tinkering with node shortly after I heard Ryan introduce it at JSConf EU, and it was a very different world, not much for Node to draw from on the browser side, no modules, no promises, not even TypedArrays IIRC.

Re: Deno 1.9

#52

Post by paxys »

rsp1984 wrote: post #39

I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.

In the simplest terms, it is meant to be a replacement for Node.js.

Re: Deno 1.9

#53

Post by _gjrn »

rsp1984 wrote: post #39

I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.

Deno has a couple of very good selling points, the main one is that it allows to use JS web browser API's in the CLI, this includes things that range from the Fetch API[1], up to WebGPU even! all in the command line interface.

Besides this, it uses the same module system as the browsers do. The JS module system is in my opinion very well designed and intuitive. No need for AMD or CommonJS or Node require's.

Other good things about Deno is that it includes a lot of goodies by default. In that single binary you get in your command line interface:

- A very very decent and fast bundler (bundling in JS is a mess, the Deno is straightforward and needs no config and no hacks, which, surprisingly is unique in the JS bundling scene)

- Testing library

- TypeScript support (for those that like it)

- Documentation generator

- Linter

- Syntax modifier (like prettier)

- Official VS Code plugin

Unlike Node, it uses Rust to bridge the gap between the JS engine and the OS, and leverages on a lot of very cool Rust libraries.

Re: Deno 1.9

#54

Post by brundolf »

tolmasky wrote: post #27
GenerocUsername wrote: post #2

I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake... Does anyone have a short anecdote why I might bother to invest in yet another JS framework?

It's really weird that most responses to you are that Deno isn't a framework, as if changing the category the thing is in would somehow magically remove your choice fatigue, especially considering that the most likely interpretation of your fatigue would make the distinction between runtime and framework fairly meaningless in this case: they are both for practical purposes a set of APIs you must learn on top of an ex…

Frameworks tend to dictate a certain way of doing things and introduce a pile of their own concepts and abstractions. Runtimes tend to be unopinionated. There's very little learning-fatigue around Deno, and there's almost no choice-fatigue since it's only the second mainstream (non-browser) JS runtime.

Re: Deno 1.9

#55

Post by paxys »

maga wrote: post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention).

Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold for?

Re: Deno 1.9

#56

Post by worik »

I have been programming computers since 1988, so I have seen a lot of things come and go. Not often has there been a just relationship between quality and popularity.

Never has that been so stark as with Node.js. So many mistakes, mistakes that have been made before. Such a mind boggling lack of purpose. There has never been a need for Node.js - except to play with the cool kids that programme Javascript on the client, server, on any &&^^*!! thing!

I still do not see the need for Javascript anywhere but in a browser, and with Webassembly, most of the impressive things done in the browser do not need Javascript any more.

So my preference is for Javascript to quietly die out in a dignified exit stage left. But I am not always completely correct. So if you must, then use Deno. Node.js is simply awful. Deno is only useless. A vast improvement.

Re: Deno 1.9

#57

Post by TechBro8615 »

tehbeard wrote: post #36
FractalHQ wrote: post #32

Earlier quoted context omitted.

What do you mean by reuse of web apis? I’m curious to read up on this feature.

Things like ArrayBuffer/view, fetch(...) and worker threads being the same spec/interfaces as the browser implementations rather than homegrown stuff like Buffer, child_process and any number of npm wrappers around the http module in node.

Hopefully the story is the same in five years after Deno and browsers have both had time to evolve. Are there plans in place for tracking future updates to Web APIs in Deno?

Re: Deno 1.9

#58

Post by tkzed49 »

maga wrote: post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?

Re: Deno 1.9

#59

Post by [deleted] »

tkzed49 wrote: post #58
maga wrote: post #20

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?

[deleted]

Re: Deno 1.9

#60

Post by tolmasky »

brundolf wrote: post #54
tolmasky wrote: post #27

Earlier quoted context omitted.

It's really weird that most responses to you are that Deno isn't a framework, as if changing the category the thing is in would somehow magically remove your choice fatigue, especially considering that the most likely interpretation of your fatigue would make the distinction between runtime and framework fairly meaningless in this case: they are both for practical purposes a set of APIs you must learn on top of an ex…

Frameworks tend to dictate a certain way of doing things and introduce a pile of their own concepts and abstractions. Runtimes tend to be unopinionated. There's very little learning-fatigue around Deno, and there's almost no choice-fatigue since it's only the second mainstream (non-browser) JS runtime.

Perhaps in the general case, but Deno is probably as opinionated or more so than your average JS framework choice on node.js. And certainly more opinionated than a more "neutral" runtime change like when Microsoft made the Chakra-backed node.js. For example, choosing to go with Deno cuts you out of much of the npm ecosystem (either due to the specific module model, or simply because the fundamental APIs are different, which is why express won't run "out of the box" on Deno -- there had to be ports of express and koa, etc.), which certainly is a bigger side-effect than switching from React to Vue. It also, to its credit, bets big on Typescript, a very opinionated decision (and I'd argue a good one too!). It bets big on async/await (which is still somewhat contentious in the node.js community, but luckily fading). In other words, there's not a lot of information conveyed from "it's a runtime not a framework," at least not in this case, aside from technical aspects. And again, I think it is precisely worth pitching it on its opinions, like the browser-compatible APIs, etc.
Post reply on HN