Well my background in programming is that when I started studying informatics, which is kind of Computer Science plus Software Engineering, I first started with Scheme, did a lot of Scheme, later did a lot of Haskell and some other programming languages and after my studies I mostly programmed Java and it turns out that these two languages Java and Scheme prepared me quite well for JavaScript later on.
Brian: Right, so now your focuses are almost entirely on JavaScript, and you have a particular fascination with the language itself, I know a lot of other people that I’ve talked with them are more interested in some of the things like the Frameworks and other aspects of it but not the intracacies of the actual language, that’s kind of your focus.
It’s kind of my thing that’s true. I always really liked language design and I looked at various languages while doing my studies and after, I always found that really interesting. My diploma thesis I did was very language design related, so that was always something that interested me. And because I had seen bits and pieces of JavaScript in other languages, it was interesting for me to kind of explore those in the language and in detail. Even while I did my PhD Thesis, I worked with people who were very much into semantics and formal methods, so that kind of prepared me for this a little bit more formal stuff in the specification and help me with kind of understanding that. Because the ECMAScript specification is really a blessing, because whenever there is a kind of a question about the language – how does it work? – you always get a definitive answer, so you don’t have to scour the web – what’s the opinion? And there are a lot of different implementations, so not having a spec would be kind of impossible, because you want these different implementations to be compatible. But the spec is really awesome to have as kind of the definitive source whenever you have a question about JavaScript and there are quite a few of those.
Brian's full question: I didn’t know, I thought because I’ve always heard, I think everybody at this conference would agree that JavaScript is the perfect language, I think there is never anybody complaining about JavaScript ever. You have a lot of experience with the language, what would be, there is always people complaining that JavaScript isn’t enterprise ready or JavaScript is not an ideal language for developing anything but what are your thoughts I’m kind of the state of JavaScript in?
There are several aspects to it. To me, it’s always that if you are looking for a perfection, JavaScript certainly isn’t your language. So when it comes to sheer beauty of a language, especially syntax, then Smalltalk is incredible, Common Lisp is incredible. Common Lisp has a lot of just incredible ideas and a lot of these ideas I think yet have to be rediscovered by the mainstream, and same thing for Smalltalk. And then there are other languages out there, well Haskell, I really like Prolog, there is a lot of beauty out there and JavaScript certainly isn’t the most beautiful language in the world but it’s pragmatically at the moment I think, a very good choice. And what makes the language interesting is that, on one hand it isn’t too bad so you can be productive with it, on the other hand you have the whole web platform behind it, so whenever you are thinking of implementing a graphical user interface you can use HTML, CSS and soon web components. And then you have a lot of libraries, Node.js did a lot to make the language a lot more interesting as well.
So that’s just a lot of JavaScript code out there that you can use too, so if you need a good parser you have Esprima and other parsers, so there is just a lot of code out there. And second the future of JavaScript looks really nice, so the upcoming version of JavaScript, ECMAScript 6 is really nice, it has a lot of features that those people who want JavaScript to be enterprise-ready really want to have badly. And third what I really like is at the moment there is a lot of experimentation going on, so you have asm.js which is very nice which brings near native or gets JavaScript very close to native speeds, then you have Parallel.js which more less is like very easy parallelization without any of the problems of say locking and stuff. Then you have Sweet.js which brings Macros to JavaScript, you have SIMD which brings single instruction, multiple data to JavaScript and especially to asm.js, so there is a lot of experimentation going on, a lot of companies chipping in and helping out, so simply from a language design stand point JavaScript is very exciting at the moment.
Brian's full question: So you mentioned a little bit about some of the upcoming versions of JavaScript, the ECMAScript specification, ECMAScript 6 and even there is already talk a little bit about EcmaScript 7, kind of prematurely, but you are speaking on ECMAScript 6 here and you mentioned that some of those things are some of the features that people have been calling for for a long time. What are some of the ones your most excited about and that you think people should be most excited about?
Two features that I’m most excited about, actually those two features I’m most excited about when it comes to ECMAScript 6 are actually kind of like the two most boring features and those are Classes and Modules, and if you’ve been programming JavaScript for a long time you are going to say: “We already have those” so there are a lot of libraries that help you with inheritance in kind of emulate all kind of class systems, inheritance systems and even inheritance mechanisms. But the problem is there is too many of those out there, so code that you write usually isn’t portable, so you write it specifically for one framework or for one inheritance library and it just isn’t portable, and tools have a very hard time kind of figuring out what the class hierarchy is and whenever they want to help with some kind of static analysis when you are using like an IDE and you type dot and you want to find out what methods can be used for that object or on that object. It’s very, very difficult to do unless you really help the IDE’s along quite a lot.
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.
Brian: I think those are good examples. I remember even myself, when I moved away from JavaScript for a while and then I came back like 4 years ago to doing JavaScript and I was looking at, one the first things I was looking at was how to do a Class in JavaScript, and I remember I found hundreds of articles and everyone implemented it slightly differently, and there was no definitive answer to what works better and why things were done. So I would say even from an approachability standpoint for the language I think that……
For newcomers that will be great, Classes will be great for newcomers.
Yes, so the thing is there actually is a committee that evolves the language and that committee is called TC39 and kind of the members of TC39, I hope I’m getting this right but it’s approximately correct I think. The cool thing about JavaScript is that a lot of companies are collaborating that are normally competitors, so you have a very broad community that supports JavaScript and you have several open implementations that you can choose from, should you ever want to embed JavaScript for example. So this openness is great, so you have all the major browser vendors, you have Mozilla, you have Google, you have Microsoft, you have Adobe, Opera and several other companies that are part of TC39 and they send delegates to TC39 meetings and these delegates decide on how to evolve the language.
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.
5. [...] Do you have any opinions on that kind of thing?
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!