4 ms·

Initial server-side rendering is still an option. User will be able to read the page, at least. And if URLs use a sane scheme, navigation would work too

cabirum 11y ago
Not an option. Concrete examples: anything webgl, image editing, games, even a simple curl app from yesterdays post (curlbuilder.com). Implementing curl app server-side would require double work which is against principles of progressive enhancement (or programming in general).
- wtbob 11y ago
  > Implementing curl app server-side would require double work which is against principles of progressive enhancement (or programming in general). That's exactly the use-case of server-side JavaScript! Write a small library to build curl commands; use it in both the web page's JS and on the server, with a small shim on each. 1¼ times the work.
  - cabirum 11y ago
    Thus forcing me to use js as a server-side lang.
    - wtbob 11y ago
      Yes, that is the catch. But I'd rather impose the burden of writing JavaScript on developers than the burden of requiring JavaScript on users.
- simonw 11y ago
  Implementing http://www.curlbuilder.com/ http://www.curlbuilder.com/ with progressive enhancement (without duplicate code) is trivial - in fact it would make a great tutorial on how to do progressive enhancement. Just implement it as a regular form-based application, then add some JavaScript which Ajax-submits the form data and loads in the generated curl command on each keystroke. (Or you could use server-side JS and share code on the client and server)
pharke 11y ago
and if there's nothing on the page to read? Should every chat app have a non-JS fallback option? Do we need to implement all color scheme, layout and templating tools in pure CSS? Facetiousness aside, the web is most definitely not just text based anymore. Whether we like it or not, the web is now in part visual (and aural) and is becoming increasingly moreso. This is not a bad thing. It provides a platform for rapidly developing and deploying applications that cover the full gamut of uses we have thought up for the personal computer. Using JS to simply display static content is overkill and not the best use of the technology and it is absolutely correct to say that this is better served by using Plain Old HTML. That is not the entirety of the web anymore and the more I see this argument that every web app must support a text only interface the more it sounds to me like an argument for every television show and movie to be produced as a radio drama with pictures.
- mariusz79 11y ago
  > Should every chat app have a non-JS fallback option? Is it really that hard to add "We're sorry but your page did not load correctly" ?
  - pharke 11y ago
    I'm not arguing against providing a decent notice to people who's browser set up is not compatible with the technology being used by the application. I believe that, where possible, elements should provide support for people who's interaction with the web may be limited whether by physical disability or some other limitation. I'm not advocating dropping semantic tags and serving all text by inserting it into the dom, I just believe that the web is moving beyond being simply a platform for disseminating static content and while that remains important we should not let it hamper efforts to evolve the web as a platform for new technologies and uses. I suppose I should have more verbosely indicated the facetiousness of the first few rhetorical questions but they do serve a point.

cabirum 11y ago

Not an option. Concrete examples: anything webgl, image editing, games, even a simple curl app from yesterdays post (curlbuilder.com). Implementing curl app server-side would require double work which is against principles of progressive enhancement (or programming in general).

wtbob 11y ago
> Implementing curl app server-side would require double work which is against principles of progressive enhancement (or programming in general). That's exactly the use-case of server-side JavaScript! Write a small library to build curl commands; use it in both the web page's JS and on the server, with a small shim on each. 1¼ times the work.
- cabirum 11y ago
  Thus forcing me to use js as a server-side lang.
  - wtbob 11y ago
    Yes, that is the catch. But I'd rather impose the burden of writing JavaScript on developers than the burden of requiring JavaScript on users.
simonw 11y ago
Implementing http://www.curlbuilder.com/ http://www.curlbuilder.com/ with progressive enhancement (without duplicate code) is trivial - in fact it would make a great tutorial on how to do progressive enhancement. Just implement it as a regular form-based application, then add some JavaScript which Ajax-submits the form data and loads in the generated curl command on each keystroke. (Or you could use server-side JS and share code on the client and server)

pharke 11y ago

and if there's nothing on the page to read? Should every chat app have a non-JS fallback option? Do we need to implement all color scheme, layout and templating tools in pure CSS? Facetiousness aside, the web is most definitely not just text based anymore. Whether we like it or not, the web is now in part visual (and aural) and is becoming increasingly moreso. This is not a bad thing. It provides a platform for rapidly developing and deploying applications that cover the full gamut of uses we have thought up for the personal computer. Using JS to simply display static content is overkill and not the best use of the technology and it is absolutely correct to say that this is better served by using Plain Old HTML. That is not the entirety of the web anymore and the more I see this argument that every web app must support a text only interface the more it sounds to me like an argument for every television show and movie to be produced as a radio drama with pictures.

mariusz79 11y ago
> Should every chat app have a non-JS fallback option? Is it really that hard to add "We're sorry but your page did not load correctly" ?
- pharke 11y ago
  I'm not arguing against providing a decent notice to people who's browser set up is not compatible with the technology being used by the application. I believe that, where possible, elements should provide support for people who's interaction with the web may be limited whether by physical disability or some other limitation. I'm not advocating dropping semantic tags and serving all text by inserting it into the dom, I just believe that the web is moving beyond being simply a platform for disseminating static content and while that remains important we should not let it hamper efforts to evolve the web as a platform for new technologies and uses. I suppose I should have more verbosely indicated the facetiousness of the first few rhetorical questions but they do serve a point.