ES.next needs You!

The next JavaScript specification is moving towards completion. TC39, the technical committee charged with creating ES.next (also known as ES Harmony, and sometimes ES 6) has already tentatively approved a number of proposals and there are a bunch more straw men awaiting approval. TC39 includes some of the finest minds in JavaScript (not least, Brendan Eich himself) but as Jeremy Ashkenas famously cautioned “JavaScript is too important to be left to the experts”. They need our help.


The Problem

Some history. In order to foster consensus on the heels of the ambitious yet ultimately ill-fated ES 4, which was abandoned due to internal wrangling, ES 5 adopted a deliberately incremental and conservative approach, addressing immediate pain points without significantly restructuring the language. ES.next picks up many of the threads left over from ES 4, sometimes co-opting idioms and conventions from other languages in an attempt to address decade-old issues which, in truth, many productive JavaScript developers have long since overcome. There are some in the JavaScript development community who have severe misgivings over this approach, while others are generally happy but have the knowledge and experience to offer improvements. Unfortunately members of both groups are having a hard time being heard.

There is essentially one channel of input into the the TC39 group – the es-discuss mailing list. Unless you’re already a member of TC39, it’s a less than an ideal forum for change. Non-members can feel like outsiders, outflanked by TC39 gurus, who (understandably) would rather not revisit the scenes of their hard-fought consensus, so instead simply restate (often en masse) the opinions that got them there. Being a visitor to es-discuss is often frustrating; its untenable for an individual to claim to represent the perspective of the developer community, yet without the weight of the developer community, lone voices are easily dismissed. Many developers have told me they have given up on es-discuss, some have even stated that they hope ES.next will just go away. That’s too bad, it means our extraordinary community, the innovators and the creators, the doers and the fixers are (or feel they are) effectively excluded from the process whereby the next version of their language will be defined.

Getting onto TC39 is tough, it takes plenty of time and money. In Brendan Eich’s words “It’s hard unless you are a non-profit”. The TC39 committee does a great job of poring over the academic nuances, and to their credit they’re also making huge efforts to make the language more accessible to those with little or no JavaScript experience. But the big disenfranchised white elephant in the room is us: experienced, capable JavaScript developers who love the language for what it already is: closures, first-class functions, a limited syntax which in turn provides an unlimited capacity for innovation. We know the quirks, we work with them every day and invariably we’ve learned how to use them to our advantage. In fact, love of the language is what appears to be missing from the current set of ES.next proposals. Classes in a dynamic language where mock classical inheritance is the third of fourth best form of re-use, hard lexical this binding which erodes the feasibility of call and apply and adds yet another rule of context assignment, block scoped let declarations that must co-exist with function scoped var declarations, incongruous const and static keywords, type guards. Which of these features have we, the developer community, been holding our breath in anticipation of? How is the addition of these features (when backwards compatibility more-or-less forces the retention of existing language features) going to simplify the language and keep it flexible?

ES.next feels like step one of a well-intentioned long term master plan – with the ultimate aim of weaning developers off of some of JavaScript’s most characteristic features: functional scoping, late this binding, prototype semantics, globally bound natives and the arguments object – to name a few. The scale of these proposals means browser adoption will inevitably be staggered and piecemeal, and of course legacy code must still work; so while new features are added, old ones cannot be removed. The short term looks like a confusing mess of new rules and semantics coexisting with old ones.

To be clear ES.next has good things too: the module loader proposal is huge (though we must ensure the API is concise enough to encourage adoption); weak maps and proxies seem like natural fits for the language and will have little or no impact on the legacy code base; and Object.extend (or a variant thereof) is long overdue. Still a large portion of the developer community remains gravely concerned by the sheer weight and complexity of new features, or worse still, they’ve become disinterested in the entire process. We’re too good to not have a say in the next JavaScript.

JSFixed

JSFixed is an initiative created by Anton Kovalyov and myself. There are two goals

1) Provide the the TC39 committee with a much needed gauge of developer opinion.
2) Provide developer feedback directly to browser vendors.

As a first step we want to hear your opinions as we explore the best way to make this project effective. Should we develop and promote our own set of language proposals or should we focus on filtering and refining the existing TC39 work according to actual developer need? Do you want a different set of features than those advocated by TC39, or just fewer new features? To that end we want to encourage all interested developers to submit feedback via our github account. We’ll also be reaching out personally to interested developers via coffee, beer, IRC, IM and email.

Our intention is for the discussion process to be entirely open and documentation media to be freely editable, wiki-style. However, in order to avoid the endless back-and-forth and design-by-committee nature of the TC39 process, final proposals will likely be triaged and voted on by a team of 3-5 people (with full deference to the feedback of the community). We want to encourage a transparent and approachable documentation style with copious examples. Backus-Naur notation, while a necessary formality, should not be a pre-requisite to understanding a proposal.

We Need You!

