123

123 JSJ Traceur with Erik Arvidsson


Panel

Discussion

01:52 – Erik Introduction

03:49 -Background of Traceur

05:10 – Implementing Features 06:31 – Other Languages

08:37 – ES6 Development 09:14 – Promises

09:45 – Object.observe 10:24 – Traceur & ES6/7 12:19 – Production

14:23 – Features and Functions

20:34 – Libraries

22:52 – Run-Time Library Functions

26:29 – Future of es6 Features

30:26 – Development Work Flows

34:05 – Future of Traceur (Support)

  • Polyfills

Picks

Next Week

The Origin of Javascript with Brenden Eich

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

[This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. They also have a terrific backlog of courses you can watch including JavaScript the Good Parts, Build Web Applications with Node.js, AngularJS In-Depth, and Advanced JavaScript. You can go check them out at FrontEndMasters.com.]

[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous delivery, check them out at Codeship.io, continuous delivery made simple.]

[This episode is sponsored by WatchMeCode. Have you been looking for regular high-quality video screencasts on building JavaScript done by someone who really understands JavaScript? Derick Bailey’s videos cover many of the topics we talk about on JavaScript Jabber and are up on the latest tools and tricks you need to write great JavaScript. He also covers language fundamentals, so there’s plenty for everybody. Looking over the catalogue, I got really excited and I can’t wait to watch them all. Go check them out at JavaScriptJabber.com/WatchMeCode.]

[This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]

JOE:  Hello everybody and welcome to episode number 123 of JavaScript Jabber, which is Traceur with Erik Arvidsson. My name is Joe Eames. I’m your host. And today on our panel we have Jamison Dance.

JAMISON:  Hello, friends.

JOE:  AJ O’Neal.

AJ:  Yo, yo, yo, coming at you briefly from Orem, Utah.

JOE:  And our special guest today as I mentioned is Erik Arvidsson. We’re going to be talking about Traceur.

ERIK:  Hello everyone.

JOE:  So Erik, would you like to take a minute and introduce yourself?

ERIK:  Sure. So, my name is Erik Arvidsson. I work at Google, [specifically] on the Chrome team doing JavaScript related stuff. I’m a member of TC39, which is ECMA technical committee number 39 which is responsible for the next version of JavaScript standard. On the Chrome team, I work on web-related stuff like standard stuff, some Polymer stuff. I saw you had a JS Jabber a couple of weeks ago about Polymer, which was pretty exciting. I do some V8 stuff on [inaudible], too. Yeah.

JOE:  Awesome.

JAMISON:  Are those two teams pretty separate from each other, the V8 team and the other Chrome teams?

ERIK:  Yeah. So, it’s by design. The V8 team is independent and we have a strict API boundary between Chrome and V8.

JAMISON:  Cool. I never knew that. Interesting fact.

JOE:  Yeah, that is interesting.

ERIK:  Oh, yeah. So, V8’s main customer is clearly Chrome. And when V8 changes their API, there’s always someone willing to update Chrome. And sometimes, other users like Node.js gets a short stick there because no one keeps them in the loop.

JAMISON:  [Laughs] [I would assume] they’re okay. Well, that’s probably why their version of V8 is so old.

ERIK:  So, Traceur is my 20% project, which means that it’s something I do on my spare time. 20% means that I can take 20% of my time at work to work on something that’s fun and hopefully related to my main work.

JOE:  So, is it really only 20% of your time or does it end up being more?

ERIK:  Yeah, it tends to be more because it’s so much fun. So, I tend to on my work hours, I try to at least do code reviews. I tend to not do any large coding work at the office. I try to do that at home.

JAMISON:  So, can you explain what Traceur is, just for people who maybe haven’t heard of it?

ERIK:  Yeah. So, let’s do the background of Traceur. So Traceur, it’s a compiler that compiles JavaScript next version to JavaScript current version. And right now, we’re mostly focusing on ES6, ECMAScript edition 6, which is more or less done. The spec [inaudible] is done. And so, there’s a bunch of features in ES6 that ES5 does not support of course, so we take the ES6 code and compile it to ES5. So, it will run in all your modern browsers. Right now, it does not support ES3 so you need IE9 or above I believe, maybe an IE10.

And yeah, so Traceur started in 2011 as more of a proof of concept or a tool to help us design new standards. It was done by a guy called Peter Hallam and it was introduced at JSConf 2011. Him and Alex Russell were presenting it back then. So, it started off as a research project more or less where the goal was not really usability or efficiency. But over time, we tried to transform it or make it more useful for real code so you can actually use it.

