Discuss
  • TC39 vs "the community"

TC39 vs "the community"

# David Bruant (11 years ago)

I'm not quite sure what this is all about, so forking in hope for clarifications. I'm sorry to send a message that will probably be read as noise by a lot of people, but I'm also tired of some of these pointless and unconstructive, if not destructive, fights among people (in here, on Twitter or elsewhere). I hope to have a conversation to start the end of the alleged unharmonious relationship between TC39 and JS developers.

Domenic, your email suggests a fairly strong dichotomy between "TC39" and "the community". As far as I'm concerned, to begin with, I don't see anything that is called "the community" in JavaScript. I join Axel's point of view. I see lots of communities with different backgrounds and interests, especially among the JS devs. I personnally don't feel associated with "the community" you describe. I encourage you to either speak only for yourself or provide a more specific description of whose point of view you're referring to (preferably without a definite article).

Le 19/06/2014 21:13, Domenic Denicola a écrit : Unfortunately, that's not the world we live in, and instead TC39 is designing a module system based on their own priorities. (Static checking of multi-export names, mutable bindings, etc.)

If I knew nothing about how ES standardization works, I'd be thinking "who the fuck are these TC39 people who decide features based on their own agenda against the interest/experience of the developers? Who do they think they are anyway?"

Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned?

I'm not quite sure I understand the dichotomy and the alleged TC39 priorities that would be that far off from what JS devs otherwse need, so please get it off your chest so we can all move on.

They've (wisely) decided to add affordances for the community's use cases, such as layering default exports on top of the multi-export model. As well as Dave's proposal in this thread to de-grossify usage of modules like "fs". By doing so, they increase their chances of the module system being "good enough" for the community, so that the path of least resistance will be to adopt it, despite it not being designed for them primarily. It's still an open question whether this will be enough to win over the community from their existing tools, but with Dave's suggestion I think it has a better-than-even chance.

The transitional era will be a particularly vulnerable time for TC39's module design, however: as long as people are using transpilers, there's an opportunity for a particularly well-crafted, documented, and supported transpiler to give alternate semantics grounded in the community's preferred model, and win over enough of an audience to bleed the life out of TC39's modules. We already see signs of community interest in such "ES6+" transpilers, as Angular illustrates. Even a transpiler that maintains a subset of ES6 syntax would work: if it supported only export default x, and then gave import { x } from "y" destructuring semantics instead of named-binding-import semantics, that would do the trick. Interesting times.

