i m still opening a dozen tabs and reading them whenever i want, unfortunately most newer js only web blogs such as inc mobile, end up having a lot of errors and white pages..
i understand your newly found js excitement with your full ember.js app, but do'nt forget the lessons from java the browser plugin and flash.
1. ok you re real time, but don't assume i m watching your site like a tv
2. dont consume my precious cpu power.. otherwise app throttling will come to browser tabs..
3. dont end up in lots of clientside errors due to various problems, including local storage.. twitter mobile client is an abysmal example where tweets are lost on screen and inc mobile is another with empty ehite pages
JavaScript architecture skills evolved much more slowly than traditional back-end web development and of course it's more difficult to monitor errors that happen on the client side, so yes, it's still a reality that there is a correlation between heavy javascript and broken pages.
However I don't think citing the problems with Flash and Java Applets is applicable. JavaScript maturity is explicitly the long-awaited remedy to the problems of those bolted-on runtimes. It's true that bloated over-the-top CPU-hogging monstrosities will be done with JS as with prior technologies, but there's no technology that is immune to that.
FWIW, Ember is pretty performance-oriented and lets you get a lot done with a very low code / performance / byte overhead.
Javascript is no cure-all. Just like flash and java, avoiding the subjugation of built-in browser features (back button, bookmarking, hyperlinks, context menus, copy and paste) requires explicit effort many developers simply don't give either out of laziness or ignorance.
Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature.
> Being able to CURL any page on your site and parse it using standardized, agreed upon tag names is a feature.
But the vast majority of my users don't even know what cURL is, so why should I worry about this? And in any case, I believe that if I wanted to extract content programmatically, consuming the same API that the Javascript uses to fetch content would be much easier than extracting it from HTML.
The vast majority of users don't know what a bookmark, a URL or a back button is. This isn't any kind of argument. We don't do the right thing because people know about it. We do it because it doesn't secretly break so many of the conveniences we're used to. We. Us. Power users. Hackers.
Tell me, why should you be lazy just because you think the vast majority of your audience are fools and won't notice?
-sigh- why would you take that away from my comment? The point is that javascript makes it possible to build a performant and smoothly integrated web app where with Java and Flash by their plugin nature it is impossible.
I think some browsers already slow down the render loop in non-visible tabs, but the much nicer solution (if people use it) is the Page Visibility API.
i understand your newly found js excitement with your full ember.js app, but do'nt forget the lessons from java the browser plugin and flash.
1. ok you re real time, but don't assume i m watching your site like a tv
2. dont consume my precious cpu power.. otherwise app throttling will come to browser tabs..
3. dont end up in lots of clientside errors due to various problems, including local storage.. twitter mobile client is an abysmal example where tweets are lost on screen and inc mobile is another with empty ehite pages