JAMISON:  So, I know that a lot of the web’s platform comes from implementing things and then it gets standardized [inaudible]. Was Traceur ever prescriptive for ES6 or is it only descriptive? Did you only implement things that were in the spec or did you try out things that eventually made it into the spec?

ERIK:  Oh yeah, both I would say. Early on, we prototyped class syntax, a lot of different class syntaxes. We showed them to the committee, the standards committee, and gave feedback on the different proposals. And then there are things like destructuring, which we just basically implemented what was in the spec and what was in Firefox early on.

And another important feature that we implemented early on was async functions, which allows you to untangle your callback chains using promises and a dedicated syntax so your code looks very imperative line by line. And this was based on C#’s async functions, which now, well, I can’t believe it, so async functions is something that we are going to add in ES7. For ES6, we could not convince the committee that async functions were important enough. But we did get generators in there. And generators have more or less the same structure as an async function and it’s pretty easy to convert one to the other.

JOE:  That’s really interesting that it was based off of C#. Are there other languages that implement the same feature that could have based it off of, and why C#’s async functions?

ERIK:  I’m sure there are other languages that do it similarly. One of the reasons, the guy who started Traceur, Peter Hallam, came from C# and Microsoft. He wrote big parts of that compiler. So, it came natural for him to do the work and propose that in the committee.

JOE:  Awesome. Was that based on generators or did what generators allow you to do, was that based on async functions? Or were they in parallel and just happened to overlap in functionality?

ERIK:  So, the way that we envisioned it a couple of years ago was that we would have async functions in the spec. The committee felt that it was a step too far, too much magic. So, instead there were a lot of people pushing for generators with a library on top of it. The champion of generators is Dave Herman of Mozilla. He has a library called Task.js which allows you to take a generator function with yield, yield expressions in it, and wrap it in this Task.js library. And then it behaves more or less like an async function. So, with ES6 we got generators and promises. So, once those were in the spec and everyone was happy with them and everyone understood them, it was a baby step to get async functions approved for ES7.

JOE:  But people on the committee thought the async functions were too ambitious. So, is there anybody on the committee you want to call out and call them an idiot over the air?

ERIK:  Nope. I’m not going to do that.

[Laughter]

ERIK:  No, I think it was the right approach. It would have been a lot of extra work for ES6 and ES6 is already a huge spec. And it’s good to cut things down sometimes. Too bad, because I really like async functions. I think async functions are much more important than generators. But once we had generators and promises in there, it was a piece of cake to get the rest approved.

JOE:  Now, you said that the ES6 spec is more or less fixed. What does that mean more or less?

ERIK:  So, ES6 is in a feature freeze. So, it’s just bug fixes at this point. Initially, we were supposed to have it stamped and approved by the end of this year, which means that ECMA would say it’s done. We decided that we needed another six months to fix more bugs, but it doesn’t mean that we’re adding any new features. So, all the features you see in the draft today, they will be in the spec.

JOE:  So, when is it going to be totally finalized?

ERIK:  Middle of next year, June next year.

AJ:  So, I’ve got a question about promises. Did it get standardized as promises A+ or not?

ERIK:  Yes. If I understand the details correctly, it’s a superset. And promise, Domenic Denicola was the champion of that. And he designed and worked heavily with…

JAMISON:  What a surprise, Domenic championing promises. [Chuckles]

ERIK:  Yeah, Domenic Denicola, oh yeah. I guess you know him.

JAMISON:  [Laughs]

ERIK:  Yeah, so he did a tremendous job working on promises and finally getting that into the spec.

JOE:  So, my big question is why the heck did Object.observe not make it into ES6?

ERIK:  I’m not really sure. I feel like it was brought up a bit too late in the process. And at the same time, we are redesigning the whole process. So, once ES6 is done, we’re going to try to do a yearly spec release or at least maybe every 18 months or so. And at that point, it won’t be driven by features. It will be driven by how complete the features are. So, Object.observe is complete from a spec standpoint. So, once the ES7 train comes, it would be included there.

JOE:  So, I want to bring this back to Traceur but I think that a little bit of groundwork about ES6 and ES7 is germane to this discussion. And I had understood that when it comes to ES7, it’s no longer going to be waiting for 20 features, wrapping them all up, and calling it ES7 right?

ERIK:  Correct. It will more date-driven. So, once December 2015 comes, we’ll look at features and see which ones are done. And then we’ll just include those.

JOE:  So, how will that affect Traceur.

