Good strategy for a frontend

[bigfatbird]

I was wondering what the initial architecture for the frontend/ui could be like?

Should you create a native hi for each major os, or write once run everywhere like electron (you said you didn't want that)?

I could have a look into a simple macOS gui in the next few days, so there could be something clickable

[jaytaph]

I think there are a few things we need to take into account:

• we (will) have a gosub-engine that does the most work
• we have user-agents that will display the data and act with user input

I haven't looked into how engines like webkit and gecko and even chromium do this, and how they communicate with the user agents. My initial idea was to see if we can create a (relatively simple) text user agent, as this sounds the least work, but a graphical user-interface is ultimately what it should become.

I sounds like a browser should be native, to give the most flexibility and performance, but I think we should define first what would be part of the engine, and what would be part of the user agent, and how we would communicate between them.

[neuodev]

I think:

• User Agent should: interact with the server (HTTP) and the engine to serialize the files. Decide how to render the "structured" response from the engine.
• Engine: Serialize the files and send a "structured" response

[neuodev]

The model I am description is too "simple" and fails capture how modern browsers works. The engine has more to do with more than "serializing" the files. It can have databases, session storage management, or even another "wasm" engine.

I would say. it will be really great if we can have a working e2e solution. this is far more important than worrying about the future.

A fully working text based browser (only parsing html, css) will be great and we can take things further from their.

[jaytaph]

I haven't read into what we would need for the different systems and how they communicate. I can image that a DOM-tree would be the output of the engine, and this would be passed to the server. But for instance, when we deal with cookies, is that a UA thing, or a engine thing?

It would be nice to have some people figure out more about the complications and what we would need. I'm not worried about rendering pages correctly, but I'm curious how it would work with different tabs/sessions, the v8 engine (assuming we use that one for javascript), etc.. I think the goal would be to be able to browse a site, and render a dom-tree in the user-agent.. maybe even have clickable links (since we process a-tags without issues at that moment).. and work from there.

[hugmatj]

Slow kid question - UA in this case refers to…

[Sharktheone]

UA = User Agent

[Juses24]

I think a strategy is a plan of actions designed to achieve a long term or overall aim

[hugmatj]

I going to use this line one day. Outstanding.

[emwalker]

I'd pitch for investigating these topics before getting too far into this question:

• How does Chromium interact with the app layer?
• How does Gecko interact with the app layer?
• How does Servo interact with the app layer?

Seems good to research this topic in advance, as I can imagine you could paint yourself into a corner with the wrong starting assumptions.

[jaytaph]

Agreed with @emwalker. A lot more research is needed on many different topics, but I wouldn't be afraid to experiment with different components at this moment. Writing small proof of concepts gives us just like doing research some insights in the problems we will face later on.

I don't expect a complete rewrite of the codebase in say a year, but I do think that with knowledge gathered during the year, we should rewrite some parts in order to give it a more stable foundation.

I don't want to create a million pages, but it might be nice if we have a place where we can bundle research (links, notes etc) together. I'm not sure that github is the correct place for this though.

[bigfatbird]

I will start to implement a POC-Frontend in Swift and SwiftUI in the coming weeks

[Kiyoshika]

I'm also on MacOS so I can help with testing, but I don't know anything about Swift

[bigfatbird]

@Kiyoshika Me neither 😅

[jaytaph]

Would it be possible to incorporate webrender into swift? I thnk it would be a good addition to use this renderer so we could focus on the other parts of the browser

[bigfatbird]

I know there's at least https://lib.rs/crates/swift-bridge , so there can be some overlap between rust and swift.

I haven't don't much macOS-dev yet, there's much to learn. When I have the first prototype of a working app I'll see if I can add the parser to it, so we can at least display the output somewhere in the gui.

[bigfatbird]

• https://burgers.io/calling-rust-from-ios

• https://www.strathweb.com/2023/07/calling-rust-code-from-swift/

• https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-06-rust-on-ios.html

• https://blog.mozilla.org/data/2022/01/31/this-week-in-glean-building-and-deploying-a-rust-library-on-ios/

I also found this

[jaytaph]

Gecko: https://wiki.mozilla.org/Gecko:Overview

[hugmatj]

While going through the readme the line “communicate via sockets or something” made me think about another new-ish project
https://github.com/socketsupply/socket. Their vibe seems like it might be similar to y’alls, possibly. Other supposing the projects feel similar I dont have anything other than encouraging wishes to add (apologies). GL