5 ms·

Actually it would be great - in the best interest of users - to make this distinction more pronounced. The "document web" should be a relatively safe space that

Actually it would be great - in the best interest of users - to make this distinction more pronounced. The "document web" should be a relatively safe space that you can comfortably browse with JS disabled. The "app web" is a different beast, and the trust of the user to turn on the JS engine should be earned. We could have "web browsers" and "app browsers", with the former being much more safe and less resource-consuming.

krapp 9y ago
The distinction isn't pronounced. Few sites are, distinctly, only "apps" or "documents." So how would one define an "app" in this case, in a way that wouldn't encompass most of the existing web as "apps?"
- ethbro 9y ago
  Anything that uses JavaScript? Or allows only the minimal subset required to implement AJAX type functionality. The argument for expanding web standards has always been "if we don't, then they'll just appify it and we won't have any say" (see DRM debate). An explicit decoupling of information from interactivity would lessen the pressure for that.
  - krapp 9y ago
    "Anything that uses Javascript" would include, as I said, almost the entire web, including sites which primarily serve text and act as documents, including Hacker News. View the source - it even uses AJAX.
    - librexpr 9y ago
      I've just replied to you with JS disabled. I also created this account with no JS (this was a year ago). Upvoting also works without JS. In my experience, of all the websites that don't work without JS, only a minority actually need it. Most of the time it's silly things like articles and blog posts that just show a blank screen without JS, or drop-down menus that rely on JS even though there are perfectly fine non-JS ways to do it, etc.
      - walterstucco 9y ago
        You can live without electricity if you want. It's not really necessary I bet most of the things we do today with electric tools can be done without
    - c22 9y ago
      "Anything that requires JavaScript" might be a better criteria. Hn gracefully falls back without JavaScript enabled because it's not necessary, just some added convenience.
      - krapp 9y ago
        Even then, sites which lack graceful degradation aren't so qualitatively different from the few that do that they need to be moved to an entirely different platform, viewed from a different device and considered "applications" and not "documents." That seems like throwing the baby out with the bathwater. What does make sense to me is a new platform based on WASM, with related tooling. Photoshop in the browser or something running the Unreal Engine or .Net is not the web enough to maybe deserve its own thing. But a new platform based on what are essentially complaints about complexity or efficiency would be too messy.
    - ethbro 9y ago
      Yes. Right now there's next to zero incentive not to use JavaScript. And only slightly more to engineer a working fallback page. Bifurcating the web would provide one.
      - krapp 9y ago
        You're arguing for a technical solution to what is essentially a cultural problem.
        ethbro 9y ago
        I'd argue that the cultural problem (sites being VM-tech-heavy) is caused by a technology choice (never saying "this much technology is sufficient for a large part of the web"). Or to put it another way, extrapolated down this path README.txt files on the web in the future will only be accessible with a pair of VR goggles.
  - closeparen 9y ago
    A document is static. It's neither necessary nor desirable that we access documents over the internet by contacting their owners. It's better for both privacy and resilience to handle documents over something like IPFS. The web as we know it is much better suited to applications, where websites have behavior as well as content. Whether the rendering is server-side like HN or client-side like Facebook is irrelevant.
- PhasmaFelis 9y ago
  I'd argue that most sites are "documents" that have had "apps" unnecessarily shoehorned into them for cosmetic or financial reasons.
  - cfreeman 9y ago
    Seems kind of silly to ignore that javascript enables much more robust user interfaces. It can and is used poorly or maliciously, but it's used for far more than cosmetic or financial reasons.
    - userbinator 9y ago
      What is "much more robust" even supposed to mean? It sounds like meaningless marketingspeak. The countless number of sites that break the back button, scrolling, general navigation, showering my eyes with distracting animations, or show some stupid popup when I select text make me lean towards the UI being much better without JS, and indeed I keep it off by default. I once had a site beg me to enable JS "for a better user experience", one which didn't need it to work. I did, and promptly turned it off again when I realised what the "better" actually meant (see above). Not going to fall for that one again...
    - adrianN 9y ago
      When I want to read an article in a newspaper, I don't need a "robust" user interface, I need the text and (sometimes) the pictures. Links to other relevant content are a bonus. This could be done with the very first web browser. Yet for some reason (hint: money) newspaper websites load megabytes worth of scripts to display kilobytes of text.