ERIK:  I don’t think it will. It does affect the feature requests list, pretty much. So, it’s easier to know what to implement and what to enable by default. I see Traceur being even more important in the future because browsers are finally starting to ship ES6 and ES7 features. And people still want to support some older browsers. So, with ES7 and ES6, it will be more important. I don’t really think that ES7 is going to change the way that Traceur is going to go from here.

JOE:  So, one of the things I think is interesting about Traceur is the fact that it doesn’t implement everything that’s part of what’s ES6. Are there more ES6 features that Traceur is going to be implementing or is it done with what it’s going to implement of ES6?

ERIK:  Right now, there are some features in ES6 that are just not, they will be just too inefficient to emulate, like full support for symbols requires that you intercept every single object lookup, like square bracket lookup in a num object. It gets really complicated and expensive. Same thing with proxies. If you want to fully emulate proxies, you have to basically write every single property lookup, every single function call, which is just not something that I’m willing, or I don’t think anyone would be willing to actually put in production.

JAMISON:  So, I wanted to ask about that, related to stuff in production. We had Erik Bryn on a while ago and he talked about, mentioned Traceur a little bit. And he said that, and I’m probably going to misquote, but I feel like he said there were people using it in production even though it compiles down, because [inaudible] syntax and semantics exactly right, it would sometimes compile down to relatively inefficient code. And if you were less strict about getting it to match the spec 100% or missing some edge cases, you might be able to optimize it a little bit. Is that the case, does Traceur explicitly choose correctness over maybe speed or production-readiness or something?

ERIK:  Initially it was all about correctness. And right now, it still tries to be correct and it’s still important to be correct, but we have done optimizations which allow us to still be correct but it’s faster.

JAMISON:  Sure.

ERIK:  But there are definitely some ideas to do a subset and make that faster.

JAMISON:  Do you think that, well first of all, did you know that people are using this in production? And if so, do you think that’s a good idea?

ERIK:  I know people are using it in production. And I think it’s a good idea. You just need to be aware of which features we’re using. So, Traceur has a bunch of options. Some of these are experimental. Experimental means that they’re either non-standard or they’re just too inefficient to implement. And so, as long as you don’t use the experimental flag, then you’re good for production.

JOE:  Didn’t let use to be experimental and now it’s not?

ERIK:  So, let is still experimental. And the main reason why is that it’s implemented as a try/catch block because that’s the only way in ES5 to get the correct let scoping. Last week, or actually last weekend, we landed a pull request that changes let to use functions, like if is or just ordinary variables. There are some [inaudible] bugs on that one. But once those are done, we’re planning to enable it by default.

JAMISON:  Sweet.

JOE:  Very cool. What other features of Traceur are implemented particularly inefficiently or are extremely difficult to implement but are implemented and people might want to watch out for?

ERIK:  Yeah, I think it’s just symbols. Symbols are slow, like I said.

JAMISON:  Alright. I got to confess. I feel like I do this every podcast, but I don’t know what symbols are in ES6.

ERIK:  Okay.

JAMISON:  I got to admit my stupidity. Yeah.

ERIK:  So, I’ll try to explain what they’re used for. So, in ES5 every property is a string. So, when you do a.b, the property name is a string “b” actually. And you can use a square bracket and a string expression b and it will do the same thing. In ES6, we have something called symbols, which is a different kind of property key. And the main benefit of that one is that it’s a unique symbol. So, there will never be a collision. So, if you create one symbol, the only way that you can get, so let’s say you have an object that instead of using a string b to assign a property to the object, you use a symbol that you created.

So, with symbols you can create properties on an object that are guaranteed to be unique. There’s no way that there’ll be a conflict between two [inaudible] symbols. And the only way to get the symbol back out is to have access to the symbol itself. So, this allows you to have unique symbols. In ES5 people sometimes use a random string to make some kind of uniqueness but it’s not really guaranteed to be unique. Someone can easily just look it up and use it or accidentally get to it by doing a for in loop or something like that.

JAMISON:  So, the symbols are the keys of the object.

ERIK:  Yeah. So, symbols are a new kind of property key.

JAMISON:  Okay. Is it similar to symbols in Ruby?

ERIK:  I believe so. I haven’t done much Ruby but I know influenced by gensyms in other languages.

AJ:  So, does this mean that we’ll be able to do private stuff inside of a prototypical instance?

ERIK:  Well, there was a long discussion about how we wanted to implement symbols. And right now, they’re not private. They are not visible in for in loop, so it’s hard to accidentally get it. You can deliberately get it by using reflection. And you can also get to them by using a proxy. And in the ES6 design days, we were talking about having private symbols and public symbols. But for ES6 we decided just to do public symbols. And for ES7 we’ll revisit it again.

