6 ms·
A re-introduction to JavaScript
- chintan 15y ago> Last Updated Date: March 7, 2006
- rodion_89 15y agoFortunately the document does not have any material that is particularly dated and not useful today.
- switz 15y agoUnless they can predict the future, it was updated as recently as 2009: > The fourth edition was abandoned, due to political differences concerning language complexity. Many parts of the fourth edition formed a basis of the new ECMAScript edition 5, published in December of 2009. EDIT: If you scroll to the bottom right it says: "Page last modified 21:08, 5 Jan 2012 by Janet Swisher"
- yuhong 15y agoYea, that date is under "Original Document Information".
- artursapek 15y agoWho cares, when was Javascript last updated? I learned something new.
- michaelkscott 15y agoThe page was actually updated relatively recently. I don't know where you got that from.
- greggman 15y agoSadly JavaScript's 16bit strings are broken. Unicode has more than 16bits worth of codes. Especially now that emoji have finally been added the 140million Japanese users of them can now finally take all their messages online......except JavaScript will choke on all of them Welcome to tons of JS Unicode String libraries to work around this problem :-(
- cygx 15y agoI don't get your point - you should not care about characters/codepoints, but rather user-perceived characters/grapheme clusters. You need a library for that regardless of whether the underlying representation is UTF-16 or UTF-32....
- pilif 15y agoMost modern languages such as Python 3 and Ruby 1.9 have you only care about characters and never about the internal representation. Calling the respective methods to get a strings length for example will always return the length in characters. There is no way to get to the byte length without explicitly naming an encoding you'd like to get the byte length for. Older languages, like PHP or JS, Python 2 and Ruby 1.8 leak their internal implementations. The methods to retrieve a string length would return the amount of bytes the internal representation of the string requires. If you need the length in characters, you need to call different methods - sometimes even from external libraries.
- masklinn 15y ago> Most modern languages such as Python 3 Not true until Python 3's "flexible strings" implementation. Unless you're using "wide" builds (which use UTF-32 internally), which are already available in Python 2 and are not the default representation.
- thristian 15y agoI'm pretty sure every Linux distribution's official Python packages are wide builds. Certainly, this is the case on Ubuntu and Debian, and I think Red Hat as well.
- masklinn 15y ago> I'm pretty sure every Linux distribution's official Python packages are wide builds. That's a matter of Linux distributions packaging (again, by default, without any specific configuration, Python will set itself up using narrow builds), and if you assume wide builds your code is broken. Furthermore, pilif asserted a difference between Python 2 and Python 3. There is no such thing prior to the yet-unreleased Python 3.3 as making wide builds the default was explicitly rejected for Python 3, Python 2 and Python 3 behave exactly the same way on that front (again, prior to Python 3.3) Of course pilif is also wrong in asserting that "The methods to retrieve a string length would return the amount of bytes the internal representation of the string requires.", Python < 3.3 returns the number of code units making up the string (never the number of bytes for the the unicode string types — str/bytes is a different matter as it's not unicode data)
- adamrmcd 15y agoThis was actually an thorough overview for JavaScript newbies. My only complaint was that the author glossed over apply() and call() saying they were 'difficult to illustrate', two functions that were new to me. Wisely, the author did link to https://developer.mozilla.org/en/Introduction_to_Object-Oriented_JavaScript https://developer.mozilla.org/en/Introduction_to_Object-Orie... to fill in the gaps.
- schristo 15y agoAccording to the article, the code below causes a memory leak in IE, though I fail to see how. function addHandler() { var el = document.getElementById('el'); el.onclick = function() { this.style.backgroundColor = 'red'; } } I'm assuming the author believes `this` is evaluated immediately and refers to the `el` variable instance, rather than being evaluated when the function is called. Any ideas?
- jdale27 15y agoWhen addHandler is called, the anonymous function expression is evaluated and its result is assigned to el.onclick. Thus, el contains a reference to the newly created function. However, when the function is created, it captures the environment in which it is defined, including the variable el. Thus, el points to the function, and the function (closure) points to el. This is the circular reference that IE can't handle.
- schristo 15y agoMaybe I'm missing something, but the function doesn't point to `el`. `el` just exists in a lower execution context on the stack. If a variable inside the anonymous function referenced `el` directly, then a closure would be formed over `el`. In this instance `this` is just assigned when the function is called.
- mattmanser 15y agoI'm not sure whether you're saying the code is wrong or you can't understand how that code creates the circular reference. This problem was widely known and stopped being a problem in IE8 I believe. Maybe it was IE7. A while ago anyway. That code looks like the type of circular reference that would cause it. You used to be able to download tools to watch for the memory leak. From what I remember the closure will keep a reference to el even though it will never use it, which means el won't be garbage collected when removed from the dom, which means the closure won't be removed from the onclick to free up el. Hence a circular reference. IE6's javascript garbage collector couldn't detect that. The article is old. Here's an article from MS in 2005 describing the problem in more detail: http://msdn.microsoft.com/en-us/library/Bb250448 http://msdn.microsoft.com/en-us/library/Bb250448 Apologies if you understood that and were just saying the code is wrong, but it looks right to me. Not that I can be bothered to fire up IE6 to test it out. EDIT: Some more detail about the definitely historical leak from SO, it also turns out it was only partially fixed in IE7: http://stackoverflow.com/questions/1999840/javascript-circular-references-and-memory-leaks http://stackoverflow.com/questions/1999840/javascript-circul...
- karpathy 15y agoWow that was good! I'm very happy to have found this. I've had very little luck finding good tutorials for experienced programmers who just want to pick up JavaScript. Most tutorials I found either assume very little prior knowledge and write dense paragraphs on what an object is, or they assume too much and explain too little. I love the focus on example-driven explanation as I somehow process code much faster than text, and I love that it is all on a single page (a surprisingly rare feature!).
- jarek-foksa 15y agoIf you are looking to learn how OOP in JavaScript works, I would highly recommend you to read http://killdream.github.com/blog/2011/10/understanding-javascript-oop/ http://killdream.github.com/blog/2011/10/understanding-javas... instead of this MDN article.
- perlpimp 15y agoThis tutorial reminds me of Python reference by new riders from which I picked up and started coding fresh literate python in 2 days, writing code that worked and without bugs. I guess if you can show commonly used idioms and supply edge conditions such as "NaNs are toxic" - language learning happens in a snap. big thumbs up for the tutorial.
- methoddk 15y agoWonderfully written. A great lang that doesn't get enough credit. When people ask me things about JS, I'm sending them there.
- finnw 15y agoToday I would recommend that anyone who plans to learn JS learns Lua first. It's similar enough, but simpler and you don't have to be concerned with all the browser-specific functions right away.