3 ms·

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

conradfr 13y ago
Well if the fallback is ng-cloak with the css I guess he got it :)
mathrawka 13y ago
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 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.
e12e 13y ago
Well, from the url: http://blog.angularjs.org/2013/11/angularjs-120-timely-delivery.html 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.
- jessedhillon 13y ago
  Its Blogger -- doing it this way allows them to cache the viewer across their thousands of blogs, and load only the content.
  - e12e 13y ago
    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).
    - jessedhillon 13y ago
      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.
      - pandeiro 13y ago
        Just send binary (that next?)
      - e12e 13y ago
        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.

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

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

e12e 13y ago

Well, from the url: http://blog.angularjs.org/2013/11/angularjs-120-timely-delivery.html 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.

jessedhillon 13y ago
Its Blogger -- doing it this way allows them to cache the viewer across their thousands of blogs, and load only the content.
- e12e 13y ago
  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).
  - jessedhillon 13y ago
    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.
    - pandeiro 13y ago
      Just send binary (that next?)
    - e12e 13y ago
      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.