Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

I'm somewhat of two minds about this.<p>On the one hand, I think he has a point that said features of JS.next are cutting against the grain of present-day JS. There are quite a lot of people programming in JS, many of whom may or may not deserve to be called good programmers but who nonetheless can produce functioning web pages, that would have to switch to a very different coding model to work with JS using these new features.<p>On the other hand, it's difficult to program your code when you know than any of your invariants can be accidentally stomped on by any other code that happens to run on the same page. It's also difficult to write libraries when everything's guts are exposed, even with red tape. Raymond Chen over at MSFT has an entire blog that could be titled "How Implementation Details Become <i>De Facto</i> Interfaces Due to Insufficient Encapsulation."<p>I think my final thought on the matter, is that when you think about it, it's really quite silly that we only have one language for front-end web development. It is, in fact, unacceptably silly. Like, seriously guys, what the hell? This is totally crazy. If you want to do server work, or non-web client applications, or embedded, or whatever else, you have a full array of programming languages. These run the gamut from ball-gag-and-leather-straitjacket static languages to walk-into-anyone's-house-and-drink-their-milk dynamic languages, from concise expressive languages to low-level bit-fiddly-ones, from parens to curly braces to significant whitespace to perl.<p>On the web we have JavaScript. Not that it's a bad language, it has its warts (what doesn't?) but it's actually a cute little language. But I don't have the option of using a language with static guarantees. Or deterministic memory management. Or asynchrony. Or macros. None of these are strictly better, they're all just personal preferences, but the point is, you don't have the choice.<p>That lack of choice is probably what's driving these against-the-grain additions to JS.next. They're adding more features to JavaScript so that it can cover some of the bases that it currently doesn't, and all the different directions it's being pulled in are understandably causing some stress. I think it's the wrong solution, but it's also the one with the easiest transition path. The ideal solution, is that we could use different languages from different paradigms, but how the hell do you crowbar them into existing browsers?<p>So uh... do I have conclusion? I dunno, language evolution is hard, let's go shopping.

<p><pre><code> "const" does not add anything new to a variable. If you don't want to change the value of a variable ... don't change the value of the variable. </code></pre> I've got a better idea: how about we mark the variable in some way and get the compiler to remember this for us. Then, when we come back to the code in 6 months, we won't make mistakes.<p>I have a decade of experience in "dynamically" typed languages, and I prefer modern statically typed languages in <i>almost</i> all situations. Now it turns out you can have both: see Racket and Typed Racket for instance.

jashkenas is one of the most prolific and talented JS devs around (CoffeeScript, backbone.js, underscore, docco are among his credits). I can see why he and other library producers would want as much flexibility in the language as possible.<p>Library <i>consumers</i>, on the other hand, will reap the most benefit from the proposed constraints.<p>`private` is important metadata for a library consumer. Documentation generators can ignore private members, and private tags serve as roadsigns that the member can be ignored if one is only interested in the API. `private` is a very powerful filter.<p>The same can be said for `const`: indicating a value shouldn't change eliminates one more thing one needs to hold in their head as they explore a lib's boundaries.<p>I don't care at all about the performance benefits; I care about communication. `private` and `const` are nearly-free, expressive documentation.<p>I actually like Ruby's "red tape" approach; it offers library consumers helpful metadata while still allowing flexibility. Maybe the best solution is for library developers to rigorously use the _private and CONST naming conventions, and reserve `private`, `const`, and `freeze` for security-sensitive code. Wouldn't that offer the most flexibility?

This is similar to the divide I see in the PHP community.<p>There's been such a big movement towards more strictness, more Java-like features and frameworks, while the more interesting development today seems to be moving away from that, towards more concise, flexible, and expressive languages like Ruby and Python, more FP ideas, and the rise of server-side Javascript.<p>I started programming professionally in Perl, where you were handed a loaded gun and learned the hard way not to shoot yourself in the foot. I appreciate the discipline that demands, making you think hard about what you're doing.<p>I really hope the Javascript community doesn't start to compromise its dynamic nature and lose one of the things that made it great. There are areas where syntax could certainly be improved/made more concise, but keep the dynamism and flexibility all the way (and add more!). Good on Jeremy for fighting for that.

My general feeling is that these un-features take things away, and what they purport to provide in exchange is fewer bugs by virtue of being able to check certain constraints at ‘compile time’.<p>I’m all for taking things away, but I personally want more in exchange. For example, if you’re going to give me immutable or const declarations, give me lazy evaluation as part of the bargain.<p>So I’m not opposed to taking things away, I am just optimistic that we can provide a lot more value than ‘constraints’ in exchange. And if we aren’t going to provide more value, I think we’re setting our sights too low.

As a long time writer of JavaScript I say bring it on. If you want JavaScript to succeed outside client browsers in a big way you must to consider performance. If it wasn't for incredible perf gains in the past couple of years you would not see JavaScript pushing into the server side.<p>However JavaScript performance still leaves much to be desired - <a href="http://stackoverflow.com/questions/6216888/is-nodejs-faster-than-clojure" rel="nofollow">http://stackoverflow.com/questions/6216888/is-nodejs-faster-...</a>.<p>I want JavaScript to close the gap without sacrificing dynamism. And it won't - these feature are <i>entirely optional</i> and they free the implementors to make assumptions which allow further optimization.<p>"Pay for what you use"<p>To be totally honest I don't see myself writing plain JavaScript much longer, I'm closing in on 7 years now. At work I use quite a bit of CoffeeScript and very likely in the near future I'll leverage ClojureScript.

