9 ms·

This is really exciting. I'm glad to see rust being used for serious apps. This is actually the first new browser engine that I know of being written in the pas

by paddy_m 14y ago

This is really exciting. I'm glad to see rust being used for serious apps. This is actually the first new browser engine that I know of being written in the past 10 years. Good for Mozilla for attempting hard problems in innovative ways.

hobbyist 14y ago
I am not well-versed in the browser designs, could you highlight what hard problems are you referring to?
- kibwen 14y ago
  Check out the high-level overview of Servo's design: https://github.com/mozilla/servo/wiki/Design https://github.com/mozilla/servo/wiki/Design The goal is extremely pervasive concurrency in aspects that no modern engine has yet begun to approach (and likely could not approach without enormous effort and/or a full-on rewrite).
  - jerf 14y ago
    You can drop the "likely". Retrofitting pervasive concurrency onto a sizable existing codebase is to a first approximation impossible. It makes merely trying to retrofit pervasive unit testing (hard, but "merely" a long mechanical slog) or correctness with string encoding a cake walk. "Impossible" here can be taken to read as "would require as much effort to do the retrofit as the rewrite would take".
  - shawn-butler 14y ago
    >> Because C++ is poorly suited to preventing these problems, It is really hard to take seriously any project that has this kind of nonsense in its introduction.
    - eruditely 14y ago
      This says more about you than the quality of the project.
    - steveklabnik 14y ago
      I think you're being downvoted because if anyone knows about the pain of using C++ to develop a browser engine, it's Mozilla. They have some pretty strong empirical evidence to back up their statement.
      - shawn-butler 14y ago
        No, you don't bash a language for failures of the people using it. It is hyperbole unsupported by any evidence and it is precisely this mentality that keeps our profession on the Greatest New Thing(TM) every x years treadmill for better or worse. Language bashing/trolling serves no purpose. I am rather most likely being downvoted because HN in the past few months has taken an extreme downturn towards a slashdot/herd mentality, but that is just another pendulum swinging.
        nnethercote 14y ago
        No, you're being downvoted because fine-grained parallel programming in C++ is really hard, but you're saying that it's not.
        shawn-butler 14y ago
        Wow, I said what? Also while I hate to be the harbinger of bad news, parallel programming in any language is Really Hard(tm) for most people. Personally, I think there's a fundamental disconnect in how human cognition perceives the world on the one hand and massive parallelism on the other at which very few people I have met really excel relative to the larger population.
        abraininavat 14y ago
        Are you claiming that all languages are equally good for all purposes? Or are you claiming that C++ is in fact particularly well suited for parallel development and inherent avoidance of data races? Coming from a C++ developer, I don't think you're well aware of its limitations. Do yourself a favor and learn a little bit of Rust. It'll open up your mind a little, and just might make you a better C++ programmer.
  - pkulak 14y ago
    > Copy-on-write DOM. In Servo, the DOM is a versioned data structure that is shared between the content (JavaScript) task and the layout task, allowing layout to run even while scripts are reading and writing DOM nodes. Wow
- shadowmint 14y ago
  Are you kidding? HTML is a massive spec even before you step in and implement the HTML5 javascript APIs. Then you also have to make sure that your rendering engine behaves in a sane way, supports all the obscure CSS rules from the spec and from webkit... There's a reason Opera stopped playing this game; it's hard work.
  - IgorPartola 14y ago
    Why is it so massive? Why does it need to specify in grave detail the difference between <span>, <label>, <code>, etc.? How about a spec like this: - There are two types of elements: block and inline. You can declare a name of an element with a particular type using perhaps XML namespaces, or just a JSON object. - Inline elements can be floated left/right along other inline elements. - Block elements may be positioned absolutely inside their parent elements or relatively to their current position. You cannot float them. - Width/height may be specified as a pixel width, percentage width of parent, percentage of available space, or percentage of screen size. Additionally, you may specify the box model: whether to include borders, margins, padding, etc. - CSS rules about typography, margins, borders, padding, etc. shall apply. This way, you can include your own basic rules and build on top of them. I had the misfortune to do a bit of hacking with GTK+ and at first thought "what an archaic way to lay out elements?!" Then it came to me that HTML + CSS is not advanced, it is cluttered. There are many ways to position an element on the page, and they will conflict. Additionally, things like opacity affecting z-index, having a parent element have a size to give the child element a percentage size, etc. lead to a ton of hacks. It's time we have a better, cleaner tool than the browser if we are going to build serious apps on this platform.
    - saraid216 14y ago
      Backwards compatibility, I think?
    - kyrias 14y ago
      Because if the spec didn't, every engine would do things their own way and no website would work in more than one browser.
