4 ms·

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 y

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!
  - krapp 9y ago
    >I would view it as a guideline or a best practice, rather than a restriction. >I would definitely offer scripting, but just not all features. That's a restriction. If site authors have to abide by that or else not have their content render in your browser, you're restricting their freedom to publish the content they want or make their own decisions about what code they choose to write. But if you still have a "backup engine" that will run it anyway, then what's the point? >I don't think this is hostile to developers at all, unless AMP is already hostile. I would think Chrome was hostile if it gave preference to AMP over standard HTML. Those aren't decisions that browsers should make. >Why can ads inject arbitrary javascript into my website?! Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work - you request a URL, you get back whatever the server decides that URL points to. Changing that dynamic would change the web at a fundamental level.
    - captainmuon 9y ago
      I think you are misunderstanding me. I was just trying to answer "how could you concievably write a web browser engine if you are not Apple/MS/Google/Mozilla". My answer is: focus first on the happy path. There are a ton of websites that could be rendered with a simpler browser engine - I believe also faster and with less memory. Fall back transparently to an established engine if necessary. This is similar to how a tracing JIT compiler makes assumptions about the types of variables, and if these are violated (because the language is dynamic), falls back to the legacy path, an interpreter. I further think, if you sell it right, you could get people running sites like blogs, documentation, wikis, to opt in to "strict" or "lite" or "document" mode, but that is an orthogonal issue.
    - eadmund 9y ago
      > > Why can ads inject arbitrary javascript into my website?! > Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work I'd argue that the web wasn't intended to involve executing code, but rather it was originally envisioned to be a means of viewing documents.
baddox 9y ago
That sounds like a much more graspable technical goal, but you would effectively be competing not with modern browsers but rather with the web as a whole, which is a much more difficult social/political goal. If at the same time you could encourage widespread adoption of your HTML subset, then you may be onto something. This is essentially what Google did with AMP, their incentive being their caching network and apparent favoring in search results.
tree_of_item 9y ago
Not sure why you're downvoted, this is a good plan of attack.

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!
- krapp 9y ago
  >I would view it as a guideline or a best practice, rather than a restriction. >I would definitely offer scripting, but just not all features. That's a restriction. If site authors have to abide by that or else not have their content render in your browser, you're restricting their freedom to publish the content they want or make their own decisions about what code they choose to write. But if you still have a "backup engine" that will run it anyway, then what's the point? >I don't think this is hostile to developers at all, unless AMP is already hostile. I would think Chrome was hostile if it gave preference to AMP over standard HTML. Those aren't decisions that browsers should make. >Why can ads inject arbitrary javascript into my website?! Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work - you request a URL, you get back whatever the server decides that URL points to. Changing that dynamic would change the web at a fundamental level.
  - captainmuon 9y ago
    I think you are misunderstanding me. I was just trying to answer "how could you concievably write a web browser engine if you are not Apple/MS/Google/Mozilla". My answer is: focus first on the happy path. There are a ton of websites that could be rendered with a simpler browser engine - I believe also faster and with less memory. Fall back transparently to an established engine if necessary. This is similar to how a tracing JIT compiler makes assumptions about the types of variables, and if these are violated (because the language is dynamic), falls back to the legacy path, an interpreter. I further think, if you sell it right, you could get people running sites like blogs, documentation, wikis, to opt in to "strict" or "lite" or "document" mode, but that is an orthogonal issue.
  - eadmund 9y ago
    > > Why can ads inject arbitrary javascript into my website?! > Because that's what the site authors decided to publish. Like it or not, that's the way the web is intended to work I'd argue that the web wasn't intended to involve executing code, but rather it was originally envisioned to be a means of viewing documents.

baddox 9y ago

That sounds like a much more graspable technical goal, but you would effectively be competing not with modern browsers but rather with the web as a whole, which is a much more difficult social/political goal. If at the same time you could encourage widespread adoption of your HTML subset, then you may be onto something. This is essentially what Google did with AMP, their incentive being their caching network and apparent favoring in search results.

tree_of_item 9y ago

Not sure why you're downvoted, this is a good plan of attack.