6 ms·

I wonder: who could even feasibly introduce another browser today? The task seems almost impossible.

by baddox 9y ago

nrhk 9y ago
Well you could also fork Chromium I guess.
- colehasson 9y ago
  And with Puppeteer/Devtools programmers can stay in text editors.
- Vinnl 9y ago
  Except that that doesn't really broaden the ecosystem, unfortunately.
  - rlanday 9y ago
    Given enough time, it does. People used to talk about a “WebKit monoculture” on mobile back when both Safari and Chrome were built on WebKit (although, they enabled different features and used different JavaScript engines). After Google forked WebKit to create Blink, WebKit and Blink started to diverge with different development priorities resulting in different improvements being made and different features being implemented. So as time goes on, and code gets added, removed, and rewritten, much of the commonality eventually disappears over time.
jopsen 9y ago
mozillia research is sort of doing it with gecko. But yeah, from scratch is hard... Google didn't even do that, they started from webkit.
- mercurial 9y ago
  With Gecko ? It's their original engine. You probably mean Servo (the experimental Rust engine).
  - erikbye 9y ago
    I guess it's not wrong to call it their original engine, just remember it's a two-decades-old development that started at Netscape.
    - gsnedders 9y ago
      Well, arguably started at DigitalStyle.
      - robin_reala 9y ago
        Can you expand? I thought I had a good grasp of Mozilla’s history but this is the first time I’ve heard of them.
        dev_tty01 9y ago
        https://en.m.wikipedia.org/wiki/DigitalStyle https://en.m.wikipedia.org/wiki/DigitalStyle
        gsnedders 9y ago
        So my understanding is following Netscape's acquisition of DigitalStyle, the decision was made to replace Netscape's existing layout engine with something based on what DigitalStyle had in their editor (which, unlike Netscape's existing one, supported things like reflow), and it was this combination that was open-sourced. Notably, it was only really the layout engine that was replaced: the HTML parser and the JS VM survived unchanged, hence the name NGLayout for what became Gecko.
- Klathmon 9y ago
  And webkit started from KHTML
captainmuon 9y ago
I would first target a subset of HTML, for example static documents instead of web apps. You would have a specification like AMP which restricts what elements you can use. If a document used the full spec, I would fallback to another engine (e.g. WebKit). You could have full documents in iframes inside limited documents (but cross-frame scripting might be hard to get right in that case). Also, I would try to make it as modular as possible. E.g. layout engine, css engine, js engine etc. as libraries, use the system codecs instead of bundling own codecs, and so on. And it would help to have an extensive test suite, which you could take from other browsers.
- krapp 9y ago
  The difference between static web documents and web apps isn't the set of HTML they use, it's just that the latter are designed to deeply integrate javascript (and/or, to futureproof this comment, WebAssembly) into their UI, rather than do all of the logic on the server between requests. The only way to ship a browser that doesn't render "web apps" would be to simply not support scripting of any kind. That would permanently break much of the web unless you offered a way to opt in to scripting the way current browser users who run script blockers can. But then you just have a regular browser with script blocking turned on by default. Having different engines for "static" and "web app" documents, and defining a proprietary standard for the former as a restrictive subset of HTML would be unnecessarily complex and hostile to web developers.
  - captainmuon 9y ago
    There is a subset of web pages that only use a subset of features - Hacker News is an example, but better examples would be Wikipedia, many news sites, documentation of all kinds, and so on. You have basically static HTML, and use JavaScript for 1) progressive enhancement and decoration (what used to be called "DHTML"), 2) ads, and 3) more and more for client side rendering. You can't do much about 3 right now, but I would offer support for 1 and 2. I would definitely offer scripting, but just not all features. You could autodetect a "lean html" site, or you could use a marker such as "<html lean>" like AMP does. I don't think this is hostile to developers at all, unless AMP is already hostile. You would have a subset of the web platform, yes, but if you only use that you are likely to have a faster and leaner website - even without a new engine. I would view it as a guideline or a best practice, rather than a restiction. Side note: I think the co-mingling of documents and apps is the source of a lot of problems today. Why can ads inject arbitrary javascript into my website?! On mobile, I am regularly redirected to annoying ads that proclaim my phone is infected, and make my phone vibrate and make noise. A news article shouldn't be able to do that!