The indifference of many developers towards the EcmaScript standard is understandable. They didn’t write it and it doesn’t represent their needs. This can change. We, all of us, can change it. By putting developers at the center of the design process we can remove the perceived barrier between TC39 and the larger JavaScript community, and by doing so breath fresh life and energy into future standards. Everyone who cares about JavaScript ought to have a stake in its future, everyone who cares about JavaScript needs to be heard – web developers, node developers, CoffeeScript developers, anyone whose productivity and creative output depends on JavaScript. The greater the participation, the easier it becomes for JSFixed to speak on behalf of JavaScript developers and the more JavaScript becomes representative of all those who use it.

It is our hope that by acting as a clear and vocal advocate for the developer community, JSFixed will have a positive impact on the TC39 process, ES.next and JavaScript.

● Create an issue at github
● Follow us at @jsfixed

About these ads

34 thoughts on “ES.next needs You!

  1. And I already thought that everything is lost. I’m glad there are still some good people out there. Personally, my biggest problem with ES6 are classes. One does not simply add classes to “prototype-based language”. It feels like people which found out they will have to use JavaScript due to it’s success decided to change it to something they are used to and by doing so destroy it.

    On the other hand, there are few things I really like in ES6 like the “…” operator.

  2. Thanks for leading the charge, Angus. It seems like the most critical thing would be getting endorsement from the most influential JS practitioners/library authors: John Resig, Jeremy Ashkenas and someone from the node.js community (Ryan Dahl or Isaac Schlueter?).

  3. I want to believe that JS future will be about a crystal clear language, cleaned up of its sometimes misleading confusions, a bare-metal sword to lead meta-programming to its definitve success.

    In the company where I work I’m the most experienced JavaScript developer (and lover) and once the person I’m teaching to achieves that minimum understanding about it, I can see real creativity and happiness in their eyes. JS can be the foundation for a really good dynamic programming world.

    Think about The Candor language. They took out too much IMHO, but it’s the direction we all should approve. Simplicity and expressiveness CAN be achieved without polluting the syntax.

  4. I’d like to see a breakdown of the various features on the table, examples for each, and a vote up/down toggle for the community. Basically, implement UserVoice.com over ES6.

  5. For me (and this may be unpopular):

    1. EASY TRANSITION. Ideally a pattern where I can serve (and reference) JS5 code for a new (and compliant) interpreter, and older JS for the installed base.

    2. DEPRECATE THE “BAD PARTS”. I think they are close to this. But like someone else said, “==” should die.

    3. BOOST PERFORMANCE. JS optimization has been insane lately, keep this curve going. Help Google and Firefox and Microsoft and everyone get another doubling or more of performance. Wring it. This will drive the adoption.

  6. drop function\n() syntax. Noone uses it itentionally, and if that happens all discussions about semicolons go away. One of the worst problems with the language, and hands down the largest source of contention.

    add optional byte code. It is insane we have to download js apps every time, and pay the parsing “start time”. This is the most important thing that could be done right now.

    provide better syntax for function(){}. In ES6 it is =>/->, that is awesome, please make it happen

    Io style object structure/inheritance. It is simple, just as powerful as js, and stays away from the insanity of adding java classes.

    bring arguments.caller/callee back. It is a language feature that is downright amazing to have, and it sucks that it got taken away

  7. Personally, part of the barrier with getting involved / invested in ES.next is the overhead associated with getting up to speed on what the proposed features are and their examples of use. I really like the idea of getting developer feedback to inform TC39′s decisions, but I feel like having to wade through Github issues isn’t any easier than dealing with reading a mailing list.

    Seems like it would be quicker for developers to gauge the potential utility of a proposed feature with a more visual layout. I know using issues on github is a more immediate approach… perhaps to gauge interest, but building a dedicated site with a better visual layout could have a lot of potential. have a grid of features.. each one having the following components:
    - name
    - proposed usage example (code)
    - examples of existing patterns / approaches that this would replace (code)
    - links to conflicting / related features
    - related type(s): String, Object, Number, etc.
    - vote module
    - comment module

    basically a sortable grid of fixed 200px x 300px scrollable boxes showing the name, associated type, #votes at the top. click title to expand to full screen. allow sort by votes, feature, name, etc. use github oauth as the only form of login identity

    Anyway, would be more work, but it would result in something that would be useful for committee-based language evolution in general… I’m sure it could grow to see usage beyond TC-39.

  8. Pingback: ES.next needs You! | F2E | Scoop.it

  9. nothing must be dropped, it must remain %100 backward compatible, or it will never have a chance

  10. Personal wish list (I’m sure several of these are available in ES5):
    1. Function overloading and/or default arguments
    2. Simple foreach syntax for arrays and objects
    3. Non-broken ‘typeof’ operator
    4. Improved regex engine (probably PCRE-compatible)
    5. Argument ‘splat’ (…) syntax
    6. C#-style coalesce operator
    7. Chained comparisons (e.g. 0 < x <= 100)

  11. Those who have been creating the future (aka web applications using js) for the last 15 years (while the rest worried about Flash I suppose) have succeeded at building the highly performant, stable, profitable applications which this group is saying are impossible unless the language changes.

    (If they are not claiming these changes to js are *necessary* to its success then they are saying exactly nothing of any use, at all)

    Also, one of them (and maybe more) are stuck in the past: http://projects.latimes.com/prop8/donation/8930/

    Just ignore them. Definitely do not waste your time trying to teach them anything.

      • Implied in this article, and well known outside of it, is the truth that politics, specifically, led to the ES->x->y->z forks and rifts. And so here we are.

        It is important to understand agendas, and the types of minds one is dealing with. For example, a bigot would believe there is only one right way to look at an issue. That sort of calcified thinking leads to, well, endless discussion.

        We are simply trusting the future to those who do not have the maturity to put aside their own agenda and create something within a timeline, respecting the actual (not theoretical) needs of customers (read: working (not conferencing) developers — the people who are *actually* responsible for the success of JS), like a company or individual with something to lose would. Indeed, the *entire premise of this article* makes my argument for me, and the Ashkenas quote, supra, gives it the necessary flair.

        The committee is a nonsense. This field is no longer served by the academics. We are smarter than them. We’ve solved the “problems”. We know better; we demand better. We are leaders who have revolutionized software development. The solution is in leadership, by brilliant workaround and paradigm-shattering innovation aimed at massive, global, advances. More jobs driven by greater penetration enabled by brilliant ideas executed beautifully using javascript distributed via browser and similar clients. Evolutionary and disruptive change driven by ambition, not chalky fictions written with the yellow blood of ego and undeserved privilege, in dusty drawing rooms.

        The question really is: are you going to continue to give respect to those who don’t deserve it and work with those of us who do real work and make real change happen, or simply pretend to do so by writing important articles like this one while simultaneously refusing to accept their actual implications? I believe in what you are saying, and here is your chance to lead. Stop hanging on and jump.

  12. I’ve always felt that the JavaScript specification process was in a horrible state and I never felt that it was worth dwelling on what was being proposed since the process seemed so closed. I understand that evolving a ubiquitous language in a way that moves the community forward with minimal disruption is a really hard problem, but not having a way to integrate public feedback is something that needed to be fixed and I am very pleased to learn about JSFixed. Thank you for taking the time to break down the issues and I look forward to sharing my feedback and encouraging feedback from JavaScript developers as well!

  13. Pingback: JSSpy » Es.next needs you!

  14. Hi Angus,

    My name is Tina, and I’m the community manager for Atomic Reach, a content curation platform that connects bloggers with brands looking for high-quality content. I am reaching out to you about an opportunity to be featured on http://bandofcoders.com.

    Atomic Reach is working with Band of Coders to invite a select group of bloggers to join the Band of Coders community. We’re looking for blogs on topics such as software development, web development, and lean development.

    What’s in it for you? The Band of Coders editorial team will only publish an excerpt and link to your posts so they’ll be sending new readers to your blog. It’s also a new way to interact with and reach new people, and boost your blog’s search engine ranking.

    Social Media Love for you too! Beyond having your content featured on the Band of Coder’s site, they will also be promoting your content via Facebook, Twitter, Google+, Pinterest and Tumblr!

    If you’re interested, please send me an email at tinajin @atomicreach.com with “Coders” in the subject line, and I’ll send you a link to activate your account. I’d also be happy to answer any questions.

    We look forward to you joining the Band of Coders community.

    Sincerely,
    Tina Jin
    Community Manager

  15. Setting out what should be in or out of ECMAScript without a clear vision of where it is headed is bound to result in an endless process of discussion and digging deeper and deeper into detail with no real gain.

    As I understand it, JavaScript was intended to be a small, simple and forgiving language. As a consequence, it’s probably the most widely used programming language in terms of people writing it and clients running it. That simplicity has to count for something, it’s created an amazingly popular language that is eminently suitable for web development.

    Every suggested change should be challenged to show how it better meets the vision of the language, how it moves it forward. The concept of “improvement” only has meaning if you can measure progress toward something.

    How do comments like “remove ==” help? As I see it, “==” is in perfect harmony with a loosely typed language, “===” is the exception, where strict typing is being imposed. How do classes make the language simpler or easier to use? Strict mode does nothing that good programing standards and thorough testing won’t fix, so what’s the point, as a debugging tool? How does var for context scope and let for block scope make life easier? What glaring problem does it fix? Or does it just introduce a concept from another language for the sake of it?

    Where are the changes that make the language simpler and easier to use? Please don’t destroy the very things that make JavaScript what it is.

  16. This is unrelated, but I can’t figure out how else to contact you, Angus: Is it just me or is the published Hemingway piece now missing some text between Bolano and Dickens? It seems to be missing the discussion about Bolano and the code for Dickens?

  17. Keep == as .js is a loose typed language
    Add prototypes to all objects (not just constructor functions) – this would make prototype inheritance much easier to set up
    Allow for multiple prototypes – object.prototypes could be an array, checking the items in order for child-value access
    Don’t make public values read-only or lock things down with strict typing – these just make workarounds more painful (and they will still be worked around) and code reuse more difficult
    Don’t use lexical binding for ‘this’ – it makes the functions fixed to objects and then we *can’t* reuse them properly

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s