Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
And all those incompatibilities will go away in ECMAScript 6 which is nice and then code will become more portable and tools will have a simpler and easier time statically analyzing source code. And that’s what’s great about Classes, so with Classes I’m kind of 96% happy, I absolutely like the syntax, I’m really, really grateful that they made it into ECMAScript 6. I would had love slightly different semantics under the hood but the argument for translating Classes to constructors was backwards compatibility and that is a very valid reason, so I can accept that reason begrudgingly, and I do like Classes so I’m in favor of Classes. And for modules it’s kind of the same reason, at the moment you have two competing standards when it comes to modules and in both work really well, so you have basically CommonJS or actually its mainly Node.js and npm, and on the other hand you have AMD, so you have two competing cams and everybody has strong opinions either way, so whenever you write a library you have to at least support two module systems possibly more, which is a pain, and which again makes code a lot less portable than it should be. And hopefully and probably ECMAScript 6 modules will be adopted by all of the community and will kind of end that and will again make code more portable.
For newcomers that will be great, Classes will be great for newcomers.
4. Let’s talk a little bit about the process of how they design the language, so there is a lot of perception that it’s more like it’s a “design by committee” kind of thing, but I know we were talking about his a little bit earlier, it’s not really that way in your opinion?
So until now you do have design by committee, but when it comes to a specific feature, what TC39 does is they appoint so called champions and that’s one person maybe two people and they work together on the design of a feature and afterwards will be an implementation and feedback from the implementation and the specification of the feature will be refined and in the end kind of TC39 has to say: “Will it get included?” and obviously before that it already tells that the champions do we want the features or not and only if the features wanted by TC39 the champions go to work, but TC39 has the final say and occasionally gives feedback to the champions as well, but the actual design of the feature is done by one to two persons which is great and I think it was Fred Brooks who said that for good design I think one person is optimal, maybe two people but you have to have kind of this single say benevolent dictator, this single person with a clear taste, because if you have a, if you do design by democracy then you’ve kind of lose this kind of clear taste and this kind of consistency inside a feature, which is why I think that having champions is a great choice.
Brian's full question: And along those lines, what do you think about there is been somewhat of an effort to create well the kind of give them the term “prollyfill”, the idea that I’m going to create a library that kind of marks up a feature I’d like to see and hopefully it will get implemented the way that I’ve already build it, kind of like say Google did a little bit like with Polymer and other people …….so like where they’ve taking a loose spec but finish out the implementation hoping to actually influence the way it get implemented, do you have any opinions on that kind of thing?
I think the name that have given it’s kind of newish approach to do that, because traditionally I think it was more like spec the feature, implement it and then live with it, and this new approach has been call by a group of people “extend the web forward”, so are as opposed to kind of writing the standard first and kind of crossing the fingers to get it right. Now they are actually trying to implement it first as you said, via libraries, and it’s more about finding out primitives that gives people something to build on as suppose to starting with the high level stuff right away, so if you try out things in the wild for a little longer, you are going to get feedback, you will find out what works and what doesn’t, and only if it did work in the wild, only after that you standardize, and I think that’s a really smart approach and the whole web will profit from that and the credibility of standards obviously increases as well and with the web components you have at least two prollyfills at the moment, you have Mozilla with X-Tags and you have Goggle with Polymer. So that you already trying to be interoperable, communicating with each other, so you have a lot of input and there is a lot of people already at the moment implementing and building web components. So when we finally do have a standard it will be just more thought out and just work better.
Both the next versions of Ember and Angular JS will be based on web components, I don’t know how exactly they do it, do like when they wanted to be backwards compatible, they may rely on the web components polyfill from Polymer, at least that’s what I’m guessing that Angular JS in doing, I’m not exactly sure how Ember does the proollyfillingmaybe they have their own prollyfill. But this is awesome news, so and web components are another example of increasing the portability of web platform code, because at the moment it can be, well you have all these frameworks, arguably too many frameworks out there, you pick one because it’s nice, because it suits your taste and then you look on the web and you want the date picker or you want any kind of nice widget, and then it turns out that the very nice widget that you find only works for JQueryUI and you happen to not be using JQueryUI and then you can’t use it in other frameworks or with your framework of choice. Especially if you have these more web centric frameworks such as Angular and Ember, if you’re just a programmer, you almost always need a web designer to kind of make things look nice, and as a programmer I want just to rich widget said that it can’t just plug together and create something that doesn’t look awful relatively quickly, and web components will give us that, so it looks like that will be broadly adopted, and Ember and Angular will be based on them so it will be really great for the web platform, because you will have these universal widgets and they will be useful and usable in I’m guessing all frameworks eventually, and that creates like this huge shared ecosystem for widgets. And as I said it’s going to be great for the platform.
Brian: Yes, I think it’s going to be interesting, I’m curious to see how that turns out, you can see people already starting to develop the obviously but I’m thinking even in terms of companies who create commercial widgets and things like that seems like there is a whole marketplace that it’s kind of evolve there potentially for commercial widgets and stuff.
Yes, right now it seems like do you often targeting Angular thanks to web components they will be able to target web components and you’ll have broader availability of these components and maybe I don’t know how much sense that will make but even Bootstrap will be nice as web component, some of the widgets that Bootstrap has.
Brian: Well those are all the questions I had today, hopefully you’ve I didn’t mention but you came all the way from Munich to come here to New York, so hopefully you will enjoy New York a little bit and enjoy QCon and thanks for coming!
I always love New York. Thanks for having me!