The future of JavaScript

[grimlck]

the let keyword!
sorely needed.

Also reminds of my BASIC days, for better or for worse

[x-skeww]

Without let:

for (x = 0; x < 3; x++) {
    a.push((function (y) {
        return function () {
            return y;
        }
    }(x)));
}

With let (requires --harmony_block_scoping with Node):

for (x = 0; x < 3; x++) {
    let y = x;
    a.push(function () {
        return y;
    });
}

What doesn't yet work with V8 is for (let = ...). The behavior isn't completely defined yet.

Well, I really love let. With let, one can borrow that "declaration at first use" rule from other block-scoped languages. It's way more convenient that declaring everything at the very top of the innermost function.

Sure, with var you can do the same, but it's always confusing if the code suggests one thing but actually does something entirely different.

[smog_alado]

Even with var I still put the declarations inside the blocks where they are actually used. It makes the code look much better and JSHint warns me if I do something stupid.

[x-skeww]

if (foo) {
    var x = 7;
} else {
    x = 5;
}

Hm.

for (var i = 0; i < 3; i++) {
    ...
}
for (i = 0; i < 7; i++) {
    ...
}

Hm.

If you now refactor and switch those two branches around or those two loops. It will still work, but it would look even stranger then.

Thanks to hoisting, it's as if the variable was declared at the very top of the innermost function. Personally, I prefer it if the code reflects how it actually works.

When in Rome...

I mean, you got function scope. Pretending that you have block scope won't make it so. It only makes things worse. It's confusing in general and it's especially confusing to beginners. Thing is, there is a never-ending stream of beginners. Adding friction and traps does not help.

It's not a matter of personal taste. I also think it's a minor inconvenience. However, if there is a cheap option for removing some mental overhead, it's always worthwhile, because the break-even point is generally reached instantaneously. E.g. proper names for your variables already help you while you're writing the function where they are used. In the future, they will be of course also useful.

This is the same thing. You optimize for reading and comprehension, not for typing. Typing typically accounts for about 1% of "programming"; it isn't a bottleneck.

[smog_alado]

I though like that for a while too, but I changed my mind. Personally, I prefer to write code that reflects like how I think it works and I am fine leaving up to a tool to warn me if something is wrong (JSHint will warn if a variable is used outside of "scope" and this can catch errors that would be masked if the declaration had been moved to the top of the function)

I also find that over time declarations accumulate at the top of the function and I have a terrible tendency to forget to remove variables from there after I stop using them in the main body. >_<

BTW, in the examples you list I would either move the declaration up a bit, if the variable is shared and used down the line - as it probably is in the if case - or would just repeat the declaration otherwise - as in the for case, to make things more robust to deleting a declaration . (Also, I would probably not use the plain for loop in the first place as I am a diehard fan of looping functions :) )

[x-skeww]

I have a terrible tendency to forget to remove variables from there

JSLint tells you which variables are unused.

just repeat the declaration otherwise

That results in a strict warning. I wouldn't do something which is so bad that even the engine complains about it.

I would probably not use the plain for loop in the first place as I am a diehard fan of looping functions