JOE:  Very cool. So, are symbols your favorite feature then?

ERIK:  No. I think [inaudible] is my favorite feature.

JAMISON:  [Laughs]

JOE:  Sorry, what was that?

ERIK:  [And classes] are my favorite feature.

JOE:  Really?

ERIK:  And I know a lot of people hate on them. But I find them very useful. And I think a lot of the hate comes from misunderstanding what classes in JavaScript actually are. So, a lot of people, almost everyone, here use prototype inheritance in JavaScript. And it’s just a lot of boilerplate code to get it right. And even if you think you’re getting it right, you might not actually be getting it right. Or you might be using YUI or Dojo or some other JavaScript library and they don’t happen to really agree on what certain things to do especially when it comes to calling super.

So, in ES6 we’re adding dedicated syntax that’s up the prototype chain in the same way that a correct library would do it in ES5. We’re just going to give you syntax so it’s clear what’s going on. It’s easy to read, easy to write. As a bonus, we’re going to give you a real super implementation, so you can easily just write super and that will call the super method or the super constructor. Yeah, so in ES5 you can do all these things. It just gets pretty ugly. And I like syntax that describes you intention. I think that it’s important to say what you mean and code should definitely say what you mean.

JAMISON:  I feel like a lot of the objections to the class stuff in JavaScript are just tech hipster-ism. People are just sad that it looks a little bit more like Java now.

ERIK:  Yeah. That’s fair. But on the other hand, JavaScript does come from a C-like syntax. And we already have keywords for class and extends and static. So, it just makes a lot of sense to reuse those keywords. You have less risk of conflict, for example. So, when it came to static methods in ES6 no one really wanted to use the static keyword because they’re not really static. They’re instance properties on the actual function that you’re using for your constructor. But since we have the keyword there and no one could come up with a better keyword, it was just logical.

JAMISON:  [Laughs] [Inaudible] a reluctant decision.

ERIK:  Yeah, but it was… when you see static, you know what it’s going to mean.

JAMISON:  Sure.

ERIK:  People will know what it means even though it’s not exactly what they might expect from other languages.

JOE:  Right.

ERIK:  And I can name a couple of other features that I also like. I really like spread and rest. So, today a lot of people use function.prototype.apply and pass in arguments or an array of some kind. And spreading just allows you to spread that array into all the arguments. And the same thing works for array literals. So, it’s really hardly any reason to ever use apply anymore, for example. And same thing with the rest arguments. There’s hardly any reason to use arguments anymore. You can just name your rest arguments and you start as a plain array. It’s small things, but I think it just fits very well with the language and it’s just something that’s very convenient.

JOE:  My favorite I think is the arrow functions.

AJ:  Yeah.

ERIK:  Oh yeah. I forgot about that one, too. It’s just I’ve been using this stuff for a long time. So, Traceur itself is written in ES6. So, I’ve been writing ES6 code for a couple of years, actually. And once in a while, I have to write code that’s not written in ES6 and I forgot that I cannot use method shorthands and arrows functions. It’s just very convenient.

JAMISON:  So, I want to ask a related question about authoring libraries in ES6. So, I know there’s, I think the [inaudible] thing that Facebook distributes is in ES6 and it’s not really, it makes it difficult to consume unless you’re also using ES6 and something Traceur. Do you know, because [I’m on V8 often], how do you feel about how people using ES6 can interact with other people who are still using ES5?

ERIK:  So, a lot of people today, they use build steps. And when you have a build step, it’s fine. I don’t think it’s an issue. I think the way that this is going to play out is that people are going to use the module loaders to load ES6 code from ES5, because module loaders is an API that works even in ES3. You can do feature detection for that. I’m not sure that answers your question, though.

JAMISON:  No, it kind of does. So, if someone uploads a library that’s ES6 into npm, people consume that using a module loader [inaudible] transpile that down to ES5 if you’re using ES5? Is that how it works?

ERIK:  Yeah. So, there are two options here. One is to use a module loader that does the compiling on the fly. Guy Bedford has a module loader called ES6 Module Loader. It uses Traceur for the parsing and transformations. But he implemented the module loader from the ES6 spec and this all works in ES5. And the other alternative is to compile ES6 modules ahead of time to maybe CommonJS modules or AMD modules, which yeah, some people do that. And that’s easy to consume if you’re in Node.js at least.

