Hello everyone, I've been working on a tiny web engine (if you can call it that), called Ferus. It did get mentioned in the Nim Blog's May&April update, but at that time it didn't even have proper layout. Now, a few weeks after that, we've added a ton of new stuff. Ferus is designed to be anti-monolithic by design and all of most of it's useful components are split up into small libraries (ferushtml, ferusgfx, and very soon, ferusjs and feruscss) so that they benefit the Nim ecosystem as a whole. I am a student working on this as a hobby project though, mostly for fun, and worst of all, with very little HTML/CSS experience. Ferus also has another goal, that is, to embrace parallelization. This goal is not in effect right now as I and a few others cobble things together.
Here's the already existing features
Here's some new changes in Ferus and I'd like to hear everyone's opinions and feedback.
Here's what I want Ferus to do soon
And a few distant goals
And, now it is time to talk 'bout ferusgfx, our new rendering backend. It's hardly complete right now, but essentially, here's what the thought process is:
Here's the repos for all of ferus: https://github.com/xTrayambak/ferus https://github.com/xTrayambak/ferushtml https://github.com/xTrayambak/ferusgfx
Always great to see more browser engines in development.
I've been working on a similar project for a while, and only recently released it; maybe you will find it interesting. Though our end goals are different (I target terminals), and my approach is in large part "NIH for fun", so it's more of a monolithic repository with everything under the sun included (not unlike SerenityOS, though obviously much more limited in scope).
Anyways, the repository can be found here: https://git.sr.ht/~bptato/chawan
It has complete HTML5 parsing, (somewhat limited) CSS cascading + layouting, and also a (rather limited) DOM interface with automatic JS binding generation. Feel free to look around and take whatever you find useful.
(Also, a tip on HTML5 parsers: if you roll your own, base it on whatwg's standard. I initially tried to make a "good enough" parser, but that way lies madness: you'll be forced to figure out all the weirdness IE and friends introduced over the years yourself, or perpetually run into edge cases where your parser does something different than others do.)
That's super nifty!
Checkout my cssgrid implementation. It's designed to be pluggable via a generic "rect/box" type you provide.
That's an interesting project to stress-test Nim.
Just some ideas:
Would be interesting to have <script type="Nim">echo "Hi"</script>
You can test Fersu Compatibility with randomly generated HTML & CSS, take screenshot in Ferus and Chrome, and compare images.
A C U S T O M W E B B R O W S E R
Hopefully that shouldn't be the case, and should actually lead to more modular and better maintainable code. If needed a package can be forked, but even then code can be shared, but that could be the worst case scenario.
Here are the packages used by Chromium, as an example: https://www.chromium.org/chromium-os/packages/