Support NeoGAF

[Vanillalite]

1st up Early in the Day Mozilla...

Mozilla and Samsung Collaborate on Next Generation Web Browser Engine



Mozilla’s mission is about advancing the Web as a platform for all. At Mozilla Research, we’re supporting this mission by experimenting with what’s next when it comes to the core technology powering the Web browser. We need to be prepared to take advantage of tomorrow’s faster, multi-core, heterogeneous computing architectures. That’s why we’ve recently begun collaborating with Samsung on an advanced technology Web browser engine called Servo.

Servo is an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s massively parallel hardware to enable new and richer experiences on the Web. To those ends, Servo is written in Rust, a new, safe systems language developed by Mozilla along with a growing community of enthusiasts.

We are now pleased to announce with Samsung that together we are bringing both the Rust programming language and Servo, the experimental web browser engine, to Android and ARM. This is an exciting step in the evolution of both projects that will allow us to start deeper research with Servo on mobile. Samsung has already contributed an ARM backend to Rust and the build infrastructure necessary to cross-compile to Android, along with many other improvements. You can try this now by downloading the code from Github, but it’s just the beginning.

Rust, which today reached v0.6, has been in development for several years and is rapidly approaching stability. It is intended to fill many of the same niches that C++ has over the past decades, with efficient high-level, multi-paradigm abstractions, and offers precise control over hardware resources. But beyond that, it is *safe by default*, preventing entire classes of memory management errors that lead to crashes and security vulnerabilities. Rust also features lightweight concurrency primitives that make it easy for programmers to leverage the power of the many CPU cores available on current and future computing platforms.

In the coming year, we are racing to complete the first major revision of Rust – cleaning up, expanding and documenting the libraries, building out our tools to improve the user experience, and beefing up performance. At the same time, we will be putting more resources into Servo, trying to prove that we can build a fast web browser with pervasive parallelism, and in a safe, fun language. We, along with our friends at Samsung will be increasingly looking at opportunities on mobile platforms. Both of these efforts are still early stage projects and there’s a lot to do yet, so now is a good time to get involved.