adventured 9y ago
Amazon and Facebook could both launch entirely new browsers. Spotlight it constantly on Amazon.com or across Facebook's properties as with Chrome on Google.com. Facebook already has far more cash and profit than they know what to do with. $38 billion currently, rapidly climbing. They'll add ~$20 billion to that in 2018. They could do a new browser just for kicks if they wanted to, and they have the vast global reach to generate some uptake. Whether either could claw meaningful share away from Chrome is an entirely different question. Samsung, Tencent and Alibaba all have the resources to launch entirely new browsers if it made sense.
- rwmj 9y ago
  Alibaba already have their own browser of a sort (https://en.wikipedia.org/wiki/UC_Browser https://en.wikipedia.org/wiki/UC_Browser). As I understand it, it's some kind of thin mobile browser which renders on the server side.
  - kinlan 9y ago
    There are multiple versions of UC browser. My understanding of it is: - uc mobile on Android now uses the blink engine, it used to use Webkit. - uc mini ( I think that's the name) has server renderer but it's "uc engine" is a derivative of gecko (not checked recently)
- nojvek 9y ago
  Hiring talent to build browsers is not as easy as throwing money. The bottleneck is engineers who have the know how to build it. Building your own browser could be a shitty business decision if you can't compete with Chrome for ad dollars. A browser makes sense if you can bundle it with an OS. Android : chrome, ios: safari and Windows: Edge Facebook makes a shit ton of money from ads people click on chrome.
- Mountain_Skies 9y ago
  Amazon sort of has their own browser called Silk. It's based on Chromium so it's not a built from the ground up endeavor but has been customized on their Fire devices to 'enhance' the browsing experience in a way that seems to benefit Amazon.

I wonder: who could even feasibly introduce another browser today? The task seems almost impossible.

by baddox 9y ago

I wonder: who could even feasibly introduce another browser today? The task seems almost impossible.

nrhk 9y ago

Well you could also fork Chromium I guess.

colehasson 9y ago
And with Puppeteer/Devtools programmers can stay in text editors.
Vinnl 9y ago
Except that that doesn't really broaden the ecosystem, unfortunately.
- rlanday 9y ago
  Given enough time, it does. People used to talk about a “WebKit monoculture” on mobile back when both Safari and Chrome were built on WebKit (although, they enabled different features and used different JavaScript engines). After Google forked WebKit to create Blink, WebKit and Blink started to diverge with different development priorities resulting in different improvements being made and different features being implemented. So as time goes on, and code gets added, removed, and rewritten, much of the commonality eventually disappears over time.

jopsen 9y ago

mozillia research is sort of doing it with gecko. But yeah, from scratch is hard... Google didn't even do that, they started from webkit.

mercurial 9y ago
With Gecko ? It's their original engine. You probably mean Servo (the experimental Rust engine).
- erikbye 9y ago
  I guess it's not wrong to call it their original engine, just remember it's a two-decades-old development that started at Netscape.
  - gsnedders 9y ago
    Well, arguably started at DigitalStyle.
    - robin_reala 9y ago
      Can you expand? I thought I had a good grasp of Mozilla’s history but this is the first time I’ve heard of them.
      - dev_tty01 9y ago
        https://en.m.wikipedia.org/wiki/DigitalStyle https://en.m.wikipedia.org/wiki/DigitalStyle
      - gsnedders 9y ago
        So my understanding is following Netscape's acquisition of DigitalStyle, the decision was made to replace Netscape's existing layout engine with something based on what DigitalStyle had in their editor (which, unlike Netscape's existing one, supported things like reflow), and it was this combination that was open-sourced. Notably, it was only really the layout engine that was replaced: the HTML parser and the JS VM survived unchanged, hence the name NGLayout for what became Gecko.
Klathmon 9y ago
And webkit started from KHTML

captainmuon 9y ago

I would first target a subset of HTML, for example static documents instead of web apps. You would have a specification like AMP which restricts what elements you can use. If a document used the full spec, I would fallback to another engine (e.g. WebKit). You could have full documents in iframes inside limited documents (but cross-frame scripting might be hard to get right in that case). Also, I would try to make it as modular as possible. E.g. layout engine, css engine, js engine etc. as libraries, use the system codecs instead of bundling own codecs, and so on. And it would help to have an extensive test suite, which you could take from other browsers.

krapp 9y ago
The difference between static web documents and web apps isn't the set of HTML they use, it's just that the latter are designed to deeply integrate javascript (and/or, to futureproof this comment, WebAssembly) into their UI, rather than do all of the logic on the server between requests. The only way to ship a browser that doesn't render "web apps" would be to simply not support scripting of any kind. That would permanently break much of the web unless you offered a way to opt in to scripting the way current browser users who run script blockers can. But then you just have a regular browser with script blocking turned on by default. Having different engines for "static" and "web app" documents, and defining a proprietary standard for the former as a restrictive subset of HTML would be unnecessarily complex and hostile to web developers.
- captainmuon 9y ago
  There is a subset of web pages that only use a subset of features - Hacker News is an example, but better examples would be Wikipedia, many news sites, documentation of all kinds, and so on. You have basically static HTML, and use JavaScript for 1) progressive enhancement and decoration (what used to be called "DHTML"), 2) ads, and 3) more and more for client side rendering. You can't do much about 3 right now, but I would offer support for 1 and 2. I would definitely offer scripting, but just not all features. You could autodetect a "lean html" site, or you could use a marker such as "<html lean>" like AMP does. I don't think this is hostile to developers at all, unless AMP is already hostile. You would have a subset of the web platform, yes, but if you only use that you are likely to have a faster and leaner website - even without a new engine. I would view it as a guideline or a best practice, rather than a restiction. Side note: I think the co-mingling of documents and apps is the source of a lot of problems today. Why can ads inject arbitrary javascript into my website?! On mobile, I am regularly redirected to annoying ads that proclaim my phone is infected, and make my phone vibrate and make noise. A news article shouldn't be able to do that!

