8 ms·

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

kibwen 13y 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 13y 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 13y 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 13y ago
    This says more about you than the quality of the project.
  - steveklabnik 13y 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 13y 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 13y 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 13y 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 13y 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.
        shawn-butler 13y ago
        The C++ memory model (which btw is what underlies any threading facility) was always sufficient for handling the complexity but it never offered any opinions or constraints on implementations until C++11; the standards committee wisely preferred to defer instead to the writers of libraries to provide appropriate designs and services tailored to the specific needs of user communities and particular operating system facilities. I'm pretty sure based on your writing that you have little to offer me that I don't already understand about the language, but thanks for your hollow advice though. Here, I'll make an empty prediction in return: in 3 years you will be complaining about how difficult it is to do distributed parallelism in Rust and what absolute garbage it is compared to <insert name here>. The point was simple but fanbois want straw men and windmills at which to tilt: if you have something you think is better, extol its virtues and provide comparative analysis instead of bashing/trolling what currently exists completely out of any useful context. I really have little interest in discussing anything technical on HN anymore. Here's a token wikipedia link, that's what passes for knowledge I guess [0]. Also I would keep your "advice" to yourself. I certainly hope you wouldn't speak to people like that in person, and you definitely wouldn't be allowed to speak in such a fashion to me in particular. I am pretty familiar with Rust's evolving semantics and syntax, thanks. [0] http://en.wikipedia.org/wiki/C%2B%2B11#Threading_facilities http://en.wikipedia.org/wiki/C%2B%2B11#Threading_facilities
- pkulak 13y 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 13y 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 13y 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 13y ago
    Backwards compatibility, I think?
  - kyrias 13y 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 13y ago
Presumably to squeeze out maximum performance from multi-core machines. Current engines are all single thread per page instance.
paddy_m 13y 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.

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 13y 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 13y 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 13y ago
  This says more about you than the quality of the project.
- steveklabnik 13y 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 13y 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 13y 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 13y 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 13y 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.
      - shawn-butler 13y ago
        The C++ memory model (which btw is what underlies any threading facility) was always sufficient for handling the complexity but it never offered any opinions or constraints on implementations until C++11; the standards committee wisely preferred to defer instead to the writers of libraries to provide appropriate designs and services tailored to the specific needs of user communities and particular operating system facilities. I'm pretty sure based on your writing that you have little to offer me that I don't already understand about the language, but thanks for your hollow advice though. Here, I'll make an empty prediction in return: in 3 years you will be complaining about how difficult it is to do distributed parallelism in Rust and what absolute garbage it is compared to <insert name here>. The point was simple but fanbois want straw men and windmills at which to tilt: if you have something you think is better, extol its virtues and provide comparative analysis instead of bashing/trolling what currently exists completely out of any useful context. I really have little interest in discussing anything technical on HN anymore. Here's a token wikipedia link, that's what passes for knowledge I guess [0]. Also I would keep your "advice" to yourself. I certainly hope you wouldn't speak to people like that in person, and you definitely wouldn't be allowed to speak in such a fashion to me in particular. I am pretty familiar with Rust's evolving semantics and syntax, thanks. [0] http://en.wikipedia.org/wiki/C%2B%2B11#Threading_facilities http://en.wikipedia.org/wiki/C%2B%2B11#Threading_facilities
pkulak 13y 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 13y 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 13y 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 13y ago
  Backwards compatibility, I think?
- kyrias 13y 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 13y ago

Presumably to squeeze out maximum performance from multi-core machines. Current engines are all single thread per page instance.

paddy_m 13y 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.