- Offler 14y ago
  Presumably to squeeze out maximum performance from multi-core machines. Current engines are all single thread per page instance.
- paddy_m 14y ago
  Creating a new language that handles concurrency and pointer bugs in a systematic way that is also fast is amazing. Writing a new browser engine in said language is very ambitious and important.
tantalor 14y ago
Chromium is 5 years old. WebKit is 7 years old. Do they count? KHTML is a bit older (14 years).
- metageek 14y ago
  paddy_m said browser engine, so Chromium doesn't count. And WebKit wasn't actually new; it was based on KHTML.
  - Samuel_Michon 14y ago
    Try to find KHTML code in modern Webkit. I'd be surprised if it's more than 5%. By that standard, Firefox uses the same engine as Netscape Navigator did.
    - dave5104 14y ago
      I think the intended meaning was a new browser engine written from scratch, and not based on another browser engine that came before.
    - azakai 14y ago
      A similar thing has happened in Gecko. Probably modern Gecko browsers share similar amounts of old code as modern WebKit browsers share of old KTHML code (that is, very little in both cases).
      - Samuel_Michon 14y ago
        Right, that was my point. It doesn't really matter where it started, whether it's entirely original or not. Otherwise, IE10 should be considered a bad browser, which it isn't.
    - wahnfrieden 14y ago
      More important than lines of code, how much foundational architecture do they share? Code is just an implementation detail, architectural changes are more feasible in a new codebase.

by paddy_m 14y ago

hobbyist 14y ago

I am not well-versed in the browser designs, could you highlight what hard problems are you referring to?

kibwen 14y ago
Check out the high-level overview of Servo's design: https://github.com/mozilla/servo/wiki/Design https://github.com/mozilla/servo/wiki/Design The goal is extremely pervasive concurrency in aspects that no modern engine has yet begun to approach (and likely could not approach without enormous effort and/or a full-on rewrite).
- jerf 14y ago
  You can drop the "likely". Retrofitting pervasive concurrency onto a sizable existing codebase is to a first approximation impossible. It makes merely trying to retrofit pervasive unit testing (hard, but "merely" a long mechanical slog) or correctness with string encoding a cake walk. "Impossible" here can be taken to read as "would require as much effort to do the retrofit as the rewrite would take".
- shawn-butler 14y ago
  >> Because C++ is poorly suited to preventing these problems, It is really hard to take seriously any project that has this kind of nonsense in its introduction.
  - eruditely 14y ago
    This says more about you than the quality of the project.
  - steveklabnik 14y ago
    I think you're being downvoted because if anyone knows about the pain of using C++ to develop a browser engine, it's Mozilla. They have some pretty strong empirical evidence to back up their statement.
    - shawn-butler 14y ago
      No, you don't bash a language for failures of the people using it. It is hyperbole unsupported by any evidence and it is precisely this mentality that keeps our profession on the Greatest New Thing(TM) every x years treadmill for better or worse. Language bashing/trolling serves no purpose. I am rather most likely being downvoted because HN in the past few months has taken an extreme downturn towards a slashdot/herd mentality, but that is just another pendulum swinging.
      - nnethercote 14y ago
        No, you're being downvoted because fine-grained parallel programming in C++ is really hard, but you're saying that it's not.
        shawn-butler 14y ago
        Wow, I said what? Also while I hate to be the harbinger of bad news, parallel programming in any language is Really Hard(tm) for most people. Personally, I think there's a fundamental disconnect in how human cognition perceives the world on the one hand and massive parallelism on the other at which very few people I have met really excel relative to the larger population.
      - abraininavat 14y ago
        Are you claiming that all languages are equally good for all purposes? Or are you claiming that C++ is in fact particularly well suited for parallel development and inherent avoidance of data races? Coming from a C++ developer, I don't think you're well aware of its limitations. Do yourself a favor and learn a little bit of Rust. It'll open up your mind a little, and just might make you a better C++ programmer.
