6 ms·

I'd love to abandon my C/C++ UI frameworks for React, but I need - consistent rendering/support across multiple platforms and versions - multiple windows - r

by qppo 6y ago

I'd love to abandon my C/C++ UI frameworks for React, but I need - consistent rendering/support across multiple platforms and versions - multiple windows - rendering to a window that isn't owned by the UI being rendered or created by the framework Can I do that all in React native? Edit: don't need to bring up electron.

whb07 6y ago
Wasm
- nikivi 6y ago
  With WASM though you will still have to have the app be deployed within browser context. Thus losing hotkeys to the browser etc Or you can build native WASM apps?
  - unsignedint 6y ago
    That's probably where Blazor is eventually heading to? There seems to be some preview on the mobile native, though, it's probably not strictly a WASM as it provides binding through Xamarin...[0] [0]: https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings-feb-2020-update/ https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings...
  - whb07 6y ago
    No actually. There are projects that can run in a server. The spec doesn’t say anything about web only.
- millstone 6y ago
  That's absurd; if you're shipping a native app you can compile native code.
metalliqaz 6y ago
what the heck is that third one about?
- rburhum 6y ago
  maybe an OpenGL type of rendering?
- int_19h 6y ago
  I think they mean stuff like XAML islands in Win32.
- qppo 6y ago
  I work with applications that generate windows and manage their lifetimes independently of whatever is inside the window. afaict, most web/mobile UI frameworks assume they're the only thing in the universe, whereas on desktop there's a complex application managing zero or more rendering surfaces and portions of the code only know about the one that they're supposed to target. It's a hairier problem than you'd expect it to be. I'm not an expert but my understanding is that it's tricky to deal with the event loops when you're not the master of your domain, at least in a platform agnostic way. The workaround is usually to spawn multiple processes, but then the management of app state has to have an IPC layer underneath the internal APIs and there needs to be a master daemon running somewhere. In keeping with front page posts, the plugin API for Apple's Logic Pro (audio units) is an example of that. You are handed an NSView* and need to render on it, but you don't create it.
- munchbunny 6y ago
  I think it means using the same process to control multiple windows simultaneously. You can do it with various C/C++ libraries and .NET, but IIRC not Electron, which leads to the question: can you do it with React Native?
kevmo314 6y ago
Electron can't do multiple windows or consistent rendering? Legit question, I just started using Electron, hadn't heard of the former and thought the latter was a selling point because all platforms wrapped Electron's Chrome.
- deleted 6y ago
  [deleted]
- 43920 6y ago
  Electron supports multiple windows, but it ends up being annoying to do because each window runs in its own process. If your app has any kind of central state that's shared between windows, you end up copying data between processes frequently, which can be slow. Rendering consistency is generally pretty good; I haven't run into any issues with that.
  - virtue3 6y ago
    just ship everything with sqlite :) it'll be fine
  - freefriedrice 6y ago
    This bugs me to no end about Electron. The one module that existed to implement cross window / process communication is deprecated with no alternative. I haven't found a solution for multithreading in electron without killing the base process (which they explicitly say NOT to do compute in) or the rendering process (duh).
    - 43920 6y ago
      Web workers launched from the renderer work fairly well if you just need compute. I think I've also seen some apps add an additional BrowserWindow that's never displayed onscreen, although that will increase your memory overhead.
- qppo 6y ago
  This list is && not ||
