[themerone]

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.

[CyberDildonics]

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.

[ogoffart]

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)

[themerone]

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.

[moal]

Actually FLTK has full unicode support, right-to-left and bidi text. The limiting factor is the OS. For rtl and bidi, it depends on the OS. On linux for example, if FLTK is built with pango support, it'll support them just fine. On windows and macos, these work out of the box. As for accessibility, the only thing missing is screen reader support. Otherwise tab navigation, ime and other modalities are supported. FLTK's bindings in Rust provide an accesskit adapter which supports screen readers using the accesskit crate.

[pjmlp]

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

[wiseowise]

Nothing screams efficient use of time like learning programming languages for every little thing.

[pjmlp]

It isn't harder than learning new JavaScript frameworks every month.

[wiseowise]

Haha, JS framework meme.

[yellowapple]

> FLTK and other libraries cannot be used from JavaScript.

What's the obstacle to using it via FFI (which Deno seems to support)?

[ogoffart]

Someone has to first write bindings to the library using said FFI. This is not something most JavaScript dev can do. This has to be written by someone who knows C++ and JavaScript, and be good at both to understand all the details. (How the two interacts, how the lifetime of C++ objects play with the garbage collector, how do the inventloop mixes, ...) Writing such binding is a huge work as they the whole API need to be wrapped. And sometimes concept from the one language don't map easily in the other. (eg. templates)

And then you still have to ship an extra binary in addition to Deno itself.

[yellowapple]

Right, but that's still a far cry from being entirely unable to use them together. And as for the extra binary, that's hardly an obstacle if you already have to ship Deno itself anyway (and that ain't even considering the possibility of statically-linking it into a custom Deno binary).

[dwmbt]

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

[CyberDildonics]

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.