Whatever TC39 settles in and is eventually part of the standard will inevitably have tooling associated to it. Maybe not by "the community" (whoever that is), but I'm fairly certain TypeScript will adopt it for instance. I'm fairly sure IDEs will all eventually have syntactic or "intelligent" support of the official standard modules (which is less clear for whatever-transpiler-modules). Some people who aren't part of "the community" will write code in ES6 modules. Whatever they end up being, I'll probably be on that end pretty much for the same reason I choose to not write coffeescript (because AFAIC my own taste in code has less worth than other's ability to understand the code I write).

Whatever they end up looking and behaving, ES6 modules will happen with "the community" or without it.

# Domenic Denicola (11 years ago)

Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned?

TC39 has a lot of constituents who use their experience with other languages to develop the shape of features, instead of building on community-developed solutions to the problems the community sees as worth solving. In modules this is particularly apparent. If you want a qualifier for "community," try "ES5-module using community."

I wouldn't call these accusations, and in general I don't appreciate the uncharitable (perhaps even accusatory) tone of your message. Experience from other languages is valuable in evolving a language---of course! It would be silly to think otherwise. And often these working modes are not in conflict at all, allowing us to solve problems the community has run into by drawing upon our experience with other languages. But there is, especially in this case, a real conflict between the guidance from other languages and the guidance from "the ES5-module using community's" experience.

Whatever they end up looking and behaving, ES6 modules will happen with "the community" or without it.

They may "happen", in that engines may indeed implement the syntax once it settles, and browsers may indeed implement a loader once it's designed and specced. But whether they will be adopted by, say, Node.js (by supplying their own loader implementation), or the 80K packages on npm, or by the developers who are currently using AMD, or the developers who are currently just happy with <script> tags, is another question. Any claims otherwise are tendentious speculation, to borrow a phrase.

# John Barton (11 years ago)

On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola <domenic at domenicdenicola.com> wrote:

Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as developers are concerned?

TC39 has a lot of constituents who use their experience with other languages to develop the shape of features, instead of building on community-developed solutions to the problems the community sees as worth solving. In modules this is particularly apparent. If you want a qualifier for "community," try "ES5-module using community."

The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful. Thus ES6 cannot build on their solution. Their experience did however have a huge impact on the ES6 module design.

I wouldn't call these accusations, and in general I don't appreciate the uncharitable (perhaps even accusatory) tone of your message. Experience from other languages is valuable in evolving a language---of course! It would be silly to think otherwise. And often these working modes are not in conflict at all, allowing us to solve problems the community has run into by drawing upon our experience with other languages. But there is, especially in this case, a real conflict between the guidance from other languages and the guidance from "the ES5-module using community's" experience.

I started out with a similar opinion. Then I wrote some ES6 code.

What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers?

Whatever they end up looking and behaving, ES6 modules will happen with "the community" or without it.

They may "happen", in that engines may indeed implement the syntax once it settles, and browsers may indeed implement a loader once it's designed and specced. But whether they will be adopted by, say, Node.js (by supplying their own loader implementation), or the 80K packages on npm, or by the developers who are currently using AMD, or the developers who are currently just happy with <script> tags, is another question. Any claims otherwise are tendentious speculation, to borrow a phrase.

Implementors and proponents of legacy systems always fight for their point of view. It's natural and valuable input. But at this point we are speculating about tendencies of developers, not arguing about technical feasibility. Some node developers will never switch; some devs will always use script tags; some business apps will be written in COBOL. It's ok.

jjb

# Jeremy Martin (11 years ago)

I'll make this point as concisely as possible, since this conversation is quite given to noise:

While others may disagree, I feel the source of contention/disunity on modules is more fundamental than syntax or who's (not) listening to who. Specifically, ES6 modules are far less immune to platform nuances than other features, like, say, fat-arrows. That is, the merits of fat-arrows are basically the same regardless of what platform you're on... but that isn't (as) true of modules. While there's certainly overlap in what Node vs. Browser vs. PhoneGap (etc.) devs want out of a module loader, there are necessarily divergences as well.

I say this hesitantly and with great respect for TC39 and its members... but I have a hard time imagining a unified voice emerging on anything that's situated this close to individual, disparate platform needs.

# C. Scott Ananian (11 years ago)

Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers?

It would certainly be helpful if there was a migration doc written that carefully explained the "best practices" way to allow your node package/script-tag library/amd module/commonjs module to support ES6 modules as well, in the spirit of the one-liner "amd or node.js or..." prefixes that are commonly used.

# Jasper St. Pierre (11 years ago)

On Fri, Jun 20, 2014 at 11:39 AM, John Barton <johnjbarton at google.com> wrote:

I started out with a similar opinion. Then I wrote some ES6 code.

What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers?

As a developer currently writing ES5 code, what's the best way to try out writing ES6 code that uses modules? Every time I try and look at bootstrapping ES6 with modules, I can't figure it out. A "Get Started Trying It Out" guide would go a long way, I feel.

# Axel Rauschmayer (11 years ago)

A minimal, pragmatic and well integrated solution is the ES6 Module Transpiler: square/es6-module-transpiler

Additionally, Addy Osmani maintains a comprehensive list of tools: addyosmani/es6-tools

Axel

# Andrea Giammarchi (11 years ago)

I am trying to stay outside this discussion as much as I can but there is a specific sentence that I'd like to understand:

On Fri, Jun 20, 2014 at 8:39 AM, John Barton <johnjbarton at google.com> wrote:

The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful.

how 80K modules mentioned by Domenic, the concrete adoption of CommonJS or the usage of Browserify for most of the web, can be defined exactly a failure?

I am not sure ES6 modules have been overlooked since the beginning but I believe that the rest of "the real-world" in production out there will keep doing just fine with current inline or AMD based require("module") logic.

A new ES6 syntax, unfortunately unable to be brought over a UML (Unified Module Loader) as it has done before, will also take much longer to became a de-facto standard as require has become these days.

Here probably the "community" sentiment Domenic mentioned, everyone I know somehow applauded fat arrow, nobody I know reacted differently from "WTF?!?" about ES6 modules.

That being said, as complex and powerful APIs can be wrapped and brought to simpler libraries, maybe we actually will keep using require but with import ES6 from "module" behind the scene so everyone might win?

Best

# John Barton (11 years ago)

On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

I am trying to stay outside this discussion as much as I can but there is a specific sentence that I'd like to understand:

On Fri, Jun 20, 2014 at 8:39 AM, John Barton <johnjbarton at google.com> wrote:

The ES5-module using community tried, valiantly, to reach a compromise module solution. They were not successful.

how 80K modules mentioned by Domenic, the concrete adoption of CommonJS or the usage of Browserify for most of the web, can be defined exactly a failure?

Individually both node modules and amd modules are a huge success. I was only referring to the unsuccessful effort at convergence.

I am not sure ES6 modules have been overlooked since the beginning but I believe that the rest of "the real-world" in production out there will keep doing just fine with current inline or AMD based require("module") logic.

A new ES6 syntax, unfortunately unable to be brought over a UML (Unified Module Loader) as it has done before, will also take much longer to became a de-facto standard as require has become these days.

Here probably the "community" sentiment Domenic mentioned, everyone I know somehow applauded fat arrow, nobody I know reacted differently from "WTF?!?" about ES6 modules.

That being said, as complex and powerful APIs can be wrapped and brought to simpler libraries, maybe we actually will keep using require but with import ES6 from "module" behind the scene so everyone might win?

To the best of my knowledge, nothing in ES6 prevents you from continuing to use require(). If you think require() is the perfect module system, then use it. I think the ES6 module system is better and I plan to use it. If we ever stop talking about it and ship it.

jjb

# Andrea Giammarchi (11 years ago)

I think tools made require the winning choice but about having both I am not sure I've read about dynamic folder such:

import _ from loDashFolder

if that's a thing then

var require = function (fromWhere) {
  return  import _ from loDashFolder
};

or whatever will be

# Andrea Giammarchi (11 years ago)

typo ...

var require = function (fromWhere) {
  return  import * from fromWhere
};

or something similar

# Juan Ignacio Dopazo (11 years ago)

On Friday, June 20, 2014 7:15 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

typo ...

var require = function (fromWhere) {
  return  import * from fromWhere
};

That's not valid ES6. It's specified that:

  • Import and export statements can only be top level statements
  • The module name must be a string literal.
  • Import * is not specified.

ES6 modules are designed to be static. So no, you can't use import statements under the hood in require(). But you can set up things so that you can use import to import CommonJS modules.

Juan

# Garrett Smith (11 years ago)

On 6/20/14, David Bruant <bruant.d at gmail.com> wrote:

Hi,

I'm not quite sure what this is all about, so forking in hope for clarifications. I'm sorry to send a message that will probably be read as noise by a lot of people, but I'm also tired of some of these pointless and unconstructive, if not destructive, fights among people (in here, on Twitter or elsewhere). I hope to have a conversation to start the end of the alleged unharmonious relationship between TC39 and JS developers.

Domenic, your email suggests a fairly strong dichotomy between "TC39" and "the community". As far as I'm concerned, to begin with, I don't see anything that is called "the community" in JavaScript.

Words tend to get coopted and their meanings stretched to suit agendas.

<aside>

If you're easily offended, or if you wish not to read opinionated information, stop reading now. Also, I add nothing whatsoever to the technical matter of this discussion. </aside>

Developer relations is public relations for developers, and public relations is propaganda. This is because Edward Bernays used a propaganda technique to rename propaganda to "Public Relations".It stuck.

The renaming of term "propaganda" was necessary because it had lost any acceptibile legitimacy that it had maintained prior its use in WWII, when Joseph Goebbels' used Edward Bernays' propaganda.

Similarly, popular opinion for the bellamy salute, changed around this time, which is why schools now use the hand-on-heart techqnique to instill the values. But that is getting off topic on an already off topic thread.

The terms, "community", "developer relations", and "technical evangelism", are all used to describe roles for corporate propaganda.

"The community," where propaganda is disseminated, exists more recently as corporate-sponsored technical events and, starting a few years back, on w3c mailing lists. Large numbers of individuals are organized (By Google, Microsoft, etc) to accept what is fed to them through these corporate vehicles, and willingly do so for three reasons (1) the great potential for career advancement via social climbing, (2) the large amount of money in corporate community, and (3) a shortage of corporate-free spaces.

The term "community" has long been coopted outside the world of tech, generally to leverage herd mentality, so as to control, categorize, marginalize, and otherwise take advantage of subsets the public.

And so now too in software, where companies hire representatives to promote agendas, "the community" represents something of value to them: influence.

Developer relations and community managers are generally presentable, attractive, and serve their company's agenda. Programming skill is not so important. Appearance and presentation are.

Developer relations is generally very well-compensated for very light work hours (e.g. $150k+ 4d/wk, 6h/d). Don't get me wrong, I'm all for working fewer hours! -- my point is that "community," and those who manage to shape it, play a significant role in the corporate agenda to the expense of anything resembling consensus-based voluntaryist community.

# joe (11 years ago)

And here I thought you were making an educated argument with your explanation of the history of propaganda and public relations. When I first read "corporate propaganda," I thought you mean the propaganda of JS developers, not commercial corporations.

Frankly, I find the idea that commercial interests trump corporate identity hard to fathom. If that were true, Java would be a very different language today, and JavaScript would have long fallen into disuse. "The community," very much exists; it's not a figment of some PR type's imagination. Anyone claiming there isn't a sense of corporate identity among JS developers is fooling themselves.

I'm on the side of TC39, by the way. I don't believe in democracy in software. That's why we have standards organizations.

Joe

# Brendan Eich (11 years ago)

+1

But Garrett's post was helpful in its own way. @horse_esdiscuss agrees!

# Garrett Smith (11 years ago)

On 6/23/14, joe <joeedh at gmail.com> wrote:

And here I thought you were making an educated argument with your explanation of the history of propaganda and public relations. When I first read "corporate propaganda," I thought you mean the propaganda of JS developers, not commercial corporations.

Frankly, I find the idea that commercial interests trump corporate identity hard to fathom.

So you agree, then.

# Garrett Smith (11 years ago)

Nice.

I wonder what Horse would think of Vermin Supreme's pony identification program.

But in all seriousness, Google, MSFT, are all pushing for IoT or "wearables" by putting on events featuring that, creating a buzz, and making press on the event.

# Jasper St. Pierre (11 years ago)

On Thu, Jun 26, 2014 at 2:41 AM, Garrett Smith <dhtmlkitchen at gmail.com>

wrote:

Nice.

I wonder what Horse would think of Vermin Supreme's pony identification program.

But in all seriousness, Google, MSFT, are all pushing for IoT or "wearables" by putting on events featuring that, creating a buzz, and making press on the event.

What are you talking about? Google and MSFT are giant companies with hundreds of divisions and hundreds thousands of employees. Yes, some of those are dedicated to product research like wearables or self-driving cars. Others on operating system or software development. I have no idea why you think the fact that a large company has lots of R&D arms means anything for ES6 or TC39.