0xDEEPFAC 6y ago
This is electron by another name, Microsoft is forcing us into a web sandbox. If electron is Chrome and Edge is Chrome and Microsoft uses Edge for this - then its all chrome in all directions. Native is much faster and more powerful - WE MUST RESIST! https://www.youtube.com/watch?v=_p6tvs-qjpA https://www.youtube.com/watch?v=_p6tvs-qjpA
- monadic2 6y ago
  Is this true? React native for ios and android draw with native widgets, not a DOM.
  - mynameisvlad 6y ago
    It is not. Here's the GitHub for the Windows implementation: https://github.com/microsoft/react-native-windows https://github.com/microsoft/react-native-windows And here's the fork of React Native for the Mac one (it doesn't seem to be as polished as the Windows one yet): https://github.com/microsoft/react-native-macos https://github.com/microsoft/react-native-macos
    - 0xDEEPFAC 6y ago
      I would be very surprised if they didn't use any pieces used by Edge (how else would they render css?). A quick search of their code though and I couldn't find it. Perhaps I assumed too much
      - gunn 6y ago
        React native doesn't really use css - there are no .css files, no cascading either. It's more like a style engine that uses a subset of css ideas as a starting point. It uses flex-box (and only flex-box) for layout, adds some convenient shorthands - marginVertical, marginHorizontal, and does some surprising (but useful) things like has transform take a JS array of key value pairs - https://reactnative.dev/docs/transforms#transform https://reactnative.dev/docs/transforms#transform
      - 6y ago
satvikpendem 6y ago
You could use Flutter. It has the first point, but I am not necessarily sure about the latter ones.
albertTJames 6y ago
You should be able to do all this, if it is as flexible as RN for mobile
alkonaut 6y ago
VST2 just has to die already
c-smile 6y ago
Sciter then (https://sciter.com https://sciter.com): - multiple platforms... Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles. - multiple windows - Yes. Multiple desktop windows and you can even render separate DOM elements in popup windows. - rendering to a window that isn't owned by the UI being rendered Yes, you can render it on top DirectX, OpenGL, Vulkan (coming) or in child window/nsview/gtkwidget. There is also Sciter.Lite that allows to render UI without any DWM - on frame buffer / video memory directly. Check : https://sciter.com/sciter-and-directx/ https://sciter.com/sciter-and-directx/ - don't need to bring up electron. Not Electron. All this in monolithic dll/so (5..9mb) that even can be linked in statically. - consistent rendering across multiple platforms. Check screenshots of https://notes.sciter.com/ https://notes.sciter.com/ , are they consistent enough? - ... for React React (Reactor in Sciter terms) is implemented natively. JSX (SSX in Sciter) is a part of language/runtime - no need for additional compilers, etc. - I'd love to abandon my C/C++ ... No need to. You can still manage (update, handle events) UI directly from C++ if needed. You can even create custom native DOM elements that can even draw themselves by native code.
- qppo 6y ago
  Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the ground in your framework than using my existing codebase and frameworks with larger ecosystems. I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite. Some bencharks comparing engine performance to V8 would also be much appreciated.
  - c-smile 6y ago
    1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases. 2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sciter-sqlite.h https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci... 3. "it has a larger community..." I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed. "Some bencharks comparing engine performance to V8" Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.
acoates 6y ago
Consistent cross platform: This is actually the one thats probably most difficult with react-native. Since unlike electron or Flutter, React-Native uses native UI for each platform. This means you can achieve full parity with native apps in terms of the UI. But all the platforms have different capabilities so since react-native can take full advantage of all the platforms, and isn't lowest common denominator, there are differences between the rendering / support across multiple platforms. Can the native UI framework do multiple windows? - Then React-Native can do multiple windows. Rendering to a windows that isn't owned by the framework is what React-Native refers to as Brownfield apps. This is absolutely supported. For instance, Microsoft Office is using React-Native for some parts of their UI in Android, iOS, Windows and macOS. And the Office window is not created or owned by react-native.
- c-smile 6y ago
  For that matter: Sciter supports use of native platform (or custom) native windows or widgets. For different reasons an combinations. I saw cases when even Qt widgets were used as DOM elements in Sciter controlled main window. So you can get best of two worlds - flexibility of HTML/CSS (rendering, layout managers) and native UI behavior and look.
crazypython 6y ago
> - rendering to a window that isn't owned by the UI being rendered or created by the framework I once used a native library I installed with iOS' native package manager, Cocoapods. I rendered a React Native view inside the native view, which was contained inside a react native view. The only limitation is that the two react native views used separate bundlers i.e. the two react native views can only communicate through the native platform, they couldn't communicate to each other via JavaScript.
freefriedrice 6y ago
Java? STMicroelectronics uses it for almost all of their applications, which ship in one zip file with binaries for Win/Mac/Linux. It ticks #1 and #2, but I don't know about #3. Of course, I'm not sure if having web-like programming is your implicit #4?
k__ 6y ago
Revery comes to mind here.

by qppo 6y ago

whb07 6y ago

Wasm

nikivi 6y ago
With WASM though you will still have to have the app be deployed within browser context. Thus losing hotkeys to the browser etc Or you can build native WASM apps?
- unsignedint 6y ago
  That's probably where Blazor is eventually heading to? There seems to be some preview on the mobile native, though, it's probably not strictly a WASM as it provides binding through Xamarin...[0] [0]: https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings-feb-2020-update/ https://devblogs.microsoft.com/aspnet/mobile-blazor-bindings...
- whb07 6y ago
  No actually. There are projects that can run in a server. The spec doesn’t say anything about web only.
millstone 6y ago
That's absurd; if you're shipping a native app you can compile native code.

metalliqaz 6y ago

what the heck is that third one about?

rburhum 6y ago
maybe an OpenGL type of rendering?
int_19h 6y ago
I think they mean stuff like XAML islands in Win32.
qppo 6y ago
I work with applications that generate windows and manage their lifetimes independently of whatever is inside the window. afaict, most web/mobile UI frameworks assume they're the only thing in the universe, whereas on desktop there's a complex application managing zero or more rendering surfaces and portions of the code only know about the one that they're supposed to target. It's a hairier problem than you'd expect it to be. I'm not an expert but my understanding is that it's tricky to deal with the event loops when you're not the master of your domain, at least in a platform agnostic way. The workaround is usually to spawn multiple processes, but then the management of app state has to have an IPC layer underneath the internal APIs and there needs to be a master daemon running somewhere. In keeping with front page posts, the plugin API for Apple's Logic Pro (audio units) is an example of that. You are handed an NSView* and need to render on it, but you don't create it.
munchbunny 6y ago
I think it means using the same process to control multiple windows simultaneously. You can do it with various C/C++ libraries and .NET, but IIRC not Electron, which leads to the question: can you do it with React Native?

kevmo314 6y ago

Electron can't do multiple windows or consistent rendering? Legit question, I just started using Electron, hadn't heard of the former and thought the latter was a selling point because all platforms wrapped Electron's Chrome.

deleted 6y ago
[deleted]
43920 6y ago
Electron supports multiple windows, but it ends up being annoying to do because each window runs in its own process. If your app has any kind of central state that's shared between windows, you end up copying data between processes frequently, which can be slow. Rendering consistency is generally pretty good; I haven't run into any issues with that.
- virtue3 6y ago
  just ship everything with sqlite :) it'll be fine
- freefriedrice 6y ago
  This bugs me to no end about Electron. The one module that existed to implement cross window / process communication is deprecated with no alternative. I haven't found a solution for multithreading in electron without killing the base process (which they explicitly say NOT to do compute in) or the rendering process (duh).
  - 43920 6y ago
    Web workers launched from the renderer work fairly well if you just need compute. I think I've also seen some apps add an additional BrowserWindow that's never displayed onscreen, although that will increase your memory overhead.
qppo 6y ago
This list is && not ||

0xDEEPFAC 6y ago

This is electron by another name, Microsoft is forcing us into a web sandbox. If electron is Chrome and Edge is Chrome and Microsoft uses Edge for this - then its all chrome in all directions. Native is much faster and more powerful - WE MUST RESIST! https://www.youtube.com/watch?v=_p6tvs-qjpA https://www.youtube.com/watch?v=_p6tvs-qjpA

monadic2 6y ago
Is this true? React native for ios and android draw with native widgets, not a DOM.
- mynameisvlad 6y ago
  It is not. Here's the GitHub for the Windows implementation: https://github.com/microsoft/react-native-windows https://github.com/microsoft/react-native-windows And here's the fork of React Native for the Mac one (it doesn't seem to be as polished as the Windows one yet): https://github.com/microsoft/react-native-macos https://github.com/microsoft/react-native-macos
  - 0xDEEPFAC 6y ago
    I would be very surprised if they didn't use any pieces used by Edge (how else would they render css?). A quick search of their code though and I couldn't find it. Perhaps I assumed too much
    - gunn 6y ago
      React native doesn't really use css - there are no .css files, no cascading either. It's more like a style engine that uses a subset of css ideas as a starting point. It uses flex-box (and only flex-box) for layout, adds some convenient shorthands - marginVertical, marginHorizontal, and does some surprising (but useful) things like has transform take a JS array of key value pairs - https://reactnative.dev/docs/transforms#transform https://reactnative.dev/docs/transforms#transform
    - 6y ago

satvikpendem 6y ago

You could use Flutter. It has the first point, but I am not necessarily sure about the latter ones.

albertTJames 6y ago

You should be able to do all this, if it is as flexible as RN for mobile

alkonaut 6y ago

VST2 just has to die already

c-smile 6y ago

Sciter then (https://sciter.com https://sciter.com): - multiple platforms... Yes: Windows (x32,x64, ARM64), from XP to 10, MacOS, Linux/GTK, IoT and mobiles. - multiple windows - Yes. Multiple desktop windows and you can even render separate DOM elements in popup windows. - rendering to a window that isn't owned by the UI being rendered Yes, you can render it on top DirectX, OpenGL, Vulkan (coming) or in child window/nsview/gtkwidget. There is also Sciter.Lite that allows to render UI without any DWM - on frame buffer / video memory directly. Check : https://sciter.com/sciter-and-directx/ https://sciter.com/sciter-and-directx/ - don't need to bring up electron. Not Electron. All this in monolithic dll/so (5..9mb) that even can be linked in statically. - consistent rendering across multiple platforms. Check screenshots of https://notes.sciter.com/ https://notes.sciter.com/ , are they consistent enough? - ... for React React (Reactor in Sciter terms) is implemented natively. JSX (SSX in Sciter) is a part of language/runtime - no need for additional compilers, etc. - I'd love to abandon my C/C++ ... No need to. You can still manage (update, handle events) UI directly from C++ if needed. You can even create custom native DOM elements that can even draw themselves by native code.

qppo 6y ago
Kind of a chicken and egg situation, I looked at sciter for a project about a year ago and estimated that it would cost more time/money to get things off the ground in your framework than using my existing codebase and frameworks with larger ecosystems. I can't really commit to sciter and your flavor of JS until it has a larger community, more docs, and more onboarding materials so I can get teams up to speed and working quickly, reinventing fewer wheels, and have more discoverability in your docs and community so I can even know how to do things and what I don't need to rewrite. Some bencharks comparing engine performance to V8 would also be much appreciated.
- c-smile 6y ago
  1. I've been told that it takes 1..2 weeks for average front end developer to get into Sciter and features that I've added to HTML/CSS to support desktop UI use cases. 2. "larger ecosystems..." Sciter is embeddable and extendable engine, this means that you can extend it by existing native libraries, time proven and effective. Here is how SQLite native namespace looks in Sciter: https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sciter-sqlite.h https://github.com/c-smile/sciter-sdk/blob/master/sqlite/sci... 3. "it has a larger community..." I am aiming not to larger but rather more professional community. Sciter sources contains patches from these dev teams: https://sciter.com/#customers https://sciter.com/#customers Security audit was made by Symantec and 3 more AntiVirus vendors. All that... Source code base is compact enough for a C++ programmer to get into when needed. "Some bencharks comparing engine performance to V8" Slower than V8 but faster than Python 3. But script performance in Sciter is not that critical (never been a bottleneck) for simple reason: script treated as a glue between native function calls. If you need something to run with bare metal speed - just provide native function(s) for this functionality. JS approach in this respect is simply crazy: to run something fast add megatons of JIT implementation and then another twist: WebAssembler. Why not just to compile what is needed with C++ into native code and call it? Again, Sciter is embeddable and extendable by design.

acoates 6y ago

Consistent cross platform: This is actually the one thats probably most difficult with react-native. Since unlike electron or Flutter, React-Native uses native UI for each platform. This means you can achieve full parity with native apps in terms of the UI. But all the platforms have different capabilities so since react-native can take full advantage of all the platforms, and isn't lowest common denominator, there are differences between the rendering / support across multiple platforms. Can the native UI framework do multiple windows? - Then React-Native can do multiple windows. Rendering to a windows that isn't owned by the framework is what React-Native refers to as Brownfield apps. This is absolutely supported. For instance, Microsoft Office is using React-Native for some parts of their UI in Android, iOS, Windows and macOS. And the Office window is not created or owned by react-native.

c-smile 6y ago
For that matter: Sciter supports use of native platform (or custom) native windows or widgets. For different reasons an combinations. I saw cases when even Qt widgets were used as DOM elements in Sciter controlled main window. So you can get best of two worlds - flexibility of HTML/CSS (rendering, layout managers) and native UI behavior and look.

crazypython 6y ago

> - rendering to a window that isn't owned by the UI being rendered or created by the framework I once used a native library I installed with iOS' native package manager, Cocoapods. I rendered a React Native view inside the native view, which was contained inside a react native view. The only limitation is that the two react native views used separate bundlers i.e. the two react native views can only communicate through the native platform, they couldn't communicate to each other via JavaScript.

freefriedrice 6y ago

Java? STMicroelectronics uses it for almost all of their applications, which ship in one zip file with binaries for Win/Mac/Linux. It ticks #1 and #2, but I don't know about #3. Of course, I'm not sure if having web-like programming is your implicit #4?

k__ 6y ago

Revery comes to mind here.