4 ms·

The benefit would be that compatibility code (which can obfuscate the base a lot and take a large proportion of the code base) would be in a different branch or

by slasaus 11y ago

The benefit would be that compatibility code (which can obfuscate the base a lot and take a large proportion of the code base) would be in a different branch or automatically added. Web developers could use tools like cssnext to automatically add all the goop without ever being distracted by it themselves. Less code needs to be reviewed, tested and maintained. As for the engine side, the benefits would be the same like with OpenSSH etc. as mentioned in the GH issue. Unfortunately (or fortunately if he is right) a Servo developer thinks "this separation (if it’s even possible) sounds like a bunch of additional work with no benefit". I'm afraid this nice and shiny new engine will end up being complex and unmaintainable like all the others. Again this is speculation not based on facts, but experience with software development in general.

acqq 11y ago
> Web developers could use tools like cssnext to automatically add all the goop without ever being distracted by it Can't they do that now? What exactly would that proposal bring new? > Less code needs to be reviewed, tested and maintained. Now there's four, then would be five different browsers. Why does this reduce anybody's work? > this is speculation not based on facts, but experience with software development in general. I'd say that experience you refer to doesn't include the one described in: https://xkcd.com/927/ https://xkcd.com/927/
- Argorak 11y ago
  > I'd say that experience you refer to doesn't include the one described in: > https://xkcd.com/927/ https://xkcd.com/927/ In any case, this is a most innovation-unfriendly reference that is all too common.
  - acqq 11y ago
    Independently of the generality of your remark, here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody.
    - slasaus 11y ago
      > here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody. OP here. Totally right, because I didn't know how Servo is implemented, I've asked. Sorry for mixing in some emotion and hope about which answer I would get. I respect any developer doing any work and do realize it's all too easy to spread opinion without hacking on some solution. Maybe as a non-contributor I should not have ventilated my opinion.
pcwalton 11y ago
I think you're under the impression that new Web sites tend to avoid all the "goop". Presumably for OpenSSH, if you control the server and it's properly configured you can drop the ugly, old code. Not so on the Web. Old and new Web sites alike rely on all sorts of corner cases. If I had to name the parts of Servo I'd love to drop, it wouldn't be what you think: it'd probably be inline hypothetical box/containing block calculation, followed by CSS 2.1.E compliant content layerization. Probably margin-collapse too. These areas are where most of the complexity and bugs lie, but they're also the areas that Web developers won't give up. Drop correct rendering of inline hypothetical blocks and you break google.com. The fact is that simple Web browsers already exist (ELinks, for example). You aren't using them because they don't support enough of the "ugly" features. Browsers have to be complex because the Web is complex. The Web is complex because people rely on the complex features.
- slasaus 11y ago
  /updated > If I had to name the parts of Servo I'd love to drop, it wouldn't be what you think ... Interesting. > I think you're under the impression that new Web sites tend to avoid all the "goop". Well as a web developer myself I do realize I'm adding a lot of workarounds, that's part of my frustration. It seems counterproductive for you guys as engine developers, and us web developers to use such an ever increasing amount of code just to work around stuff we throw at each other. > Presumably for OpenSSH, if you control the server and it's properly configured you can drop the ugly, old code. Not so on the Web. Old and new Web sites alike rely on all sorts of corner cases. Maybe for OpenSSH, but I think OpenSSL suffers from the same legacy compatibility issues as a browser. Still LibreSSL took an OpenSSH like approach by separating out all system specific exceptions from the base and put them in a different portability package. > ... (ELinks, for example). You aren't using them because they don't support enough of the "ugly" features. I'm not using elinks or other text based browsers not because they miss a lot of features, but because they're not as secure as I did expect from a text based browser[0]. They are still full of all sorts of features[1] that add to it's complexity without having enough value, imho. I think it's a feature to be not full featured. [0] http://marc.info/?l=openbsd-tech&m=140516601718662&w=2 http://marc.info/?l=openbsd-tech&m=140516601718662&w=2 about gopher support in lynx [1] Elinks: Full-Featured Text WWW Browser - Lots of protocols (local files, finger, http, https, ftp, smb, ipv4, ipv6) http://elinks.or.cz/about.html http://elinks.or.cz/about.html

