4 ms·

Unlike IE, Chrome initially built off WebKit, so a lot of the work in writing a renderer was already done. Obviously a lot of work with V8, multiprocess IPC, e

Unlike IE, Chrome initially built off WebKit, so a lot of the work in writing a renderer was already done. Obviously a lot of work with V8, multiprocess IPC, etc. still went into the effort but still easier than starting from scratch like what IE did.

ubercore 4y ago
IE started with Mosaic, no?
- jerrygoyal 4y ago
  a lot of work with great UX as well
- kryptiskt 4y ago
  It started with Spyglass, who were Mosaic licensees, but apparently wrote their own code. The story of Spyglass is told here https://ericsink.com/Browser_Wars.html https://ericsink.com/Browser_Wars.html "Management made the decision to transition our business completely and pursue the market for web browsers. Tim Krauskopf, the founder and head of development, asked me to write a web browser. I started work on Spyglass Mosaic on April 5th, 1994. The demo for our first prospective customer was already on the calendar in May. I ended up as the Project Lead for the browser team. Yes, we licensed the technology and trademarks from NCSA (at the University of Illinois), but we never used any of the code. We wrote our browser implementations completely from scratch, on Windows, MacOS, and Unix. We were not the first Mosaic licensee, but we were the last. Prior to us, a company called Spry took the Mosaic code and tried to sell "Internet in a Box". People still seem to get Spry and Spyglass confused because of the similar names." "Internet Explorer 2.0 was basically Spyglass Mosaic with not too many changes. IE 3.0 was a major upgrade, but still largely based on our code. IE 4.0 was closer to a rewrite, but our code was still lingering around -- we could tell by the presence of certain esoteric bugs that were specific to our layout engine. Licensing our browser was a huge win for Spyglass. And it was a huge loss. We got a loud wake-up call when we tried to schedule our second conference for our OEM browser customers. Our customers told us they weren't coming because Microsoft was beating them up. The message became clear: We sold our browser technology to 120 companies, but one of them slaughtered the other 119."
olliej 4y ago
While this is true, and I'm generally fairly anti-chrome, this does disregard a huge amount of very real, and very hard engineering work. I think V8 was not actually that complicated - a lot of the "deep" computer science they originally wrote and talked about in marketing material was from the 80s, and things like the hidden classes were picked up almost immediately by JSC at least (as in just a few weeks of non-crunch time). The original JITs for V8 and subsequently JSC were essentially template JITs, i.e not particularly complicated (for JSC the big issue was having to support x86, x86_64, and Thumb2, and managing the security implications on iOS). Even the GC imo wasn't super impressive. The primary reason that Spidermonkey and JSC didn't have the JIT or hidden shape concepts wasn't engineering complexity, but simply that at the time the apparently important perf problems were with other parts of JS and the DOM - so huge numbers of objects (the argument for generational GC), and non-dom property access (which recall was not optimized in V8 at the time) were just not considered that important compared to other parts of JS and the browser. But when you get to WebCore and the browser the Chrome folk did a lot of very hard work, the process separation was also conceptually simple, but practically a huge amount of very complex work. You can contrast the difference in time it took to get JS engines performance up to the same order as V8 vs the time it took any degree of process separation in WebKit and Gecko. The first multiprocess Safari was just two processes, the app, and the render process - just getting WebKit going with a single separate render process was a lot of work, it was at least two full releases before true multiprocess was a thing in WebKit (WebKit's multiprocess model makes the process separation part of the engine, vs. the blink model of having the app be responsible). Then for sandboxing, WebKit obviously got to leverage the Mac+iOS sandboxing that was built into the system. The chrome folk had to build an entire sandboxing system for windows, without kernel support, or in fact any support. Which was another gigantic amount of work. So kudos to the chrome team, they did a lot of work, and a lot of it was very hard, and shouldn't be reduced or dismissed.

ubercore 4y ago

IE started with Mosaic, no?

jerrygoyal 4y ago
a lot of work with great UX as well
kryptiskt 4y ago
It started with Spyglass, who were Mosaic licensees, but apparently wrote their own code. The story of Spyglass is told here https://ericsink.com/Browser_Wars.html https://ericsink.com/Browser_Wars.html "Management made the decision to transition our business completely and pursue the market for web browsers. Tim Krauskopf, the founder and head of development, asked me to write a web browser. I started work on Spyglass Mosaic on April 5th, 1994. The demo for our first prospective customer was already on the calendar in May. I ended up as the Project Lead for the browser team. Yes, we licensed the technology and trademarks from NCSA (at the University of Illinois), but we never used any of the code. We wrote our browser implementations completely from scratch, on Windows, MacOS, and Unix. We were not the first Mosaic licensee, but we were the last. Prior to us, a company called Spry took the Mosaic code and tried to sell "Internet in a Box". People still seem to get Spry and Spyglass confused because of the similar names." "Internet Explorer 2.0 was basically Spyglass Mosaic with not too many changes. IE 3.0 was a major upgrade, but still largely based on our code. IE 4.0 was closer to a rewrite, but our code was still lingering around -- we could tell by the presence of certain esoteric bugs that were specific to our layout engine. Licensing our browser was a huge win for Spyglass. And it was a huge loss. We got a loud wake-up call when we tried to schedule our second conference for our OEM browser customers. Our customers told us they weren't coming because Microsoft was beating them up. The message became clear: We sold our browser technology to 120 companies, but one of them slaughtered the other 119."

olliej 4y ago

While this is true, and I'm generally fairly anti-chrome, this does disregard a huge amount of very real, and very hard engineering work. I think V8 was not actually that complicated - a lot of the "deep" computer science they originally wrote and talked about in marketing material was from the 80s, and things like the hidden classes were picked up almost immediately by JSC at least (as in just a few weeks of non-crunch time). The original JITs for V8 and subsequently JSC were essentially template JITs, i.e not particularly complicated (for JSC the big issue was having to support x86, x86_64, and Thumb2, and managing the security implications on iOS). Even the GC imo wasn't super impressive. The primary reason that Spidermonkey and JSC didn't have the JIT or hidden shape concepts wasn't engineering complexity, but simply that at the time the apparently important perf problems were with other parts of JS and the DOM - so huge numbers of objects (the argument for generational GC), and non-dom property access (which recall was not optimized in V8 at the time) were just not considered that important compared to other parts of JS and the browser. But when you get to WebCore and the browser the Chrome folk did a lot of very hard work, the process separation was also conceptually simple, but practically a huge amount of very complex work. You can contrast the difference in time it took to get JS engines performance up to the same order as V8 vs the time it took any degree of process separation in WebKit and Gecko. The first multiprocess Safari was just two processes, the app, and the render process - just getting WebKit going with a single separate render process was a lot of work, it was at least two full releases before true multiprocess was a thing in WebKit (WebKit's multiprocess model makes the process separation part of the engine, vs. the blink model of having the app be responsible). Then for sandboxing, WebKit obviously got to leverage the Mac+iOS sandboxing that was built into the system. The chrome folk had to build an entire sandboxing system for windows, without kernel support, or in fact any support. Which was another gigantic amount of work. So kudos to the chrome team, they did a lot of work, and a lot of it was very hard, and shouldn't be reduced or dismissed.