ethbro 9y ago
Good point. The commingling of the two is probably more the "failure" of the web than anything else. There's no reason I should be required to go through the "app" web (Flash, JS, Silverlight) to get something off the "document" web. ... and most use cases don't require an "app" web.
brownbat 9y ago
I really think there should be a .text TLD. I don't know how you enforce it exactly, and maybe it's redundant with pastebin. It still nags at me that sometimes I want to go to the web to just read a thing, measured in the tens of kilobytes, and all this other nonsense just gets in the way. It's my kooky nostalgia probably. Old man yells at cloud. But other times, for fleeting moments, I think about applying for that TLD and feel just a bit like Ray Kinsella...
- panic 9y ago
  I really think there should be a .text TLD. That would be great -- I'm imagining a whole TLD full of sites like http://text.npr.org http://text.npr.org and http://lite.cnn.io/en http://lite.cnn.io/en.
  - azernik 9y ago
    Doesn't have to be that minimalistic - I could see up-to-date CSS being a good member of a document-only web.
- kevin_thibedeau 9y ago
  gopher://
  - Endy 9y ago
    I do find it interesting that within the last year, two new and viable gopher browsers have been created - one for Windows and one for Android.
- DavidPiper 9y ago
  There's .page that could work just as well. I'd be keen to see a movement like that too.
Tobba_ 9y ago
There isn't really any practical reason for most sites to support users with JS disabled, as they're a pretty small minority. So there isn't really any good reason sites or users would actually care about or bother making the distinction. Just make a separate "document web", with a standard that isn't utterly lovecraftian and has all the functionality that current ostensibly "document-only" sites (i.e news, forums, etc) rely on JS for. Then, disguise it inside some hip web framework where the client end just acts as a viewer, client-side rendering to boot (with a fallback for users with JS disabled). Make sure an independent implementation can access the underlying "document" through the endpoints the clientside rendering uses. Now you're able to essentially fool people into supporting it. Also, you could choose to represent your document sites as a pile of data and non-Turing-complete "scripts" that do the presentation, with state that can only change upon user interaction. That may seem like a really backwards way of doing it, but if done right, it would give you a really good bang for the buck in terms of functionality/UX vs implementation complexity.

krapp 9y ago

The distinction isn't pronounced. Few sites are, distinctly, only "apps" or "documents." So how would one define an "app" in this case, in a way that wouldn't encompass most of the existing web as "apps?"

ethbro 9y ago
Anything that uses JavaScript? Or allows only the minimal subset required to implement AJAX type functionality. The argument for expanding web standards has always been "if we don't, then they'll just appify it and we won't have any say" (see DRM debate). An explicit decoupling of information from interactivity would lessen the pressure for that.
- krapp 9y ago
  "Anything that uses Javascript" would include, as I said, almost the entire web, including sites which primarily serve text and act as documents, including Hacker News. View the source - it even uses AJAX.
  - librexpr 9y ago
    I've just replied to you with JS disabled. I also created this account with no JS (this was a year ago). Upvoting also works without JS. In my experience, of all the websites that don't work without JS, only a minority actually need it. Most of the time it's silly things like articles and blog posts that just show a blank screen without JS, or drop-down menus that rely on JS even though there are perfectly fine non-JS ways to do it, etc.
    - walterstucco 9y ago
      You can live without electricity if you want. It's not really necessary I bet most of the things we do today with electric tools can be done without
  - c22 9y ago
    "Anything that requires JavaScript" might be a better criteria. Hn gracefully falls back without JavaScript enabled because it's not necessary, just some added convenience.
    - krapp 9y ago
      Even then, sites which lack graceful degradation aren't so qualitatively different from the few that do that they need to be moved to an entirely different platform, viewed from a different device and considered "applications" and not "documents." That seems like throwing the baby out with the bathwater. What does make sense to me is a new platform based on WASM, with related tooling. Photoshop in the browser or something running the Unreal Engine or .Net is not the web enough to maybe deserve its own thing. But a new platform based on what are essentially complaints about complexity or efficiency would be too messy.
  - ethbro 9y ago
    Yes. Right now there's next to zero incentive not to use JavaScript. And only slightly more to engineer a working fallback page. Bifurcating the web would provide one.
    - krapp 9y ago
      You're arguing for a technical solution to what is essentially a cultural problem.
      - ethbro 9y ago
        I'd argue that the cultural problem (sites being VM-tech-heavy) is caused by a technology choice (never saying "this much technology is sufficient for a large part of the web"). Or to put it another way, extrapolated down this path README.txt files on the web in the future will only be accessible with a pair of VR goggles.
