Hacker News Reader

Comment by joelanman | Hacker News Reader

The 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-...

View on HN

See this comment: 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.

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

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).

> 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.

Thus forcing me to use js as a server-side lang.

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.

Implementing 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)

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.

> 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" ?

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.

Bullshit. 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?

That'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.

Re-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.

Most 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.

Almost 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.

There is a difference between a web page and a web app. People need to stop conflating the two in discussions like this.

Reply on news.ycombinator.com