11 ms·

It's amazing to see actual effort taking place to build a new browser engine from scratch. I would say that since the late 90ies, there hasn't been a single ne

by pilif 10y ago

It's amazing to see actual effort taking place to build a new browser engine from scratch. I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. The existing engines have it much easier as they are allowed to grow with the spec, but a new engine has to do everything from scratch. This makes it even more impressive to see how far Servo is already (yes. I know - there's probably some overlap with some existing Mozilla code, but still). Huge congrats to everyone involved. We need unafraid visionaries like you people to actually move the web forward.

RubyPinch 10y ago
There are some smaller groups that are working on their own engines (slowly but surely) https://gngr.info/ https://gngr.info/ comes to mind
- userbinator 10y ago
  There's also Dillo and Netsurf.
  - yellowapple 10y ago
    Not to mention the various terminal browsers, like lynx and links.
- nickpsecurity 10y ago
  If interested in Java browsers, then you might like to check out one that had quite a bit of development. https://sourceforge.net/projects/xamj/ https://sourceforge.net/projects/xamj/ The main site is down due to dain issues. Googling will also give you a blog and Github. Their Cobra engine was Java IIRC. All that code might make a nice head start even if this project is dead or goes that way.
_pmf_ 10y ago
Edge is a new engine, too.
- iso-8859-1 10y ago
  EdgeHTML is based on Trident: http://www.neowin.net/news/whats-powering-spartan-internet-explorer-of-course http://www.neowin.net/news/whats-powering-spartan-internet-e...
- rat87 10y ago
  doesn't seem like it https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML > EdgeHTML is a proprietary layout engine developed for Edge. It is a fork of Trident that has removed all legacy code of older versions of Internet Explorer and rewritten the majority of its source code with web standards and interoperability with other modern browsers in mind.
  - ybx 10y ago
    Sounds like it's based on Trident to me
    - coldtea 10y ago
      Sounds like it's so rewritten compared to Trident, it's not even alike anymore.
      - viscanti 10y ago
        The end result might look fairly different, but I'm not sure that 'forked-and-refactored' is considered 'new' by very many people.
        nickpsecurity 10y ago
        "rewritten the majority of its source code with web standards and interoperability with other modern browsers in mind" I think coldtea is focusing on highlighted part. A rewrite like that might change so many behavioral aspects, esp user- or developer-visible, that it can be considered a new engine rather than mere clean-up of behaviorally-identical old one. I certainly reuses some code and techniques but differences might be major.
gsnedders 10y ago
> By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. It's a two sided coin: HTML now defines a lot of the basic web platform parts in enough detail that you can just implement the spec and have a web browser that works, whereas in the 90s (and most of the 00s) browsers spent huge amounts of resources on reverse-engineering each other. Pretty much the only way to be web compatible then was to start with something already mostly web compatible (consider the fact that Apple's first two or three years of work on WebKit were essentially spent pretty much just fixing web compat bugs!).
- Manishearth 10y ago
  Well, we still do lots of reverse-engineering, because the specs are often wrong :)
  - gsnedders 10y ago
    A lot is relative. :) Honestly, from what I see, the amount you do is relatively minuscule compared with what Opera was doing ten years ago, while Opera had far more marketshare which is normally the best way to avoid web compat issues in the first place.
  - nickpsecurity 10y ago
    It's a rule of thumb in most software I found studying high-assurance. Inevitably, some academic or commercial team wants to robustly implement some standard (esp a protocol). They notice it's specified in a combo of English and implementation code. They start doing formal specifications of English spec. Every time, IIRC, they find various inconsistencies and such that already did or could lead to real-world problems. Showed me the value of formal specs but also important lesson: using informal specs will almost always require reverse engineering and extensive testing due to, at very least, English ambiguity or implementation deviations.
    - Manishearth 10y ago
      So most of the spec bugs I've come across don't have to do with English vagaries; they have to do with the reverse-engineering not being perfect. Converting the nebulous concept of expected behavior into procedural text is hard, and there are bugs. So yeah, "implementation deviations" is usually the issue, but not really English ambiguity, at least with web specs. I put my pedant hat on when looking at proposed changes to web specs, and I believe the rest of the community does too :)
deleted 10y ago
[deleted]
kem1234 10y ago
ass
metajack 10y ago
> By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. One important mitigating factor is that newer standards often generalize older ones. For example, originally all the list elements had special case handling (and still might in other engines), but now it's possible to do all that with the user agent style sheet with new additions to CSS that generalized these things. It saves an enormous amount of work to implement the web at a particular point in time as opposed to starting at the beginning and keeping up with the changes until that same point in time. Not only that, but all the failed branches that were already explored mean that a new engine avoids quite a bit of technical debt. It's still quite hard. Here's a nice example of a layout bug on HN we thought would be simple to fix for the release, but turned ugly fast: https://github.com/servo/servo/issues/11821 https://github.com/servo/servo/issues/11821
- nickpsecurity 10y ago
  This has been interesting test. Thanks for your suggestion on the -c option for "can't load servo." That worked. Filed a bug on HN login where tab autosubmits form instead of changes textbox. I can neither see the text I'm typing nor scroll down on HN. I'll check to see if open issues on that then file them if there aren't.
