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

Deno in 2023

deno.com

Post reply on HN
Print view View original

201–210 of 235 posts

Re: Deno in 2023

#201

Post by bheadmaster »

meowtimemania wrote: post #184
bheadmaster wrote: post #51

It is interesting to me that none of the new NodeJS alternatives support multithreading. Why is that? Is it just a side-effect of using V8 engine for the heavy lifting, or is it some part of the ECMAScript specification which forbids multithreaded implementations of the language?

In what cases would you want multi-threading in javascript? I feel like most performance intensive nodejs modules drop down to c++ where real concurrency already exists. (e.g. sharp - https://sharp.pixelplumbing.com/api-utility#concurrency )

> In what cases would you want multi-threading in javascript?

In all of them - JavaScript is mostly used for asynchronous programs, which are easily parallelizable. There's no reason not to want multi-threading.

Re: Deno in 2023

#202

Post by pjmlp »

ogoffart wrote: post #126
CyberDildonics wrote: post #119

Earlier quoted context omitted.

What does it have to do with Deno and why do any of that to draw boxes and text on the screen? FLTK could do GUIs that took almost no CPU power starting with 100KB binaries 30 years ago. People doing hardware accelerated GUIs have been using openGL for almost as long. This doesn't need to be a science project or a rabbit hole, drawing a GUI quickly is well worn territory.

FLTK and other libraries cannot be used from JavaScript. JavaScript is one of the most popular programming language. But a JavaScript dev who needs to make a desktop GUI will usually need to use Electron to bring up a browser for the GUI. This means actually two JavaScript engine (Node and Chromium) The reason it has to do with Deno is that you need a JavaScript/TypeScript runtime. But you may not need a browser. So…

Alternatively, they could maybe, just maybe, learn another programming language, but that is asking too much in today's culture it seems.

Re: Deno in 2023

#203

Post by whstl »

pjmlp wrote: post #198
whstl wrote: post #178

Earlier quoted context omitted.

> without having to figure out if a type analysis bug is from me, or the tool Deno uses regular Typescript for static type checking, it's just built-in. Bun also doesn't do type checking by itself, they recommend using tsc [2]. [1] https://docs.deno.com/runtime/manual/advanced/typescript/faq... [2] https://bun.sh/docs/runtime/typescript#running-ts-files

Until they bundle Microsoft's compiler, it isn't the same thing. It is like tracking down if a C bug in GCC relates to developer, or GCC understanding of ISO C documentation. Just this alone proves it isn't the same thing, => Deno tries to keep up to date with general releases of TypeScript, providing them in the next patch or minor release of Deno.

The “Microsoft compiler” is exactly what tsc is, and is exactly what is bundled with Deno. Sorry if that wasn't clear.

Re: Deno in 2023

#204

Post by maeil »

rtcode_io wrote: post #3

Deno Deploy dropped from 35 GCP regions to just 12: https://news.ycombinator.com/item?id=39127598

If anyone from Supabase is reading here, your main marketing page still says Edge Functions run on 29 regions. Since they run off of Deno Deploy, it seems like this needs updating.

Re: Deno in 2023

#205

Post by cryptonym »

Kinrany wrote: post #107
cryptonym wrote: post #100

Earlier quoted context omitted.

NextJS doesn't have an incentive to run on anything else than Vercel. I wouldn't blame this on Deno.

I wonder if Vercel might eventually choose to run on Deno

Even if Vercel was built on Deno, I don't see them open sourcing that. Everything that manages distributed cache, edge rendering... They'd probably rather keep that closed and available only for Vercel customers.

Re: Deno in 2023

#206

Post by vwkd »

throwitaway1123 wrote: post #59
olestr wrote: post #6

You can join the waitlist in the sneak peak of JSR linked in the end of the article: https://jsr.io/waitlist I'm curious on what the Deno team is building here.

Like others have said, it's going to be a new package registry. It was unofficially announced at SeattleJS Conf 2023: https://www.youtube.com/watch?v=Dkqs8Mcxbvo&t=424s

Here's the specific talk https://youtube.com/watch?t=822&v=dipwQfcV0AU (CascadiaJS channel) or https://youtube.com/watch?t=822&v=5DX49vzLfqw (Deno channel)

Re: Deno in 2023

#207

Post by ecmascript »

atraac wrote: post #75
ecmascript wrote: post #70

Earlier quoted context omitted.

When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript. Most of it is the international libraries anyway so. I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.

So the fact that everything around is poorly made, forbids him from whining that a certain solution is as bad as everything else? Shouldn't we criticize and point out stuff that is bad, no matter whether it's as bad as something else? It's because of attitude like yours that we get 15mb of javascript on every website, 500gb games and UIs that take seconds to load.

Well my point is that it isn't that bad and there's a reason for it being ~100mb. You can throw out the Intl stuff and remove a large portion of that for example.

Re: Deno in 2023

#208

Post by ecmascript »

konart wrote: post #133
ecmascript wrote: post #70

Earlier quoted context omitted.

When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript. Most of it is the international libraries anyway so. I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.

You download it to you game rig, not some cloud solution with limited resources to be paid for. Plus you may want to have more than one instance of service running.

Pretty much all cloud services offers way more than that for free and besides, maybe don't use javascript if 100mb is such big of a deal?

Re: Deno in 2023

#209

Post by ecmascript »

surajrmal wrote: post #96
ecmascript wrote: post #70

Earlier quoted context omitted.

When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript. Most of it is the international libraries anyway so. I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.

This is whataboutism. Different sizes are acceptable for different people based on context. I worry about 10s of kilobytes for things I work on for instance.

Yes but there is a reason for it being 100mb. You get a self-contained app where you can get to write in javascript. You don't have to spend 100x the time in order to get the same app working in Rust.

If size is such a big deal, then don't use Deno, Node or Bun.

My issue is that most people that are working in restricted environments would never touch javascript since it's not well suited for those kinds of environments. People that complain tend to be haters that just want something to hate upon.

It used to be about php, now it's about javascript.

Re: Deno in 2023

#210

Post by culi »

niam wrote: post #112
culi wrote: post #86

Earlier quoted context omitted.

Pick your horse to bet on. They both have great teams behind them. Bun (written in Zig) claims higher performance. It looks promising but independent tests have yet to validate these claims. They also kinda have different goals. Bun seeks to be more of a drop-in replacement from Node whereas Deno, being spearheaded by the same person who made Node, seeks to move the industry forward and fix mistakes Deno made. Howeve…

> fix mistakes Deno made You probably meant "node" here.

yup! too late to edit
Post reply on HN