&#62; "private" does not add anything new to a property. If you don't want the &#62; property to be used outside of the class ... don't use the property outside &#62; of the class.<p>I think the author missed the point of private, because it does add something new. Specifically, it adds the ability to know that the property is not being altered outside the class without reading the entire code base.

I've done a lot of low-level JavaScript work via my time developing SproutCore 1.0.<p>Jeremy is right on. Keep JavaScript open. Add red tape if you must, but don't ACTUALLY lock it down. The openness (and lack of package management) are killer features.<p>We are lucky that JavaScript is the language in the browser; it could easily have been Visual Basic (shudder).

He seems to be under the misapprehension that libraries would be impossible or extremely difficult if you added restrictions to the language. This is illogical. Languages with many <i>more</i> restrictions, like Haskell, can still have useful libraries. Sure, jquery wouldn't be able to work in exactly the same way it does now, but it could still work. (I would imagine wrapping objects instead of actually changing their prototypes).<p>Also, he doesn't go over the most useful aspect of static OO, which is interfaces. Being able to force an incoming argument to have attached methods often makes code much simpler, because you don't have to deal with the possibility of someone passing different arguments into your function.<p>Arguments like this usually degenerate into shouting messages, so I would like to conclude that even though I am a huge fan of static typing, I don't think it's for javascript. You can always add a static type checker on top of a non-static langauge, so people like me will be happy. It might be more difficult to go the other way around.

I'm not sure where the opposition to private is coming from, outside of being anti-additional-syntax. <i>Private variables already exist in Javascript.</i> They're just inefficient, because they mean that any of an object's instance methods that reference them have to be declared inside of the class's constructor function, instead of on the prototype.<p>Private variables may be accessible outside of classes in Ruby -- but they already aren't in JS. And JS has extremely strong encapsulation through scoping and closures, so arguments against encapsulation based on the "language grain" fall a little flat for me. If an explicit private keyword enables optimization of existing functionality, then why not have one?

&#62; The freedom of having every object and every property be configurable, settable, introspectable, readable and writable, at least at the language level, is worth the trade off. If we add const, private, and other lock-down syntax, or make class properties private by default (shudder), I guarantee you that many potential innovative libraries that otherwise might spring up will never even be conceived, and frustrating situations that could have otherwise been solved by a quick patch will instead require convoluted work-arounds.<p>If you say so.

I've been asking a lot of dumb questions today, so here's another: Do we have any decent tools to measure memory usage / allocation when running a Javascript program?<p>Once we start introducing these data structures we will have to figure out actual memory storing (16bit? 32bit? 64bit?) which obviously introduces another layer of complexity to "standardizing".

I think my biggest problem with the "if you don't want X to happen, then don't do X" statement is that it only makes sense in the context of working as an individual who controls all possible moving parts. It doesn't make sense (at least, for me) in the context of a team.

Doesn't seem like many people are considering the "security" benefits of having private, constant and frozen.<p>Being able to freeze an object to prevent anything modifying it would be useful for preventing 3rd party scripts you include on your site from deleting or modifying your code's behavior.

From the article: ""private" does not add anything new to a property. If you don't want the property to be used outside of the class ... don't use the property outside of the class.<p>"const" does not add anything new to a variable. If you don't want to change the value of a variable ... don't change the value of the variable.<p>"freeze" does not add anything new to an object. If you don't want to change the shape of an object ... don't change the shape of the object. "<p>Now, having started to dabble a little in Rails and Node--and hence getting exposure to Ruby and JS--I do have respect for a lot of the interesting things you can do in those languages.<p>That said, I've also got a experience dealing with libraries and software engineering on various sized projects, and I'm sensing a pattern here.<p>It seems like good practices (encapsulation, static typing, etc.) are being ignored because they get in the way of "free programming". Now, is this actually an accepted attitude in the web development world, or are these people actively promoting terrible design practices?<p>I understand that programming routines for web pages and the like is not the same as for thick-client applications, but is the use of your library by other people through an interface or namespace collisions really not a large concern?

<i>The recent JavaScript renaissance that we're all enjoying owes debts to JavaScript's foresight as a "free", dynamic language.</i><p>Bollocks. If javascript wasn't the language of browsers, nobody would use it. Its got nothing to do with javascripts awesomeness. Indeed, that it took so long for the community (or in this case Mozilla and Google) to finally say "fuck it, this is the shitbag we're stuck with so at least lets make it faster", just tells me how much they wanted something else to be the standard.<p>The only argument for NodeJs etc is that programmers can code the same language on client and server. Was there some "foresight" that made javascript the language of browsers? No.<p>That said, why fuck with it? There are ways to encapsulate fields and methods in javascript. There are also ways to get around it. Just as there are ways to get around private and const in C++.<p>If private and const really float your boat use GWT.