1. 21
  1.  

  2. 5

    I remember the surprise at seeing KHTML then. I’d used Konquerer, but it encountered a lot of pages that it couldn’t render correctly, even then. It looked like more engineering effort than I would expect a company like Apple (remember, this was pre-iPhone, with Macs having around 7% of the market) to be able to afford. Hugely impressed with the vision of the folks behind all of the decisions that led to that point. Safari 1.0 was so much better than IE and was far less clunky than Camino on OS X, though not quite as nice as Opera, but eventually Opera’s pricing model pushed me away and I never left Safari on the Mac (though the last version is so buggy I might: it refused to connect to any UK government web sites recently for me, whereas Firefox and Edge on the same machine had no problems, and it increasingly often goes into a loop of crashing a renderer process and telling me that it has encountered a problem with a page, on large mainstream company web sites).

    1. 2

      Lots of people act like safari/webkit was just khtml, but the reality was that khtml was woefully behind gecko and trident, and it took a large amount of engineering effort to get compatibility to the level it had with safari’s first beta, let alone customer release.

      This isn’t to dump on the khtml folk: making a browser engine is a huge amount of work, and pre-whatwg/html5&es3.1 I would argue much harder than it is today. Obviously the modern web has much more API surface and features, but the piss-poor specifications from the w3c and ecma mean that basically every part of the browser had to be implemented by some variation of trial and error comparing behavior with gecko and trident. Nowadays you can follow along with serenity’s browser dev and their dev process often starts by copying the spec text in as a comment, and just implement that, and be fairly confident that it will be correct.

      If we want to be dismissive of the work apple engineers had to do to the underlying k* libraries it would be better to point to the ksvg2 code that was eventually imported as the svg implementation. That was much closer to just working as produced by the ode folk (Nicholas Zimmerman and rob buis iirc?) - most of the work in once in webkit was performance and security rather than rendering correctness (probably due to SVG being much stricter and having much more less content at the time). Obviously in the subsequent 15 years that has been rewritten as well, but the “it’s just khtml” claims re safari were never accurate, whereas “it’s just ksvg2” would have been reasonably accurate for at least 2 or 3 years of safari releases.

      1. 1

        I don’t mean to diminish that work in any way. I remember grabbing the tarballs of Apple’s KHTML fork (before they started developing it in the open) and comparing it against upstream and the changes were huge. Someone at Apple chose to commit enough engineers to a zero-revenue project to turn KHTML into something competitive and that was an amazing display of management foresight: I doubt the iPhone would have been possible, for example, without WebKit being mature.

        1. 1

          Sorry, I didn’t mean to say you were doing so - your comment was very clearly not - but seriously, even today I see people trying to say webkit/jsc is “just a khtml/kjs fork that did the real work”. I (and others) didn’t rewrite large swathes of everything multiple times to be dismissed as just being khtml/kjs :D

          Happily because the powers that be went for an open source base (Rather than a clean room), the webkit project (post-khtml’s reasonable “wtf with these tarballs” post), as that led pretty directly to my career :D

          1. 1

            The decision to take contributions to support other platforms was also very foresighted. I remember at one stage seeing over a dozen WebKit integrations, including S60 and other embedded platforms, in the main repo. It’s a real shame that Google decided with Blink to refuse to take patches for even platforms that are almost identical to their current ones (e.g. FreeBSD).

            1. 1

              I recall when the blink fork occurred and everyone talked about how much code they saved .. but no one seemed to ask what those code savings were (removing JSC, JSC DOM bindings, then the actual toolkit support: Qt, Gtk, Wx, etc). That said the cost of support for some of JSC JIT back ends was annoying back when I worked on it (many ifdefs for things like MIPS and SH4, because as much as you try to abstract things, fundamentally when dealing with CPUs directly you get squirrely stuff).

              My recollection of the pre-blink fork also had a fairly high workload from dealing with google folk who would come by, get enough patches in to get commit access (often make-work tasks like reformatting, “clean up”, “documentation”, or such), and then never be seen again. The rumor mill was that google was offering bonuses to people who go commit and/or review rights in webkit, which obviously just created make work churn for everyone else, as you’d help people get up to speed and then they disappeared once they got whatever checkmark they were after. It also meant that trying to keep track of who else was involved became hard (there were the actual competent and focused engineers, but they were drowned out by the constant churn of people with no long term interest in participation).