Hacker News Reader

Comment by Pinckney | Hacker News Reader

I think the point that's overlooked here is that the offenders aren't the clever apps that would be impossible to write without javascript. Go ahead and write those. I'm happy for you, really.

The problem is pages that require javascript to display static content. There are very few good reasons for an article, or an image gallery, or a homepage that could have been displayed just fine a decade ago to now need javascript so it can do some stupid flashy thing that breaks the expected interface behaviour. And frankly, that's most of what I'm seeing in "Sigh, Javascript."

View on HN

What, exactly, is the issue with writing a simple content site that requires JS? If you aren't pulling in half a MB of JS, but it does require scripting to function, I don't see the problem. Just because I could spend the effort to be progressive doesn't constrain me to have to do it. It doesn't make me a lazy programmer either: just pragmatic.

99.99% of the people visiting my site have JS enabled and I'm happy to support them just fine without worrying about the really long tail.

Javascript-dependent content _can_ present problems for search engine accessibility

There have been techniques for dealing with this for a very long time: https://developers.google.com/webmasters/ajax-crawling/docs/...

And this is only an issue for pages where you actually want to expose your content to search engines.

Sigh, Google-only websites.

_escaped_fragment_ is a stupid hack that requires hardest bit of work needed for progressive enhancement, but provides none of the benefit.

It's not like other search engines can't step up their game and build the same functionality.

The problem is that now everyone who wants to build a decent crawler/scraper has to do it as well. Used to be any kid in his parents' basement could put wget and sed together and explore the internet. Now Timmy has to bolt a whole damn browser runtime onto his script to make sure he's getting the content text from blog posts and twitter feeds.

Asking Timmy to "step up his game" is heartless, and it'd be unnecessary if we were better citizens.

Maybe Timmy should just have a look at the Google specification! And he would see that he could continue to crawl the web with his favorite tool! He has just to replace #! with an _escaped_fragment_ query parameter, that's not so heartless ;)

Google has been crawling AJAX'd websites bypassing the _escaped_fragment_ mechanism for at least a year now.

Has it really? Do you have an example?

I've never seen an example where Google crawled a page and included content that was loaded via ajax or an external javascript file. I have seen Google index content that is loaded from a script tag included in the html page.

https://news.ycombinator.com/item?id=3985981

Certainly cool that Google is working on this. I suspect someday it will all work perfectly.

However, from working with customers of BromBone, I know this. People have javascript powered webpages that were not getting indexed by Google. Google would crawl the page, and see no content. The pages were not in Google. After creating prerendered snapshots and serving them when the _escaped_fragment_ parameter was present, the pages showed up in Google.

