Yesterday I stopped over to watch a Douglas Crockford talk.
I have spoken here that Douglas is loved and hated in the JavaScript community, and I think there is something wrong in this situation.
As JavaScript developers, we must pay attention to one fact: Crockford knows a lot of JavaScript language. Probably more than all of us.
I say this because the foundation in the theories of Crockford make much sense, and presented by him show that he really understands what he says.
After many years studying JavaScript, i still do not consider myself able to say that I am JavaScript ninja, and taht i know everything.
That is what Crockford does seem to be a ninja and seems to know everything about the language, so the least I can do is listen to the man, pay attention and run back to maybe one day have enough knowledge to question the theories of Douglas.
During the talk Crockford proved by his theories.
But braces “{“ on right
Ex:
block {
...
}
I always put it on the right. But many programmers put on the left, thus:
block
{
...
}
It doesn’t matter. On the right or left, no matter …
Except in JavaScript.
Yes, this is different for JavaScript, for one simple reason.
look at the code:
return
{
ok : false
}
This code will fail.
If we want to return an object literal, we must always put the ”{“ on the right, because in this case the JavaScript returns undefined.
A simple change, and your program will not fail:
return {
ok : false
}
Ever use === instead ==
He explained why, and actually makes sense.
== does not work very well in JavaScript. Even Brendan knew this when he created the language.
What happened was that when the language was standardized, Brendan tried to fix this with the committee, but Microsoft insisted that should not be done.
Why the hell? I do not know.
But Brendan could at least implement ===, then this is the reason why always use ===.
Some examples that prove the failure ==:
0 == '' //true
'' == '0' //false
0 == '0' //true
false == 'false' //false
false == '0' //true
// E o mais bizarro de todos
" trn " == 0 //true
Always declare variables at the top of the function body
Interesting.
Douglas explained in the talk that JavaScript is different from other languages in relation to variable scope.
In other languages, we should always declare variables as close as possible to where we use them. In JavaScript is quite the opposite.
We should always declare variables at the top of the function, because actually is what happens, this is the first thing that is done in the execution flow.
Before the video, a interesting sentence: “If there is one feature of a language that is sometimes problematic, and it can be replaced by another feature that is more reliable, then ever use the reliable feature”
Makes sense.
Well, I recommend that everyone take a look this video. Even those who do not like Crockford. Especially those who do not like.
Open your mind, listen, study, research.
The cool to work with HTML5 is that everyting is new.
The downside of working with HTML5 is that everyting is new.
What i mean is that HTML5 is a new technology, and that many features are still in development.
In other words, is not fully defined as such features will work.
I think it’s a complicated issue for browsers, as they should implement these incomplete specifications.
But all this is part of the transition we’re in, and in some ways, this is very good.
Returning to AppCache, i will quote one of the problems i encountered using this feature, which i think has great potential.
As discussed before, the AppCache is not a feature that only allows your Web App to run offline.
The AppCache can reduce the “weight” of your app, reducing the number of requests.
Imagine that your Web App has 6 JavaScript files, 3 CSS files, and several images.
If any of these files doesn’t have constant updates, all of them can be “AppCached”.
Technically this means that if the amount of KB of your page is 200K, these 200K can be loaded directly Cache.
Yes, the browser has a default caching mechanism, but this cache is not controlled by the developer.
Another relevant factor is that none of the file header are considerd if your app is using AppCache.
With the exception of the Cache-Control: no-store.
Or not.
Well, in the specification are some details that i mentioned, but what i had a problem was this:
“Regardless of whether you include the address of the current page in the manifest, it will be cached”.
Remember that the AppCache was also thought to make an App run offline, it even makes sense, but creates other problems.
If my goal is to reduce the number of requests, and my page is constantly changing its content, this rule eliminates the possibility
to use the AppCache.
We have another rule in specification:
“With the exception of “no-store” directive, HTTP cache headers are overridden by manifests”.
Problem solved then?
No!
For some reason Google Chrome does not respect this rule.
To test this, change the settings of your server (in my case Apache):
<FilesMatch "(.html)$">
Head set Cache-Control "no-store"
</ FilesMatch>
What i did was say that all HTML files should come with the Cache-Control “no-store”.
In Firefox and Opera this works fine. All files listed in the manifest to be AppCached are there, with the exception of the current page.
In Chrome, it just does not happen. The current page always comes from the cache.
Note that this problem can be solved if we use the default functionality of AppCache: Update manifest.
But this is not always possible, or i do not always want to do it.
Being dependent on a manifest file change to update the main content is a delicate thing.
Well, i’m still searching to see if this is a Chrome bug, or actually if Google ignored the rule of “no-store”.
All around the HTML5 is promising and very exciting.
I think that one of the coolest things is the “Offline” possibility.
Strange to think of it as early as 2011, with all progress we have, lots of services on the Internet, Cloud, etc.. Isn’t?
The answer is NO. HTML5 Offline is much more than just working Offline, there are several possibilities that were previously only possible with workarounds, or impossible.
Today i will talk about one of these possibilities: the AppCache.
In my point of view, the AppCache has not had as much attention as other features of HTML5, but it certainly has great potential.
The first point to be clarified is that the AppCache is not just to run an offline web app.
AppCache can be used for one of the most important issues in Web development: Performance.
Yes, using the AppCache you can dramatically reduce the number of requests in a web application.
This is the table of browsers compatibility.
In other words, you already can develop web applications using this feature.
And notice that the major mobile browsers are also listed.
On IE, well … only in version 10. But i do not waste my time talking about it.
>> How?
A manifest file We need to provide a file with the MIME type text/cache-manifest
By convention, the file extension is. appcache
The manifest has three optional sections:
CACHE - All files should be stored in the cache
NETWORK - All URLs that need to be accessed over the Internet
FALLBACK - List of URLs that should be used if the Internet is unavailable
HTML Tag attribute In the <html> tag simply indicate where this your manifest: <html manifest=”manifest.appcache”>
A little bit of JavaScript We have an object to treat with cache, it is window.applicationCache With this object you can monitor the status of the cache
Events: cached, checking, downloading, error, noupdate, obsolete, progress,updateready
Some interesting details about the AppCache:
* The files listed in the manifest are not under the same origin policy, ie, we can list Crossdomain URLs.
But … That is not true for SSL connections, if you are using HTTPS, the files listed in manifest must obey the Same origin policy.
But … Google Chrome ignores this specification, ie, independent of whether or not using SSL connection, you can add Cross-Domain URLs .
* Browser will only refresh the cache if the manifest has been modified.
By convention, we use a comment with the version in the manifest.
Important detail:
Upon detecting that the cache should be updated, the browser must retrieve the new files.
That is, the user must refresh the page 2 times.
For this, a technique that uses JavaScript to detect if a new version is available, and then decide whether to download this new version.
// Check if a new cache is available on page load.
window.addEventListener('load', function(e) {
window.applicationCache.addEventListener('updateready', function(e) {
if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
// Browser downloaded a new app cache.
// Swap it in and reload the page to get the new hotness.
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?')) {
window.location.reload();
}
} else {
// Manifest didn't changed. Nothing new to server.
}
}, false);
}, false);
* The page where set that uses the application manifest, although not listed in themanifest, it will be cached.
This can cause some problems depending on the type of cache your application needs. For this, there is a specification rule: Files with the “no-store” directive defined in theHTTP header will overwrite the local cache.
(Thanks to @miketaylr)
Well, done.
I hope that i have passed clearly what is and what is the AppCache.
References in this article:
I’ve talked about BrowserID here before, and today i come to share some good news.
A few weeks ago, Ben Adida (https://twitter.com/#!/Benade , http://benlog.com/) became a Mozilla tech lead on identity and user data.
But who is this guy?
Well, i did not know yet, but reading about your projects, i just noticed that BrowserID will be a great success.
Ben has published several projects, all based on authentication, and two of them are email authentication, as is the main idea of BrowserID.
I just saw a lecture by Douglas Crockford about what is out there in ECMA5.
Many say that the Crockford’s arrogant, but the guy knows a lot when it comes toJavaScript.
I respect the work of man, and how not to know him personally, do not share the majority opinion.
Well, as a professional Internet watched the whole video, and I advise you to do the same.
In my view, the lecture is an overview of the future of the Web
Very near future.