JAMISON:  Oh, sure. It’s just a little bit more, if the author only publishes something that’s ES6, it’s a pain to grab it and have to compile it yourself and then to [Coffee] or I don’t know, however you pick. I like the module loader.

ERIK:  Yeah.

JAMISON:  Where it’s done on the fly.

ERIK:  Yeah, I agree. I think the short term solution is probably for people that do push ES6 packages, ES6 modules to npm is that they either precompile it or that npm maybe does the compiling for them. There will be a transition period here, yeah. It will be a little bit of extra burden for people that want to use the new stuff.

JOE:  Very cool. So, I have another question. I know that Traceur when you use it, you actually have a runtime library you need to include in your production application, right?

ERIK:  Yes.

JOE:  So, what does that runtime library actually do?

ERIK:  So, conceptually you could remove it. So for example, when you create a class, we have to set up the prototypes and set up a few other things, which is not that much code. But if you have a hundred classes in your system and you have to duplicate all that code, that’s a lot of code that you don’t want to duplicate. So, we decided to put in a runtime library. At one point, we actually did not have a runtime library for everything, but we injected the code once. It was just harder for people to maintain. They get stuff that they might not want, not that they don’t want, but it was harder for them to maintain different compilation units because you tend to compile one file at a time. And then it wasn’t clear which runtime functions you needed.

So, another way to see, to look at it, is that these runtime functions are just helpers to reduce code size. You can always inline all of these if you want, but you don’t want to. It’s just like in V8 or in SpiderMonkey. There’s stuff in there that are runtime. You don’t want to inline all of that code.

JOE:  Gotcha. So, what do you think of the other projects that are very similar in purpose and scope to Traceur, like the esnext project?

ERIK:  I think they’re all great. I’m not that familiar with esnext actually, to be honest. I was going to mention Regenerator by Facebook, which only compiles generator functions to functions, which is a really neat product. I think their output is much better than Traceur’s output. But on the other hand, they only support generator functions. And they do have experimental support for async functions.

And then another big shout-out is of course to TypeScript, which is a compiler but I wouldn’t call it ES6 compliant. But at least they’re experimenting with a lot of ES6 syntax. Their goal is more production quality. So, they take shortcuts when it comes to class behavior. But in most code, their shortcuts are fine. You’re only going to hit the edge cases if you do something weird.

JOE:  Right. Now, Traceur doesn’t support a lot of features that are more natural to be implemented as polyfills, right?

ERIK:  So, we do have a bunch of polyfills. They are not as complete as the ES6 polyfill project. I don’t remember the exact name right now.

JOE:  ES6 Shim, is that the one you’re thinking of?

ERIK:  Yes. That’s what I’m thinking of. So, we do a polyfill promise, map, set, a bunch of array methods, a bunch of string methods, and stuff like that. And these things are pretty easy to implement. It’s just a matter of someone contributing them. So, some people have asked us why we’re not using ES6 Shim in the first place. And I just felt that implementing these in ES6 with class syntax and similar was just a good thing to do. And it’s always good to have more than one implementation.

JOE:  Right.

ERIK:  And yeah, so these polyfills are optional. You don’t need to include them if you don’t want them. You can change to make the file a bit, to just include whatever you need.

JOE:  So right now though, we’ve got this difficult sport that we’re in as developers. If you want to do ES6, there’s no single place to go and be able to just do all of ES6, right? So, you end up in this position where, you have to look and, “Well, what do I want?” and then I can go for a product that supports that. Maybe Traceur supports all the things that I want so I’ll just use Traceur. But then later on you might find things that it doesn’t support, so then you got to add in some polyfills or something else. When do you think we’ll see a point where there’s a single place you can go and add in one product into your development workflow and be able to author whatever you want as far as ES6 features? And how do you think that will happen?

ERIK:  So, I think you can do that with Traceur. You will run into edge cases where polyfill is not complete or is missing, but yeah I do feel that you can actually do that. Just file bugs when you find a polyfill that’s not complete or misbehaving. And polyfills are pretty easy to implement compared to the rest of the system. So yeah, to be fair, you’re right that you cannot just put a drop-in replacement in your webpage and everything would just work out of the box. You need to cherry pick a little bit to know what you’re using.

JOE:  Right.

ERIK:  Yeah. The only way to actually find out is to try or read the documentation.

JOE:  Why is it that Traceur doesn’t implement weak map and weak set just as sets and maps?

ERIK:  That’s a good question. We actually had a pull request for map, set, weak map, and weak sets. I felt that that pull request was way too large. It did all four of them at once. So, I asked the author to split them into separate pull requests. And the weak map and weak set never came. So, I guess we’ll have to go back and do them.

