Hacker News Reader

Comment by joaodasilvaz | Hacker News Reader

Hi HN, author of windowjs here.

I was planning to have the project in a more complete state before announcing to HN :-)

It was mostly a fun project to put together v8, GLFW and Skia, and I hope others find it useful and fun to work on too.

If you find this interesting then consider getting in touch via GitHub Discussions or the mailing list and helping out with the next features: WebGL 2 API, networking (fetch) API, sound, etc.

I don't have much experience collaborating in opensource projects so any feedback is very welcome. Thanks for having a look!

View on HN

You may already know this, but for WebGL you should use ANGLE. It's what the browsers mostly use and will guarantee compatibility across platforms. Trying to implement the WebGL API over desktop GL yourself will be a never ending black hole of issues. https://chromium.googlesource.com/angle/angle/+/main/README....

Thanks for the hint!

Do you happen to be familiar with ANGLE? What happens if I just expose GLES 3.0 bindings as WebGL2 based on the native drivers on each platform?

(my earlier understanding was that ANGLE was a WebGL-to-Direct3D translation layer, for compat on Windows.)

Most desktop platforms unfortunately don't provide a native GLES driver, so you'd have to translate desktop GL to GLES. This is harder than it sounds, if you care about getting everything right. ANGLE handles that for you. Additionally it contains dozens of workarounds for serious driver issues on various platforms. And implementations of WebGL extensions that differ from GL/GLES extensions.

In addition to all that, it does let you use DirectX on Windows instead of GL (and Metal on Mac and Vulkan wherever). The reason you want that is that many Windows PCs do not have a GL driver installed. Microsoft does not ship one, so if the OEM didn't install one and the user didn't install one then it simply doesn't exist. And even when the GL driver is installed, it is often buggier than the DirectX driver. Similarly on Mac, GL is buggier than Metal (and officially deprecated).

> Most desktop platforms unfortunately don't provide a native GLES driver, so you'd have to translate desktop GL to GLES.

This is somewhat less true than it used to be since one of the required features of OpenGL 4.3 is GLES 3.0 compatibility. Unfortunately, Mac OS is stuck on GL 4.1 forever (at least until they drop support completely anyway) and the other points you bring up are quite valid.

This is very useful info for everyone aspiring to do cross platform graphics, thanks a ton!

For new development in native cross platform graphics I would recommend Dawn or wgpu-native as a base instead of GL. That will get you excellent portability with a modern style of API.

Could you say more about this? I'm currently trying to learn in this space, and it was my understanding that Skia already uses or can use ANGEL.

Very cool! I'm a web dev and I've wanted to get into game dev. From my cursory glance, this seems like exactly what I'd like to build on top of: just the essentials for a performant interactive application.

My one question: Would it be possible to integrate with SDL2? https://www.libsdl.org/

libsdl and GLFW are very similar! I ended up using GLFW because it's closer to what I wanted to do with Skia and WebGL, and I didn't need the 2D functionality of SDL.

Note that Window.js does not expose GLFW directly; it exposes APIs that are more similar to the web, for familiarity to web devs.

For example, GLFW has this for mouse input:

https://www.glfw.org/docs/latest/input_guide.html#input_mous...

But Window.js wraps that in window.addEventListener and "mousedown" events:

https://windowjs.org/doc/window#window.addEventListener https://windowjs.org/doc/window#event-mousedown

If you give it a try to build a game then keep in mind that it doesn't have a sound API yet, though that's part of the future plans.

Finally, is there something specific in libsdl that you'd like to have and Window.js doesn't support?

Awesome! I hadn't heard of GLFW before. My main use case is wanting gamepad support which it looks like GLFW has.

From all my user research, it looks like nothing beats up, down, left, right, confirmation and cancellation actions, so that's all I really need.

Are those gamepad events accessible through addEventListener?

Not right now. I've just filed an issue to track this:

https://github.com/windowjs/windowjs/issues/19

Window.js replicates web APIs where it makes sense, so I'd look into duplicating the Gamepad API:

https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API

Does that make sense to you?

100%. Sticking close to web APIs will guarantee the longest shelf life of code written against it. I'm a big fan of Deno rather than Node for the same reasons.

Thanks for building a cool project, I'll definitely be tracking along.

I've been working on something that should be fairly compatible, but I'll need to do a little tweaking on my end for windowjs: https://thelanding.page/tag/

It's basically a reactive client-side library that aims to decouple the necessary UI things like state management and event delegation from the DOM. It's tiny (~300 lines of code iirc). No external dependencies besides a lazy loaded Virtual DOM library that wouldn't be needed in a windowjs environment.

instead of an html function that renders when state changes, i can create a function that can draw on the windowjs canvas, probably on requestAnimationFrame.

I’m curious what the resulting package would look like. Like you’re including the v8 runtime but not chrome itself (A la electron). I suspect it would be smaller but no idea how much smaller.

It's quite a bit smaller though I'm not familiar with how big Electron is nowadays.

The largest part is, by far, v8; I think there's room to remove unused code there.

You can see the size of the binary in the GitHub Actions builds:

https://github.com/windowjs/windowjs/actions

Each build workflow has a "Binary size" step at the end, that outputs the binary size, size after stripping, and size after using UPX.

Here's what the latest build got:

* Windows: 6,639,616 bytes (19,523,072 before UPX)

* macOS: 8,196,112 bytes (23,431,800 before UPX)

* Linux: 8,186,668 bytes (28,679,960 before UPX and stripping, 22,346,264 bytes after stripping)

Will there be a TypeScript version?

I had two ideas for Typescript in mind:

1. provide type declarations for the Window.js APIs, and

2. integrate with the Typescript compiler during development (e.g. F5 to reload, run typescript sources "directly", show compiler errors in the console / main window, etc.)

I've just started these discussion on GitHub, please share your thoughts:

https://github.com/windowjs/windowjs/discussions/27

https://github.com/windowjs/windowjs/discussions/28

Does this cover what you had in mind? Are there better ways to support Typescript?

I'd be willing to help out putting together a TypeScript version of this depending on what the author wants to do.

Please do! I've just started discussions to figure out how to do this, please share your thoughts:

https://github.com/windowjs/windowjs/discussions/27

https://github.com/windowjs/windowjs/discussions/28

Reply on news.ycombinator.com