by slasaus 11y ago

acqq 11y ago

> Web developers could use tools like cssnext to automatically add all the goop without ever being distracted by it Can't they do that now? What exactly would that proposal bring new? > Less code needs to be reviewed, tested and maintained. Now there's four, then would be five different browsers. Why does this reduce anybody's work? > this is speculation not based on facts, but experience with software development in general. I'd say that experience you refer to doesn't include the one described in: https://xkcd.com/927/ https://xkcd.com/927/

Argorak 11y ago
> I'd say that experience you refer to doesn't include the one described in: > https://xkcd.com/927/ https://xkcd.com/927/ In any case, this is a most innovation-unfriendly reference that is all too common.
- acqq 11y ago
  Independently of the generality of your remark, here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody.
  - slasaus 11y ago
    > here we have the very specific case of somebody not even knowing how the Servo is implemented or developed suggesting that the Servo developers should do how he says, not how they do, without giving any real proof of benefit to anybody. OP here. Totally right, because I didn't know how Servo is implemented, I've asked. Sorry for mixing in some emotion and hope about which answer I would get. I respect any developer doing any work and do realize it's all too easy to spread opinion without hacking on some solution. Maybe as a non-contributor I should not have ventilated my opinion.

pcwalton 11y ago

I think you're under the impression that new Web sites tend to avoid all the "goop". Presumably for OpenSSH, if you control the server and it's properly configured you can drop the ugly, old code. Not so on the Web. Old and new Web sites alike rely on all sorts of corner cases. If I had to name the parts of Servo I'd love to drop, it wouldn't be what you think: it'd probably be inline hypothetical box/containing block calculation, followed by CSS 2.1.E compliant content layerization. Probably margin-collapse too. These areas are where most of the complexity and bugs lie, but they're also the areas that Web developers won't give up. Drop correct rendering of inline hypothetical blocks and you break google.com. The fact is that simple Web browsers already exist (ELinks, for example). You aren't using them because they don't support enough of the "ugly" features. Browsers have to be complex because the Web is complex. The Web is complex because people rely on the complex features.

slasaus 11y ago
/updated > If I had to name the parts of Servo I'd love to drop, it wouldn't be what you think ... Interesting. > I think you're under the impression that new Web sites tend to avoid all the "goop". Well as a web developer myself I do realize I'm adding a lot of workarounds, that's part of my frustration. It seems counterproductive for you guys as engine developers, and us web developers to use such an ever increasing amount of code just to work around stuff we throw at each other. > Presumably for OpenSSH, if you control the server and it's properly configured you can drop the ugly, old code. Not so on the Web. Old and new Web sites alike rely on all sorts of corner cases. Maybe for OpenSSH, but I think OpenSSL suffers from the same legacy compatibility issues as a browser. Still LibreSSL took an OpenSSH like approach by separating out all system specific exceptions from the base and put them in a different portability package. > ... (ELinks, for example). You aren't using them because they don't support enough of the "ugly" features. I'm not using elinks or other text based browsers not because they miss a lot of features, but because they're not as secure as I did expect from a text based browser[0]. They are still full of all sorts of features[1] that add to it's complexity without having enough value, imho. I think it's a feature to be not full featured. [0] http://marc.info/?l=openbsd-tech&m=140516601718662&w=2 http://marc.info/?l=openbsd-tech&m=140516601718662&w=2 about gopher support in lynx [1] Elinks: Full-Featured Text WWW Browser - Lots of protocols (local files, finger, http, https, ftp, smb, ipv4, ipv6) http://elinks.or.cz/about.html http://elinks.or.cz/about.html