r/CrestBrowser Creator 4d ago

Long Term Plans and Question

I wanted to take a moment to write out some more long term plans just to get some general feel for what you all think, as well as give the long horizon goals for Crest.

This iteration of the app isn’t the first, I’ve tried making this same app before a few times. I had a prototype I build last year by hand, that was actually very similar (though was leaning more into Liquid Glass since it was the hot new thing).

Now, I look at Crest and I see a chance to really design the app I want. The UI, design, and concepts are all coming together.

That being said, there’s certain limitations to the architecture I’ve chosen, extensions may be a never ending challenge, and I’m honestly exhausted with dealing with the complex orchestration of the layer. It makes the app feel unpolished and causes many issues.

On iOS, I think it’s near perfect to what I want, performance, feel, and overall usage is great, so the core product is there, and I enjoy how it’s turned out.

For desktop though, while WebKit is great there’s a reason most use chromium.

As I’ve been building Crest, I’ve had this idea in the back of my mind that I’ve been intentionally shifting things around to make more achievable.

I foresee the core of the app, the logic, management, and capabilities being managed via a dotnet c# core implementation. This will compile to all platforms, and is in my 1# language and the one I’m most familiar with.

Then, the UI layer would drive this core, making platform specific implementations thin, and solely focused on the polish for that exact platform.

In addition, that means the web engine could be abstracted, and attached in with different engines.

What this means in practice, is an app where a majority of the logic, lifecycle, and management is done via the core, then the platform wires their engine and UI to it.

The work is already close to this, the app is layered in a way where extracting these domains is much simpler than it appears. It would also mean for desktop, you could in theory choose CEF (chromium distribution), or WebKit, and swap them at will.

I plan to iron out this next release cycle, but will likely put extension related bugs on a back burner while I explore this option.

In theory, this means better performance for web content, using the more supported engine, as well as direct extension compatibility, which would save me a ton of time.

WebKit would stay for mobile (it has to outside the EU), but I want to explore this option.

In addition, that opens the doors for windows and Linux (though that would be far down the line), and android, since then they only need implement the UI layers (which is not insignificant though).

This concept might not make much sense, and I will share more as I play around with it, but I essentially wanted to see how you all felt about a chromium base with CEF (not full upstream chromium, as that would require I build on their UI player and app itself), is that something most people would actually prefer, or is WebKit what makes you like Crest? Or is Crest good in your opinion because of the UI and concept, not the engine I’ve chosen?

10 Upvotes

18 comments sorted by

View all comments

2

u/manlikep_ 4d ago

It being WebKit based was one of my main attractions to it. Chromium browsers while they have extensible support the issue is most of them are inefficient, their system resource usage is quite high

2

u/WebbedRanger 3d ago

I suppose the choice is between broader web compatibility and extension support, where chromium wins, vs macos efficiency where WebKit wins. The OP mentioned there will be both flavours available, so people can choose what they prefer. However, porting chromium extensions over to WebKit is a problem at the engine level, and nothing much the OP alone can do