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

31–40 of 245 posts

Re: Deno 1.9

#31

Post by croes »

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…

Maybe because there are way more JS frameworks than runtimes. It feels like dozens of frameworks pop up every day.

Re: Deno 1.9

#32

Post by FractalHQ »

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.

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

Re: Deno 1.9

#33

Post by croes »

konart wrote: post #13
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?

Should we tell him that this is not a framework? Anyone?

No.

Re: Deno 1.9

#36

Post by tehbeard »

FractalHQ wrote: post #32
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.

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.

Re: Deno 1.9

#37

Post by monocasa »

FractalHQ wrote: post #32
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.

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.

Re: Deno 1.9

#38

Post by tengbretson »

FractalHQ wrote: post #32
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.

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

Things like using UInt8Arrays instead of Node's homemade Buffer class, fetch, using WHATWG's implementation of Streams, Blob, WebWorker, etc.

Re: Deno 1.9

#39

Post by rsp1984 »

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.

Re: Deno 1.9

#40

Post by paxys »

lucacasonato wrote: post #28
brundolf wrote: post #22

Earlier quoted context omitted.

Thanks- I should probably actually file bug reports :) I am curious though: why roll your own? It seems like the only real differences are a) URLs/file extensions in the module names, and b) some type declarations for the system APIs (which I'd think just come down to some .d.ts files, not custom LSP logic). Microsoft's TypeScript language server is a wonder of engineering, and I doubt any small independent team woul…

TypeScript does not actually have a native language server. TSC is just directly shoehorned into VS Code. It is very difficult to extend (we tried with the 1.x and 2.x branch of our extension). We needed to do a lot of trickery to get TSC to do what we want, and even then it would not always work. That solution also only worked on VS Code. Our new LSP works on all editors with LSP support. We are hoping that in the c…

This is only partially true. TypeScript does have tsserver built in, which is where the language server design originated from (just with a slightly different API). The VS Code TypeScript integration is a layer around that, not a custom implementation. There are also a couple other TypeScript language servers out there (which again simply wrap tsserver and translate the APIs) which work great.
Post reply on HN