8 ms·
Right, but these problems are not specific to javascript requests. Any request can fail, be blocked, interfered with, or partially received. Users can switch of
by cabirum 12y ago
Right, but these problems are not specific to javascript requests. Any request can fail, be blocked, interfered with, or partially received. Users can switch off CSS, too. Html page may not load completely. So what?
Some of these issues are fixed with https or http/2. Some with CDN fallbacks or just sane coding. Some are not developers problems - such as clueless users installing malicious extensions or luddite users switching off js.
Why not ask 'Everyone has html, right?'.
- joelanman 12y agoThe point being made is at the bottom - progressive enhancement. If at least the html makes it across the wire, a progressively enhanced website will still "work": you can still read content, click links, submit forms http://jakearchibald.com/2013/progressive-enhancement-still-important/ http://jakearchibald.com/2013/progressive-enhancement-still-...
- cabirum 12y agoSee this comment: https://news.ycombinator.com/item?id=9432629 https://news.ycombinator.com/item?id=9432629 The web is no longer a collection of text content with links and forms. Many, is not most, web apps cannot be represented using html alone as progressive enhancement suggests. The core functionality just isn't there.
- indeyets 12y agoInitial 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 12y agoNot 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 12y 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.
- simonw 12y agoImplementing 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 12y agoand 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 12y 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 12y agoI'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.
- normloman 12y agoBullshit. Every day I see blogs and static pages that deliver the content for articles with javascript. I'll get to a blank page, disable no-script, and can suddenly read the article. Why aren't sites like those using progressive enhancement?
- briandear 12y agoThat's exceptionally common with news sites, I've found. My theory is that there is so much tracking, advertising and "optimization" happening that it destroys the reason that brought you there in the first place.
- rakoo 12y agoRe-read the linked comment. There is a distinction to be made between content-based web and application-based web. The latter absolutely needs javascript (or your application language). If your site is part of the former category though, you should make sure that you keep your focus on the content; all else is secondary. Also, I'd argue that the application-based web is still a minority compared to the content-based web, and you should check what side your site is really on.
- discostrings 12y agoMost sites aren't web apps--they're content-based, with text, pictures, and links. Progressive enhancement makes the most sense for the majority of content on the web. Web applications are certainly useful in some contexts, and progressive enhancement may not be the best approach if your application requires a lot of extended interaction. But building a web app to display primarily text- and picture-based articles and documents is misguided, and it does web users a disservice.
- agumonkey 12y agoAlmost a case for jQuery style of web design. Even though cleaner, more solid js frameworks allow for better apps, it renders the web goal dead, moving toward some kind of prototypical Self/SmallTalk environment, too dynamic, not enough core state that can watched without much specific machinery.
- ChikkaChiChi 12y agoThere is a difference between a web page and a web app. People need to stop conflating the two in discussions like this.
- chriswarbo 12y ago> such as clueless users installing malicious extensions or luddite users switching off js. So if I run arbitrary, potentially-malicious code from the Web, in the form of a browser extension, I'm "clueless"? Yet if I don't run arbitrary, potentially-malicious code from the Web, in the form of JS, I'm a "luddite"? Considering that many browser extensions are implemented in JS, the only difference is in control: users can pick and choose which browser extensions they want to use (I use a few; I've skimmed the source of a couple and written a couple myself), whereas enabling Javascript turns a machine into a third-party free-for-all.
- cabirum 12y agoExtensions have access to browser APIs not available to webpages and run on your every request. Thus they are inherently more dangerous. So installing unsigned extensions from questionable sources makes you clueless, yes. Vanilla js running on webpages should be considered relatively safe. It's sandboxed and not able to do anything - malicious of not - outside it's restricted environment. It can't even get your location or lock a cursor without asking for permission first. If you could somehow disable all logic from executing in your OS native apps, would you do this by default?
- Perdition 12y ago>It's sandboxed and not able to do anything - malicious of not - outside it's restricted environment. That argument is like the one that Linux is more secure because a malicious program will only have user rights. Malicious scripts can do plenty of damage inside their restricted environment. There are whole books on how to securely write web apps due to the danger of "sandboxed" malicious JS. Personally I don't want to be tracked and profiled yet nearly every major website is running multiple tracking and profiling scripts. >If you could somehow disable all logic from executing in your OS native apps, would you do this by default? I do disable native apps ability to communicate with the network unless they actually need it. P.S. I also find that those who take a pure "webapp" approach introduce design flaws into their apps. In Toggl for example when browsing summaries you can't open multiple tasks in detail because instead of using a hyperlink they use JS to fetch and display the task details. Any content link should be able to be opened in a new window/tab.
- bottled_poe 12y agoI don't want dynamically loaded content. I don't want pages to reload unexpectedly. I don't want a site to break standard UI behavior. I don't want externally hosted scripts to track my activity. None of this adds value to my experience as a user. I do want to view the content - ideally in a single HTTP request. Just load the damn content.
- donatj 12y agoAmen.