- closeparen 9y ago
  A document is static. It's neither necessary nor desirable that we access documents over the internet by contacting their owners. It's better for both privacy and resilience to handle documents over something like IPFS. The web as we know it is much better suited to applications, where websites have behavior as well as content. Whether the rendering is server-side like HN or client-side like Facebook is irrelevant.
PhasmaFelis 9y ago
I'd argue that most sites are "documents" that have had "apps" unnecessarily shoehorned into them for cosmetic or financial reasons.
- cfreeman 9y ago
  Seems kind of silly to ignore that javascript enables much more robust user interfaces. It can and is used poorly or maliciously, but it's used for far more than cosmetic or financial reasons.
  - userbinator 9y ago
    What is "much more robust" even supposed to mean? It sounds like meaningless marketingspeak. The countless number of sites that break the back button, scrolling, general navigation, showering my eyes with distracting animations, or show some stupid popup when I select text make me lean towards the UI being much better without JS, and indeed I keep it off by default. I once had a site beg me to enable JS "for a better user experience", one which didn't need it to work. I did, and promptly turned it off again when I realised what the "better" actually meant (see above). Not going to fall for that one again...
  - adrianN 9y ago
    When I want to read an article in a newspaper, I don't need a "robust" user interface, I need the text and (sometimes) the pictures. Links to other relevant content are a bonus. This could be done with the very first web browser. Yet for some reason (hint: money) newspaper websites load megabytes worth of scripts to display kilobytes of text.

ethbro 9y ago

Good point. The commingling of the two is probably more the "failure" of the web than anything else. There's no reason I should be required to go through the "app" web (Flash, JS, Silverlight) to get something off the "document" web. ... and most use cases don't require an "app" web.

brownbat 9y ago

I really think there should be a .text TLD. I don't know how you enforce it exactly, and maybe it's redundant with pastebin. It still nags at me that sometimes I want to go to the web to just read a thing, measured in the tens of kilobytes, and all this other nonsense just gets in the way. It's my kooky nostalgia probably. Old man yells at cloud. But other times, for fleeting moments, I think about applying for that TLD and feel just a bit like Ray Kinsella...

panic 9y ago
I really think there should be a .text TLD. That would be great -- I'm imagining a whole TLD full of sites like http://text.npr.org http://text.npr.org and http://lite.cnn.io/en http://lite.cnn.io/en.
- azernik 9y ago
  Doesn't have to be that minimalistic - I could see up-to-date CSS being a good member of a document-only web.
kevin_thibedeau 9y ago
gopher://
- Endy 9y ago
  I do find it interesting that within the last year, two new and viable gopher browsers have been created - one for Windows and one for Android.
DavidPiper 9y ago
There's .page that could work just as well. I'd be keen to see a movement like that too.

Tobba_ 9y ago

There isn't really any practical reason for most sites to support users with JS disabled, as they're a pretty small minority. So there isn't really any good reason sites or users would actually care about or bother making the distinction. Just make a separate "document web", with a standard that isn't utterly lovecraftian and has all the functionality that current ostensibly "document-only" sites (i.e news, forums, etc) rely on JS for. Then, disguise it inside some hip web framework where the client end just acts as a viewer, client-side rendering to boot (with a fallback for users with JS disabled). Make sure an independent implementation can access the underlying "document" through the endpoints the clientside rendering uses. Now you're able to essentially fool people into supporting it. Also, you could choose to represent your document sites as a pile of data and non-Turing-complete "scripts" that do the presentation, with state that can only change upon user interaction. That may seem like a really backwards way of doing it, but if done right, it would give you a really good bang for the buck in terms of functionality/UX vs implementation complexity.