You cannot really get weak maps and weak sets that are fully compliant with the spec because they add new garbage collection semantics. But you can easily create a weak map and weak set that fits certain scenarios. And the scenario I’m thinking of is when you have something cool like side table where you store some extra data on the side of an object. And that can easily be implemented as expanded properties. And then you will get the right GC behavior, too. And that’s what we should be doing. And I think I should just get that done. It’s not that hard.

JOE:  Right.

ERIK:  There are a bunch of weak map polyfills out there. And some of them are more correct than others and some of them are super slow. For the Polymer project, we needed a weak map so we did the side table structure with expanded properties on the actual keys. And we tuned that for performance because Polymer used a lot of weak maps initially. And so, we got that really fast. It’s not fully spec-compliant but it does get really fast and the code is really small, too.

AJ:  So, are you saying that the weak map polyfill’s actually compliant with the spec or close to?

ERIK:  So, the main use case for weak maps is for so called side tables or for private state where you use the object itself as the key and then you put the private state as a value in the map. So, the only way to get to that is when you have access to the map itself. So, you use that object as a key and you have access to the map, then you can get the private data out. And then you can hide that map in a closure. And as long as no one else can get to it, they can’t get to your data. And that scenario can be implemented without the private security, because it’s usually done by adding expanded properties to the actual object. And those will be visible to other people. But you will have the right behavior from a GC perspective too.

AJ:  Oh, that’s interesting. I didn’t realize that that could be done.

ERIK:  Yeah, so that one can be done as long as you don’t have cycles and stuff like that, because that’s where weak map really shines. But it can actually break your cycles between different keys and values in maps. That’s why we actually needed to add them into the language because their primitives are not there today.

AJ:  Right, yeah.

ERIK:  But even with Traceur we can actually add an extra layer of security by rewriting the code. It of course has some performance issues but we do this in some places. So, we do rewrite object.getOwnPropertyNames to not expose these private properties, or so called private properties. But you can still get to them if you select a different frame or something to circumvent our weak protection. But it’s doable.

JOE:  Right.

ERIK:  And when you transform the whole code, you can add extra security checks at runtime if you’re willing to pay the price.

JOE:  I gotcha. So, another thing that I was interested in is development workflows. And this relates to my other question where I was talking about a single drop-in. So, say for example you’re a developer and you’re a little bit interested in ES6 right now. The easiest way by far to throw a few ES6 features into your project is just to go out and grab ES6 Shim because all it is, is one script tag that you add. If you don’t have a build or if your project’s really small, you don’t have to worry about a build. And so, it doesn’t affect your workflow. It’s just one little script tag that you add in and now you can play around with some ES6 features. But you’re missing out on all the nice syntax.

ERIK:  Yeah.

JOE:  So, when it comes to actual development workflow, what development workflows have you seen or experienced that you think are the best workflows to use?

ERIK:  So, if you’re just playing around, Traceur has a single script file that you can drop in place and then you put, in your script tag you do type=”text/traceur”. And then when you load the page it will just find all those script tags and translate them on the fly and run them. That’s really easy for just playing around with it. It’s not something that I recommend for production. But it’s definitely the easiest way to get started.

JOE:  Gotcha. And what about for a more, not such a simple way to get started, if you want to do something more fully-featured in a real production-type application?

ERIK:  Yeah, in a production scenario, you definitely want to compile stuff once, preferably ahead of time. So, when you deploy your application, you compile them. There’s a grunt-traceur, there’s a gulp-traceur, and you can also use Traceur by itself and use some of the scripts we have in there. Yeah, I would probably recommend people to use gulp-traceur or grunt-traceur at this point.

JOE:  Have you helped out with either of those projects or worked on either of those projects?

ERIK:  I have not. I have not. I don’t really know how well they work, but I assume they work because I don’t hear much complaints about them.

JOE:  Well, he’s not on the call, but Aaron Frost one of our panelists is actually the guy who wrote grunt-traceur.

ERIK:  That’s true, yes. Yeah. So, I definitely [inaudible] to it.

JOE:  So, we’re going to say that it probably works great. Yeah. So, it’s the best product ever.

ERIK:  Yup.

JOE:  [Laughs] Shout-out to Aaron Frost.

ERIK:  Yeah, so you can definitely use Traceur by itself and use the scripts there. It does take some work to get it working. But once you get over that little bump, it gives you a lot more power. But then again, I would definitely recommend grunt-traceur.

JOE:  So, I just did a course for Pluralsight on ECMAScript 6 that should be released at the time now.

