Sciter then (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/

- 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/ , 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.

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.

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

Very interesting work. I need to re-evaluate in the future.

This is actually amazing. Thanks for sharing.

I see someone actually submitted the homepage 40 mins ago so I upvoted it for awareness. This is so feature complete I'm frankly surprised it hasn't hit the front page before.

https://news.ycombinator.com/item?id=23163320

HTML is half of the problem, the DOM is just fundamentally unsuited for app UI rendering, and CSS is a nightmare when applied to UI controls rather than text documents. What we need is a cross platform well-thought-out scene graph like Flash had or Flutter (kinda) has.

> the DOM is just fundamentally unsuited for app UI rendering...

Consider the following:

Native UI: is a tree of widgets. Each widget has sematic properties / attributes. Each widget may have style properties (colors ,fonts, etc.). Each widget has exactly on parent and may have multiple children. There is an API for all of these.

HTML/DOM UI: Same as above, just replace "widget" by "element".

Could you explain then why one of these is "fundamentally unsuited" and other is a perfect match?

The most glaring is the ability to measure things (including text) in order to lay them out, rather than adding stuff to the tree and waiting a while for somebody else to lay them out in order to measure them. Followed closely by absolutely everything about the way overflow "works". After that I'd add the absolutely batshit insane hoops through which one still must jump to build any sort of text editing component without throwing away all the good things about HTML like accessibility; the things going on inside Visual Studio Code required to produce even an experience as good as that must haunt the team that builds it. The disconnect in process between "building something out of built-in components" against "build and using a new component", the list goes on.

And just about all of these things are made worse by both the cascade rules and complicated precedence system of CSS.

> The most glaring is the ability to measure things (including text) in order to lay them out ...

This has nothing with the DOM (or HTML or CSS for that matter).

Yes, sometimes in desktop UI you will need to know exact element position/dimensions. That's why in Sciter I've added:

1. element.update(); method, it will force dimensions to be calculated at this moment.

2. element.onSize = function() {...} called when dimensions of the element change.

3. element.paintContent = function(graphics) {} called to paint the element on graphics. Dimensions and position of the element is known at this moment.

4. There is a Graphics.Text object that allows to calculate (not just render) text and glyph positions.

My main point with all this: it is a matter of API provided and has nothing with HTML/CSS per se.

For that matter, Flutter also uses DOM (tree of widgets, etc.). It is just that its style system is not declarative and misses cascading - for some reasons they decided to use WPF/XAML way of doing business. But we've already sang "Sic transit gloria mundi" to WPF ...

For the text editing... check html-notepad : https://html-notepad.com/ . Left sidebar (structure outline) is computed and painted in immediate rendering painting mode - when paintContent of the document is invoked.

When I wrote "DOM" I meant the DOM as in the W3C one you're looking at right now, not Sciter, which I haven't used. Nothing wrong with the concept of trees of objects, other than the fact the tree usually forms part of the objects.

The biggest problem I have with html/css is that the outcome seems unpredictable; I sit with very experienced web devs and still have to do trial and error sometimes to know where what will be and of what size. I hear, way to often, when I (backend/embedded dev) ask how to ‘not make X happen’ something like ‘try this or this’ after they check my css. How is that software development if you have to guess how things work? Maybe it is because I am a backend dev, but we have this issue far less with native dev; they just say ‘do this’ and indeed it works as expected.

HTML is for document/flow.

Only with flexbox it became kind of usable for "apps". But still, the widgets are not native. You can keep emulating and emulating, but it's very easy to spot and quite frankly super annoying.

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.

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.

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

what the heck is that third one about?

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.

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?

I think they mean stuff like XAML islands in Win32.

maybe an OpenGL type of rendering?

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.

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.

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

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.

just ship everything with sqlite :) it'll be fine

This list is && not ||

Wouldn't it have been more concise then to just state that you "needed a framework that supported rendering to a window that isn't owned by the UI being rendered or created by the framework"? I guess now I'm even more confused about what Electron supports...

EDIT: Ok I see now, you listed your requirements and just stated that Electron doesn't satisfy them. The construct is confusing to me because the way it's worded seems to suggest Electron doesn't satisfy any of them, but I understand now.

Yea sorry for being unclear, I meant I need to do all those things. I have evaluated electron in the past and tried to hack the things I need unsuccessfully, but I don't keep up with it so I've edited my comment.

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

Revery comes to mind here.

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?

VST2 just has to die already

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

Wasm

That's absurd; if you're shipping a native app you can compile native code.

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?

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

No actually. There are projects that can run in a server. The spec doesn’t say anything about web only.

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

Is this true? React native for ios and android draw with native widgets, not a DOM.

It is not.

Here's the GitHub for the Windows implementation: 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

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

It doesn't render CSS, not in that context. The way styling for layout and for colour/text/etc is specified is designed to match a subset of CSS so that developers can easily transition across to the platform, that's all (and for layout it uses an engine called Yoga, which implements CSS' flexbox spec). So in the context of actual component code, it's a layer designed to look like CSS that can generate whatever the backend being used requires to render (so it should be able to produce valid CSS as an output, as in the case of React Native Web)

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

They do a translation between CSS/flexbox and the native UI layer, just like on iOS and Android

This is misinformed.

React scripts native widgets, not HTML.