10 ms·

Looking at what it takes to actually implement the "belly of the beast" from scratch, I don't blame them. (Also, after seeing the below 350-line function that'

by btown 8y ago

Looking at what it takes to actually implement the "belly of the beast" from scratch, I don't blame them. (Also, after seeing the below 350-line function that's part of a 3113-line file, I now know that whenever I'm yelling at CSS layout behaving weirdly, there's someone with a much, much more frustrating job.) https://github.com/servo/servo/blob/master/components/layout/block.rs#L755 https://github.com/servo/servo/blob/master/components/layout... EDIT: for anyone who doesn't know, https://servo.org/ https://servo.org/ is Mozilla's ambitious project to rewrite their browser from scratch with concurrency thought in from the beginning, supported by Rust's unique approach to safe concurrency. Parts of it have already made it into Firefox: https://bholley.net/blog/2017/stylo.html https://bholley.net/blog/2017/stylo.html

ConfusedDog 8y ago
This is fraud, not a miscommunication between marketers and developers. China is known for fraudulent businessmen cheat out of a lot of money and ran to other countries. I believe this is a case of that.
- deleted 8y ago
  [deleted]
amelius 8y ago
It's sad to see that even with a rewrite (Servo), the code becomes so hairy. In my ideal world, browsers are spec'd in a functional language, and optimized mechanically (perhaps based on ad-hoc human guidelines).
- smaddox 8y ago
  That's hairy? It looks pretty clean to me. Sure, there are a lot of match cases, but they follow a fairly clean and clear pattern. Pulling them out into a hundred single-use functions certainly wouldn't make it easier to understand.