coldtea 10y ago
>I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. Compared to KHTML, Webkit and Blink were pretty much 5 or more whole new projects on top of it. And even the latest IE is hugely rewritten compared to Trident.
- pcwalton 10y ago
  There's a big difference between "slowly modified from something that works while keeping tests and web compat passing" and "written from scratch".

by pilif 10y ago

RubyPinch 10y ago

There are some smaller groups that are working on their own engines (slowly but surely) https://gngr.info/ https://gngr.info/ comes to mind

userbinator 10y ago
There's also Dillo and Netsurf.
- yellowapple 10y ago
  Not to mention the various terminal browsers, like lynx and links.
nickpsecurity 10y ago
If interested in Java browsers, then you might like to check out one that had quite a bit of development. https://sourceforge.net/projects/xamj/ https://sourceforge.net/projects/xamj/ The main site is down due to dain issues. Googling will also give you a blog and Github. Their Cobra engine was Java IIRC. All that code might make a nice head start even if this project is dead or goes that way.

_pmf_ 10y ago

Edge is a new engine, too.

iso-8859-1 10y ago
EdgeHTML is based on Trident: http://www.neowin.net/news/whats-powering-spartan-internet-explorer-of-course http://www.neowin.net/news/whats-powering-spartan-internet-e...
rat87 10y ago
doesn't seem like it https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML > EdgeHTML is a proprietary layout engine developed for Edge. It is a fork of Trident that has removed all legacy code of older versions of Internet Explorer and rewritten the majority of its source code with web standards and interoperability with other modern browsers in mind.
- ybx 10y ago
  Sounds like it's based on Trident to me
  - coldtea 10y ago
    Sounds like it's so rewritten compared to Trident, it's not even alike anymore.
    - viscanti 10y ago
      The end result might look fairly different, but I'm not sure that 'forked-and-refactored' is considered 'new' by very many people.
      - nickpsecurity 10y ago
        "rewritten the majority of its source code with web standards and interoperability with other modern browsers in mind" I think coldtea is focusing on highlighted part. A rewrite like that might change so many behavioral aspects, esp user- or developer-visible, that it can be considered a new engine rather than mere clean-up of behaviorally-identical old one. I certainly reuses some code and techniques but differences might be major.

gsnedders 10y ago

> By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. It's a two sided coin: HTML now defines a lot of the basic web platform parts in enough detail that you can just implement the spec and have a web browser that works, whereas in the 90s (and most of the 00s) browsers spent huge amounts of resources on reverse-engineering each other. Pretty much the only way to be web compatible then was to start with something already mostly web compatible (consider the fact that Apple's first two or three years of work on WebKit were essentially spent pretty much just fixing web compat bugs!).

Manishearth 10y ago
Well, we still do lots of reverse-engineering, because the specs are often wrong :)
- gsnedders 10y ago
  A lot is relative. :) Honestly, from what I see, the amount you do is relatively minuscule compared with what Opera was doing ten years ago, while Opera had far more marketshare which is normally the best way to avoid web compat issues in the first place.
- nickpsecurity 10y ago
  It's a rule of thumb in most software I found studying high-assurance. Inevitably, some academic or commercial team wants to robustly implement some standard (esp a protocol). They notice it's specified in a combo of English and implementation code. They start doing formal specifications of English spec. Every time, IIRC, they find various inconsistencies and such that already did or could lead to real-world problems. Showed me the value of formal specs but also important lesson: using informal specs will almost always require reverse engineering and extensive testing due to, at very least, English ambiguity or implementation deviations.
  - Manishearth 10y ago
    So most of the spec bugs I've come across don't have to do with English vagaries; they have to do with the reverse-engineering not being perfect. Converting the nebulous concept of expected behavior into procedural text is hard, and there are bugs. So yeah, "implementation deviations" is usually the issue, but not really English ambiguity, at least with web specs. I put my pedant hat on when looking at proposed changes to web specs, and I believe the rest of the community does too :)

deleted 10y ago

[deleted]

kem1234 10y ago

ass

metajack 10y ago

> By now, HTML and the standards surrounding it have become so big that starting from a blank slate nowadays is next to impossible. One important mitigating factor is that newer standards often generalize older ones. For example, originally all the list elements had special case handling (and still might in other engines), but now it's possible to do all that with the user agent style sheet with new additions to CSS that generalized these things. It saves an enormous amount of work to implement the web at a particular point in time as opposed to starting at the beginning and keeping up with the changes until that same point in time. Not only that, but all the failed branches that were already explored mean that a new engine avoids quite a bit of technical debt. It's still quite hard. Here's a nice example of a layout bug on HN we thought would be simple to fix for the release, but turned ugly fast: https://github.com/servo/servo/issues/11821 https://github.com/servo/servo/issues/11821

nickpsecurity 10y ago
This has been interesting test. Thanks for your suggestion on the -c option for "can't load servo." That worked. Filed a bug on HN login where tab autosubmits form instead of changes textbox. I can neither see the text I'm typing nor scroll down on HN. I'll check to see if open issues on that then file them if there aren't.

coldtea 10y ago

>I would say that since the late 90ies, there hasn't been a single new engine being made. Everything we have now is a development based on KHTML, Gecko, Presto or Trident. Compared to KHTML, Webkit and Blink were pretty much 5 or more whole new projects on top of it. And even the latest IE is hugely rewritten compared to Trident.

pcwalton 10y ago
There's a big difference between "slowly modified from something that works while keeping tests and web compat passing" and "written from scratch".