adventured 9y ago

Amazon and Facebook could both launch entirely new browsers. Spotlight it constantly on Amazon.com or across Facebook's properties as with Chrome on Google.com. Facebook already has far more cash and profit than they know what to do with. $38 billion currently, rapidly climbing. They'll add ~$20 billion to that in 2018. They could do a new browser just for kicks if they wanted to, and they have the vast global reach to generate some uptake. Whether either could claw meaningful share away from Chrome is an entirely different question. Samsung, Tencent and Alibaba all have the resources to launch entirely new browsers if it made sense.

rwmj 9y ago
Alibaba already have their own browser of a sort (https://en.wikipedia.org/wiki/UC_Browser https://en.wikipedia.org/wiki/UC_Browser). As I understand it, it's some kind of thin mobile browser which renders on the server side.
- kinlan 9y ago
  There are multiple versions of UC browser. My understanding of it is: - uc mobile on Android now uses the blink engine, it used to use Webkit. - uc mini ( I think that's the name) has server renderer but it's "uc engine" is a derivative of gecko (not checked recently)
nojvek 9y ago
Hiring talent to build browsers is not as easy as throwing money. The bottleneck is engineers who have the know how to build it. Building your own browser could be a shitty business decision if you can't compete with Chrome for ad dollars. A browser makes sense if you can bundle it with an OS. Android : chrome, ios: safari and Windows: Edge Facebook makes a shit ton of money from ads people click on chrome.
Mountain_Skies 9y ago
Amazon sort of has their own browser called Silk. It's based on Chromium so it's not a built from the ground up endeavor but has been customized on their Fire devices to 'enhance' the browsing experience in a way that seems to benefit Amazon.