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

111–120 of 235 posts

Re: Deno in 2023

#111

Post by mattferderer »

Quothling wrote: post #87
pachico wrote: post #68

I'm not a big fan of JavaScript but I admit I stayed away from it because I dislike nodejs and npm terribly. I was forced to start coding again in JS some weeks ago and I wanted to try Deno. I must say it's been a very smooth and fast experience so far. Very well done!

We use Typescript for virtually everything at my place of work. Not so much because it's a great language for the a lot of the backend, and we do use some c++ for bottlenecks, but because it's so much more productive to use a single language when you're a small team. Not only can everyone help each other, we can also share resources between the front and the back end, and we've several in-house libraries to help us w…

Curious to hear your opinion on ODATA after using it on your projects. Pros, cons, anything.

Re: Deno in 2023

#112

Post by niam »

culi wrote: post #86
andsoitis wrote: post #85

what is a great comparison between Bun, Deno, and Node.js? Why should I choose Bun over Deno or vice versa?

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.

Re: Deno in 2023

#113

Post by crowlKats »

ogoffart wrote: post #42

I'm interrested in the WebGPU feature. With Slint [1] we're working on a framework which allow to make a desktop GUI in Javascript/Typescript, without bringing a browser/webview. Currently, we do it by using binaries through napi-rs so we can bring in a window using the platform native API. And then we do some hack to merge the event loops. But if Deno supports bringing up a window directly, this means we can just sh…

it actually does: its not part of the WebGPU API directly itself, but its separate: https://deno.com/blog/v1.40#webgpu-windowing--bring-your-own...

Re: Deno in 2023

#114

Post by mborch »

fabiospampinato wrote: post #49
mborch wrote: post #47

> A program run with Deno has no file, network, or environment access unless explicitly enabled. You can do this using containerization technology, no need to invent this per language runtime.

Yes but now in non-linux systems you have the pretty large overhead of that.

On MacOS, you have built-in sandboxing via "sandbox-exec" which shouldn't incur any noticeable overhead. It's used by Chrome, Bazel, etc.

Not sure what's available on Windows.

Re: Deno in 2023

#115

Post by ijustlovemath »

dns_snek wrote: post #93
ijustlovemath wrote: post #54

Earlier quoted context omitted.

I'm not sure what your requirements are, but I've had a good amount of success with converting Node.js libraries to native libraries by embedding a CommonJS module into the binary, then running the actual code through QuickJS. Much smaller binaries. If you really are pressed for space, you could use upx, or store 7z compressed code and embed the 7z library to decompress before passing it along to QuickJS. Here's a pr…

Isn't QuickJS order(s) of magnitude slower than V8? That doesn't seem like a practical tradeoff to make outside of embedded.

Like I said, I wasn't sure of their requirements. I can say QuickJS is orders of magnitude easier to embed and understand than V8, which is why I adopted it for my use case.

Re: Deno in 2023

#116

Post by Leokuma »

andsoitis wrote: post #85

what is a great comparison between Bun, Deno, and Node.js? Why should I choose Bun over Deno or vice versa?

Deno has built-in support for TypeScript.

Deno has members in Ecma TC39, so they take part in the development and standardization of JS.

Deno brings a new mentality to development focused on simplifying things, whereas Bun aims to be an improved Node.

Deno aligns with web APIs: you can use the same APIs in the browser and in Deno. Many packages work in both platforms. Deno is even in the compatibility tables in MDN.

Deno simplifies DX greatly. It's very easy to work with Deno. Easy to install things and set up a project, easy to deploy, no config files etc.

Deno is written in Rust, which allows them to move faster and more safely. Contributing to and extending Deno is a breeze. You can add Rust crates to the runtime and use them from JS.

I feel like the Bun team has been too pressured by executives and marketing. They announced 1.0 when Bun was clearly not stable enough, giving lots of segfaults. Even their readme had a huge statement right in the beginning saying that Bun was not production ready yet, despite 1.0 being hyped all over the place.

Re: Deno in 2023

#117

Post by fshr »

xtreme wrote: post #103
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.

There are size limits when deploying on serverless or edge infrastructure so developers have to care about that. The providers also typically charge by compute seconds * memory consumed so a larger executable costs real money as well.

The compiled option isn’t intended for serverless or edge uses, you just deploy the source files and the platform takes over.

Re: Deno in 2023

#118

Post by Leokuma »

andsoitis wrote: post #102
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…

> Deno, being spearheaded by the same person who made Node, seeks to move the industry forward and fix mistakes Deno (I assume you mean Node.js) made. If they aren't able to evolve Node.js to overcome the mistakes (e.g. because they're technical in nature, or momentum of install base, or they don't have the leadership ability), I am worried that they might repeat the same pattern with Deno, since it isn't possible to…

The main difference is that Deno was thought to evolve hand in hand with browsers since the beginning. Node followed its own way and fragmented the JS ecosystem. It got to a point where it was basically impossible to realign Node's direction without breaking everyone's codebase. Mistakes will be made in Deno, but the direction of the project now takes into account the ecosystem as a whole.

Re: Deno in 2023

#119

Post by CyberDildonics »

themerone wrote: post #95
CyberDildonics wrote: post #84

Earlier quoted context omitted.

This doesn't really seem related, it seems like you're saying "maybe we will use this, here is a link to our commercial GUI library". Also why would you want to make a GUI even more bloated by integrating a browser to get webgpu and webasm (and why webgpu instead of just webGL?). That might be easy for library makers but why would someone want a giant library to make a GUI when they already have electron if they don'…

They are talking about using webgpu for rendering to screen without going through a browser. Webgpu and wasm without a web browser would be a nice way to distribute portable sandboxed code. The reason for Webgpu is that it it has semantics closer to modern modern apis like Metal or Direct X.

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.

Post reply on HN