Not only Google! Bing (and so Yahoo), Yandex and Facebook (only #! for this last) support this protocol too.

And if you use html5 pushstate you could even serve the HTML captures to any bots. Eventually you also could easily add graceful degradation to your site serving snapshots for non js users. As of PoC for SEO4Ajax (http://www.seo4ajax.com), I built this application (http://www.appscharts.me) illustrating this purpose.

_escaped_fragment_ is a bit of a hack, but it also provide enormous benefit. It allows you to gain all the benefits this article is talking about (which I won't repeat here) and still make you site crawlable without duplicating code.

You are right about one thing, it is a pain to setup. Much harder than it sounds at first. After doing it a few times, I finally got sick of it and built http://www.BromBone.com. It's a service that takes generates the html snapshots for site owners and keeps them up to date. I hope it will let site owner keep all the positives and eliminate most of the new negatives.

I have to assume, in Google’s case anyway, that they are indexing according to ‘what the user sees’. Not to do so would means lower-quality search results. Users don’t care how the page ‘happens’.

I make this assumption because most of us don’t actually know how Google works, acting as a user’s proxy is in Google’s interest, and it is certainly within their technological capability. (Let me emphasize assume, again.)

This would require that the crawler actually renders sites, indexes the resulting DOM, and clicks what can be clicked. A headless Chrome, perhaps.

From Google's technical guidlines:

"Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site."

https://support.google.com/webmasters/answer/35769?hl=en

Not sure what you are trying to say by merely copying and pasting text about random search engine spiders that may have trouble crawling you. Maybe you could explain?

With regard to Google, however, they are explicit in their support for JavaScript rendered sites:

https://developers.google.com/webmasters/ajax-crawling/docs/...

Amongst many other links.

The "issue" is that you can just put the simple content in a noscript tag and then your simple content site does not require JS. The content cannot be simple if JS is required.

"99.99% of the people visiting my site have JS enabled"

Do you know that for a FACT, or are you just guessing?

To add to this, generally most user data collected is through javascript.

If you don't have javascript enabled...

Yup, that's always in the back of my mind when people talk about javascript-enabled user stats. Of course, it's perfectly possible that the OP IS recording accurate(-ish) JS usage stats, it's just more involved than other client stats that are readily provided to the server, so less likely. If 99.99% wasn't just a figure plucked out of the air, it sounds believable that it's being obtained 'correctly', since it's not 100% :)

...because if it's say 98%, you have just thrown away 2% revenue.

Hardly, you have to consider the additional cost of attempting to support that additional 2%; it could very well cost more than it's worth in development time and long term complexity. Of course that's an app specific decision. Every market you specialize for has a cost, short term and long term, so it has to be worth it financially; businesses aren't in the habit of just being nice for no reason.

Another way to put it is that vanilla HTML will support the full market so you have to be confident that moving away from it will cover that margin in revenue or savings just to break even. On a large commerce site for example, even a small percentage of revenue could be a staggering amount.

That's the opposite way of putting it. The way of extra work to support edge case users that often aren't worth the effort. Now maybe it's worth it for a big enough site, but for the average site I doubt it ever is. I think it perfectly reasonable to ignore users who disable JavaScript for most websites.

So do I tbh but nobody ever makes a proper business case in practise. If you are going to say that HTML is no longer the default protocol for serving content to browsers (and that it is therefore extra work to support rather than the other way round), it seems like quite a big step. I guess we can rationalise the tattered corpses of Java widgets, Flash, ActiveX, Silverlight by saying they had proprietary roots and no universal support but feels like there's a lot of handwavey stuff around client support, RESTfulness, SEO.

Of course HTML is the default protocol, but not vanilla HTML; many sites require JavaScript as well; the default is HTML + JavaScript not just HTML. Supporting non js enhanced HTML is extra work.

It isn't extra work or an edge case. It is doing the baseline correct thing. I can't count the number of fad obsessed "web developers" who ask us why we serve html instead of javascript crap, while they take 3 times as long to produce a broken version of the same thing.

> It is doing the baseline correct thing.

You don't get to define what the baseline correct thing is for a business, profit does that. Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.

>You don't get to define what the baseline correct thing is for a business, profit does that

That's what I am using.

>Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.

I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.

> I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.

I simply don't believe you. It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone. There is no arguing this, it's more work to support 2 modes of interaction than it is to support only 1. You may find it a comfortable workflow for you, to start with vanilla HTML and then progressively enhance it, but regardless of how much you like the style, it is more effort and does have more long term maintenance costs to forever support 2 modes of interaction. No one who isn't completely full of shit would argue that progressive enhancement is less work.

HN is not the venue for that kind of garbage. Your personal experiences and biases are not universal objective truths. Grow up.

I require no lecture about HN from you, I've been here since the beginning. I listed facts not personal experiences and I'm sorry you can't handle that and resort to lying.

> It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone

That is not a fact. It may well be your experience from the way your applications were written, but it is not a fact. You clearly do need a lecture, or you wouldn't be posting garbage.

Whatever child; goodbye.

"Hardly, you have to consider the additional cost of attempting to support that additional 2%"

That's certainly not how I calculate revenue...

Revenue isn't the right metric; profit is. My point is that chasing revenue isn't what good businesses do, they chase profit. I don't care about 2% additional revenue if doing so reduces profit due to the extra development and maintenance overhead and neither should any sane business person.

Obviously. This would have been a solid response to dreamfactory's comment.

His javascript based analytics software has all the numbers.

Search-engine optimization is a large part.

The fact that the JS frequently results in lower usability is biggest on my list. I've encountered Blogger themes which are so fucking piss-poor I literally cannot read them, even with JS enabled.

If the primary goal of your site is content, stick with vanilla HTML. You're vastly better off for it.

> Search-engine optimization is a large part.

It doesn't look like it is too difficult to add search indexing support.

http://eviltrout.com/2013/06/19/adding-support-for-search-en...

"Not too difficult" and "is actually done by your typical technically naive person" is a few worlds apart.

Because most of those solutions have their own half-assed impls of * Loading indicators * Navigation through history * Error display * Scrolling I could go on.

The top reason to require Javascript is to enable user tracking (e.g. Google Analytics, but not just that at all).

Check out meteor.js for why JavaScript would be needed for "static only content". Real time updates. That's why. Everything is an app.

Is this something people even want in content driven sites though? Imagine reddit in real time, it would be a mess and impossible to keep track of what you last read.

Why should users have to click refresh for pages to load more comments or to see when someone replies to you? The fact that reddit does not do this is not evidence that it would be confusing.

Because sites that distract me from what I'm reading to tell me that there are new comments are extremely annoying.

Sure, you could add, say, auto-loading for new comments when you reach the bottom of the page, or setting the message icon to orange when you get a reply, but that hardly requires a full-blown web app, it's a simple addon to a static site.

disqus deals with this issue quite well , disqus will just notify you there are new comments ,it's up to you to load them or not.

You can try out for yourself :)

http://telesc.pe

I have, and it works ok when there is a ton of concurrent users. But on the other hand, I don't think the UX of telescope is any better than reddit's and in some ways worse (example: clicking on a post with a large amount of comments cause the page to pause without any visual feedback. This could be fixed, but is any better than just a regular link?)

Which is silly. If I'm just trying to view a news article from yesterday or a year ago, I shouldn't have to worry about what some silly script is trying to do.

If the core of the content is or should be text, then there's no need for countless silly layers around it.

Maybe you want a PDF instead.

Or maybe some sort of "hypertext" document. That could contain links to other such documents, allowing users to easily navigate content. All this interlinked content could form some sort of "web" even.

So, for static content that changes in real time.

When your only tool is a hammer, everything looks like a nail. There are valid use cases that meteor.js is awesome for, but one should avoid cargo culting.

Maybe I'm getting old but sometimes I really really don't want real time updates.

You want to keep hitting refresh, refresh, refresh?

He wants the page not to change under him when he hasn't hit refresh. Personally, race conditions between user and UI drive me crazy.

No reason why you can't provide real time updates on your content driven site. and respect progressive enhancement. I'd submit this would be the easiest way to do it.

Reply on news.ycombinator.com