Also the core JavaScript editor in VSCode, Monaco, can be just run in a web browser, and I believe now they added it to GitHub. So another alternative might be to have a native Monaco wrapper which has some ideas from Electron but maybe not a full clone of the API.
I am not hung up on VS Code. I do like the editor indeed (I tried picking up Emacs like three times in my life and it never sticked) and I like the source indexer and how “lightweight” it feels compared to Visual Studio. Debugger is also pretty good and I like that I can use VS Code for my main languages I use (C++, Python and Scala). The plugin/extensions ecosystem is nice too.
All that being said I can work with another IDE that is somewhat similar and it’s not “opinionated” and gets out of the way.
It might be possible to build another runtime on Haiku which has the Electron API but uses WebKit and other Haiku APIs.
I thought about the same but I’m not sure how much work that would be. We should keep this idea on the TODO list…
A lightweight runtime for Electron sounds like a good idea,but I think it’s complicated.
Electron is really awful,I try to avoid it on every OS and haven’t used any Electron app for over a year I think,but unfortunately this stuff is really popular because it makes it really easy to create one application for every platform (with the cost of OS-integration,native look and feel,good performance,low memory footprint,… but nobody seems to care).
As there’s a huge demand for it,it would be favorable if anyone can make a lightweight runtime,preferably based on HaikuWebKit and dynamically linked to the apps,before anyone steps in and actually ports the whole Chromium bloat and brings huge statically-linked Chromium+Webapp binaries to Haiku.
Electron provides very many custom APIs however,which HaikuWebKit and other webbrowser engines don’t offer and all of those need to be rewritten from scratch to work with HaikuWebKit if you want to make it a drop-in replacement that works without changing anything in the Electron apps.
And I think a drop-in replacement is the only thing that makes sense,because Electron app developers take cross-platform compatibility for granted and won’t care about a custom runtime of a niche OS that they’ve never heard of before.
I already looked at Ultralight before and it won’t work.
You can see big parts of it on Github,but unfortunately their renderer UltralightCore is proprietary as they state in the Readme of the Ultralight repo: https://github.com/ultralight-ux/ultralight#comparison-with-chromium
That means we won’t be able to compile the whole thing for Haiku,except if anyone buys a paid license for 2000 dollars,but then we won’t be allowed to use it for more than one app.
I hoped that Ultralight could be the base for a more modern Webbrowser on Haiku before the QtWebEngine port happened,so I had a deep look into it already,but can’t remember all links that state that it won’t work.
Tauri looks much better as it’s completely open-source and therefore could be compiled on Haiku,but I didn’t know it before and haven’t tried it.
It works with the native web engine on each platform,so it should be possible to integrate it with HaiikuWebKit,but I don’t know how much work that will be.
Also it doesn’t look like a drop-in replacement for Electron but rather an alternative for app developers,which must completely optimize their app for Tauri instead of Electon then (possibly rewriting all custom APIs,but I haven’t looked into the details).
That being said,that’s all a mix of personal opinions and my experience when using Electron ugh and looking into Ultralight.
I have not that much experience with C++ programming and web browsers that I could help in any way with creating the native Electron app runtime
That only says that you’re not allowed to chip a fully bloated Chromium engine with every single webapp and that totally makes sense,because it wasted tons of storage on other OSes.
You can still port Electron apps in a way that they use one single Electron install of the OS.
Arch Linux does the same,at least for some applications,so that’s totally possible.
The only thing which is a bit confusing there is that they have multiple versions of Electron in the repository and the Electron apps depend on different Electron package versions,so if we have bad luck and the compatibility between different Electron versions is really that bad,we still end up with multiple bloated Chromium binaries on one system as we need to package every single Electron version
I won’t use any Electron nonsense either,haven’t used it for over a year on Linux.
Unfortunately I’m pretty sure that it will come to Haiku sooner or later,so we should try to implement it in a form that it causes as few harm to the Haiku ecosystem as possible.
That is part of the selling point of Electron for app developers, actually. You ship your app with its whole runtime and you don’t have to worry if the runtime has been deployed to ustrs or if they run an older or newer version or anything like that. It just works the same way it works on everyone else’s machine. And Electron can make ABI/API breaking changes all the time. Devs can integrate these in each app whenever they want to, instead of discovering it when an user updates their runtime and suddenly an app stops working. Or having electron commit to stable ABIs for 20 years like we do.
This saves users a ton of frustration, and developers a lot of time doing user support. For a lot of people this seems totally worth the extra ram and disk usage.
Long term I am sure Haiku will want to offer a nice way to use the WebKit port in a WebView for applications that need HTML rendering, like an email reader for example. I’m not sure of the state of that with our current WebKit port.
I am not sure if we then want to extend that to make something Electron-like for making “HTML apps”. I am also not a big fan of Electron apps and tend to avoid them though as mentioned I have continued to use VSCode on Windows for now. But it might be nice to allow people to make little HTML widgets that are Replicants to drop on the desktop. Though that would just be doable with a WebView API I suppose.
Given how Electron works with constant API breakage it might be more work than it is worth to make some kind of API wrapper with a different runtime. And the whole thing is kind of against the Haiku philosophy of fast, well-integrated native apps. Well I think that is the general philosophy
A reason why people don’t care about performance is probably because their use-case is very heavy to begin with. A big part of the fun with chat applications like Discord and Revolt is in spamming multimedia, having animated avatars and banners, doing HD video calls and so on with lots of people.
There is just so much going on in these applications that you wouldn’t expect a machine that struggles with Electron to be suitable either way. It would be like trying to run RPCS3 on a Core 2 Duo.
This however does not excuse the fact that VisualStudio Code uses Electron. That to me is really bizarre, because you wouldn’t expect it to be web focused or flashy in any way.
VSCode is not heavy at all. It is pretty much optimised for the use case. I think it is the poster child for Electron. I use it every day in the same way others might use Notepad++. I also use Visual Studio 2019 and 2022, and occasionally Visual Studio Mac. The full product is way heavier and VSCode is snappy and has a massive plug-in ecosystem.
Someone did a port of CudaText. I seem to recall it is a VSCode clone in FreePascal. Might that be helpful?
There is an undocumented and non-ABI stable API (BWebView). Usage is quirky and unpractical, for two reasons:
your window needs to be a BWebWindow
WebKit wants to run a lot of code in the main thread, and in our current WebKitLegacy port, that is the BApplication thread. So it needs to do invasive things at the BApplication side
This makes the thing not-so-generic.
Maybe this will be a little better with WebKit2, since hopefully we can move a lot of the “needs to be in main thread” stuff out to other processes. And have only a smaller bit of code to run inside the application using BWebView. If done right, this part will be fully self-contained in BWebView.
If you don’t mind each such replicant spawning several executables in the background to do anything (you need a WebProcess to do the HTML/CSS/Javascript and a NetworkProcess to do the resource fetching), then yes, why not. This is not any better than Electron in terms of useless bloat, however.
I’m not sure why this is nicer than just writing a replicant with native APIs… is it because you can take code from online and just drop it into a replicant? Or because it will attract web developers to the platform?
I think it is currently easier to use web APIs (if you already know them) to make a fairly complicated GUI than to use native APIs. Part of it is the declarative vs imperative style. Of course it is possible, and probably desirable, to make a native Haiku declarative GUI API, something more like Qt’s QML. I’d probably prefer this to making it easy to make HTML replicants.
So I’m not going to go crazy writing code to make this possible right now, but I am sure at some point it will be possible. We absolutely need a properly abstracted BWebView for native apps to use when needed. I’d prefer if we made it such that a single running BWebView had the option of running everything within the same process rather than having to have all the multi-process stuff from WebKit2 that Adrien talked about. But I don’t know how difficult that is.
Personally, I think the best choices are Paladin, KDevelop and Pe (built in) KDevelop may Paladin is light and easy to use but KDevelop may be more feature packed also Paladin uses Pe as the actual editor Paladin only adds Debugger, Compilation tools and project templates.
That’s how webkitlegacy currently works and it’s a big problem. Everytime the browser engine crashes or goes out of memory or whatever, it would take down the whole app with it.
The webkit team seems to kind of accept that the engine will crash sometimes: in webkit2 they just detect that, and restart it automatically. There is really no point in keeping things in a single process mode. And as a replicant it would just be too invasive: you will still need to run most things in a separate BLooper to not make the ui super slow in the window where the replicant is added.
At some point mmu_man had the much simpler NetSurf running as a replicant. Even that was a quite complex and not very reliable thing.
Web technology looks nice and shiny, but it comes at the price of huge complexity under the hood.
Also, would a d clarative ui system really help? BLayoutBuilder already comes pretty close. Personally if I was to reduce the amount of code to write a native app, this is not where I’d look at first. I would rather add more SendNotices() calls in standard widgetsso an app can be wired together using StartWatching/SendNotices instead of manually dispatching messages. And maybe more importantly, implement something to avoid writing MessageReceived() functions manually: automatically turn message content into function arguments, and call an handler function directly with that. Now this would save writing a lot of boring code.
