14 ms·

I'm convinced that using an embedded browser engine to render app UI is the future. Browser rendering engines are so powerful and versatile and universal I don'

I'm convinced that using an embedded browser engine to render app UI is the future. Browser rendering engines are so powerful and versatile and universal I don't see how they can lose. "But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. I'm excited for the new crop of browser engines because they could fix those deficiencies, opening up browser tech to app developers without hugely compromising the experience.

horsawlarway 2y ago
I mean... Just to be clear, Electron has pretty much taken the world by storm. Huge number of Enterprise/productivity apps are shipped on Electron. It's hard to beat the value proposition on the business side if you need a website for the product.
- infogulch 2y ago
  True but anyone that cares about battery life or runs more than one of these apps hates it. So I guess my threshold for "taken by storm" is both "very common" and "users don't hate it".
  - icedrift 2y ago
    It is tragic that the only robust solution for cross platform apps eats up so much memory and storage but we're getting to the point where it's not that big a deal.
    - viraptor 2y ago
      Java and .Net/Avalonia are right there... Electron is not the only cross platform solution.
      - infogulch 2y ago
        While .NET has the cross-platform-vm thing going, is not particularly suited to cross-platform rendering. The web is. And don't get me started on WPF.
        viraptor 2y ago
        That's why I mentioned https://avaloniaui.net/ https://avaloniaui.net/ which does the part. WPF is not bad compared to everything happening in the web frameworks.
        AcquiescentWolf 2y ago
        I disagree. After working with WPF for a while, I'd prefer almost anything from the frontend world (except React) over WPF. Avalonia is nice though.
        throwaway2037 2y ago
        Is WPF cross-plaform?
        AcquiescentWolf 2y ago
        * WPF: Windows-only. * MAUI: Windows, macOS, Android, iOS. * Avalonia: Windows, Linux, macOS, Android, iOS, browsers.
      - lmm 2y ago
        I can remember when the rhetoric against Java apps being "slow" was just as strong as it is against Electron now. And they've always been less native-feeling and clunkier than Electron.
        pjmlp 2y ago
        Java is a ferrari when compared to Electron.
- akritrime 2y ago
  Yeah I was going to comment the same thing. A very big reason why we are even having this conversation about a browser engine powering native apps is because electron exists. Yes it's sub-optimal but that hasn't impeded its conquest in the slightest.
- pjmlp 2y ago
  If you need a Website, use a browser.
  - horsawlarway 2y ago
    They do and and they did. You just don't like that they used the browser in both places.
    - pjmlp 2y ago
      My computer already has an browser installed, I am not a browser collector.
      - horsawlarway 2y ago
        Might be better if you were, though. Personally - I collect quite a few for different things. I almost always have at least chrome, firefox, ungoogled-chromium, and - recently - ladybird installed. Not to mention a couple different chromium versions for various electron apps (slack, discord, etcher, bitwarden, vscode, postman, etc). Different browsers do different things well, and electron does the "desktop app" niche better than the others right now. In the same way that ladybird does the "not tracked by corporations" part, and firefox does the "still supports manifest v2 extensions" part. You can complain all you'd like (and I recognize you from other places hating on electron) and it's fine, but it doesn't change incentive structures for the folks deploying these, and as a full time linux user... I am SO fucking happy to have all the BS apps my company requires "just work" on my computers because of electron. If you don't want to use software developed with Electron... more power to ya. Go make that choice. Leave the rest of us out of it. From my side... it'd be great if we can make electron suck less (and trust me, I definitely agree that we can), but right now... it's still a pretty huge win.
        pjmlp 2y ago
        Only one Electron app is tolerated on my computer, VSCode, and that is because for some stuff that is the only place I get plugins for, and that is about it. Everything else, if there is a Web app, then I use the browser, no need to ship it alongside every single application out there. It is like those garbage mobile apps, that are exactly the same website that I can access via the Webbrowser, packaged inside a "native" app. And I say this as someone that works primarly in distributed systems and Web.
