3 ms·

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, document

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.
  - krapp 9y ago
    >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. That's fair - but it doesn't imply that it was intended to not execute code, so much as that it wasn't feasible to consider at the time. The web wasn't originally intended to display images either, but it evolved over time. Certainly, in either case, javascript was never intended to carry the burdens it's been made to, but people found it useful to have a Turing capable language as part of the web, and here we are for better or worse. And the web in the near future when WebAssembly takes off is going to execute binaries compiled from arbitrary languages, of which javascript will be only one option. That's going to be awesome in both senses of the word. Not what the web was originally intended for, and certainly not the best of all possible worlds, but I would argue that it's still better than static documents alone, in terms of the possibilities it provides to publishers and users. And maybe the pendulum will swing the other way at some point. Maybe people will choose to write lighter pages and not use unnecessary code. But if they don't, that's still their choice to make, not yours or a browsers to make on their behalf. And unlike with C, C++, Java, etc, you can turn javascript off if you want and still use some of the web.
reificator 9y ago
> I don't think this is hostile to developers at all, unless AMP is already hostile. I think the prevailing opinion on Hacker News is exactly that.
- tree_of_item 9y ago
  I don't see how a subset of HTML could be hostile. AMP is not Google Search.
  - krapp 9y ago
    A subset of HTML isn't hostile. A browser that defaults to only rendering that subset is hostile, because it relegates any content which doesn't conform to that proprietary spec to second-class status.
- baddox 9y ago
  My impression is that HN’s hostility toward AMP is caused less by the spec itself and more by Google’s leverage of its market power in search to incentivize AMP adoption, as well as its “web-breaking” behavior (like sending you to ugly and self-serving google.com/amp/whatever URLs).
baddox 9y ago
It’s true that we can look at most websites and generally agree on which ones are “light” (e.g. HN or Wikipedia) and which ones are “heavy” (e.g. Gmail or SoundCloud), but that doesn’t mean it would be easy to define a specification that would allow all and only light websites to be built. An extremely light and content-focused spec like Gopher would exclude a lot of websites that we would consider light. Terms used to describe light subsets of web capabilities, like “DHTML,” do not appear to be well defined. My initial attempt would be to exclude XHR/fetch, dynamic URL/history manipulation (window.history), and loading resources from other domains. But the latter would probably exclude things I don’t oppose (like CDNs) and things I don’t necessarily support but which would surely drastically impede adoption (like third party ads/analytics services). Can you propose a better and more viable spec?

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.
- krapp 9y ago
  >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. That's fair - but it doesn't imply that it was intended to not execute code, so much as that it wasn't feasible to consider at the time. The web wasn't originally intended to display images either, but it evolved over time. Certainly, in either case, javascript was never intended to carry the burdens it's been made to, but people found it useful to have a Turing capable language as part of the web, and here we are for better or worse. And the web in the near future when WebAssembly takes off is going to execute binaries compiled from arbitrary languages, of which javascript will be only one option. That's going to be awesome in both senses of the word. Not what the web was originally intended for, and certainly not the best of all possible worlds, but I would argue that it's still better than static documents alone, in terms of the possibilities it provides to publishers and users. And maybe the pendulum will swing the other way at some point. Maybe people will choose to write lighter pages and not use unnecessary code. But if they don't, that's still their choice to make, not yours or a browsers to make on their behalf. And unlike with C, C++, Java, etc, you can turn javascript off if you want and still use some of the web.

reificator 9y ago

> I don't think this is hostile to developers at all, unless AMP is already hostile. I think the prevailing opinion on Hacker News is exactly that.

tree_of_item 9y ago
I don't see how a subset of HTML could be hostile. AMP is not Google Search.
- krapp 9y ago
  A subset of HTML isn't hostile. A browser that defaults to only rendering that subset is hostile, because it relegates any content which doesn't conform to that proprietary spec to second-class status.
baddox 9y ago
My impression is that HN’s hostility toward AMP is caused less by the spec itself and more by Google’s leverage of its market power in search to incentivize AMP adoption, as well as its “web-breaking” behavior (like sending you to ugly and self-serving google.com/amp/whatever URLs).

baddox 9y ago

It’s true that we can look at most websites and generally agree on which ones are “light” (e.g. HN or Wikipedia) and which ones are “heavy” (e.g. Gmail or SoundCloud), but that doesn’t mean it would be easy to define a specification that would allow all and only light websites to be built. An extremely light and content-focused spec like Gopher would exclude a lot of websites that we would consider light. Terms used to describe light subsets of web capabilities, like “DHTML,” do not appear to be well defined. My initial attempt would be to exclude XHR/fetch, dynamic URL/history manipulation (window.history), and loading resources from other domains. But the latter would probably exclude things I don’t oppose (like CDNs) and things I don’t necessarily support but which would surely drastically impede adoption (like third party ads/analytics services). Can you propose a better and more viable spec?