Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
my name is Forrest Norville and I'm a developer at MPM incorporated and I'm here to talk to you about the next version or two of JavaScript I'm truly sorry that I'm what stands between you and lunch but this is a talk I've wanted to give
for a long time and I hope you find it valuable I also compared you all the cows at least once in here so that's a thing so equi script the standard that defines the next version of the JavaScript language is probably going to be ratified towards the end
of this year it describes the most sweeping set of changes to the language and at least a decade and it's the endpoint of a lot of work and at least one giant fiasco as a node developer who's been writing fairly involved javascript full-time for the
last three years and been using javascript is a full-stack developer for at least a decade before that I have a lot of friends who are also node developers as es6 gets closer to standardization a lot of friends are skeptical or concerned about what they see
is needless complication and wrongheaded design decisions I can see why you might feel that wave there's a lot that's going to change as the new features roll out and it's not clear how all this new stuff is going to combine but every risk can
also be viewed as an opportunity I feel comfortable saying that everything that's in es6 as of now has a good reason to be there in this talk I'm going to spend a little time talking about the trauma which shaped the development process of es6 and
then talk about what we can do as a community to figure out how to use es6 effectively ultimately the point of this talk is this it's up to us as developers to make es6 is a success and we can do that if we work together and spread what we learn as widely
and quickly as we can so es6 wasn't developed in a vacuum there are a lot of parties involved and I think it's helpful to map out who everybody is and how they relate or don't to each other I grouped the contributors into three categories standards
committees stakeholders or implementers and the developer community first the committee's in particular and in particular tc39 it's impossible to discuss the development of JavaScript without mentioning tc39 or to give it its full name ACMA International
Technical Committee 39 tc39 is the steward responsible for es 262 the Ekman scripts standard the two most important figures on tc39 are its chairman brendan eich who really doesn't need any further description and the editor of es 262 alan wharfs brock
without them and the other members of tc39 the web platform as we know it would not exist the membership of tc39 is largely self selecting a point as Rick Waldron forcefully reminded me the other night worth keeping in mind when you look at its makeup the
various member companies of acumen nominate delegates to join tc39 and subsets of the delegates attend the individual face-to-face meetings where the bulk of the standardization work gets done trying to stakeholders a language specification on its own isn't
very interesting unless you're some kind of programming language nerd you need implementations to actually do anything and that's where stakeholders into the picture you can also think of these teams as implementers but I call them stakeholders because
I want to be clear that the owners of the specs and the owners of the implementations are interdependent neither can get a new version of the language standardized without buy-in from the others the important stakeholders have names that should be familiar
to you Mozilla Google Microsoft Apple Adobe but there's an interesting trend which is the increasing importance of library developers in the standardization process jQuery ember angular and the AMD in required GS communities have all contributed substantially
to es6 and several of the most active members of tc39 come from that world this is a new and very important development because it brings the standard closer to us as developers I think I forgot something oh yeah you'll note that I didn't mention node
and that's because with certain significant exceptions node just uses an implementation of JavaScript it doesn't implement JavaScript itself despite what a lot of node users think it has very little control over its own language runtime this is something
that only seems weirder the longer you use node but strictly restricting itself to being a consumer of v8 has been key to its rapid development all of us work and wrangling is pointless without us the JavaScript community all tc39 online can do is let us loose
with the standard and see what we do with it you can think of us as a herd of cows let loose and high pasture over time we'll figure out the best ways to get around and the easiest way to do things and end up laying down trails if tc39 is doing its job
it will be watching what paths we've made and come in behind us and tend and pave them for our convenience and safety this paints a picture of a tiny little ecosystem with its own feedback loops and checks and balances and with some allowances made for
the inescapable politics and wrangling that comes from any activity involving a lot of people with conflicting goals that's pretty much what's actually happening with that out of the way let's talk about what happened six years ago the last time
a lot of JavaScript was going through a lot of changes what was the es for fiasco put another way what made some of you out there a little skeptical about JavaScript odds of successfully being updated well standards bodies are strange beasts with minds of
their own but they do have principles and goals stated or unstated and sometimes those goals fall into conflict Edwyn script for was a very ambitious stakeholder led project spread out over many years the stakeholders had many goals among them being to add
proper classes to Java scripts prototype object system to unify JavaScript with Flash's action strip and to generally take what had more or less accidentally turned out to be a cornerstone of the web and put it on a more solid footing at the same time
tc39 was working on Ekman script 3.1 an incremental refinement of ekam script 3 the problem that most of you have probably encountered with branchy development is that multiple groups working on multiple versions of a single thing at the same time end up generating
a lot of overhead and Comm when it comes time to figure out how to reconcile everything into a final end product ultimately what sunk es for along with the extremely ambitious nature of the changes was the fact that the team working on es 4 had essentially
created an entirely new thing and called the JavaScript they completely lost the plot and the blame storming was fast and furious for a very long time it's hard to overstate how traumatic this was years of spec work stakeholder discussions and implementation
[ ... ]
Nota: se han omitido las otras 3.441 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.