Comment by philbo | Hacker News Reader

Comment by philbo | Hacker News Reader

Parent Full thread

If you're building JavaScript-heavy/single-page applications, you should be applying the principle of progressive enhancement anyway, there is no reason not to do so.

Progressive enhancement brings a number of benefits, of which friendliness to search engines is just one. User has JS turned off? Page still works. Request to CDN fails? Page still works. Silly lint error slips through to production, breaking all your JS? Page still works. Weird cross-browser issue breaks your JS in some clients? Page still works.

The most frequent arguments against progressive enhancement, which has been prevalent amongst a number of back-end and product people I've worked with, is that it is a waste of time and that it adds too much extra effort. I disagree with both. It is not always necessary to reach full feature parity between your JS and non-JS implementations, for instance an auto-suggest input in your JS code can happily be a vanilla input in the non-JS. But if you do just enough to ensure that your application is functional without JavaScript enabled, my (subjective, biased) experience has been that it doesn't take too long.

A web site can be Javascript-heavy[0] without being a web application[1]. There's a big difference.

If you just need auto-completion, modal dialogs and similar features then you shouldn't build a web application, and you definitely should make your site work without Javascript.

On the other hand, if you are building Google Maps, then you should build a web application. Google Maps doesn't work when you disable Javascript.

Supporting clients without Javascript in web applications often doesn't make sense. If it does, you should consider building a standard web site. Just imagine building Google Maps without Javascript. Or better yet, imagine using a version of Google Maps without Javascript. I'm sure that there are people that could pull that off and still end up with something good but it's not the case for most teams (not enough time, resources or skill) building web applications.

[0]: What's considered Javascript-heavy anyways? I think that including support for standard stuff like auto-completion, modal dialogs or even just including bootstrap's javascript these days makes your site Javascript-heavy.

[1]: By this I mean a single page web application that uses Javascript for state management/routing, rendering, communication with the backend, etc. You should be able to deploy an application like this on S3 and it should work. That's not a requirement but I'm just trying to point out that it's an application built completely with Javascript, with no backend support (except for the api that it communicates with).

> On the other hand, if you are building Google Maps, then you should build a web application. Google Maps doesn't work when you disable Javascript.

The "web application" label you use here means what? That it's okay to ignore web development best practices like progressive enhancement, because "web application"?

That Google Maps ignored progressive enhancement is not a good reason for labelling it as a web application.

Is Fix My Street (http://fixmystreet.com/) a web application? It uses a Google Maps type interface so you can report broken street lights, fly tipping:

https://www.mysociety.org/2011/07/08/technical-fixmystreet-m...

> it's an application built completely with Javascript, with no backend support (except for the api that it communicates with).

It's a circuitous definition. Surely an API requires a backend? And surely that API predominantly uses HTTP?

There isn't much difference between returning structured data, and returning an HTML view of structured data. That's just a twiddling of views from a controller (assuming a well-structured codebase). Both deal with an HTTP request and emit an HTTP response, one just does an extra step of rendering HTML.

My problem with this approach is most people don't/can't pull it off properly with the end result being mediocre/sub-standard in either case. It's like when iPhone competitors tried to compete by producing duo keyboard/touch screen phones. They just ended up loosing both ways.

Pick one and do the best design/implementation you can pull off. One design/implementation is hard enough and unless you don't plan to do any real hustling (like getting out of the office and do some face-to-face marketing and lead generation), SEO shouldn't be that high on your list anyway. Good if SEO works for you but it's not the end of the world if it doesn't.

I agree, the goal of Snapsearch is to allow the possibility of going full steam ahead with heavy javascript, and not having to worry about trying to make it all compatible with non-js clients like search engines. It's all about reducing the workload in making single page apps.

> the goal of Snapsearch is to allow the possibility of going full steam ahead with heavy javascript, and not having to worry about trying to make it all compatible with non-js clients like search engines.

The same people who can't build websites in a progressively enhanced way are the same ones that also can't get other fundamental concepts working properly, like:

* Using HTTP URLs in links (or even, using anchor elements as links)

* text-equivalents for non-text content

* not relying on colour to convey content

* Using appropriate semantic structure to mark up content.

There's not much that can be done to save a developer at that point. The best your tool can do is expose more inferior/low-quality content to a search engine (inaccessible in terms of Perceivability, Operability and Usability - since your solution only deals with the Robustness principle of accessibility), after it has been safely constrained inside a JavaScript-mandated environment.

When JavaScript dependency becomes an acceptable starting point, semantic structure, and good markup principles get dumped just as quickly, because they are interdependent.

Easier said than done if you're using something like Angular or Ember.

If angular or ember make it difficult to follow best practices, are they the best tool for the job?

Less trollishly, although I have no experience with angular or ember, I have built a progressively enhanced application with knockout and I thought it went quite well. As with any progressively enhanced application, it requires that your back-end is set up to respond with both markup and JSON responses, but the data- attributes responsible for binding behaviour are just ignored by the browser when script is not running.

Perhaps my experience is too simplistic, though. Can you give me an example of the kind of things that angular and ember make difficult to progressively enhance?

Yehuda Katz, the lead on Ember.js was categorical about the use of ember.js when you require progressive enhancement: Don't use ember.js.

So this is just a case of using the wrong tools for the job, buying the hype without validating the requirements.

Don't you generally use those for web apps where SEO and search engine indexation is less important? I'm not very experienced in this area, so I find it hard to think of an example where you need indexation/SEO-optimization for the kinds of things you do with Angular or Ember.

I'm very curious to hear of some examples.

Content sites should be able to take advantage of javascript technologies more fully. It's all about user experience in the end. There's all sorts of new ways of navigating or presenting content that isn't just a static document after static document. In these cases, SEO is a requirement.

Ah, good point.

And come to think of it, I'm working on a basic blog and I'm using javascript (react.js, specifically) to make the client-side experiences smoother... I had completely forgotten about that.

Thanks for the insight.

I'm finding a handy benefit of progressive enhancement is that it forces two distinct server side web-controllers for each piece of functionality - a server-side representation, and an Ajax representation.

That's useful in separating the the HTML generation from the business logic in a way that's obviously evident. So it helps me structure the code in a good clean way.

Reply on news.ycombinator.com