4 ms·

The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a

The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a faster language in a desktop environment are lost on most web developers, I think, simply because most of them don't actually do any desktop or graphics API work. They simply wouldn't know. Also UI compositors are not a solved space. If they were, people would absolutely not being using Electron. But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they?

rahkiin 3y ago
Please, if someone has just that, let me know. It would be excellent for games. I do believe there are implementations of flexbox in rust.
- andrewmcwatters 3y ago
  Yeah, it's a problem space I'd like to try to tackle again some day. Yoga et al. aren't enough. I think people are dying for a web-based compositor in other host language environments, but don't know how to elucidate this concept because they don't know anything else.
- fit2rule 3y ago
  [dead]
suby 3y ago
Right. The point of wanting to avoid redraws is for performance. Sure, you avoid redundant redraws in web browsers, but it defeats the point because the browser is slow compared to native, even with those avoided redraws.
text0404 3y ago
i mean, people have done some pretty impressive stuff with React and threejs: https://codesandbox.io/s/i2160 https://codesandbox.io/s/i2160. i work in FE with 3D engineers with graphics and game development backgrounds who are at the forefront of the field, working on browser-based applications. we tried desktop apps and found the browser to be a better balance for performance, compatibility, and desired features (data streaming, webgl, React for turning incredibly complex state into 3D/UI) without being too low level. we can also deploy updates easily, without excessive build times, with little to no interruption to our users. edit: another neat one: https://deck.gl/examples/trips-layer https://deck.gl/examples/trips-layer
chrismorgan 3y ago
> But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they? There’s actually quite a lot of interesting work going on in that general space, has been in various forms for some years. A couple that immediately spring to mind: • Azul <https://azul.rs/ https://azul.rs/> builds on WebRender, as used in Firefox. I haven’t looked at it for a few years, but it looks to have grown quite interesting now. • Blitz <https://github.com/DioxusLabs/blitz https://github.com/DioxusLabs/blitz> is based on from-scratch implementations of CSS layout and rendering, and wgpu rendering. It’s not usable yet, but is a very interesting concept. If one happens to be familiar with React Native: it’s kinda like that, or React Native Web.
- ricardobayes 3y ago
  React Native Web is a bit like scratching your left ear with your right arm :)
  - chrismorgan 3y ago
    Actually, forget the React Native Web thing, I think I was mixing it up with something from a few years back that was more the other way round (running React web stuff on React Native, not running React Native on web). React Native Web… eh, it has a potential place. Maybe like scratching your left ear with your right arm, because your left arm is partially paralysed, or something!
mike_hearn 3y ago
Technically, you could ship a minimal link of a JVM and use JavaFX. It has a compositor, a CSS 2.1 rasterizer, layout managers and renders to D3D or OpenGL surfaces. I think they're adding Metal at the moment. The weakness is interop with C/C++. There's a new Java FFI in the works that makes that a lot better by auto-generating bindings from header files and avoiding JNI, but it hasn't shipped as stable yet. It's usable. You just have to accept that the API might change a bit. You can also compile the whole thing to a native library that doesn't use a typical JVM at all. Memory usage and startup time is a lot better if you do that. You can also expose functions natively to C, or bind to C natively, using a different approach. If I were to do use that approach I'd write a generic binding layer that lets you connect JavaFX observables to their C++ or Rust-side data structures. FX has an architecture that's very based on observable variables, which all have a uniform API, so if you can control those from the native side then you can do anything. Either updating state objects that are then in turn connected to UI objects, or directly updating UI.

rahkiin 3y ago

Please, if someone has just that, let me know. It would be excellent for games. I do believe there are implementations of flexbox in rust.

andrewmcwatters 3y ago
Yeah, it's a problem space I'd like to try to tackle again some day. Yoga et al. aren't enough. I think people are dying for a web-based compositor in other host language environments, but don't know how to elucidate this concept because they don't know anything else.
fit2rule 3y ago
[dead]

suby 3y ago

Right. The point of wanting to avoid redraws is for performance. Sure, you avoid redundant redraws in web browsers, but it defeats the point because the browser is slow compared to native, even with those avoided redraws.

text0404 3y ago

i mean, people have done some pretty impressive stuff with React and threejs: https://codesandbox.io/s/i2160 https://codesandbox.io/s/i2160. i work in FE with 3D engineers with graphics and game development backgrounds who are at the forefront of the field, working on browser-based applications. we tried desktop apps and found the browser to be a better balance for performance, compatibility, and desired features (data streaming, webgl, React for turning incredibly complex state into 3D/UI) without being too low level. we can also deploy updates easily, without excessive build times, with little to no interruption to our users. edit: another neat one: https://deck.gl/examples/trips-layer https://deck.gl/examples/trips-layer

chrismorgan 3y ago

> But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they? There’s actually quite a lot of interesting work going on in that general space, has been in various forms for some years. A couple that immediately spring to mind: • Azul <https://azul.rs/ https://azul.rs/> builds on WebRender, as used in Firefox. I haven’t looked at it for a few years, but it looks to have grown quite interesting now. • Blitz <https://github.com/DioxusLabs/blitz https://github.com/DioxusLabs/blitz> is based on from-scratch implementations of CSS layout and rendering, and wgpu rendering. It’s not usable yet, but is a very interesting concept. If one happens to be familiar with React Native: it’s kinda like that, or React Native Web.

ricardobayes 3y ago
React Native Web is a bit like scratching your left ear with your right arm :)
- chrismorgan 3y ago
  Actually, forget the React Native Web thing, I think I was mixing it up with something from a few years back that was more the other way round (running React web stuff on React Native, not running React Native on web). React Native Web… eh, it has a potential place. Maybe like scratching your left ear with your right arm, because your left arm is partially paralysed, or something!

mike_hearn 3y ago

Technically, you could ship a minimal link of a JVM and use JavaFX. It has a compositor, a CSS 2.1 rasterizer, layout managers and renders to D3D or OpenGL surfaces. I think they're adding Metal at the moment. The weakness is interop with C/C++. There's a new Java FFI in the works that makes that a lot better by auto-generating bindings from header files and avoiding JNI, but it hasn't shipped as stable yet. It's usable. You just have to accept that the API might change a bit. You can also compile the whole thing to a native library that doesn't use a typical JVM at all. Memory usage and startup time is a lot better if you do that. You can also expose functions natively to C, or bind to C natively, using a different approach. If I were to do use that approach I'd write a generic binding layer that lets you connect JavaFX observables to their C++ or Rust-side data structures. FX has an architecture that's very based on observable variables, which all have a uniform API, so if you can control those from the native side then you can do anything. Either updating state objects that are then in turn connected to UI objects, or directly updating UI.