psychology dector

The Fluent conference co-chairs look ahead. [A blog post by Simon St. Laurent, originally published on the O'Reilly Programming Blog, republished with permission.] JavaScript and HTML5 just keep moving. One day it’s form validation, the next animation. Then it becomes full-on model view controller stacks getting data from sensors on devices and communicating with back-end servers that are themselves largely JavaScript. Peter Cooper and I have tried to capture some of this power in the upcoming Fluent conference , so that attendees can find their ways to the tools that work for them. Early registration for Fluent ends April 10. To get a 20% discount, use the registration code “2ALITY”. Peter and I paused for a moment to talk about what we’re doing and where we see JavaScript and the Web heading. Though we work together on the conference, our perspectives aren’t quite the same, something I think works out for the better. Highlights include: Different tiers of technology adoption...

[This post is part of a series on JavaScript quirks.] JavaScript is very tolerant when it comes to accepting values. For example, everywhere it expects a number, it does not reject values from other types, but tries to convert them: > '5' - '2' 3 > '5' * '2' 10 Automatic conversion to boolean is rarely problematic and often useful. It is covered here as a preparation for later – we’ll use it to work around quirks. Automatic conversion to string, however, can cause problems. Implicit conversion to boolean: “truthy” and “falsy” values Whenever JavaScript expects a boolean value (e.g. for the condition of an if statement), any value can be used. It will be interpreted as either true or false . The following values are interpreted as false : undefined , null Boolean: false Number: -0 , +0 , NaN String: '' All other values are considered true . Values interpreted as false are called falsy , values interpreted ...

A core of JavaScript (the so-called “good parts”) is elegant, but that core is often obscured by quirks. This introduction is the first of a series of blog posts that looks at twelve common quirks and how to best deal with them: Implicit conversion of values Two “non-values” – undefined and null Normal equality ( == ) Unknown variable names create global variables Parameter handling The scope of variables Inadvertent sharing of variables via closures Array-like objects Subtyping constructors Reading and writing of properties this in real functions The for-in loop A concluding post will cover ECMAScript 6 [1] , which will eliminate most of the above quirks. The series will provide a good overview of JavaScript. It is a translation of a previous blog post in German. ECMAScript 5 will be used and a basic knowledge of JavaScript is required, but much will be explained. I will post one quirk per week. Reference: ECMAScript: ES.next vers...

With Blink , Google has created a permanent fork of the WebKit HTML engine. This blog post mentions a few interesting facts that provide context for that decision. How much did each company contribute to WebKit? There are several interesting diagrams and numbers in the article “ Reviewers and companies in the WebKit project ” (by Daniel Izquierdo Cortázar for Bitergia). It’s remarkable how much Google has recently contributed to WebKit. Obviously, not all contributions are created equal: some benefit everyone, others only the contributor. We don’t know what the ratio between the two kinds is for Apple, Google, etc. Why didn’t WebKit2 adopt Chrome’s multiprocess architecture? Here is an Apple employee’s explanation of why WebKit2 has a multiprocess architecture that is different from Chrome’s: Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could bu...

JavaScript usually automatically converts values to the type that a method or operator needs, which can lead to a variety of bugs. As a counter-measure, Brian McKenna ( @puffnfresh ) suggests using the following code for your tests: Object.prototype.valueOf = function () { throw new Error('Use an explicit toString'); }; What is the effect of this code? You now can’t use the plus operator to convert an object to string, any more: > var obj = {}; > 'Hello '+obj Error: Use an explicit toString > String(obj) '[object Object]' > obj.toString() '[object Object]' > 'Hello '+String(obj) 'Hello [object Object]' How does this work? To convert an object to a specific primitive type T, it is first converted to any primitive value which is then converted to T. The former conversion happens in two steps [1] : Call method valueOf() . If it returns a primitive, we are done. O...

Quick tip (via David Klassen ): The following shell command lists all (highly experimental!) ECMAScript Harmony [1] features that can be switched on in Node.js. node --v8-options | grep harmony For example, Node.js 0.10.2 supports: --harmony_typeof enable harmony semantics for typeof --harmony_scoping enable harmony block scoping --harmony_modules enable harmony modules (implies block scoping) --harmony_proxies enable harmony proxies --harmony_collections enable harmony collections (sets, maps, and weak maps) --harmony enable all harmony features (except typeof ) Note: “harmony semantics for typeof ” is something that (unfortunately) had to be rejected for Harmony. It would have consisted of typeof null returning 'null' , but that change would break too much existing code. Reference: ECMAScript: ES.next versus ES 6 versus ES Harmony

Most people know that ECMAScript is the language standard behind JavaScript [1] . Fewer people know that its name comes from Ecma International , the organization managing this standard. Interestingly, that organization started as “European Computer Manufacturers Association (ECMA)”, but renamed itself to “Ecma International” in 1994. That was done to reflect its increasingly international focus. Ecma is now not considered an acronym, any more. Ecma International is located in Geneva. In contrast, TC39 [1] , the Ecma-hosted committee evolving ECMAScript, is rather USA-centric (true to where JavaScript was created and who created it) and usually meets somewhere in California. This little bit of history also explains why it’s spelled ECMAScript and not EcmaScript: That’s a remnant from when Ecma was still ECMA. Reference: ECMAScript: ES.next versus ES 6 versus ES Harmony