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 
Thanks, i knew about this, but my opinion is: every tech which increases complexity is harmful, therefore i wont touch it.
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.
I bet they said this to the guy who invented the wheel 
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.
If you refer to a GUI that uses a layout language as the basis for its engine as declarative, I’m all for it. It’s difficult to combine and optimize widgets that superclass a button for each click zone. I’ve devised an algorithm that combines all click zones into a grid layout whose x and y coordinates are stored in a fixed length array for each direction. This means that the x layout and the y layout can be processed independently of the handles in the 2d grid, which are invariant after the initial layout.
If it would be desirable, I’ll describe it in greater detail. The general idea is that the x array and y array is recomputed for the resize operations just like vertex shaders are in 3d engines. The rows and columns are invariant as the models being drawn by the 3d engine would be.
One thing I’d like to look at, given I now have a semi working 64bit install of Haiku, is getting something like Xaml to design UI for Haiku. We are not talking full on MVVM here, just the ability to create a Xaml style document that represents the UI and get Haiku to generate that Document at runtime for display and binding. To do it, I might need to subclass some of the controls, as it would be a lot easier if there was a way to define the path to the event callbacks. But I think it might be possible to do that via a BWindow descendent. The one thing it needs is auto layout, but I think Haiku has that now, right?
Indeed, Haiku has a layout API: The Haiku Book: Introducing the Layout API.
Your suggestions of using XAML is interesting, following step would then be creating a QT Creator like window editor.
Something similar to ALE? https://depot.haiku-os.org/#!/pkg/ale/haikuports/0/9/1/-/6/x86_64?bcguid=bc230-CXAV
Maybe. Xaml is an Xml based format, so I would imagine it is similar to other similar layout systems. A BAPI version might be like:
<BWindow Title="A window">
<BView Name="My view">
<BButton Text="Click me" Clicked="ClickHandler" />
</BView>
</BWindow>
The ClickHandler would be a method with a known signature, probably mapped in from the App or the BWindow by some convention. The Xaml is more than that though, it allows namespace mapping and data binding. I would just have a look and see what is possible.
This is what I meant by declarative UI code, and QML is similar. But as pulkomandy suggested there might be some other lower hanging fruit to improve other aspects of the Haiku UI code before adding a new UI language. With BLayoutBuilder the C++ code can be pretty decent and similar to XAML and QML is some respects:
Re:GUI Layout engine
What I had in mind was something like the SixtyFPS GUI engine whose language is entirely external to the source file so it can be used in different programming languages without modification. Also, a GUI language can transpile into a more integrated structure than raw object-oriented components using custom optimization passes. As @memsom suggested, it could be XML to keep the parser easier to implement using using some XML library. Of course the SixtyFPS GUI engine is GPL so it shouldn’t be used directly in the OS but something similar to it like GXI would be MIT licensed.