To take a look at what we’re doing and contribute to the projects you can download and try the recently-released Rust 0.6 or check out the source for Rust and Servo on GitHub. Then come participate in the development process on the Rust (https://mail.mozilla.org/listinfo/rust-dev) and Servo (https://lists.mozilla.org/listinfo/dev-servo) mailing lists.

- Brendan Eich, CTO, Mozilla



Chromium Blog

Blink: A rendering engine for the Chromium project



WebKit is a lightweight yet powerful rendering engine that emerged out of KHTML in 2001. Its flexibility, performance and thoughtful design made it the obvious choice for Chromium's rendering engine back when we started. Thanks to the hard work by all in the community, WebKit has thrived and kept pace with the web platform’s growing capabilities since then.

However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit.

This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.

In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.

Throughout this transition, we’ll collaborate closely with other browser vendors to move the web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency.

To learn more about Blink visit our project page.

Posted by Adam Barth, Software Engineer

 

[Leucrota]

So many rendering engines. I will use whatever one works the best.

 

[Why would you do that?]

FWIW, it has been revealed that Blink is the rendering engine Opera is switching to, not WebKit.

 

[Valnen]

Firefox for life.

 

[$200]

But will this make the new Firefox better than 3.6?

 

[reilo]

That's good news, I suppose. There comes a point in a software's lifecycle where improving it and expanding it just becomes too cumbersome at the cost of performance and so forth.

 

[lenovox1]

That's good news, I suppose. There comes a point in a software's lifecycle where improving it and expanding it just becomes too cumbersome at the cost of performance and so forth.

And Gecko has been dusty for a long time. A slimmer, more efficient platform that works better on all the devices Mozilla wants to be on is a great next step.

 

[Blackhead]

Lol, the Opera folk must be scratching their heads on what they've gotten themselves into by switching to WebKit. They actually built their stuff on Chromium so they'll probably have to follow Google to this Blink thingie too.

 

[AuthenticM]

Is this a good thing ?

 

[goodfella]

Won't this be a pain for web developers?

 

[Soodanim]

I really need a CPU with more than 1 core.

 

[mugurumakensei]

Won't this be a pain for web developers?

Not really, as long as they implement the standard, the only changes web developers will see is speed boosts.

 

[Leucrota]

I really need a CPU with more than 1 core.

Laptop from 2007 here. Midori, a supposedly lightweight browser, uses all of my RAM and runs the dual core CPU like crazy sometimes. Chromium, slightly more stable, will use 100% of the CPUs while decoding 720p video on youtube.

I hate upgrading though...

 

[Why would you do that?]

Lol, the Opera folk must be scratching their heads on what they've gotten themselves into by switching to WebKit. They actually built their stuff on Chromium so they'll probably have to follow Google to this Blink thingie too.

As I mentioned, Opera actually switched to Blink, not WebKit.

I can now post a link, though:

http://www.brucelawson.co.uk/2013/hello-blink/

It’s great to be able to talk publicly about Blink, the new engine that will power Opera’s browsers (disclosure: my employer, but this is a personal post) and Chrome henceforth. I know a lot of people worried that there would be less diversity on the Web once Opera Presto was retired, and the forking of WebKit into Blink restores that balance. Opera will be contributing to Blink in future.

[added 22:46 UK time] My boss, Lars Erik Bolstad, said on Opera’s behalf: “Our ambition is to contribute Opera’s browser engine expertise to Blink, ranging from the implementation of new web standards to improvements in existing code.”

(found out via Brettison)

 

[giga]

Won't this be a pain for web developers?

Damnit, now I have to test another browser?

This isn't going to change the amount of testing you need to do. If you test in Chrome but not Safari, you're doing it wrong. For starters, they’ve never used an identical build of WebKit, and even then, WebKit is just the layout engine. Safari and Chrome always had different JavaScript engines, different CPU & GPU rendering, and different network stacks (see http://paulirish.com/2013/webkit-for-developers/).

With an increasing number of build and run-time flags, the different ports of WebKit have been diverging for years. For Chrome, it reached a point where keeping the Chromey bits separate from the WebKitty bits was getting in the way of performance and security improvements. Some of these changes are related to Chrome’s multi-process model, so don’t make sense to the world-of-WebKit, and it’d be unfair to try to shoehorn those requirements into that community.

I lamented the loss of Opera's engine, Presto, and see Blink as a rebalancing of engine diversity. I hope Blink can do for layout & rendering what V8 did for JavaScript, although the improvements will be more gradual.

As developers, we bear the scars from days where "another engine" meant the difference between IE6 and Firefox 3 (wow "bear the scars", you can tell I've been watching Game of Thrones), but modern browsers are more compatible, see the similarities between Firefox and Chrome which use completely different engines.

Blink won't introduce its own vendor prefix either, it'll retain "-webkit-" for features that already use it, removing them after they land unprefixed. New experimental features can be activated in about:flags in the Dev and Canary builds.

So basically, Apple wouldn't let Google land Dart into WebKit?

I assume you're thinking that, because I thought that. Is this Google's Henry VIII move? Well, from what I've seen so far, Google seem pretty serious about preventing Blink becoming a Google-born feature party. Exploration of new features is being done in the open - http://www.chromestatus.com/features, policies will be published on adopting new features and when they may be considered stable.

To me, the pattern for feature adoption sounds rather Mozilla-like (http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0731.html), in a good way. I'm sure we'll see Dev and Canary builds will be used to trial non-standard features, much as they as now, but rigorous processes are being put in place to select what gets promoted to stable, and when.

https://plus.google.com/116237864387312784020/posts/d62jMDKXcLb

 

[PGamer]

But will this make the new Firefox better than 3.6?

Firefox has been better than 3.6 since version 4.

 

[Chris R]

As long as this makes the stuff I do with web development easier I'm ok with it! If I have to go grab another device to debug stuff on though...

 

[Mr. Wonderful]

So we've got

Google on Blink
Firefox on Servo
and Apple on WebKit 2.

All new platforms that aim to take advantage of multiprocess design. Honestly, I think maybe one of the biggest reasons for Google's change (other than because they can) is that they might not have been cool with Apple's fundamental shift with WebKit 2, when they already had their own higher up multiprocess design with Chrome. Is there anyone else besides Apple who is even using WebKit 2 at this point?

The only thing that makes me uneasy is Firefox's partnership with Samsung. I don't want to see Firefox tank on other platforms and potentially hardware platforms just because of this partnership with Samsung.