Hacker News new | past | comments | ask | show | jobs | submit login

With Javascript disabled the page is completely blank.

edit (bringing text from comment up a level):

If you are building apps for people other than yourself, then having a banner to notify them it won't work is better than a blank page.

A typical banner that I make includes the following things:

- Positioned at the top via CSS and sticks there

- Includes a link to http://www.enable-javascript.com

- Includes a tracking image so I can see how many people are coming without JS enabled

If you have a white page like this blog does, people will think your site is broken and bounce... and may never come back.




Not sure what you were expecting. AngularJS apps aren't usually built with a noJS fallback in mind.


If you are building apps for people other than yourself, then having a banner to notify them it won't work is better than a blank page.

A typical banner that I make includes the following things:

- Positioned at the top via CSS and sticks there

- Includes a link to http://www.enable-javascript.com

- Includes a tracking image so I can see how many people are coming without JS enabled

If you have a white page like this blog does, people will think your site is broken and bounce... and may never come back.


Well, from the url:

http://blog.angularjs.org/2013/11/angularjs-120-timely-deliv...

I was expecting a) a blog post, and b) from the .html-ending a hypertext document, maybe with text and images?

What possible reason could there be for this to be "an app"? It's a blog, it's for reading -- and you already need a reader to access it -- why would you implement a (new) rendering engine?

Ok, I can see an argument for adding comments via javascript and a service, or for posting blog posts and doing admin stuff. But the other reasons (user tracking etc) for having this as "an app" only detracts from the readers experience.


Its Blogger -- doing it this way allows them to cache the viewer across their thousands of blogs, and load only the content.


Well, if they just served html, they'd still only need to serve the content (and the viewer, the web browser, would indeed be cached in the form of an installed application on the end user's system).


The content can be served as a JSON object containing just the post and the metadata. If you scale up to millions of requests, suddenly you're saving a lot of bandwidth by not sending the same header, sidebar, footer etc everytime.


1) You could send the sidebar, footer etc as json, and the content as html. [edit: an by json I mean javascript ;-) or a combination of a script-tag with a fancy-nav.js, and then pull in any additional elements via json/javascript urls]

2) "lot of bandwidth" - I doubt it. It's only the embedded html you'd have to resend -- and that gets compressed with the rest of the main html document. Everything else (images, css, javascript) gets cached via normal request caching.


Just send binary (that next?)


Well if the fallback is ng-cloak with the css I guess he got it :)


Well, I just figured out that these "blogs" (edit: blogger.com blogs) at least provide rss -- doesn't really work in w3m (it downloads the xml, rather than doing som magic and try to render it) -- but at least for me this "design" is far superior to the bloated javascript mess that they try to get you to use:

http://blog.angularjs.org/feeds/posts/default?alt=rss




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: