Maybe it's just me, but from time to time I try latest Servo build and it never survives more than few minutes of usage before crashing. Last time I did it was 3 days ago, I opened a website and it crashed with "RefCell already borrowed" in what seems to be a logger module. This always strikes me as weird because one of the selling points for Rust is memory and thread safety (quote from the website: "eliminate many classes of bugs at compile-time").
Yes it's safe but undesirable, like Java's NullPointerException.
A more interesting question is why it was not possible to use compile time borrow checking in this particular case. It shows how valuable the borrow checker is when you can use it.
I think Servo's killer application would be a mobile-first browser for postmarketOS/Mobian/other mobile Linux distros. It's a weird vacuum because Firefox has its Android port, but when you run Firefox on small linux (touch)screen, the experience is very suboptimal. I'd call it unbearable if it wasn't for bunch of tweaks in form of https://gitlab.postmarketos.org/postmarketOS/mobile-config-f...
Chrome is no better, as it has a very weird hardcoded minimum window width of 500px.
I've long thought its killer feature would be embeddable cross-platform UI and native-wrapped web apps like Electron and Capacitor. For these cases it doesn't need to render the entire public web, but the subset used by the application developers. It's a much more tractable problem.
Chrome had a project a long time ago called Razor whose goal was to make a 120fps streamlined subset of the web platform for those types of use cases. They tried to throw away warts of the web that slowed down parsing and rendering like quirks modes, floats, negative margins, infinite entity expansion, element adoption, and probably most built-in elements, leaving a few core built-ins and custom elements.
Razor apps could have run on the web, and in a Razor runtime. Unfortunately, IMO, they kept removing things until they removed the document, and swapped in Dart for JS and the project became Flutter which is not very web-like at all.
I thought Razor was a neat idea, and Servo could really fill that space well.
Fascinating, and I’ve been working on a native UI project I call Figuro for a couple of years now (1) that’s built on the idea of simple nodes.
It’s surprising how similar to HTML it’s becoming. I feel like it's sorta an inverse of the Flutter story. Lately I’m working on adding a subset of CSS. Adding padding and margins too seems like a good idea too, etc. Part of me wonders how much of a webpage I could render with it.
Yes this is the ideal space for a performance minded web rendering engine rewrite.
And if you do it well enough as a subset it can become the next standard where the modern web is just the subset, you can even integrate it with a legacy render where you fall back to legacy when you detect you cant handle it, and have the fast path for the subset.
Didn’t realize that was the backstory of Flutter, I thought this was headed in a different direction.
I heard the YouTube team did something similar for their embedded / resource-constrained environments where the client just renders barebones HTML/JS and only what is needed is implemented in the engine.
That's also an unfortunate story, because they've really lagged on adding features in the past because they generally have no way to update the engine on TVs. So any new feature would take 5-10 years to be usable.
So almost 10 years ago they didn't invest in some core things like web components, and they could have used them by now if they did.
The minimum window width is a funny thing, Chrome has been steadily raising the minimum every time they make changes to the UI. It used to have a minimum around 320px and now on some configurations it's nearly 800px. There's an old open bug about it where people periodically comment to complain that it was raised again.
We are a very small team and rely on maintainers to actively look after a frontend. For example Chris does a brilliant job keeping the Amiga frontend in shape and I keep GTK going. Other frontends like Windows, RISC OS and Atari lack a maintainer altogether and are kept going purely through inertia.
Unfortunately the Mac OS X frontend became unmaintained some time ago and eventually stopped working altogether which resulted in its removal from the master branch and hence releases.
I was wondering if one could build an alternative Electron with Duktape and Netsurf's rendering engine and what the memory footprint would be? Most Electron apps don't even use animations and they could be "backported" to HTML4 and CSS2 :-) Webviews are kind of great for portability, but having full blown HTML5 is overkill for most of the apps.
I did it with Sciter as a UI layer of Node.js (I am an author of Sciter)
Sciter.Node.js takes 30 Mb or RAM in minimal configuration.
It adds 4mb (sciter.dll/so) to original Node.js distribution.
It runs all windows in single UI thread - main thread of Node.js so there is no need for marshalling between multiple processes as in Electron case.
In fact sciter.dll is a "node.js" by its own - it contains script VM and libuv - the same as Node.js itself uses.
I am considering the option to make strip down version of sciter for Node.js. That version will not have any scripting but will rather use JavaScript and libuv from Node.js.
This reminds me of Elchemy (https://github.com/wende/elchemy) which uses the Elm compiler to output "readable" Elixir. I wonder if anyone has played with both and can compare them?
What's even worse is that the install script at https://www.opscode.com/chef/install.sh is also unavailable, which is the default way of getting chef installed onto newly provisioned server.
The author of the article seem to think that a good iOS icon is a one that uses a perspective trick to produce a faux 3d effect. I'm not sure these are very usable when sized down to 57x57 pixels which is default iPhone icon size (double that for retina).
