joaodasilvaz

Not quite, as this is a native program and not a Javascript module.

Window.js is like Node itself, but has different APIs. The main difference is that it gives you a desktop window and the Canvas 2D API, and doesn't have any of Node's networking APIs.

Other differences to Node:

* every source is imported to Window.js as an ES6 module.

* Window.js does not support NPM and doesn't aim to.

* Node uses callbacks for async APIs, Window.js uses Promises

* Node is widely tested and used, Window.js is quite new and experimental :-)

Other projects have built bindings for GLFW for Node. Have a look at the GLFW documentation and search for "node":

https://www.glfw.org/community.html#bindings

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?

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

What kind of APIs do you have in mind?

Ideally yes, Window.js should make it possible (and easy!) to build fully accessible programs. I don't have much experience in this area though, so I'd have to look for help building this :-)

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?

From a quick look at plask.org:

* seems like Plask is only for macOS (Window.js also supports Windows and Linux)

* Plask exposes the Skia APIs directly to Javascript; Window.js exposes a <canvas>-alike API instead (but also based on Skia)

* Plask supports video playback with AVPlayer; Window.js doesn't have video support (for now :-)

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

Note that Chrome also builds on Skia, via the Blink rendering engine. So Skia is very well aligned with the needs of the Canvas API.

As for performance, Window.js has a bit less overhead since it doesn't have a DOM and doesn't implement web security.

On the other hand, Chrome is widely used and has a super talented team that knows systems programming, GPU programming, etc in a lot of depth and have spent a ton of time optimizing web APIs. So I wouldn't be surprised if Chrome and Electron have better performance in benchmarks -- this is definitely something to measure!

As an example, this p5js example runs very slowly on Window.js:

https://p5js.org/examples/simulate-smokeparticles.html

The reason is that it's doing something like a getPixel(x, y) call in a loop, which Chrome somehow optimizes; in Window.js this is going to be a roundtrip to the GPU for each pixel, which is extremely expensive.

(IMO, the right way to implement getPixel based on the Canvas API would be to read all the pixels once via canvas.getImageData)

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)

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?

Three.js should load and run as long as its usage of window, document, etc works as it expects. So the plan is to have a small loader that prepares the environment that Three.js expects before loading it.

This has already been done for Processing/p5.js:

https://windowjs.org/about/processing

After the initial load, all of the p5.js APIs make CanvasRendering2DContext calls, which Window.js implements natively.

Almost all of the p5.js examples work with this approach, except those that use DOM elements like buttons and sliders. Those elements could also be faked, with some patience :-)

I think it's pretty cool that p5.js scripts can run on a desktop window this way, outside of the browser!

As an aside, I also originally intended to implement an HTML renderer on something like Window.js, and make a "browser from scratch" based on it. Maybe for another day...

Electron is a lot more feature-complete and mature, and that's what should be used for any serious projects indeed :-)

Window.js is a subset; it doesn't include the DOM nor the CSS APIs, nor a lot of web APIs.

Window.js is a tool I wish I had for exploratory 2D (and 3D) programming, without having to install multiple tools, SDKs and runtimes, and without the restrictions that web pages have when it comes to desktop applications. I wanted something like Processing but with more control, or like <canvas> but without all the browser cruft around it, and in a native window.

I think it could be a very useful tool to learn WebGL via webglfundamental.org, for example, and having something that runs on the desktop quickly.

A goal of Window.js is to eventually run Processing (p5.js), Pixi.js, Phaser and Threejs programs, as long as they don't use the DOM too much.

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!