Earlier quoted context omitted.
I just don't get the point of ladybird. They have full time engineers and are soliciting donations, so it's clearly more than a hobby project. Maybe my assumptions are off, but I just can't imagine they could ever become competitive in terms of features, security and performance with the big engines. Blink is setting the pace, Webkit is barely able to keep up and Gecko is slowly falling behind. All of these teams are…
Ladybird has better results in web rendering tests than Servo, and slowly is gaining on Firefox. They are already quite competitive.
I tried Servo
191–200 of 256 posts
Re: I tried Servo
#192> This is a danger to the open web in more ways than one. If there is only one functioning implementation of a standard, the implementation becomes the standard. I still don't understand why this is a problem. As long as the engine implementing the spec - governed by committee formed by entities other than Google itself - is open source. The problem and the waste of resource is how we are behaving now. The browser en…
Maybe worse is what we need to realize that many of the W3C and WHATWG standards are past the point of saving, and those organisation are no longer a good avenue for further advancement of the web.
Re: I tried Servo
#193I feel like Mozilla is going to join the annals of history with the likes of Xerox in the category of "Companies that created the technology of the future and casually tossed it to the wayside for competitors to scoop up" with Rust and Servo. It's mind-boggling that for a company so often seemingly playing catch-up with Google, Mozilla actually leapfrogged Google in the browser development space for a time, and then.…
It's dishonest to compare that to "the technology of the future", especially when nobody chooses their browser based on whether a page loads in 82ms or 70ms. They mostly choose browsers based on familiarity and marketing and what's preinstalled. Chrome is fast enough for most people that they're not gonna switch just because their dweeb nephew mentioned some other browser might be marginally faster.
And they didn't toss Rust aside either. New bits of Firefox continue to be written in Rust to this day. That was actually the primary reason Servo was dropped - the bits of the browser engine that could be replaced with Servo bits easily had already been replaced. Rewriting Gecko slowly was deemed more practical than committing to 5+ years of parallel development and hoping that by the end it would be possible to replace millions of lines of Gecko code in one fell swoop.
Re: I tried Servo
#194Earlier quoted context omitted.
If Mozilla decides to dump Gecko, then it's time for a hard fork and an abandonment of Mozilla. Maybe it's time now. edit: I mean dumping Gecko for Chromium, not Servo.
Honestly, dumping gecko would be a suicide for Firefox. Much of Firefox's minuscule userbase consists of knowledgeable nerds who are holdouts from the Blink monoculture.
Maybe their primary addressable market is nerds, but I guarantee more people quit using Firefox because of websites not working correctly or Google's marketing than because of any of the things that HN loves to complain about.
Re: I tried Servo
#195Earlier quoted context omitted.
> I want to (1) build blindingly fast, low-latency, super performant UX for users, … (2) maintain developer velocity, (3) have access to nice UX primitives and widgets … (4) have it look nice and modern. Find me when you find this, because I actually think it is impossible. I think there is fundamentally too much inherent complexity to abstract away to keep 2 and not sacrifice 1. Specifically for something properly c…
I believe it’s possible, but it’s going to take a little bit of outside of the box thinking in that it’d be most practical if the UI toolkit isn’t bound strictly to a single paradigm. Both imperative and declarative UIs have serious problems. Imperative toolkits can get hairy with their boilerplate and can make staying in sync with data state a real challenge, while declarative toolkits have a strong tendency towards…
But as you alluded to, data binding can be difficult. For some things, and even most web pages fall into this, you effectively load the data up front render something and then don’t touch it again, on change you can absolutely just rerender everything because it is truly trivial to render.
But for other things you need extremely complex data binding with constraint systems and things are extremely complex to render (CAD, Games, etc). For that you need cacheing and partial updates etc
These is a spectrum between that and I just don’t see the ability to abstract over it.
And taking a11y into consideration no matter how you choose to render you also need to construct a tree or graph for screen readers, this also needs data binding. You will probably also be tying keyboard navigation to that graph (other than for a game but even then maybe)
I feel like though a lot of performance problems on web is 1) people not understanding fundamentally how expensive certain operations are 2) lack of hardware acceleration for some vector operations in CEF / browsers
For 1 just think about some UI element, a rounded button or something. A mesh had to be dynamically generated for that UI element and then drawn, if you for some reason are causing that mesh to be regenerated every frame that becomes expensive very quickly.
Text is generally generated on the fly and cached as well, if its not software rendered.
Once you get down to the nuts and bolts modern UI is a complex problem, and to build a framework for that, you need to get into the nuts and bolts.
We’re not even discussing rendering APIs yet…
Re: I tried Servo
#196Like many HN readers, I have read countless accounts of web browsers and web browsing over the years.
Unfortunately, I cannot recall even one that took an account such as this one and concluded something like, "We need to modify the Google and MacRumors pages so they work with Servo." Unfortunately, the conclusion is usually something like, "We need to fix Servo so it works like Chromium/Chrome."
The reason I believe this is unfortunate is that (a) it ultimately places control in an ad services company and (b) it creates the wrong incentives for people who create web pages. Pages could be modified to conform to what Wikipedia, CNN Lite, the author's personal site and text-only NPR have done. This is not difficult. In fact, it is easier than modifying Servo to do what Chromium/Chrome is doing.
IMO, the "standard" web browser should not be effectively defined by an ad services company (including its business partner, Mozilla) nor should the standard for a web page be defined by the "most popular" web browser, To me "popular" and "standard" are not necessarily the same. Web _pages_ (cf. web _browsers_) should work with unpopular browsers and popular browsers alike, According to OP, Wikipedia, CNN Lite, the author's personal site, and text-only NPR may meet the standard.
In sum, fix web pages not web browsers.
As a hobbyist, I still compile and experiment with w3c's original libww library and utilities. Below is short script I use to compile static binaries. With a TLS forward proxy these utilities, with few modifications, if any, can still work very well for me for retrieving web pages on today's web. (I am only interested in learning www history and optimising text retrieval, not graphics.) This library is generally "ancient" on the www timescale and yet it still works 30 years later. That's useful for www users like me, but maybe not for the online ad services companies and sponsored web browsers optimised for data collection and surveillance. Internet is supposed to be a public resource not a private one, i.e., highest priority of www pages and www browsers should be to serve www users not online ad service providers.
# previous: download and compile w3c-libwww-5.4.2
pwd|grep "w3c-libwww-"||exec echo wrong directory
export x=$(pwd)
export examples=$x/Library/Examples
export linemode=$x/LineMode/src
export commandline=$x/ComLine/src
export robot=$x/Robot/src
y="
libwwwinit.a libwwwapp.a libwwwhtml.a
libwwwtelnet.a libwwwnews.a libwwwhttp.a
libwwwmime.a libwwwgopher.a libwwwftp.a
libwwwdir.a libwwwcache.a libwwwstream.a
libwwwfile.a libwwwmux.a libwwwtrans.a
libwwwcore.a libwwwutils.a
$x/modules/md5/.libs/libmd5.a -lm"
cd $x/Library/src/.libs
for z in
head libapp_1 libapp_2 libapp_3 libapp_4 init chunk
chunkbody LoadToFile postform multichunk put post
trace range tzcheck mget isredirected listen
eventloop memput getheaders showlinks showtags
showtext tiny upgrade cookie
do
gcc -s -static -O2 -Wall -o $examples/$z $examples/$z.o $y
done
gcc -static -s -O2 -Wall -o $linemode/www
$linemode/www-HTBrowse.o $linemode/www-GridText.o
$linemode/www-ConView.o $linemode/www-GridStyle.o
$linemode/www-DefaultStyles.o
$x/PICS-client/src/.libs/libpics.a $y
gcc -static -s -O2 -Wall -o $robot/webbot
$robot/webbot-HTRobot.o $robot/webbot-RobotMain.o
$robot/webbot-RobotTxt.o $robot/webbot-HTQueue.o $y
gcc -static -s -O2 -Wall -o $commandline/w3c
$commandline/w3c-HTLine.o $y
# next: symlink binaries to a folder in $PATH
# or export PATH=$PATH:$examples:$commandline:$robot:$linemodeRe: I tried Servo
#197I feel guis have taken a wrong turn. We need a simple composable language. I want entire theorems built from the least amount of axioms possible. HTML and css is not it. The sheer complexity is what causes all the bs.
Re: I tried Servo
#198> This is a danger to the open web in more ways than one. If there is only one functioning implementation of a standard, the implementation becomes the standard. I still don't understand why this is a problem. As long as the engine implementing the spec - governed by committee formed by entities other than Google itself - is open source. The problem and the waste of resource is how we are behaving now. The browser en…
> The browser engine should become as the Linux Kernel: one engine and different distros. Try spending a month with a BSD - personally, I recommend OpenBSD, or (yes) macOS. Alternatively, try ZFS where you've previously used mdadm+lvm+luks+etc. The difference is like sitting in a chair that has all of its screws tightened. You only notice how bad was your previous chair once you feel there's no wobbling.
I vastly prefer the OpenBSD kernel too, but if you use a distro that does things properly such as NixOS, the BSDs are the ones that feel wonky.
Re: I tried Servo
#199Earlier quoted context omitted.
I believe it’s possible, but it’s going to take a little bit of outside of the box thinking in that it’d be most practical if the UI toolkit isn’t bound strictly to a single paradigm. Both imperative and declarative UIs have serious problems. Imperative toolkits can get hairy with their boilerplate and can make staying in sync with data state a real challenge, while declarative toolkits have a strong tendency towards…
I’ve been thinking about this myself and really UI development is mostly about design up front, many times with a well built design system UI changes can be trivial. But as you alluded to, data binding can be difficult. For some things, and even most web pages fall into this, you effectively load the data up front render something and then don’t touch it again, on change you can absolutely just rerender everything be…
I also think that UI frameworks try to hard too be “magic” and unopinionated where they should instead be highly communicative and naturally guide developers into the happy path. So following your example of the excessively re-rendered button, the framework should really be detecting the unneeded redraws and complaining to the dev about them and potentially even presenting as compiler errors in production builds until they’re fixed (which the compiler offers hints on how to do).
Re: I tried Servo
#200Earlier quoted context omitted.
Ladybird has better results in web rendering tests than Servo, and slowly is gaining on Firefox. They are already quite competitive.
In the update videos posted on the Ladybird YouTube channel it's said that they have exhausted most of the low hanging fruit in terms of correctness. Browsers and the web standard have a very long tail of odd behavior that you need to implement. I could be wrong, but if I had to guess they'll stall at a point where it's just good enough that some people will make it work, but it's not really useful for general use.
Since a couple weeks ago it became possible to view all major commercial news websites I use in my country.
If it works for most websites and you only have to reach for Chrome sometimes it would still be perfectly usable.