cheez 8y ago
lol https://github.com/llvm-mirror/llvm/blob/48d710e2cb4c462c7b21d6c8a076540a8b1998a4/lib/Target/X86/X86ISelLowering.cpp https://github.com/llvm-mirror/llvm/blob/48d710e2cb4c462c7b2...
jerf 8y ago
"(Also, after seeing the below 350-line function that's part of a 3113-line file, I now know that whenever I'm yelling at CSS layout behaving weirdly, there's someone with a much, much more frustrating job.)" Browser authors are on the receiving end of over 20 years of standards all written by people who were not, personally, the ones implementing them, plus a healthy dollop of "code that worked in this one browser once and become a de facto standard", for which the way tables format themselves in all their myriad ways comes to mind, based around whatever was convenient in already-crufty codebases now long dead. And then all these nightmares get together and interact. And the end users expect this to be fast. And web developers expect to be able to reach into the middle of this epically complicated data structure and tweak a style and have what may literally be the entire page rerender, and they expect that to be fast and easy. And using a language that was never written to be fast. (If anything, Javascript was written to be implemented quickly, if you read the story about where it came from. There was no time to be worrying about how well it could be JIT'ed 10ish years later.) I don't spend a lot of time wondering why my browser is so slow; I often find myself wondering how it manages to be so fast. The spec for a browser is insane. I definitely believe that a future of browsers will be a combination of web assembly and a much more raw rendering layer that will offer access to font rendering and the OpenGL primitives, and a non-trivial number of the biggest websites will eventually implement their own renderers. I say "a" future because the current web rendering system will be around to the end of my prognostication powers. But I suspect this bypassing of the "legacy" renderer is also ultimately inevitable. Give it about 5 years or so.
- digi_owl 8y ago
  From personal experience, any site will render quickly of you kill the 10+ externally sourced JS frameworks it loads (or it will just show a white on white page that you can throw reader mode at). Frankly what went wrong was that print media designers got involved and used flash and JS to turn static text into virtual pamphlets etc.
- mamcx 8y ago
  I wonder why browser makers not take full advantage of the high churn of the JS ecosystem to move forward. Let put a end to the madness, and say "after 2020, not more in the old apis" and do a clean standard. Then take advantage of the fact html/js have tags that could declare versions, and when a old page show, use the old rendered, and when a new, use the clean one. By then, most PC/mobile devices are powerfull enough to have 2 renders alive and the transition will be fast for more big/popular sites.
wemdyjreichert 8y ago
There's nothing wrong with using open source code, but then saying it's "fully homegrown" is more than slightly disingenuous.
- deleted 8y ago
  [deleted]
- fspeech 8y ago
  The company just changed its name to "Redcore" after the ZTE ban earlier this year. There is a demand for software/hardware that is "homegrown" not subject to US control.
deleted 8y ago
[deleted]
SegFaultCDumped 8y ago
If it was so difficult to write a browser, then how did Vivaldi guys manage to write not one, but two browsers (previously Opera and now Vivaldi) from scratch.
- _Tev 8y ago
  Sorry for late reply but your response is hillarious - Vivaldi is just re-skined Chrome. New Opera too. Old Opera (presto engine) was developed over a decade, so not really example of "how to easily write web browser".

by btown 8y ago

ConfusedDog 8y ago

This is fraud, not a miscommunication between marketers and developers. China is known for fraudulent businessmen cheat out of a lot of money and ran to other countries. I believe this is a case of that.

deleted 8y ago
[deleted]

amelius 8y ago

It's sad to see that even with a rewrite (Servo), the code becomes so hairy. In my ideal world, browsers are spec'd in a functional language, and optimized mechanically (perhaps based on ad-hoc human guidelines).

smaddox 8y ago
That's hairy? It looks pretty clean to me. Sure, there are a lot of match cases, but they follow a fairly clean and clear pattern. Pulling them out into a hundred single-use functions certainly wouldn't make it easier to understand.

cheez 8y ago

lol https://github.com/llvm-mirror/llvm/blob/48d710e2cb4c462c7b21d6c8a076540a8b1998a4/lib/Target/X86/X86ISelLowering.cpp https://github.com/llvm-mirror/llvm/blob/48d710e2cb4c462c7b2...

jerf 8y ago

"(Also, after seeing the below 350-line function that's part of a 3113-line file, I now know that whenever I'm yelling at CSS layout behaving weirdly, there's someone with a much, much more frustrating job.)" Browser authors are on the receiving end of over 20 years of standards all written by people who were not, personally, the ones implementing them, plus a healthy dollop of "code that worked in this one browser once and become a de facto standard", for which the way tables format themselves in all their myriad ways comes to mind, based around whatever was convenient in already-crufty codebases now long dead. And then all these nightmares get together and interact. And the end users expect this to be fast. And web developers expect to be able to reach into the middle of this epically complicated data structure and tweak a style and have what may literally be the entire page rerender, and they expect that to be fast and easy. And using a language that was never written to be fast. (If anything, Javascript was written to be implemented quickly, if you read the story about where it came from. There was no time to be worrying about how well it could be JIT'ed 10ish years later.) I don't spend a lot of time wondering why my browser is so slow; I often find myself wondering how it manages to be so fast. The spec for a browser is insane. I definitely believe that a future of browsers will be a combination of web assembly and a much more raw rendering layer that will offer access to font rendering and the OpenGL primitives, and a non-trivial number of the biggest websites will eventually implement their own renderers. I say "a" future because the current web rendering system will be around to the end of my prognostication powers. But I suspect this bypassing of the "legacy" renderer is also ultimately inevitable. Give it about 5 years or so.

digi_owl 8y ago
From personal experience, any site will render quickly of you kill the 10+ externally sourced JS frameworks it loads (or it will just show a white on white page that you can throw reader mode at). Frankly what went wrong was that print media designers got involved and used flash and JS to turn static text into virtual pamphlets etc.
mamcx 8y ago
I wonder why browser makers not take full advantage of the high churn of the JS ecosystem to move forward. Let put a end to the madness, and say "after 2020, not more in the old apis" and do a clean standard. Then take advantage of the fact html/js have tags that could declare versions, and when a old page show, use the old rendered, and when a new, use the clean one. By then, most PC/mobile devices are powerfull enough to have 2 renders alive and the transition will be fast for more big/popular sites.

wemdyjreichert 8y ago

There's nothing wrong with using open source code, but then saying it's "fully homegrown" is more than slightly disingenuous.

deleted 8y ago
[deleted]
fspeech 8y ago
The company just changed its name to "Redcore" after the ZTE ban earlier this year. There is a demand for software/hardware that is "homegrown" not subject to US control.

deleted 8y ago

[deleted]

SegFaultCDumped 8y ago

If it was so difficult to write a browser, then how did Vivaldi guys manage to write not one, but two browsers (previously Opera and now Vivaldi) from scratch.

_Tev 8y ago
Sorry for late reply but your response is hillarious - Vivaldi is just re-skined Chrome. New Opera too. Old Opera (presto engine) was developed over a decade, so not really example of "how to easily write web browser".