5 ms·

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 tog

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!

tylerchilds 5y ago
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/ https://www.libsdl.org/
- joaodasilvaz 5y ago
  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_mouse_button 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#window.addEventListener https://windowjs.org/doc/window#event-mousedown 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?
  - tylerchilds 5y ago
    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?
    - joaodasilvaz 5y ago
      Not right now. I've just filed an issue to track this: https://github.com/windowjs/windowjs/issues/19 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 https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API Does that make sense to you?
      - tylerchilds 5y ago
        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/ 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.
matthewfcarlson 5y ago
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.
- joaodasilvaz 5y ago
  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 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)
modeless 5y ago
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.md https://chromium.googlesource.com/angle/angle/+/main/README....
- joaodasilvaz 5y ago
  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.)
  - modeless 5y ago
    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).
    - klabb3 5y ago
      This is very useful info for everyone aspiring to do cross platform graphics, thanks a ton!
      - modeless 5y ago
        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.
cabalamat 5y ago
Will there be a TypeScript version?
- EMM_386 5y ago
  I'd be willing to help out putting together a TypeScript version of this depending on what the author wants to do.
  - joaodasilvaz 5y ago
    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/27 https://github.com/windowjs/windowjs/discussions/28 https://github.com/windowjs/windowjs/discussions/28
- joaodasilvaz 5y ago
  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/27 https://github.com/windowjs/windowjs/discussions/28 https://github.com/windowjs/windowjs/discussions/28 Does this cover what you had in mind? Are there better ways to support Typescript?

tylerchilds 5y ago

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/ https://www.libsdl.org/

joaodasilvaz 5y ago
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_mouse_button 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#window.addEventListener https://windowjs.org/doc/window#event-mousedown 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?
- tylerchilds 5y ago
  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?
  - joaodasilvaz 5y ago
    Not right now. I've just filed an issue to track this: https://github.com/windowjs/windowjs/issues/19 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 https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API Does that make sense to you?
    - tylerchilds 5y ago
      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/ 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.

matthewfcarlson 5y ago

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.

joaodasilvaz 5y ago
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 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)

modeless 5y ago

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.md https://chromium.googlesource.com/angle/angle/+/main/README....

joaodasilvaz 5y ago
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.)
- modeless 5y ago
  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).
  - klabb3 5y ago
    This is very useful info for everyone aspiring to do cross platform graphics, thanks a ton!
    - modeless 5y ago
      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.

cabalamat 5y ago

Will there be a TypeScript version?

EMM_386 5y ago
I'd be willing to help out putting together a TypeScript version of this depending on what the author wants to do.
- joaodasilvaz 5y ago
  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/27 https://github.com/windowjs/windowjs/discussions/28 https://github.com/windowjs/windowjs/discussions/28
joaodasilvaz 5y ago
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/27 https://github.com/windowjs/windowjs/discussions/28 https://github.com/windowjs/windowjs/discussions/28 Does this cover what you had in mind? Are there better ways to support Typescript?