- pkulak 14y ago
  > Copy-on-write DOM. In Servo, the DOM is a versioned data structure that is shared between the content (JavaScript) task and the layout task, allowing layout to run even while scripts are reading and writing DOM nodes. Wow
shadowmint 14y ago
Are you kidding? HTML is a massive spec even before you step in and implement the HTML5 javascript APIs. Then you also have to make sure that your rendering engine behaves in a sane way, supports all the obscure CSS rules from the spec and from webkit... There's a reason Opera stopped playing this game; it's hard work.
- IgorPartola 14y ago
  Why is it so massive? Why does it need to specify in grave detail the difference between <span>, <label>, <code>, etc.? How about a spec like this: - There are two types of elements: block and inline. You can declare a name of an element with a particular type using perhaps XML namespaces, or just a JSON object. - Inline elements can be floated left/right along other inline elements. - Block elements may be positioned absolutely inside their parent elements or relatively to their current position. You cannot float them. - Width/height may be specified as a pixel width, percentage width of parent, percentage of available space, or percentage of screen size. Additionally, you may specify the box model: whether to include borders, margins, padding, etc. - CSS rules about typography, margins, borders, padding, etc. shall apply. This way, you can include your own basic rules and build on top of them. I had the misfortune to do a bit of hacking with GTK+ and at first thought "what an archaic way to lay out elements?!" Then it came to me that HTML + CSS is not advanced, it is cluttered. There are many ways to position an element on the page, and they will conflict. Additionally, things like opacity affecting z-index, having a parent element have a size to give the child element a percentage size, etc. lead to a ton of hacks. It's time we have a better, cleaner tool than the browser if we are going to build serious apps on this platform.
  - saraid216 14y ago
    Backwards compatibility, I think?
  - kyrias 14y ago
    Because if the spec didn't, every engine would do things their own way and no website would work in more than one browser.
Offler 14y ago
Presumably to squeeze out maximum performance from multi-core machines. Current engines are all single thread per page instance.
paddy_m 14y ago
Creating a new language that handles concurrency and pointer bugs in a systematic way that is also fast is amazing. Writing a new browser engine in said language is very ambitious and important.

tantalor 14y ago

Chromium is 5 years old. WebKit is 7 years old. Do they count? KHTML is a bit older (14 years).

metageek 14y ago
paddy_m said browser engine, so Chromium doesn't count. And WebKit wasn't actually new; it was based on KHTML.
- Samuel_Michon 14y ago
  Try to find KHTML code in modern Webkit. I'd be surprised if it's more than 5%. By that standard, Firefox uses the same engine as Netscape Navigator did.
  - dave5104 14y ago
    I think the intended meaning was a new browser engine written from scratch, and not based on another browser engine that came before.
  - azakai 14y ago
    A similar thing has happened in Gecko. Probably modern Gecko browsers share similar amounts of old code as modern WebKit browsers share of old KTHML code (that is, very little in both cases).
    - Samuel_Michon 14y ago
      Right, that was my point. It doesn't really matter where it started, whether it's entirely original or not. Otherwise, IE10 should be considered a bad browser, which it isn't.
  - wahnfrieden 14y ago
    More important than lines of code, how much foundational architecture do they share? Code is just an implementation detail, architectural changes are more feasible in a new codebase.