Re: TC39 vs the community
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. On 6/23/14, Brendan Eich bren...@mozilla.org wrote: +1 But Garrett's post was helpful in its own way. @horse_esdiscuss agrees! /be joe 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. 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 -- Garrett @xkit ChordCycles.com garretts.github.io ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Thu, Jun 26, 2014 at 2:41 AM, Garrett Smith dhtmlkitc...@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 RD arms means anything for ES6 or TC39. -- Garrett @xkit ChordCycles.com garretts.github.io ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jasper ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On 6/23/14, joe joe...@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 @xkit ChordCycles.com garretts.github.io ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
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 On Sun, Jun 22, 2014 at 9:41 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 6/20/14, David Bruant bruan...@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. -- Garrett @xkit ChordCycles.com garretts.github.io ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
+1 But Garrett's post was helpful in its own way. @horse_esdiscuss agrees! /be joe 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. 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On 6/20/14, David Bruant bruan...@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. -- Garrett @xkit ChordCycles.com garretts.github.io ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
TC39 vs the community
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. 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.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: TC39 vs the community
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola dome...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
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. On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com wrote: On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola dome...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Jun 20, 2014 11:39 AM, John Barton johnjbar...@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? 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. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@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. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jasper ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
A minimal, pragmatic and well integrated solution is the ES6 Module Transpiler: https://github.com/square/es6-module-transpiler Additionally, Addy Osmani maintains a comprehensive list of tools: https://github.com/addyosmani/es6-tools Axel On Jun 20, 2014, at 19:54 , Jasper St. Pierre jstpie...@mecheye.net wrote: On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@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. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
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 johnjbar...@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 Regards ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi andrea.giammar...@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 johnjbar...@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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
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
Best Regards
On Fri, Jun 20, 2014 at 2:29 PM, John Barton johnjbar...@google.com wrote:
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi
andrea.giammar...@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 johnjbar...@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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
typo ...
```
var require = function (fromWhere) {
return import * from fromWhere
};
```
or something similar
On Fri, Jun 20, 2014 at 3:14 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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
Best Regards
On Fri, Jun 20, 2014 at 2:29 PM, John Barton johnjbar...@google.com
wrote:
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi
andrea.giammar...@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 johnjbar...@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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: TC39 vs the community
On Friday, June 20, 2014 7:15 PM, Andrea Giammarchi
andrea.giammar...@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___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