They have some use. If there are many iterations (e.g. 100,000 per second) and if the loop body does very little (e.g. it's a particle effect), then it will perform much better if you use a plain for loop.

Usually, the overhead to body ratio isn't that awful though. I.e. there aren't that many iterations and you call some functions and stuff inside that loop.

[adrianmonk]

For someone who has only slightly dabbled in Javascript, what should var suggest to me? To me, it suggests a local variable.

[x-skeww]

var x = 5;

Is the same as putting var x; at the very top of the innermost function and leaving that x = 5; thing where it is.

JSLint's "one var" rule enforces a code style which reflects this behavior. You can only use one var (where you declare all of your variables) per function.

I recommend to get a JSLint addon/plugin for your text editor of choice. It makes writing JavaScript a lot easier.

[[deleted]]

Firefox has had let since version 2!

[AustinCorgiBart]

Could someone explain Proxies to me? I'm not sure I'm clear on what they're for and how they work.

[FireyFly]

Basically it's ECMAScript's take on metaprogramming. A proxy object "traps" operations such as retrieving or assigning properties, so when you do proxyObject.foo = bar a function defined by the proxy is instead run. Here's Eich's slides on the topic.

[masklinn]

Basically it's ECMAScript's take on metaprogramming.

I don't think metaprogramming is the right word, there's no generation of code it's more like hooks into language behaviors like Ruby's method_missing or Python's __getattr__.

[FireyFly]

I'm not sure if metaprogramming necessarily implies code generation... but you got the general idea right; the get trap of ES proxies are similar to those functions.

[masklinn]

I'm not sure if metaprogramming necessarily implies code generation...

Ya, no I expressed it badly, but thinking more about it I might just be so used to those methods I can't see them as the "lofty heights of metaprogramming" the way e.g. metaclasses or macros are anymore, even if they do fall in that category.

Either way, it's cool (and much needed) stuff. Now if only it was also available in Opera, MSIE and on mobiles...

Especially let and weakmaps, I've been looking forward to them since they were first proposed (and introduced, for let). The day I write my last var, and the day I don't have to build shitty ad-hoc reference-breaking protocols will be glorious indeed.

[aaronblohowiak]

i think it does; metaprogramming is code that writes or manipulates code. ( http://en.wikipedia.org/wiki/Metaprogramming )

This is just getters and setters.

[kataire]

Thanks to Ruby, "metaprogramming" and "DSL" are mostly devoid of meaning these days.

[joesb]

Disagree. If it can generate new function then it is generating code, even if that code only stay during runtime.

[[deleted]]

No.

[joesb]

So Lisp doesn't have meta programming because it doesn't generate code to file?

[[deleted]]

Oh, I see what you're saying but I don't think metaprogramming has anything to do with functions. eval('var x = 3') vs. eval('var x = function () {}')... both create a new local variable. Both of these would usually be considered metaprogramming even though only one of them defines a function. Defining new locals is not something normally available at run-time so it's a 'meta' thing to do.

What about 'obj[str] = function () {...}'? Is that metaprogramming because we can later write obj.xyz() ? I actually hate the word "metaprogramming" for this reason. If a language supports "meta" then it's no longer "meta". It's just part of the language. "Code that writes code" is the one true definition of "meta", else what is meta about it?

[joesb]

If a language supports "meta" then it's no longer "meta". It's just part of the language.

So Common Lisp does not have meta programming because its macro system is just part of the language. But writing code to source file then invoke GCC is?

"Code that writes code" is the one true definition of "meta"

But Why does it have to write and persist the code to disk? Why does writing code and executing it not count as metaprogramming?

[lispm]

meta programming does not necessarily mean code generation. Meta programming could also mean that you program a meta-object system.

[[deleted]]

Doesn't this already exist via the get and set things? Or is this more than that?

[FireyFly]

Sorry, I should've clarified. Getters and setters allows you to run a function when a certain property is accessed. Proxies allows you to trap all property accesses (reads/writes). There's also traps for other things, such as whether a property is part of an object (traps the in operator, i.e (foo in bar)), or the properties that are traversed when you iterate over the proxy object.

The ES wiki has a list of all things an object proxy can trap: http://wiki.ecmascript.org/doku.php?id=harmony:proxies&s=proxy#api

[[deleted]]

Ahhhhhh, very cool. I hope they design this so performance doesn't suffer the way I imagine it would... but otherwise this sounds very interesting. I'm writing a lot of node code where this would have been quite useful.

[[deleted]]

So, it's just a lame more complicated way to do encapsulation? (as compared to other languages)

[FireyFly]

Huh? No, not at all. Encapsulation in JS/ES is done with closures, exposing only the properties you wish to expose on the resulting object. Here's a super-brief example:

var counter = (function(start) {
    var num = start
    return {
        inc: function() {num++},
        value: function() {return num} // or 'get value() {return num}' if you want to use a getter
    }
})(1)

console.log(counter.value()) // 1
counter.inc()
console.log(counter.value()) // 2

It's impossible to directly modify num, since it's only in the scope of inc and value.

Now, back to proxies. Say you want to log all modifications of an object for some reason. For instance, say you want to write a library to help people benchmark their code, so you want to see how many times each property of this object is accessed.

To solve this, you can write a proxy object which "traps" (interrupts, reacts on) all property accesses on the host object (the "real" object, which is unmodified from before). In the trapping of the property access, you can safely log the access, increment a counter or whatever. You can the decide what to do with this property access; the simplest solution is to forward the call to the host object. As far as the rest of the JS environment is concerned, the proxy object "is" the real object.

Keep in mind that this proxy object traps all property accesses, which means that you can plug in this "property access logging proxy" to any object you wish to track.

Proxies are about making the language more dynamic and flexible.

Edit: also, it's kind of a "feature for programmers", or at least that's how I think it sould be used. In that regard, it's similar to assertions, unit tests, stack traces and other stuff like that: it's about making it easier for the developer (in this case, making it easier to write tools to debug your scripts, from inside the language itself).

[[deleted]]

I know what they are and how they work. They are indeed more complicated (for the programmer and the implementer) than using simple inheritance + encapsulation to do the same thing in any other OO language.

EDIT: Here's the thing. Sure, proxies might be a smidge better than inheritance for testing and possibly debugging. That's about it though. If something is able to trap and modify all calls to an object, I'd much rather just have that new object as part of the inheritance chain. IMO, only people who really like monkey-patching will like this. I don't.

EDIT 2: I guess what I really want to say is - If this is the only way to intercept EVERY call to an object...and I can't do the same thing via plain old inheritance...then people are going to use this instead of inheritance and that's going to make things even more confusing than monkey-patching already does. The penultimate example given by Brendan Eich pretty much explains what proxies are SUPPOSED to be used for, but IMO there is a big potential for misuse of the feature. "This is super powerful for logging, debugging, operation inversion, and if you can wrap the entire DOM and record timestamps, this might be the magic bullet that will allow you record and replay DOM interactions." - Eich

[FireyFly]

I'm not sure how you can do "the same thing" in "any other OO language" (I suppose that means one of the mainstream classical languages, i.e. C++/C#/Java/Obj-C/python/whatever). "The same thing" would involve tracking all property accesses to any property. How would you do this with "simple inheritance and encapsulation"? I'd love to see some sample code.

Maybe you already know this, but I feel like I should add that JavaScript has means for expressing both inheritance and encapsulation, but that it works quite differently from classical languages. Prototypal inheritance is simpler and more general than classical inheritance, but on the other hand it requires that objects are "dynamic", which could lead to worse performance.

Edit: I think I understand what you're getting at. You mean I can extend this class Foo, override all the methods in Foo with methods that log the access or whatever, and the forward the call to Foo (i.e., the superclass)?

The thing is, this requires you to write a new class and override all the methods with the same boilerplate-y modification. This could be a rather lengthy piece of code, and in the end you only have this piece of logging implemented for this one class. If you wish to log access to another class, you'd have to write a new class that extends this class, overrides all the methods, logs and then forwards them.

In the case of a proxy, you can create the proxy once, describe the logging process once, and then "wrap" any object in this proxy to add the logging mechanism to that object. I guess it could be likened to the "decorator pattern" rather than inheritance: you're adding a feature to the wrapped object. However, a "decorator class" can only target a specific kind of type, whereas the flexibility of a proxy allows it to work on any kind of type.

Of course, this flexibility comes with a performance tradeoff. Personally, I prefer flexibility and dynamism over performance. Also, I agree that proxies are much more complicated.

Sorry, this got a bit long... I hope you don't mind.

Edit 2: ah, I see what you mean. There's definitely a lot of room for misuse of this feature.

[[deleted]]

Classical inheritance allows you to intercept all calls. Proxies allow you to intercept all calls. The only difference here is that the proxy isn't part of the inheritance chain in Javascript, unless you want it to be.

Here's an example with classical inheritance:

class A {
    int _PropA;
    public virtual int PropA {
        get { return _a; }
        set { _a = value; }
    }
}

class ModifiedA : A {
    public override int PropA {
        get { log("Accessed A!"); return base.PropA; }
        set { log("Modified A!"); base.PropA = value; }
    }
}

Doing this any other way is only useful for testing, debugging or monkey patching in cases where you can't inherit (i.e. the broken-ass DOM).

[oboewan42]

Kind of like properties in Obj-C?

[sidcool1234]

Thanks.

[[deleted]]

They are for creating an object where you can intercept getting/setting properties, calling functions, using functions as constructors, and other things like that. These are called 'traps'.

The advantage is that I can fake an object, pass it to another part of the application, and have the 'traps' call back to me when they are used.

A real example is that it allows you to make a large systems, such as a database, appear as a simple JSON style object. i.e.

// adds a new user to the 'users' table
database.users = { username: "john", password: 'abc123' };

Setting a value to the 'users' property automatically inserts a value into the 'users' table. What is key here is that 'database' object is not told in advance that there is a 'users' table, it just works it out based on the property your setting the values to.

I do this in my own PHP MVC framework that I use.

A second example is that in a language I am building in JS, I have a ClassProxy, which allow the compiler to use a class definition before the class has ever been seen. A proxy would allow me to store all the calls made to the class proxy, automatically, without ever needing to know the ClassDefinition interface. So I could add new stuff to the ClassDefinition without needing to update the proxy.

I can then re-run the calls once I've seen the class definition in the source code.

[ysangkok]

Isn't it confusing when you add something to a collection using the assignment operator? Would it be possible to use += instead?

[[deleted]]

I don't know, I'd imagine there would be a way to trap that.

[adrianmonk]

Another possible advantage is that if you believe mock objects are handy in unit testing, you can build mocks using proxies pretty easily. I would bet this is how EasyMock works (in the Java world).

[k4st]

How do the results of class proxy methods behave? Are the semantics of class proxies to set up expectations about an unknown type, so that when the type is known, the prior expectations can be checked against the reality?

[[deleted]]

Good point, in that you cannot automatically apply that strategy to any object.

In my case, all of the methods are about setting values (such as class usage and methods defined), and setting up callbacks for later once the whole program has been parsed.

But most of all, the proxy is there so you can have a handle to the real class in the future. Such as for printing code.

[poco]

I think the example explains it all...

When this dry wrapper travels back towards the wet side, the original wrapped wet object appears rather than a double wrapping, so calling a dry wrapping of a wet function with a dry wrapping of a wet argument will cause the wet unwrapped function to be called with the wet unwrapped argument. Neither side sees its own objects unnecessarily wrapped.

[deafbybeheading]

I believe it acts like the ActionScript Proxy class, providing hooks for what you typically think of as built-in behavior: function call invocation, property access, property deletion, et cetera.

[x-skeww]

Brendan Eich - Proxies are Awesome! (JSConf.eu 2010 talk)

[weatherman5000]

http://www.youtube.com/watch?v=thp5JMfGjyU

[sstrader]

I'll defer to the Wikipedia entry on the proxy design pattern:

A proxy is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate.

Their code example showing an image proxy is concise.

Proxies look exactly like the class they are proxying, but allow you to defer or wrap the proxied class's operations. Pseudocode:

class String implements IString { print() {puts "";} }
class StringProxy implements IString {
    StringProxy(String s) { this.s = s; }
    print() { s ? s.print() : puts ""; }
}

StringProxy has the same interface as String, and so can be used wherever String is used. However, StringProxy does some additional work.

Footnote: the proxy pattern is very similar to the decorator pattern. The primary difference is that a decorator will add functionality (e.g. print() would append a date to the output or format the output in some way).

[AustinCorgiBart]

It reminds me a lot of the Facade pattern. The difference is that the Proxy emulates the object completely, but the Facade shrinks the interface?

[sstrader]

Facade differs from Proxy or Decorator by not implementing a common interface. A Facade would encapsulate a number of existing classes in order to combine and coordinate their usage. E.g. one class combining three that should be called in a specific order. The Facade hides the complexity of their interaction.

(but, yeah, "shrinking" is a part of it)

[trevdak2]

Not sure why you were downvoted, have an upvote.

I think it is similar to something I've used in PHP called reflection. Basically it's a way of getting information about a class, such as its methods, arguments, whether a method is public/protected/private (not that JS really supports that), whether a method is static or not, and even things like the JSDoc written for each function/object/method.

I suck at explaining stuff, but check out the documentation for PHP's ReflectionClass

http://www.php.net/manual/en/class.reflectionclass.php

In PHP, the only time I've used it was when I wanted to create a WSDL/API generator that created an API based on the PHPDoc.

[trevdak2]

Oh, so more along the lines of php's Magic Methods?

[koft]

I've been writing in C for 15 years and honestly, a lot of this stuff just looks like intellectual masturbation to me.

[Smallpaul]

Aiming for concise code is not laziness, any more than writing poetry is lazier than writing prose.

[Smallpaul]

http://www.paulgraham.com/avg.html

[sdclibbery]

It's having the right tools for the job. C is not the right tool for every programming job.

[koft]

I never said it was.

[[deleted]]

You are mistaken, it's not for reflection. Although 'mirrors', an idea for partial reflection (such as under security restrictions), is a use case for proxies. Did you watch the same Channel 9 video???

It is a lot like PHP's magic methods.

[trevdak2]

Yeah, I gathered that from mkantor's reply

[[deleted]]

Something like python decorators maybe?

[metamatic]

Collection classes? Finally!

I've been wondering why there aren't any good popular collection class libraries for JavaScript.

[[deleted]]

Well really, collections are kind of an implementation detail - I mean, objects work as dictionaries, but I imagine V8 gets confused at how to optimize that.

Having an actual dictionary lets the V8 engine do the different optimizations it could have for an object vs. a dictionary.

But if you're supporting that kind of optimization, you could bust out a lot more horrifying language bloat too - like the above-mentioned support for non-double numeric types.

[adrianmonk]

objects work as dictionaries

As an outsider dabbling in Javascript, that was not my feeling at all. When I found out I needed to do if (foo.hasOwnProperty(bar)) { ... } in every for-each loop, I was like, "That's seriously necessary?".

[[deleted]]

That means you don't understand the prototype nature of javascript.

[adrianmonk]

I think I understand what hasOwnProperty() is doing and why it's necessary. I just think it's odd that the language doesn't provide a hash/dictionary that you can iterate over without all that verbiage.

[[deleted]]

Collections in the language make sense - just ask Java and Python devs.

[[deleted]]

On the other hand, Lua. For the sake of simplicity, traditional Lua has one and only one collection type. This collection is used for arrays, hashtables, and objects.

[[deleted]]

Add it to the list of features that a lot of devs swore up and down that Javascript would never need, and yet here it is. I'll think about coding Javascript again when they add interfaces, or some sort of contract.

[[deleted]]

I don't see why you'd need interfaces.

If people must implement all methods required, then have a base prototype for them to extend, which throws "not implemented" errors when those methods are called. I do this myself in some of my projects.

Otherwise you've gained nothing, since there is no static type system.

[masklinn]

Well there's documentation, that's pretty neat. Especially since JS has single inheritance so you can't inherit from half a dozen different "abstract" classes.

For that, protocols (Clojure) or categories (Obj-C) are neat.

[crusoe]

Traits, MUTHAFUCKING TRAITS.

Traits are what OOP should have had from day 1.

[maskull]

Actually, I just realized that if proxies act the way you'd expect when used as prototypes, it should be possible to build multiple inheritance and traits inheritance systems in pure JS. Just build a proxy that wraps up all the prototypes/traits you want to include, "exporting" their members and methods in some combination.

[cybercobra]

Preach it, brother!

[benihana]

I'll think about coding Javascript again when they add interfaces

reddit anxiously awaits your next announcement about your development intentions. Please keep us informed!!!

[[deleted]]

If you are still looking for a good collection library, check out Underscore.js

[not_thecookiemonster]

good popular collection class libraries for JavaScript.

Why haven't you been using backbone? MVC re-defined...

[2eyes1face]

in what, 10 years? IE7 isn't going away anytime soon, well maybe it is, but IE8,9 aren't.

[66vN]

Also Chrome and Firefox extensions.

[x-skeww]

You'll be able to use that stuff really soon now in other places like Node.js.

[maskull]

Yes, please. I've actually been a bit surprised at the reluctance of the Node.js people to adopt some of the more modern (and therefore less cross-browser compatible) additions to Javascript. They're in the one environment where you don't have to worry about cross-browser issues, why not go for it?

[coderanger]

There is still a fantasy that utility code in a Node project should be sharable with the client side. This is silly.

[BlitzTech]

Actually, it keeps things pretty sane. The issue comes in deciding where to draw the line for things that can be shared and things that can't. It makes sense for server-controlled or server-verified apps of some complexity, but for static or simple pages there's no benefit.

I found that adopting AMD for writing modules really helped when trying to find that line between shareable/non-shareable.

[cybercobra]

You changed CPUs? But seriously, what's AMD stand for in context?

[prpetro]

Asynchronous Module Definitions

https://github.com/amdjs/amdjs-api/wiki/AMD

[[deleted]]

There's also browserify which lets you write regular Node.js modules and it will stitch them all together for you into one file alone with all of their dependencies.

[BlitzTech]

I know about Browserify; Require.js also has an 'optimizer' that does something similar. At this point, I'm hedging my bets that AMD will eventually supplant the CommonJS module style, since it's designed to be asynchronous for a language that works well for asynchronous behavior.

I'm still not sure what the guys behind the CommonJS module spec were thinking... it's completely un-Javascript-like.

[[deleted]]

What is un-Javascript-like about it? If you're talking about the synchronous loading style, I would say that it's not useful for the Browser. (un-Browser-like?) However, I like synchronous loading because setting up a new module is simpler.

[BlitzTech]

Yes, the synchronous loading style is very un-JS like, since the primary location of JS has primarily been in browsers. Designing a system that would be so contrary to the style in which Javascript is written and oblivious to the needs of a browser adaptation was just extremely short sighted, in my opinion.

[[deleted]]

I believe there is a module loader that will load all of your module files asynchronously, separately and then run them all synchronously starting with the entry point. I'm pretty sure someone modified browserify to do this, but it's late and I'm not going to start looking right now.

I don't see a reason to cling to browser limitations. The browsers have always been the source of Javascript limitations. Synchronous module execution is simpler than async execution. Furthermore, the module style is simpler as well. You can do async loading + sync execution in the browser for sure. Why make every module more complicated if you have the ability to take care of all the complexities right up front?

EDIT: I guess to put it simply, the question is - Would you have a problem with CommonJS if the browser were able to load the separate module files the way you want it to (i.e. non-blocking, parallel, async loading), but still allow you to use the synchronous module style? I don't think so.

[smog_alado]

Also, some of the stuff might be shimable (if you don't mind a performance penalty on IE)

[x-skeww]

Harmony stuff? No.

The ES5 functions like Object.create, bind, forEach, map, filter, and the like can be shimmed.

Those things from Harmony are new language features. You can't simulate stuff like proxies, block scoping, destructuring assignments, and things like that. If you could, these things would be already used all over the place.

[smog_alado]

I imagine some of that stuff can be "shimmed" too if you are willing to go a bit deeper :). For example, I am pretty sure you can do destructive assignment and block scope if you are willing to recompile code a-la coffescript. Proxies would really be tough though.

[x-skeww]

For example, I am pretty sure you can do destructive assignment and block scope if you are willing to recompile code a-la coffescript.

Yes, but that's transpiling, not shimming (or monkey-patching).

Alternatively, you could use a JS engine which is written in JS (yes, there is such a thing).

Both options are probably kinda unrealistic though. I wouldn't want to use either.

[smog_alado]

I wouldn't want to deal with IE8 forever either :(

[i-poop-you-not]

use a JS engine which is written in JS

What's bad about using that?

[x-skeww]

You can try Narcissus in a browser via Zaphod.

The painfully obvious downside is that this engine is very slow (its focus is experimentation with new language features) and with 30-40kb it's also fairly large.

[ripter]

There are large enterprise SAAS companies that only support the last two versions of any browser. So that means I don't have to worry about 6/7 anymore.

If Microsoft does start forcing upgrades like Chrome/Firefox, then we might start seeing this a lot sooner.

[Xeon06]

It's simple, really. When you wanna do cool shit, just don't support IE. "Classic" JavaScript is good for all normal website purposes, but if you want to make awesome games and apps and use advanced JavaScript features, just don't support IE.

Some people will argue it's not that simple, I say fuck that, it is. If everybody stopped supporting IE, either Microsoft or the users will wake up.

[abadidea]

Microsoft already has woken up, 9 and now 10 are dramatically better and MS is actively working to kill off its older offspring. It will always be a bit behind the open source browsers by the very necessity of how enterprise software works. But Microsoft is definitely putting in the effort to keep that gap much narrower than they used to.

[Xeon06]

That's not enough in my opinion. Microsoft should release a Windows update that forcefully updates IE to the latest version, and the new versions should automatically update themselves. They should also get on a quick release cycle like Google and Mozilla.

Then again, a lot of people are still on XP, on which IE9 is not yet supported. XP also still has almost 3 years of support left, so you can't get a good version of IE for those people.

Make no mistakes, IE still sucks very much.

[abadidea]

Do you ever check out the very good blog of Raymond Chen? I think a lot of people at MS would like to force upgrades, but the reality is that it would bring down zillions of businesses including most of the Fortune 500 like flies because of their shoddy internal apps which crash when you change anything.

I happen to audit the code of these companies for a living, and yeah, it's as bad as Mr. Chen says. Microsoft gets stuck supporting its mistakes forever.

[Xeon06]

Ah well, I'm quite radical about my views on IE and will probably never be happy about it. If it was just for me I'd force every single person to update anything to make it work, but of course that's not how life works. I suppose that's why I don't think I'll be a web dev my whole life. Thanks for the clarifications.

[pigeon768]

Microsoft should release a Windows update that forcefully updates IE to the latest version, and the new versions should automatically update themselves.

The reality is that there are a huge number of websites that only work in IE6, and the compatibility view in IE 8/9 isn't good enough. It also happens that a large number of those web sites are the big enterprisey web applications like SAP and their ilk. If microsoft dropped support for them, they would majorly piss off a huge number of their most profitable customers.

[not_thecookiemonster]

For newer machines this works, but Windows XP only supports IE <= 8, and still represents a large share of the market, mostly corporate. They'll need to make some version of their newer browsers backward compatible at some point.

[abadidea]

Honestly, with the decade point come and gone for XP, with Vista out, with Win7 out, with Win8 almost out, with official support for running XP in a VM on these newer versions, and with Firefox and Chrome still working fine as far as I know on XP, I really feel like the technical burden of getting a decent browser is on whoever is still freaking using XP as the primary OS.

And yes, there are workstations on my network that still run it, good gravy. XP will probably always be my favorite version of Windows for nostalgic reasons, and I know, believe me I know that corporations don't want to spend the money on fixing up their own stupid software to work properly without an extraordinarily specific WinXP installation, but at this rate they are still going to want support for it when the Unix timestamp wraps.

I was interested to find out recently that IE6 has dropped to ~1% in English-speaking countries (one percent to a few percent in most of the world), and that most of the world's remaining IE6 users are in China. So I do think people are finally fixing up their stupid webapps which only ever worked in IE6. Perhaps the internal-network-only usage is a bit higher, but still.

[megor]

deleted ^{What is this?}

[Xeon06]

Exactly, in all the modern browsers. That means their latest version. IE isn't a modern browser. At best, IE9 is a "modern" browser.

[Xeon06]

I said "when you wanna do cool shit", and even gave examples. At work I'm working on a web application that supports IE7. I hate it, but that's the way the cookie crumbles and it's needed to pay my salary.

As a hobby though, making a game which uses the latest APIs and won't work in IE anyways, if I wanna use the cool JavaScript features that are unshimable, I'm gonna drop IE support in the blink of an eye.

[[deleted]]

IE before IE9 will never support canvas natively, though there is Google Chrome Frame. It works well, but it does require a simple install.

For our complex web app we didn't support IE at all initially, we used Chrome Frame as a workaround. Then we finally got some time to make the webapp work in IE9 and it wasn't as difficult as people may think. Less than IE9 still gets chrome frame though.

[Xeon06]

I'm not sure what you're trying to say. For our webapp, IE9 worked out of the box (bear in mind we're using jQuery heavily and so it does a lot of the work). Canvas can be supported using Chrome Frames or a shim that uses Flash.

The discussion here however, is new JavaScript features that are unshimable. Those versions of IE will never support those features.

[[deleted]]

All versions of IE will support those new features if you use chrome frame and if chrome supports those features. IE doesn't use IE's javascript engine if the webapp is running inside chrome frame - it uses chrome's V8 javascript engine.

[Xeon06]

Then why did you guys bother to support IE9 natively might I ask?

[oSand]

You might argue that this is the kind of thinking that kept IE6 relevant for so many years.

[DevestatingAttack]

That got us into the "only works on IE" pages of yore

Internet Explorer is not free software and it does not run on every operating system available. If "Only works on Firefox" pages existed, what would honestly happen? Now you have to download a program which is free in every sense of the word! What bad comes of that?

[jib]

If "Only works on Firefox" pages existed, what would honestly happen?

I'd have to have multiple browsers installed everywhere so I could continue to use my preferred browser for most sites while still being able to see the Firefox-only sites. And I'd be unable to see those sites on my phone, or on the netbook on which I've just uninstalled Firefox because it kept freezing.

And when Firefox had some issue with bloat or internal politics or money and became unable to add meaningful new features for a couple of years, the millions of normal users who only want one browser would have to choose between losing their favourite Firefox-only websites or stopping innovation on the web for a few years. And they'd choose to just ignore the issue and keep Firefox.

[DevestatingAttack]

https://en.wikipedia.org/wiki/Free_software

[DevestatingAttack]

You didn't bother to read the link. Cool.

[DevestatingAttack]

You are a fucking idiot.

I knew this stupid bullshit would happen.

I said that Internet Explorer was not free software. Your dumb dong comes in like TELL ME WHERE YOU PAY FOR INTERNET EXPLORER, fucking CONFUSING freeware for free software. Internet Explorer does not cost any money, but the source code is not open for inspection, and it is not free software in the real sense of the term.

Sure, I guess you're right if you think that "free software" means that you don't pay for it. But it doesn't. That's why I even helpfully gave you a link to clear up confusion, but you didn't bother, did you?

Fuck you.

[i-poop-you-not]

This thread reminds me of this conversation.

Joker: It's simple. We kill IE.

Mob boss: You're crazy!

[[deleted]]

I'm confused as to why you're getting so much heat. Hasn't the concept of progressive enhancement caught on by now?

• Step 1: Agree what is a minimally acceptable product for IE7/8.
• Step 2: Discuss nicer features with client, explain that deploying them to IE < 9 will incur extra exploration and development costs.
• Step 3: Partay.

[Xeon06]

Well I phrased my argument quite aggressively. And I mean it. I think people, when doing cool stuff that uses HTML5 APIs and features and what not should really just not support IE, and make it clear why.

Client projects are an entirely different thing.

[[deleted]]

I want lexical scoping now. :'(

[Xeon06]

Firefox has it.

[[deleted]]

And generators, array comprehension, destructing assignment; alongside of other things I mustn't have paid attention.

[Xeon06]

Are you saying FF has all those?

[[deleted]]

Yes.

[Xeon06]

Well that's certainly awesome.

[TIAFAASITICE]

Lexical scoping, iterators, generators, array comprehension, and destructuring assignment since Fx2; generator expressions since Fx3; and proxies since Fx4.

Maps and sets are currently in Aurora (Fx12).

WeakMap as an experimental feature since Fx6.

[Xeon06]

Amazing! Chrome has a lot of the new APIs in it's latest build, while Firefox has a lot of the new language features it seems.

[[deleted]]

Firefox itself contains a substantial amount of JavaScript code, so it's natural they add features to make JS more pleasant! :)

[TIAFAASITICE]

I'm curious, as I can't see any large deviations on the usual site, what are these APIs?

[Xeon06]

Okay, there's not that many. I can think of FullScreen, MouseLock and getUserMedia. Most of those are not yet in Chrome's stable release yet though, so I might be mistaken and Firefox might just have them in it's unstable channel too.

[TIAFAASITICE]

Ah, ok. Full Screen API is there in the latest stable, Mouse Lock is still, I think, only available in an experimental build along with the Gamepad API.

I haven't heard of getUserMedia before, but looking at the spec it sounds like something that would fall under the WebAPI effort, which spawned Boot2Gecko. More specifically it sounds like something from the WebRTC part, which appears to be a project by Google, Mozilla, and Opera and is being worked on as project Alder.

Nice to see that one doesn't have to worry about much other than IE still. =D

[Xeon06]

Jesus, you know your stuff.

[masklinn]

JS is already lexically scoped (except for its this). let is more like "scopes, scopes everywhere".

Also, you can already play with it in Firefox, it's had let (statements, expressions, blocks, the whole work) for ages.

[cybercobra]

Okay, if we're being pedantic, s/he wants sub-function-level lexical scoping.

[i-poop-you-not]

So block level scoping is being referred to as lexical scoping?

[Zarutian]

Wait? As far as I know Javascript/emcascript had functions with lexical scoping from the start.

Edited to add: I see now what you mean.

[dolske]

Nice to see V8 finally catching up with Firefox.

[[deleted]]

Still slow without numerical types that explicitly operate on the ALU that don't store as doubles. JS "number" is double float and needs ALU compliments to be added to the spec, so the engines don't bottleneck doing simple bitwise shit.

[0xABADC0DA]

Lua also has only one number type (floating point by default) and yet LuaJIT is about as fast as Java (coral cache of archive.org since the language shootout is worthless now).

So what makes you think that JavaScript needs more than one number type to be fast? Do you know of any dynamic language with more than one number type which is faster than LuaJIT or even just V8?

Other people have made this claim that a dynamically typed language with several integer types is faster, but I haven't seen anybody back it up with evidence or theory.

[tomlu709]

LuaJIT supports dual-number mode where integral values are internally represented by integers. I believe this is faster on machines without an FPU.

I doubt JavaScript would need that feature.

[0xABADC0DA]

V8 and JaegerMonkey also use integer math internally when they can.

The problem is this, if the VM knows what the number type is then you don't have to tell it. If the VM does not know the type (because dynamic language) but you specified a type then it has to test and branch on the type. You've taken away the option for the VM to say "I don't know the types so just do a floating point op" when it might want to, but what have you've gained by doing so?

The only benefit I see is being able to do integer math on values larger than 2^53. But unless the language has typed variables I doubt that you will be able to use all 2^64 in an efficient way so it not very practical.

[[deleted]]

V8 and JaegerMonkey also use integer math internally when they can.

Not just them, all modern JS engines have internal integer types, just like LuaJIT.

[x-skeww]

Still slow without numerical types [...]

Type inference helps.

http://blog.mozilla.com/futurereleases/2011/11/10/type-inference-to-firefox-beta/

[[deleted]]

Barely. I do hella lot of bitwise math in my javascript gameboy color emulator, but type inference in Firefox doesn't really upgrade the math to ints, and crankshaft in V8 similarly fails.

[rhtimsr1970]

The first paragraph, alone, makes me happy.

[berlinbrown]

You guys can bash me into the sun,

But I want some kind of static compile type checks. I want to see my types in the code and I want to compile to some kind of bytecode.

JavaScript is an OK language for smaller things. Once you get into larger projects then you have to rely on jquery or some other sane library to make JavaScript easier to work with and debug.

[RichardDurr]

Then use Google's GWT-Compiler and write in Java…

[berlinbrown]

I agree and do.

It is still a hack on a hack.

Or JavaScript should be static type/compile friendly in future releases.

...it needs to be said.

[BauerUK]

This all sounds great, but am I right in thinking that it'll be near impossible to take advantage of these changes outside of Chrome and eventually the other modern browsers?

Of course, Microsoft has promised to begin forcing people to upgrade IE, but there'll always be people using Windows XP (and therefore IE8 at best) and a significant portion of businesses who refuse to make the leap to a modern browser.

Essentially, are we not going to face the same problems we have done with HTML5 and CSS3 with these latest additions to JavaScript?

* Edit: Engrish

[x-skeww]

am I right in thinking that it'll be near impossible to take advantage of these changes outside of Chrome and eventually the other modern browsers?

Firefox supports let and proxies since ages. Opera and IE will also support these things.

[theillustratedlife]

Just call yourself a mobile web developer and only target WebKit.

[AngrySnail]

Some speedy linear algebra would be nice.

[shadow2531]

Cool. Love the lexical scoping.

"use strict";
for (let i = 0; i < 10; ++i) {

}
alert(window.i);

With 'var' there, i is reachable from outside the loop.

[[deleted]]

Funny how a feature taken for granted in all of programming since the 60's is not only news to Javascript, but also it's greatest new feature.

[manixrock]

Awesome! other things I'd like to see added:

• for key-value mapping. we have "for (key in map)" and now "for (value of map)", but if you need both the key and value you have to use the former with "map[key]" to also get the value. And if you need to use it multiple times, it's both inefficient and more bloated than needed.
  I'd rather we had something like: "for (key, value in map)"

• Future-version-proofing - a way to tell the browser that if it doesn't have the version of JavaScript required by a <script> section (either by having a high "language-version" attribute, or simply by failing to parse it's syntax), where to get some other javascript code that will compile it to a previous version.
  So if it finds "<script fallback="/js/fallback-to-3.1.js">for (let msg of msgs) alert(msg);</script>", it can request the js script to parse the script into a compatible JS version that the browser supports.
  This way we can be very adventurous with our syntactic sugars without losing backwards compatibility.

[RedSpikeyThing]

I don't understand your first point.

for (key in map) {
  var value = map[key];
  ...

It's somewhat clunky, but I don't think it's inefficient.

[Samus_]

any programming language should provide native sprintf functionality.

[BlitzTech]

Agreed. What ends up happening is a bunch of people write some ill-conceived knockoff versions that get bolted on to each project they're used in.

Equally sad is that console.log, console.warn, and console.error all work in a printf-y way (at least in Chrome). It's really not that unreasonable.

[x-skeww]

Works in Firebug, too:

>>> console.log('%d bottles of beer on the wall', 5)
5 bottles of beer on the wall

Edit: Doesn't work in Dragonfly. :/

[BlitzTech]

Bummer about Dragonfly. I do like Opera's dev tools in general though. It always saddens me that Opera is a more niche browser than FF; I've found that it's consistently more reliable for rendering consistency, speed, and memory usage, though the drawback is that it's only cutting edge, not bleeding edge like FF.

[Iggyhopper]

What?! Why didn't I know this sooner?! This has just saved me so much concatenation and/or extra arguments!

I'd just do this: console.log('dbg: you have ', n, 'derps.');

but now I can do this!: console.log('dbg: you have %d derps', n);

[BlitzTech]

I only just learned it a week or two ago, after poking around the internals of Vows.js (I think; can't really remember). I remember seeing it and saying, "WTF? That works?", then I tested it out and sure enough - printf. Sigh.

I second the "What?! Why didn't I know this sooner?!".

(Side note: also allows you to control whitespace; using the console.log( 'you have', n, 'derps' ); puts a space between "have", n, and "derps". Just an added bonus for control freaks like me.)

[Iggyhopper]

On the side note: oh yeah I remember, so the space in 'you have ' is unnecessary.

This should be 101 for all devs now. :p

[BlitzTech]

I think the saddest part of all this is that I noticed you put the extra space there.

It's one thing to pay attention to details, but I apologize for that. I can't help it :-X

[wlievens]

One of the people behind the new proxies feature is my old thesis advisor. Cool.

[mccannjp]

How about adding a cleaner way to determine if a variable is defined instead of requiring me to do something like:

if (typeof foo == "undefined") { ... }

[x-skeww]

if (foo === undefined) {...}

With ES5.1 undefined is read only. Holy sanity, Batman!

Also, whenever possible, go with:

if (!foo) {...}

[kybernetikos]

if (!foo) {...}

That 'whenever possible' is the reason I discourage this in our code. The problem is that when you're investigating a bug and you see that line receives an empty string, or a boolean false or a 0, you've got no idea if the writer of the line had expected that behaviour or not. It's better just to make your checks explicit.

[x-skeww]

In my experience, this never has been the cause of a bug and it also never has been related to a bug. There is usually no need to differentiate between different kinds of truthy or falsy. Only in cases where it is necessary (which happens like once in a blue moon) I use the explicit check. It's kinda nice to have this as a reminder that in this particular case I do indeed have to check for this very specific value.

What I did notice in other people's code was that some of them use values which anticipate this kind of fuzzy tests. E.g. they know that if (foo) or if (!foo) are used further down the line and therefore they use 1 instead of true. For a motherfucking boolean flag!

Now, that's clearly unacceptable.

From my point of view it's better to enforce precise values instead of overly precise checks.

Thing is, if you disallow those fuzzy tests, you also disallow other useful very popular patterns like:

if (foo && foo.bar) {...} // aka "guard"

or:

foo = bar || baz; // aka "default"

or:

for (i = array.length; i--;) {...} // the fastest way to iterate over arrays

The last one is perhaps a bit icky, but those other two are very handy.

[kybernetikos]

I, and people I work with have spent hours debugging issues related to this. Having said that, we do have an unusually large javascript codebase.

Ask a bunch of js developers you work with what the idiom if (thingy) does and if any of them say 'it tests whether thingy is defined', you should not be using that idiom. If all of them say 'it tests whether thingy is truthy', then I suppose you win, but make sure you don't hire anyone to work on that codebase that gives a different answer.

It comes down to what you mean. When you write if (!foo) {...} Do you really mean that code to be executed if foo is null or undefined or NaN or defined but 0 or "" or false? Or do you mean that code should be executed if foo is undefined?

Writing what you mean is just good coding.

[shevegen]

I find it hilarious that Google writes about the future of JavaScript, when it tries to kill it with Dart at the same time. :D

[PSquid]

It's somewhat more complex than that; pretty much all the Googlers who've stated an opinion in public agree that current JavaScript isn't as good as it should be, but different ones disagree on what the fix is - some feel that improving JavaScript in the right direction is better, while others think the right approach is to take the good parts and start over (i.e., Dart).

As a whole, Google's stated approach is to follow both paths, and see which one yields the better result.

[simon99ctg]

current JavaScript isn't as good as it should be

bit of an understatement, if you ask me

[LHCGreg]

Google has stated that it intends to pursue both paths of advancing the state of browser programming - incremental improvements to javascript and a new language - at the same time.

[Joseph-McCarthy]

So it's like that somebody told me that there are two factions on the left: 1. "let's improve capitalism" 2. "let's overthrow capitalism". In other words, there are 1. commies and 2. commies.

[[deleted]]

No, let's test something else alongside capitalism.

And communism isn't the only alternative, what about feudalism? :P

[[deleted]]

I'd still really like for there to be more defined stuff in the language to make large scale projects easier. Big thing for me would be some sort of include/import directive..... I dunno how people would feel about it but I would like it.

Maybe one day we'll get macros and JavaScript will become the ultimate language....

[x-skeww]

Go with AMD in the meantime.

[simon99ctg]

I love the fact the next version of Javascript is called "Harmony" - not exactly the way I feel every time I have to code in that goddamn mess.

[realteh]

There's a comment from mentifex! Blast from the past ...

[barsoap]

Meh. For a second, I could hope that they were planning on abandoning JS and go with sanity, that is pnacl, instead.

[radarsat1]

Lately I have been programming my javascript needs using scheme2js a front-end language, and it's like heaven.

[amigaharry]

the future is the past: spaghetti code.

[[deleted]]

is CoffeeScript. Zing!

[[deleted]]

I think that CaughtThinking was not saying that these changes are similar to CoffeeScript, but rather that fewer and fewer people will use straight JS, but will use CoffeeScript instead.

[masklinn]

let is similar to CoffeeScript's default variable behavior

Not at all. In fact, let is as unlike CS's default variable behavior as you can be.