Live data from Hacker News

Deno in 2023

deno.com

121–130 of 235 posts

Re: Deno in 2023

#121

I know it sound silly but I love the aesthetic behind Deno's brand, it makes me want to use it for one project or another. Node.js is so old now. it's reliable but boring. I want something new, bold, and daring. Node.js is not it, although it was ~11 years ago. It's interesting how our views change.

I like it too . I even liked the old website better than the current one. It was more colorful and fancy.

Brand reflects a project's philosphy. Deno is thought to be easy and simple, and the "childish" branding reflects that.

So you may not be wrong at all in your criteria. Subjective human communication can be more effective than objective communication sometimes ;). It just works at a different level.

Re: Deno in 2023

#122

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…

I poked around your website because I was curious if the name was a band reference. Love the Spiderland photo of the staff!

Re: Deno in 2023

#123

Earlier quoted context omitted.

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.

edit: i will not be taking this comment in good faith, i had a look through parents comments and it looks like they simply do not agree with Slint's approach to GUI programming: https://news.ycombinator.com/item?id=39223499#39229382

> What does it have to do with Deno

can we at least try to give people the benefit of the doubt instead of pretending like everyone is out to get you? if you read the change-log, it spells it out well:

> Our goal is to provide a windowing solution for WebGPU without linking to native windowing systems like X11

> This is a low level API that can be used by FFI windowing libraries like sdl2, glfw, raylib, winit and more to create a WebGPU surface using native window and display handles.

do you get it yet?

> 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.

i suggest talking to other graphics professionals to get a better understanding of why opengl is not _the_ solution. for a tldr[0]:

> regular OpenGL on desktops had Problems. So the browser people eventually realized that if you wanted to ship an OpenGL compatibility layer on Windows, it was actually easier to write an OpenGL emulator in DirectX than it was to use OpenGL directly and have to negotiate the various incompatibilities between OpenGL implementations of different video card drivers. The browser people also realized that if slight compatibility differences between different OpenGL drivers was hell, slight incompatibility differences between four different browsers times three OSes times different graphics card drivers would be the worst thing ever. From what I can only assume was desperation, the most successful example I've ever seen of true cross-company open source collaboration emerged: ANGLE, a BSD-licensed OpenGL emulator originally written by Google but with honest-to-goodness contributions from both Firefox and Apple, which is used for WebGL support in literally every web browser.

also, openGL is deprecated on macOS.

[0]: https://cohost.org/mcc/post/1406157-i-want-to-talk-about-web...

Re: Deno in 2023

#124
post #117
post #103

Earlier quoted context omitted.

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.

Some serverless use cases work like you say, but Docker-based options such as AWS ECS, Docker-based Lambda functions, or Kubernetes would all commonly make use of compiled options

Re: Deno in 2023

#125
post #97

Earlier quoted context omitted.

For starters Deno is much, much faster in both installation and runtime. I am not sure if I'll have the chance to exploit other features it has (besides the built-in dotenv support). Not so many years ago, even installing npm wasn't straight forward.

How is it faster in runtime? Isn't it all V8 at the end?

It's not the JavaScript runtime that's faster but the built-in APIs. Supposedly (I haven't tested this myself), Deno has faster implementations of many Node.js APIs, which I have seen reflected in benchmarks for things like throughput in an HTTP server.

Re: Deno in 2023

#126

Earlier quoted context omitted.

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.

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 you can develop your application in JavaScript using a framework that doesn't use the DOM but show a native window instead.

This is more lightweight and more secure (no risks of HTML injection and the browser is a big attack vector)

Re: Deno in 2023

#127
post #123

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.

edit: i will not be taking this comment in good faith, i had a look through parents comments and it looks like they simply do not agree with Slint's approach to GUI programming: https://news.ycombinator.com/item?id=39223499#39229382 > What does it have to do with Deno can we at least try to give people the benefit of the doubt instead of pretending like everyone is out to get you? if you read the change-log, it spell…

it looks like they simply do not agree with Slint's approach to GUI programming

My comment here is explaining exactly why I don't agree, no digging required.

Your quote is also about browsers implementing the webGL API, it has nothing to do with using basic openGL for GUIs, which again, is not required, because CPUs have been rendering GUIs for decades.

Re: Deno in 2023

#128

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…

FLTK is permanently stuck in the 90s. It doesn't have full unicode support, right-to-left & bidirectional text, and doesn't support accessibility tools.

Not to mention that development has been stagnant for 15 years since it's flagship application (Nuke), was ported to QT.

Re: Deno in 2023

#129

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?

Multithreading is achieved through workers and the event based architecture, it's not the same, but we should rather discuss the pros/cons of it.

Pros: Vertical scalability.

Cons: All your async code becomes full of data races.

I suppose adding multithreading to the Node ecosystem would be as hard (if not harder) than removing GIL from Python. At least Python has locking primitives. Node, as far as I know, has none.

Re: Deno in 2023

#130

Earlier quoted context omitted.

How is it faster in runtime? Isn't it all V8 at the end?

It's not the JavaScript runtime that's faster but the built-in APIs. Supposedly (I haven't tested this myself), Deno has faster implementations of many Node.js APIs, which I have seen reflected in benchmarks for things like throughput in an HTTP server.

Same with bun, it looks like node is leaving some performance on the table (maybe for backward compatibility or maybe because nobody bothered to improve it)
Post reply on HN