Comment by franzpeterfolz | Hacker News Reader

Comment by franzpeterfolz | Hacker News Reader

Well, I just disabled JavaScript with ScriptSafe recently due to security and privacy concerns.

And there are many blank pages I get to see, because of this kind of Architecture and CDN's. Nowadays even blogs with mostly static content don't work. That's realy annoying.

If you depend on search engines, remember you get penalties for this kind of sites. You need to have some kind of prerendering to satisfy you ChiefSearchEngineOptimizer.

How do you support Bookmarking in a Single Page Application? I think this is an essential feature and not trivial to implement correct.

I tried Angular. It works. It looks nice and smooth, but I don't think it is a good solution. JS is nice as an enhancement, but I don't like it as a dependency to use the web.

===Addit Not so long ago we have had similar approaches to JS-SPA. They were called Java Applets and Flash. These Technologies are dead. Everything you do today with JS was 10 years ago possible with these technologies. The only constant in the web that's gonna stay is HTML.

JS is overused. There are so many things you're better off without JS, like Blogs, Hackernews or simply valueable content. There might be usecases for SPA, but a high percentage are better off without these cool and fency stuff.

Eliminating Serverside Rendering for scalability reasons as a first step is often followed by implementing prerendered content in script-Tags or via react on node. The only thing that gets scaled is complexity.

If you disable JavaScript, I'm afraid you're not the target audience of 99.99% of the commercial/content internet. The web is no longer static, and websites are now essentially applications. This is a generalisation, but it mostly holds true I think.

As for bookmarking - any dynamic single page content site and many applications will support linking directly to a certain content or section of the app via various techniques.

JavaScript is not a nice enhancement. It IS the web.

It's fine to think of JavaScript as something that you depend on for major features but I still think you have to follow progressive enhancement. A small, but potentially growing, number of users have JavaScript disabled completely but a much larger number of people effectively have it disabled for a non-trivial period of time while things download or even, due to errors, until they reload the page.

If you don't degrade well under those circumstances you're at a competitive disadvantage to sites which do something like quickly return a core HTML page which can display immediately while the full app loads.

Just to reply to one point:

> How do you support Bookmarking in a Single Page Application? I think this is an essential feature and not trivial to implement correct.

I'm not sure I've ever seen this be a problem. You make sure the app is served from any route that exists within the app, and the app's router loads the correct content based on the url when it boots up.

You're correct. In modern browsers we have control over the history via the HTML 5 history API. Previously we used the hashtag to deal with state changes, which mostly worked (does allow pages to be bookmarked).

Google and other search engine crawlers view pages much like browsers these days, see e.g. http://searchengineland.com/tested-googlebot-crawls-javascri... Not sure what the ranking penalty might be. Would guess it's small to none.

I'm surprised even 10% of sites show anything these days. I get a lot of broken sites just by disabling tracking and ads.

I can imagine disabling js would be much like disabling half of the html tags.

In my experience, this isn't really true. Google still can't crawl most non-trivial javascript-powered apps, and if it doesn't work, there's little insight on what you need to tweak to get it working. It hasn't been able to crawl our javascript-powered parts of the site across two major architectures without prerender, and I know a lot of other companies with the same issue.

Most people don't disable JavaScript but beyond that edge case (I consider JS disabled an edge case) I agree that this architecture isn't necessary and overused. A single page app is great on a MacBook Pro with 2 tabs open but run that on most "normal" people's machines and it gets laggy quick.

People always mention disabled JS and SEO as pitfalls but I think performance and practicality are the obvious reasons not to do this that get overlooked. SPA architecture is something I use alongside server rendered pages. When you have one page or a series of pages in a particular user flow that would benefit from no page reloads and are heavy on interactivity then it makes sense but otherwise I can't see the value. I think developers will realize this and take a more balanced approached with a practical mix of pages rendered server side and pages that use XHR and JavaScript to enhance the experience.

> Most people don't disable JavaScript

How, exactly, do you know this?

Sure, it's probably a reasonable guess. I just wonder how many of the people making this claim are simply assuming it to be true or relying on some sort of analytics service. About the only way you could tell is by counting the server logs, which I'm often told are hard/annoying/unavailable by analytics advocates.

Lots of things work fine, and then you go to some new startups page which loads JavaScript from 35 different CDNs and refuses to do anything until they are all whitelisted.

Regarding SEO, your mileage may vary. At JustWatch we had the hypothesis that we can make a static Web App in Angular that uses SEO as the main traffic driver and is both more usable and more search engine compliant than a classic HTML serving backend.

So far, the metrics prove it's possible and we're quite happy with it. Interaction after slightly larger initial loading time (kept low via SPDY / HTTP/2 CDN) is much more snappy than the classic approach. Also, Prod/Dev parity is higher now that we're using exactly the same JS "build" in stage and prod.

Rankings are great, just prerendering took some more engineering to set up reliably than we thought. I can recommend the guys at SEO4AJAX, they've got great engineering and customer support compared to the market leader.

the new 'best practice' is to have a universal app - that renders on the server on first load, and runs as a js app subsequently. This way crawlers and browsers w js disabled still get raw markup. Also, with SPA, you can add the urls to url history, so back button, bookmark etc aren't a problem either.

We support bookmarking via url parameters and hashes. It does take some extra coding to update the hashes in the URL as each action is taken, and to check them and pull in the correct data and application state on reload... but it is definitely a solvable problem.

I have JavaScript disabled by default in my browsers. If the site doesn't load, I usually try finding an alternate source, even if end up loading the cache from Google. I don't like these websites that load JScripts from unrelated places (ie. code.jquery.com, googleapis.com -> filtered), and if it's an e-commerce, I buy elsewhere when I can.

I wish more people would do that :)

Reply on news.ycombinator.com