ERIK:  Cool.

JOE:  And when I was playing around, one of the modules that I did was actually using ECMAScript 6 today, so I did a bunch of stuff with Traceur. One of the things that I’ve discovered that I thought was really neat is that in WebStorm, there’s an automatic file watcher that if you have Traceur installed, you can hook it up and then it will watch all your JavaScript files for you and transpile it for you. So, it’s really nice if you’re just on your own. In a team environment, it doesn’t really make much sense. In a team environment, you really want an actual build. But if you’re developing on your own and instead of having to add a build step you could just have WebStorm just compile all your ECMAScript 6 files for you into ECMAScript 5 and then that’s just how you deploy.

ERIK:  If you want to compile it into a single binary, that’s going to be a bit… I assume those file watchers just compile into either AMD or CommonJS. That’s very flexible today. And it’s also what TypeScript does today. They compile into AMD or CommonJS actually. So, that’s a good way to go today, for sure.

JOE:  Yeah, I thought that was a pretty cool idea by the JetBrains people.

ERIK:  Yeah, that’s [inaudible].

JOE:  To add in Traceur support.

ERIK:  Yeah. Another thing you can do to play around is just use JS Bin. They have an option for using Traceur. So, in the JavaScript panel you can use, there’s a little dropdown where you can select the language to use and Traceur is there, too.

JOE:  Oh yeah, very cool. So, what about the future of Traceur? What is Traceur going to be supporting next?

ERIK:  A bunch of ES7 stuff that we want to prototype and implement, for example, decorators. Right now we have something called annotations which is similar to decorators but annotations are not really on track for ES7. So, it’s highly experimental. So, we would like to play around with decorators as well. Other than that, we have async functions like I said, which is really awesome. And what else is interesting for ES7? Yeah, can’t think of anything right now.

JOE:  What about Object.observe?

ERIK:  That’s another one that I don’t think Traceur is the right tool for. And if you want to implement that, you will basically have to intercept every single property access or property mutation, setters, to see if there’s an observer on it. And I think that’s just not going to perform well. It’s possible that the middle ground can be done where you use some hints to the compiler saying that this object is going to be observed and you wrap your calls somehow. But I’m not sure it’s worth it. I feel like if you really want to use Object.observe, there are libraries out there that use dirty checking to give you a higher view of the mutations. And that’s what Polymer uses for platforms that do not support Object.observe. And that’s much more performant.

JOE:  Really?

ERIK:  So yeah, those libraries, they operate on a much higher abstraction level. So, if Object.observe is available they use it, otherwise they do a dirty checking on the whole model, which is of course much more expensive. But it’s at least not as expensive as intercepting every single property setter.

JOE:  Right. Yeah, it kind of does bring up another question about Traceur. The polyfills that it’s got, do they check and see if the feature’s already implemented and then avoid overriding them?

ERIK:  Yes, they do that.

JOE:  Is that one of the requirements for any polyfills included in Traceur?

ERIK:  Yeah. I will say so, unless the one that’s shipping is completely broken. But right now, none of them are that broken. At some point in time, we were considering whether we should override the built-in map that’s set for V8 in Chrome, because the one that’s under the harmony flag has been broken for a long time until very recently.

JOE:  Right. Right, I gotcha.

ERIK:  And for example, in Node.js they still use old map and sets which does not support iteration. So, in that case we should probably override it but we don’t. I’m not sure. I have to double check that actually.

JOE:  Hmm. Yeah, I was really surprised to find polyfills that didn’t automatically check, but I found quite a few that didn’t check and just overwrote whatever was there.

ERIK:  Yeah. I’ve done that mistake, or I’m not sure it’s a mistake. I’ve done that design several times working on polyfills for Polymer. So, in that case we decided to override but there’s an initialization function. So, the person that [inaudible] [chuckles], the person that imports your polyfill should decide if they want to use it or not, because sometimes they want to use it even if there’s native support. For testing, for debugging, for multiple reasons.

JOE:  Right. So yeah…

ERIK:  In Polymer, we do the script that imports some of the polyfills decide whether they should use the polyfill or not.

JOE:  Gotcha, cool. Well, I think I’m out of questions. Is there anything else about Traceur that we should talk about that we didn’t?

ERIK:  I’m sure there is, but I can’t think of anything right now.

JOE:  Awesome. Alright, well I think we’ll wrap this up. We did have some funny technical difficulties during this call today. So, we lost Jamison mid-call and I think we lost AJ. So, it’s down to you and me, Erik.

ERIK:  Yeah.