KronisLV 2y ago
I mean, most OSes already ship with a WebView component that you can use instead of shipping an entire browser runtime. Wails does that: https://wails.io/ https://wails.io/ Tauri also does that: https://tauri.app/ https://tauri.app/ That does help with the app sizes quite a bit: https://github.com/Elanis/web-to-desktop-framework-comparison https://github.com/Elanis/web-to-desktop-framework-compariso... Sadly it doesn’t change the memory usage much so the technology is still inherently wasteful, but on a certain level it feels like a lost battle - because web technologies often feel like the choice of least resistance when you want GUI software that will run on a bunch of platforms while not being annoying to develop (from the perspective of your run of the mill dev).
- Tmpod 2y ago
  > That does help with the app sizes quite a bit: https://github.com/Elanis/web-to-desktop-framework-comparison https://github.com/Elanis/web-to-desktop-framework-compariso... Interesting resource, thanks! Was not expecting the start up values for Tauri, they're abysmal ._. Welp, at least the executables are small.
  - kibwen 2y ago
    Tauri uses the native webview on the platform, which is presumably why startup values are all over the place. (It's also somewhat suspect to the point of warranting investigation; even using the native webview there seems no reason for something that takes half a second on Windows to take 25 seconds on Linux).
    - lukevp 2y ago
      I had this same observation. My guess is because Tauri uses WebGtk and Linux doesn’t really have a “native webview” so it’s kinda shipping the whole thing? The startup time seems like Tauri’s a non-starter for a lot of apps if you want them to be cross platform, had no idea this was a thing.
      - sirwhinesalot 2y ago
amelius 2y ago
Except on iOS because Apple can't get its sandboxing act together.
taurknaut 2y ago
> Browser rendering engines are so powerful and versatile and universal I don't see how they can lose. Well browsers are pretty damn heavy for an app that won't use 99% of its functionality. Maybe some of this can be amortized with clever distro work so apps don't have to ship the whole runtime but that hasn't happened yet. (In fact, it's a little odd to me electron is based on chrome rather than the WebKit that actually ships with macos.... you should be able to ship that sort of app with a few megabytes) I'd also rather eat glass than be stuck with javascript, easily the most frustrating ecosystem I've ever worked with by a very wide margin. Just the language is ok, but the build pipelines/bundling/transpilation/polyfillls is absolutely miserable to work with and lack of a decent standard library really hurts. It's crazy how we've basically lifted up the concepts of compilation and linking c objects to the world of javascript, just to ship code in a language the browser already fully supports. Maybe WASM will help but my understanding its use of the DOM is quite awkward and still requires javascript usage.
- jampekka 2y ago
  How does WASM help with the concepts of compilation and linking c objects?
nicoburns 2y ago
> It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. By this, do you mean something like a C/C++/Rust API to the DOM?
diath 2y ago
Numerous video games have been doing precisely that for the past decade using CEF: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
- ZeWaka 2y ago
  s/o to CefGlue, the C# bindings: https://github.com/space-wizards/cefglue https://github.com/space-wizards/cefglue
- zeroq 2y ago
  and before that Scaleform!
- ChocolateGod 2y ago
  FiveM uses CEF and let's you replace much of the built in GTA V scaleform with it. It's incredible what can be done but can be far less responsive than the scaleform it replaces, but this may partially be due to it being a third party mod to the game.
  - deleted 2y ago
    [deleted]
- promiseofbeans 2y ago
  Minecraft Bedrock uses React + a "web-like platform" (I assume this means they've just implemented the bits they needed) for their UI: https://github.com/Mojang/ore-ui https://github.com/Mojang/ore-ui
  - samtheDamned 2y ago
    Bedrock's interface also feels slightly more sluggish than Java's, Though its definitely faster than the other examples here.
    - KTibow 2y ago
cyberax 2y ago
> I'm convinced that using an embedded browser engine to render app UI is the future. Sciter exists: https://sciter.com/ https://sciter.com/ And it indeed is great for UI.
- FreezerburnV 2y ago
  Has it ever been made easy to use on mobile? That’s the big thing that’s always given me pause on investing heavily in using it. Especially since it uses weird syntax in places and isn’t “just a browser”.
  - cyberax 2y ago
    It works... But it doesn't have a lot of integration. It's OK for its main use, a UI framework for primarily C/C++ programs, rather than a pure JavaScript+HTML host. A company that I'm advising is using it for their industrial IoT control dashboards, and it's great for that purpose.
- philsnow 2y ago
  > In almost 10 years, Sciter UI engine has become the secret weapon of success oh neat, I like learning about “secret weapons” like lisp/erlang > for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others. I saw that sentence ending differently in my head... It just doesn’t seem like a very strong claim, that all these products which don’t really hinge on having great (or even good) UIs consider Sciter to be their secret weapon.
  - gessha 2y ago
    Seeing “War Thunder” on their jumbotron, maybe they have other things in mind with “secret weapons” rofl
  - cyberax 2y ago
    Yeah. It's a one-man company that has great tech, but very little capacity to build an ecosystem around it. A comparable ecosystem is QML in QT, but Sciter is an order of magnitude leaner and faster.
coldtea 2y ago
>"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget). >2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. Huh?
- rafaelmn 2y ago
  >Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget). There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations. Electron has to implement everything chrome has to support even though the apps running in it will never touch it. Also web engines have to be heavily sandboxed because you cannot allow internet code break out of the sandbox. Native apps shipped with electron already ship Node and just waste resources sandboxing stuff with security layers.
  - coldtea 2y ago
    >There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations. Embedded browser engines though are either wrappers for Webkit and Blink (thus also including the "legacy parts of browser layout that make it impossible(?) to optimize some rendering") OR simplistic web rendering engines that are not as capable as Chrome/Webkit for layout and not compatible with all modern CSS/HTML features.
    - rafaelmn 2y ago
weinzierl 2y ago
"It has no native DOM API bindings" I wish we'd get direct DOM access from WASM anytime but I have little hope.
- infogulch 2y ago
  Actually, building WASM direct DOM api first, then building the native DOM api as an extension of that sounds like a great idea.
- tcfhgj 2y ago
  why? it doesn't matter in any non-trivial app
  - weinzierl 2y ago
    In other contexts people complain about every byte shipped too much but whenever WASM comes up kilobytes of useless JavaScript shims don't matter. And it is one unnecessary extra request we should not need. It is one extra build step to generate the bindings.
    - tcfhgj 2y ago
      How does it? Worst case it adds 1% KB on top (WASM has fairly big binaries in general). The unnecessary extra requests are not performance critical and the programmer doesn't even notice one more build step in the build steps of dozen other pkgs. Surely it would be nice, but it's not a real deal breaker
- yencabulator 2y ago
  My understanding is that "the DOM API" is specced very much in terms of Javascript, so WASM component stuff might see a "DOM2 API" that's similar but not really the same API. Lots of work in speccing that out, I bet. But yes, please!
deleted 2y ago
[deleted]
apaprocki 2y ago
The Bloomberg Terminal is rendered using Chromium and has been for many years. You don’t need to wait for new browser engines to use the existing ones, but you do need resources to contribute, maintain, bugfix, etc. because there is no such thing as a free lunch.
- cjpearson 2y ago
  Props to Bloomberg for contributing too. I've noticed that they have sponsored the development of CSS Grid and other features in Chromium.
tonyhart7 2y ago
Yeah but I don't want touch JS for this
petabyt 2y ago
> I'm convinced that using an embedded browser engine to render app UI is the future. I think Facebook had the same thoughts at some point and they invested heavily in web tech. Later when that backfired (because of performance issues) they started the React Native project.
- kylecazar 2y ago
  Yes, they prioritized just straight up mobile web for a while, citing things like HTML5 as the future of apps. I think that an embedded web rendering strategy for UI within the context of a framework that provides other native interfaces may indeed become a bigger thing
- whywhywhywhy 2y ago
  Apple purposefully limits what web tech can achieve on their platform so web vs native discussion needs to be heavily caveated on iOS what should be possible just isn’t. We also know it’s not a case of just Apples native tech being better because MacOS has truly lost to webtech, hard to even name an app built in the last 5-10 years by a 3rd party in Apples own tech. Everything is just Electron or cross frameworks. Personally I love truly native Mac apps but it’s certainly clear no one else cares and electron is enough.
  - lostmsu 2y ago
    Wait, I understand Apple limits competitor browsers, but non-browser apps should have no issue embedding Chromium or Gecko, right?
    - spwa4 2y ago
      They can't: https://developer.apple.com/support/alternative-browser-engines/ https://developer.apple.com/support/alternative-browser-engi... (except through the, purposefully onerous, EU alternative regulations. Which apple charges apps a per-install fee for. Normal apps can only use Webkit, without any plugins or changes)
  - andelink 2y ago
swoorup 2y ago
I am betting my chips in dioxus. Looks like a very clean project although few critical parts missing.
lukan 2y ago
I am not excited, because HTML is not a great UI framework at all. It just happens to be the most widespread by accident, because hyperlinked documents - HTML - became huge and then more and more UI elements were bolted on top of it. And suddenly it became the goto, because the plattform run everywhere. But it is still a ugly mess underneath and you might be right, that it is the future, but it is not a great one. I hope a great one will surface one day and then we can start new with something sane. "I'm excited for the new crop of browser engines because they could fix those deficiencies" And I cannot see what fixing those deficiencies could mean other, than throwing most of the standard away. It doesn't mean all of it needs to be thrown away. WebAudio API, WebGPU, etc. all became great standards. But simple UI elements, like a slider or color picker are still just ugly and impossible to make beautiful and behave sane, besides making a new one by hand, or using a libary from someone who did that. But - with WebGPU especially - I am excited for the possibility to build a sane framework on top of some subsets of the browsers capabilities.
- codingbot3000 2y ago
  That's really a good point. If you're building a native app or similar, why constrain yourself to HTML?
  - iudqnolq 2y ago
    Because flexbox & grid are amazing. And you'll probably need it anyway if you ever have to render arbitrary rich text.
    - filleduchaos 2y ago
      Flexbox, grid and rich text are not the sole domain of HTML. How do people imagine rendering is implemented in browsers to begin with?
cakealert 2y ago
Unfortunately, the best GUI in existence atm is a proprietary middleware and the language for it is XAML. NoesisGUI: https://www.noesisengine.com/xamltoy/0e2a866b60bc2b9a724b4c68eefde5eb https://www.noesisengine.com/xamltoy/0e2a866b60bc2b9a724b4c6... And it even has a studio for paying clients which makes designing a GUI trivial. https://www.noesisengine.com/studio/ https://www.noesisengine.com/studio/ The studio is made using their own GUI library and its sleek af. Not even QT holds a candle to it. Would have been nice to have such a project in the open source world.
- mcintyre1994 2y ago
  Is that desktop only, or does their demo just not work on mobile but other stuff can? I don’t get a keyboard when I focus their password input on iOS Safari.
- pjmlp 2y ago
  Qt certainly holds several candles, what happens is that people always complain about having to pay for tools, while expecting to be payed themselves. https://www.qt.io/product/ui-design-tools https://www.qt.io/product/ui-design-tools
- lofaszvanitt 2y ago
  we need something like this but with a css-html-js output
  - andyjohnson0 2y ago
    https://platform.uno/ https://platform.uno/ is an option for building web apps with xaml
    - johnisgood 2y ago
      .NET? Ugh.
      - andyjohnson0 2y ago
AnonC 2y ago
> But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. In my observation, Electron's deficiencies go beyond these two. One glaring issue is the UX not conforming to the native OS guidelines/conventions, including things like keyboard based navigation and OS feature integration. Give me a native app and an Electron (or similar app, including the abominations that are Catalyst apps on macOS), and I'll choose native apps every time.
rayiner 2y ago
https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html

horsawlarway 2y ago

I mean... Just to be clear, Electron has pretty much taken the world by storm. Huge number of Enterprise/productivity apps are shipped on Electron. It's hard to beat the value proposition on the business side if you need a website for the product.

infogulch 2y ago
True but anyone that cares about battery life or runs more than one of these apps hates it. So I guess my threshold for "taken by storm" is both "very common" and "users don't hate it".
- icedrift 2y ago
  It is tragic that the only robust solution for cross platform apps eats up so much memory and storage but we're getting to the point where it's not that big a deal.
  - viraptor 2y ago
    Java and .Net/Avalonia are right there... Electron is not the only cross platform solution.
    - infogulch 2y ago
      While .NET has the cross-platform-vm thing going, is not particularly suited to cross-platform rendering. The web is. And don't get me started on WPF.
      - viraptor 2y ago
        That's why I mentioned https://avaloniaui.net/ https://avaloniaui.net/ which does the part. WPF is not bad compared to everything happening in the web frameworks.
        AcquiescentWolf 2y ago
        I disagree. After working with WPF for a while, I'd prefer almost anything from the frontend world (except React) over WPF. Avalonia is nice though.
      - throwaway2037 2y ago
        Is WPF cross-plaform?
        AcquiescentWolf 2y ago
        * WPF: Windows-only. * MAUI: Windows, macOS, Android, iOS. * Avalonia: Windows, Linux, macOS, Android, iOS, browsers.
    - lmm 2y ago
      I can remember when the rhetoric against Java apps being "slow" was just as strong as it is against Electron now. And they've always been less native-feeling and clunkier than Electron.
      - pjmlp 2y ago
        Java is a ferrari when compared to Electron.
akritrime 2y ago
Yeah I was going to comment the same thing. A very big reason why we are even having this conversation about a browser engine powering native apps is because electron exists. Yes it's sub-optimal but that hasn't impeded its conquest in the slightest.
pjmlp 2y ago
If you need a Website, use a browser.
- horsawlarway 2y ago
  They do and and they did. You just don't like that they used the browser in both places.
  - pjmlp 2y ago
    My computer already has an browser installed, I am not a browser collector.
    - horsawlarway 2y ago
      Might be better if you were, though. Personally - I collect quite a few for different things. I almost always have at least chrome, firefox, ungoogled-chromium, and - recently - ladybird installed. Not to mention a couple different chromium versions for various electron apps (slack, discord, etcher, bitwarden, vscode, postman, etc). Different browsers do different things well, and electron does the "desktop app" niche better than the others right now. In the same way that ladybird does the "not tracked by corporations" part, and firefox does the "still supports manifest v2 extensions" part. You can complain all you'd like (and I recognize you from other places hating on electron) and it's fine, but it doesn't change incentive structures for the folks deploying these, and as a full time linux user... I am SO fucking happy to have all the BS apps my company requires "just work" on my computers because of electron. If you don't want to use software developed with Electron... more power to ya. Go make that choice. Leave the rest of us out of it. From my side... it'd be great if we can make electron suck less (and trust me, I definitely agree that we can), but right now... it's still a pretty huge win.
      - pjmlp 2y ago
        Only one Electron app is tolerated on my computer, VSCode, and that is because for some stuff that is the only place I get plugins for, and that is about it. Everything else, if there is a Web app, then I use the browser, no need to ship it alongside every single application out there. It is like those garbage mobile apps, that are exactly the same website that I can access via the Webbrowser, packaged inside a "native" app. And I say this as someone that works primarly in distributed systems and Web.

KronisLV 2y ago

I mean, most OSes already ship with a WebView component that you can use instead of shipping an entire browser runtime. Wails does that: https://wails.io/ https://wails.io/ Tauri also does that: https://tauri.app/ https://tauri.app/ That does help with the app sizes quite a bit: https://github.com/Elanis/web-to-desktop-framework-comparison https://github.com/Elanis/web-to-desktop-framework-compariso... Sadly it doesn’t change the memory usage much so the technology is still inherently wasteful, but on a certain level it feels like a lost battle - because web technologies often feel like the choice of least resistance when you want GUI software that will run on a bunch of platforms while not being annoying to develop (from the perspective of your run of the mill dev).

Tmpod 2y ago
> That does help with the app sizes quite a bit: https://github.com/Elanis/web-to-desktop-framework-comparison https://github.com/Elanis/web-to-desktop-framework-compariso... Interesting resource, thanks! Was not expecting the start up values for Tauri, they're abysmal ._. Welp, at least the executables are small.
- kibwen 2y ago
  Tauri uses the native webview on the platform, which is presumably why startup values are all over the place. (It's also somewhat suspect to the point of warranting investigation; even using the native webview there seems no reason for something that takes half a second on Windows to take 25 seconds on Linux).
  - lukevp 2y ago
    I had this same observation. My guess is because Tauri uses WebGtk and Linux doesn’t really have a “native webview” so it’s kinda shipping the whole thing? The startup time seems like Tauri’s a non-starter for a lot of apps if you want them to be cross platform, had no idea this was a thing.
    - sirwhinesalot 2y ago

amelius 2y ago

Except on iOS because Apple can't get its sandboxing act together.

taurknaut 2y ago

> Browser rendering engines are so powerful and versatile and universal I don't see how they can lose. Well browsers are pretty damn heavy for an app that won't use 99% of its functionality. Maybe some of this can be amortized with clever distro work so apps don't have to ship the whole runtime but that hasn't happened yet. (In fact, it's a little odd to me electron is based on chrome rather than the WebKit that actually ships with macos.... you should be able to ship that sort of app with a few megabytes) I'd also rather eat glass than be stuck with javascript, easily the most frustrating ecosystem I've ever worked with by a very wide margin. Just the language is ok, but the build pipelines/bundling/transpilation/polyfillls is absolutely miserable to work with and lack of a decent standard library really hurts. It's crazy how we've basically lifted up the concepts of compilation and linking c objects to the world of javascript, just to ship code in a language the browser already fully supports. Maybe WASM will help but my understanding its use of the DOM is quite awkward and still requires javascript usage.

jampekka 2y ago
How does WASM help with the concepts of compilation and linking c objects?

nicoburns 2y ago

> It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. By this, do you mean something like a C/C++/Rust API to the DOM?

diath 2y ago

Numerous video games have been doing precisely that for the past decade using CEF: https://en.wikipedia.org/wiki/Chromium_Embedded_Framework https://en.wikipedia.org/wiki/Chromium_Embedded_Framework

ZeWaka 2y ago
s/o to CefGlue, the C# bindings: https://github.com/space-wizards/cefglue https://github.com/space-wizards/cefglue
zeroq 2y ago
and before that Scaleform!
ChocolateGod 2y ago
FiveM uses CEF and let's you replace much of the built in GTA V scaleform with it. It's incredible what can be done but can be far less responsive than the scaleform it replaces, but this may partially be due to it being a third party mod to the game.
- deleted 2y ago
  [deleted]
promiseofbeans 2y ago
Minecraft Bedrock uses React + a "web-like platform" (I assume this means they've just implemented the bits they needed) for their UI: https://github.com/Mojang/ore-ui https://github.com/Mojang/ore-ui
- samtheDamned 2y ago
  Bedrock's interface also feels slightly more sluggish than Java's, Though its definitely faster than the other examples here.
  - KTibow 2y ago

cyberax 2y ago

> I'm convinced that using an embedded browser engine to render app UI is the future. Sciter exists: https://sciter.com/ https://sciter.com/ And it indeed is great for UI.

FreezerburnV 2y ago
Has it ever been made easy to use on mobile? That’s the big thing that’s always given me pause on investing heavily in using it. Especially since it uses weird syntax in places and isn’t “just a browser”.
- cyberax 2y ago
  It works... But it doesn't have a lot of integration. It's OK for its main use, a UI framework for primarily C/C++ programs, rather than a pure JavaScript+HTML host. A company that I'm advising is using it for their industrial IoT control dashboards, and it's great for that purpose.
philsnow 2y ago
> In almost 10 years, Sciter UI engine has become the secret weapon of success oh neat, I like learning about “secret weapons” like lisp/erlang > for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others. I saw that sentence ending differently in my head... It just doesn’t seem like a very strong claim, that all these products which don’t really hinge on having great (or even good) UIs consider Sciter to be their secret weapon.
- gessha 2y ago
  Seeing “War Thunder” on their jumbotron, maybe they have other things in mind with “secret weapons” rofl
- cyberax 2y ago
  Yeah. It's a one-man company that has great tech, but very little capacity to build an ecosystem around it. A comparable ecosystem is QML in QT, but Sciter is an order of magnitude leaner and faster.

coldtea 2y ago

>"But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget). >2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. Huh?

rafaelmn 2y ago
>Why would an "embedded browser engine" be any better? Electron after all is also a browser engine, and that's what makes it slow and bloated compared to native UI, not the embedded part (by which I asume you mean something like a browser engine wrapper widget). There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations. Electron has to implement everything chrome has to support even though the apps running in it will never touch it. Also web engines have to be heavily sandboxed because you cannot allow internet code break out of the sandbox. Native apps shipped with electron already ship Node and just waste resources sandboxing stuff with security layers.
- coldtea 2y ago
  >There are legacy parts of browser layout that make it impossible(?) to optimize some rendering while being standards compatible. If you just chose a subset that is fast to implement and focused on being subset you narrow the scope of the project and enable optimizations. Embedded browser engines though are either wrappers for Webkit and Blink (thus also including the "legacy parts of browser layout that make it impossible(?) to optimize some rendering") OR simplistic web rendering engines that are not as capable as Chrome/Webkit for layout and not compatible with all modern CSS/HTML features.
  - rafaelmn 2y ago

weinzierl 2y ago

"It has no native DOM API bindings" I wish we'd get direct DOM access from WASM anytime but I have little hope.

infogulch 2y ago
Actually, building WASM direct DOM api first, then building the native DOM api as an extension of that sounds like a great idea.
tcfhgj 2y ago
why? it doesn't matter in any non-trivial app
- weinzierl 2y ago
  In other contexts people complain about every byte shipped too much but whenever WASM comes up kilobytes of useless JavaScript shims don't matter. And it is one unnecessary extra request we should not need. It is one extra build step to generate the bindings.
  - tcfhgj 2y ago
    How does it? Worst case it adds 1% KB on top (WASM has fairly big binaries in general). The unnecessary extra requests are not performance critical and the programmer doesn't even notice one more build step in the build steps of dozen other pkgs. Surely it would be nice, but it's not a real deal breaker
yencabulator 2y ago
My understanding is that "the DOM API" is specced very much in terms of Javascript, so WASM component stuff might see a "DOM2 API" that's similar but not really the same API. Lots of work in speccing that out, I bet. But yes, please!

deleted 2y ago

[deleted]

apaprocki 2y ago

The Bloomberg Terminal is rendered using Chromium and has been for many years. You don’t need to wait for new browser engines to use the existing ones, but you do need resources to contribute, maintain, bugfix, etc. because there is no such thing as a free lunch.

cjpearson 2y ago
Props to Bloomberg for contributing too. I've noticed that they have sponsored the development of CSS Grid and other features in Chromium.

tonyhart7 2y ago

Yeah but I don't want touch JS for this

petabyt 2y ago

> I'm convinced that using an embedded browser engine to render app UI is the future. I think Facebook had the same thoughts at some point and they invested heavily in web tech. Later when that backfired (because of performance issues) they started the React Native project.

kylecazar 2y ago
Yes, they prioritized just straight up mobile web for a while, citing things like HTML5 as the future of apps. I think that an embedded web rendering strategy for UI within the context of a framework that provides other native interfaces may indeed become a bigger thing
whywhywhywhy 2y ago
Apple purposefully limits what web tech can achieve on their platform so web vs native discussion needs to be heavily caveated on iOS what should be possible just isn’t. We also know it’s not a case of just Apples native tech being better because MacOS has truly lost to webtech, hard to even name an app built in the last 5-10 years by a 3rd party in Apples own tech. Everything is just Electron or cross frameworks. Personally I love truly native Mac apps but it’s certainly clear no one else cares and electron is enough.
- lostmsu 2y ago
  Wait, I understand Apple limits competitor browsers, but non-browser apps should have no issue embedding Chromium or Gecko, right?
  - spwa4 2y ago
    They can't: https://developer.apple.com/support/alternative-browser-engines/ https://developer.apple.com/support/alternative-browser-engi... (except through the, purposefully onerous, EU alternative regulations. Which apple charges apps a per-install fee for. Normal apps can only use Webkit, without any plugins or changes)
- andelink 2y ago

swoorup 2y ago

I am betting my chips in dioxus. Looks like a very clean project although few critical parts missing.

lukan 2y ago

I am not excited, because HTML is not a great UI framework at all. It just happens to be the most widespread by accident, because hyperlinked documents - HTML - became huge and then more and more UI elements were bolted on top of it. And suddenly it became the goto, because the plattform run everywhere. But it is still a ugly mess underneath and you might be right, that it is the future, but it is not a great one. I hope a great one will surface one day and then we can start new with something sane. "I'm excited for the new crop of browser engines because they could fix those deficiencies" And I cannot see what fixing those deficiencies could mean other, than throwing most of the standard away. It doesn't mean all of it needs to be thrown away. WebAudio API, WebGPU, etc. all became great standards. But simple UI elements, like a slider or color picker are still just ugly and impossible to make beautiful and behave sane, besides making a new one by hand, or using a libary from someone who did that. But - with WebGPU especially - I am excited for the possibility to build a sane framework on top of some subsets of the browsers capabilities.

codingbot3000 2y ago
That's really a good point. If you're building a native app or similar, why constrain yourself to HTML?
- iudqnolq 2y ago
  Because flexbox & grid are amazing. And you'll probably need it anyway if you ever have to render arbitrary rich text.
  - filleduchaos 2y ago
    Flexbox, grid and rich text are not the sole domain of HTML. How do people imagine rendering is implemented in browsers to begin with?

cakealert 2y ago

Unfortunately, the best GUI in existence atm is a proprietary middleware and the language for it is XAML. NoesisGUI: https://www.noesisengine.com/xamltoy/0e2a866b60bc2b9a724b4c68eefde5eb https://www.noesisengine.com/xamltoy/0e2a866b60bc2b9a724b4c6... And it even has a studio for paying clients which makes designing a GUI trivial. https://www.noesisengine.com/studio/ https://www.noesisengine.com/studio/ The studio is made using their own GUI library and its sleek af. Not even QT holds a candle to it. Would have been nice to have such a project in the open source world.

mcintyre1994 2y ago
Is that desktop only, or does their demo just not work on mobile but other stuff can? I don’t get a keyboard when I focus their password input on iOS Safari.
pjmlp 2y ago
Qt certainly holds several candles, what happens is that people always complain about having to pay for tools, while expecting to be payed themselves. https://www.qt.io/product/ui-design-tools https://www.qt.io/product/ui-design-tools
lofaszvanitt 2y ago
we need something like this but with a css-html-js output
- andyjohnson0 2y ago
  https://platform.uno/ https://platform.uno/ is an option for building web apps with xaml
  - johnisgood 2y ago
    .NET? Ugh.
    - andyjohnson0 2y ago

AnonC 2y ago

> But Electron!" Yes, Electron hasn't taken the world by storm because it has two huge deficiencies: 1. It takes an enormous amount of resources including ram and disk. 2. It has no native DOM API bindings so it takes even more ram and cpu to compile and run JS quickly. In my observation, Electron's deficiencies go beyond these two. One glaring issue is the UX not conforming to the native OS guidelines/conventions, including things like keyboard based navigation and OS feature integration. Give me a native app and an Electron (or similar app, including the abominations that are Catalyst apps on macOS), and I'll choose native apps every time.

rayiner 2y ago

https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html