JOE:  [Chuckles] You did get some picks put together for us?

ERIK:  Yeah, it’s mostly things that we mentioned already. I would like to give a shout-out to Regenerator, which is on facebook.github.io, which is a really good transpiler for generators.

And then of course, TaskJS.org by Dave Herman, which allows you to do async programming today using generators.

JOE:  Is that it?

ERIK:  Yeah, I think that’s it right now.

JOE:  Okay. Well, I’ll do my picks. We’re a little backwards. Usually we have the guest go last, but since you just had that short list, I’ll go last. And if there’s anything else that you think of after I’m done, then you could have a second round. I’ve got three picks today.

The first pick is going to be Bluehost. I recently set up a WordPress site, a new WordPress site for blogging and decided to go with Bluehost. And I was really impressed with how easy it was to get up and running with them. And the fact that they auto-update, I actually got notified that they’ve auto-updated my WordPress installation for me. And they also have a ton of YouTube instructional videos on how to utilize WordPress and customize the themes and implement your own themes and use third-party themes, et cetera, or plugin whatever WordPress plugin. So, I was really pleased, because I haven’t done, hardly any WordPress before. So, it was very easy for me to get up and running and have a site put together that I really liked. So, I’m going to call out Bluehost as an awesome WordPress host and very cheap as well.

My next pick is going to be a book that I just barely finished. I went on sort of vacation to That Conference, which was awesome by the way. So, maybe that will be half a pick, is That Conference. Awesome conference, lots of bacon, really enjoyed it. But I read a book called ‘Forging Zero’ which is part of a series. And it’s on Amazon. It’s extremely cheap. It’s on Audible as well, extremely cheap. It’s like $2 on Kindle and $3 on Audible, something like that. Awesome sci-fi military book, just loved it. I completely went through it as fast as I possibly could, begging my wife to do some of the driving so I could read. And every spare minute that I had, I was reading. Absolutely loved the book and can’t wait to read the next one. The series is four or five in the series, I think.

And then my final pick with be what I mentioned earlier. Myself and Scott Allen put together a course on ECMAScript 6. And in that, we have an entire module that talks about how to use ECMAScript 6 today, including Traceur. And we used Traceur a lot in the course. So, pretty appropriate to talk about that and mention that. That course should be out by the time that this episode has been published. So, you can find that over at Pluralsight.com and I’ll put a link in the show notes.

And that’s it for me. Erik, is there any final picks or words you want to give out?

ERIK:  Since you’re talking about a book, I could also mention something I read last year that I could not put down. It’s called ‘Wool’ by Hugh Howey. It’s a sci-fi dystopian future. It’s a trilogy and all the three books are out. And they’re all on Amazon. It was just, yeah, the first book just blew me away. It was really good.

JOE:  Awesome, yeah. I’ve read that. It was definitely an excellent book.

ERIK:  Yeah. The second book and third book are not as good, but they’re still good. Last week or two weeks ago, I saw you recommended ‘The Martian’ which I also liked a lot.

JOE:  Cool. Alright, well I guess that wraps us up. Thanks again for coming, Erik.

ERIK:  Thank you.

JOE:  I really enjoyed having you on the show.

ERIK:  Thanks.

JOE:  And we’ll see everybody next week.

[Working and learning from designers at Amazon and Quora, developers at SoundCloud and Heroku, and entrepreneurs like Patrick Ambron from BrandYourself, you can level up your design, dev, and promotion skills at Level Up Con taking place October 8th and 9th in downtown Saratoga Springs, New York. Only two hours by train from New York City, this is the perfect place to enjoy early fall and Oktoberfest while you mingle with industry pioneers in a resort town in upstate New York. Get your ticket today at LevelUpCon.com. Space is extremely limited for this premium conference experience. Don’t delay. Check out LevelUpCon.com now.]

[This episode is sponsored by MadGlory. You’ve been building software for a long time and sometimes it’s get a little overwhelming. Work piles up, hiring sucks, and it’s hard to get projects out the door. Check out MadGlory. They’re a small shop with experience shipping big products. They’re smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter at MadGlory.]

[This episode is sponsored by RayGun.io. If at any point you application is crashing, what would that cost you? Lost users, customers, revenue? RayGun is an essential tool for every developer. RayGun takes minutes to integrate and you’ll be notified of your software bugs as they happen with automatic notifications, a full stack trace to detect, diagnose, and fix errors in record time. RayGun works with all major mobile and web programming languages in a matter of minutes. Try it for free today at RayGun.io.]

[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.] 

[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]

[Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]

x