JavaScript OOP that can Run Faster with Google SoundScript - Lately in JavaScript podcast episode 52 - JS Classes blog

Contents

Introduction (00:20)

Faster JavaScript OOP with Google SoundScript (1:03)

Writing Faster JavaScript (6:26)

Token Based Authentication for Single Page Apps using JSON Web Tokens (18:47)

Joyent Moves to Establish Node.js Foundation (22:58)

Io.js Roadmap (25:42)

Node.js and IO.js Reconciliation Proposal (27:24)

How NativeScript Works (30:52)

JavaScript Innovation Award Winners of December 2014 (38:31)

JavaScript Innovation Award Championship Rankings of 2015 (41:48)

Conclusion (42:41)

Contents

Listen or download the podcast, RSS feed

Watch the podcast video

Read the podcast transcript

[Music]

Manuel Lemos: Hello. Welcome to the Lately in JavaScript podcast. This is episode 52. As always, I have here with me Arturs Sosins from Latvia that just woke up, right?

Hello, Arturs.

Arturs Sosins: Yeah, it's something like that.

Manuel Lemos: Yeah, it seems to be morning.

Arturs Sosins: Good morning. Good morning.

Manuel Lemos: Well, over here, it's not yet morning, but it will be in two hours. It's always great to record soon because at least on your side, you have some sunshine on your window.

Faster JavaScript OOP with Google SoundScript (1:03)

Manuel Lemos: So we are here to talk about JavaScript and the latest happenings, things that have been happening in the JavaScript world. Before my webcam disappears like in the PHP podcast recording, we are going to start right away talking about an interesting development on the V8 engine.

As you may know, the V8 engine is the engine that Google developed and powers Chrome and also Node.js, probably other projects that I don't recall, but these are the main ones.

This development, they call it Google SoundScript. Sound in this context does not relate with noise but rather with the solid, developed, sound JavaScript implementation. And this development is to implement ways to make JavaScript faster for object-oriented programming.

There is this article here by Dr. Axel Rauschmayer. First, he mentions about things that usually slow down object-oriented programming in V8. He mentions about variables and properties that can have values of any type.

Then, also the problem of dynamically adding and removing properties from objects, also the possibility to change the type of values and also the possibility that arrays do not need to be a contiguous set of elements that can have holes like he mentioned here, and also arrays that can have elements of any type like any other variable in JavaScript.

So this SoundScript development basically consists in having... If you can add in the beginning of your scripts, "use stricter", do not confuse with "use strict". It will be a stricter mode. If you look at it suddenly, you could confuse it and think that it's the "use strict". But it's not, it's the "use stricter" parameter. It's a new mode that they are introducing here, and you can put it here.

Actually, they have here an example. I have an ECMAScript 6 class. So this is not the traditional JavaScript that you don't have classes. Anyway, this is just an example of how you could declare it in the stricter mode. There are also variants that can apply to types.

Basically what this does, all these things that can do using the SoundScript is to optimize certain things that he mentioned before that he won't be able to do, and it will allow the V8 engine to optimize and run faster.

Well, this is always interesting. Arturs, I don't know if you have looked at this article before. It's basically a proposal to what...

Arturs Sosins: It seems to be like Hack for PHP.

Manuel Lemos: Yeah.

[Laughter]

Manuel Lemos: Now, that you mentioned it, yeah, there is some parallel. It seems somewhat similar. I guess you can still mix traditional code with stricter code, and you can also do that with Hack. You can mix traditional PHP code with Hack language code.

So there is a certain parallel, but I think for those that really need to optimize their JavaScript applications, if they follow these principles to avoid these problems... these issues that sometimes they are not really necessary... I think you can benefit from great speed enhancements. This is quite interesting.

Writing Faster JavaScript (6:26)

Manuel Lemos: This ties exactly to the next topic which is yet another article that gives you some tips to write faster JavaScript. So let's look at these tips again. Again, I mean let's look at these new tips, again. More tips than we have seen before. It's not like we have seen these tips before.

So the first tip is, they put it, "Don't make me typecast" just to avoid type conversions. It is interesting because... Let me see if they put it for all examples.

They show two types of code and they link to a page in JSPerf site that compares the types of code, and they give you results so you can see exactly which approach is faster.

So in this case...

Arturs Sosins: I think even that point is why this article should be mentioned because for every example that is discussed that you can try yourself and see what is fast, what is slow.

Manuel Lemos: Yes. It's pretty cool because if you are wondering why things are really faster, you can read the article. But how fast they can be, you can see these examples and see the gains that you may get from this.

The first one, as I mentioned, is about type conversions using typecasting. There are different ways of achieving things and some ways are faster.

The second one is about "Don't re-structure objects". One thing they mentioned first is to do not use the delete operator, use the null, the null value to assign variable.

Let's take a look what are the examples here. I don't know if this is large enough. So they mentioned here that assigning a null to an object is indeed faster than deleting the object. I'm not sure, maybe this is due to garbage collection because assigning to null. Garbage collection probably will happen later, I know. I don't know. I'm guessing.

Arturs Sosins: No, but I don't think when assigning to null, I don't think garbage collection will happen at all. You still have the...

Manuel Lemos: Exactly that's what I meant. Yeah, it will be postponed or least it won't happen right away.

Also, one that is probably more evident, which is not adding properties after you create the object. Yeah, well, if you initialize your objects without properties that you need, you avoid that. If you keep adding or removing properties, that probably make it slower.

Arturs Sosins: The solution probably could be initializing the object with all the properties unique, but no values. And then you just add values in this property.

Manuel Lemos: Yeah, so just declare them and do not assign the values. I don't know if that is the case. Well, let me see here, here they initialized the Z variable with 0 and they gain like..

Arturs Sosins: 50% slower.

Manuel Lemos: Yeah. I don't understand quite these numbers. How it's going to...

Arturs Sosins: Operations per second.

Manuel Lemos: OK, this one is slower. OK, let's get back.

The next one is string concatenation. They say that you'd rather have... Let me... Where are the tests? OK.

Arturs Sosins: It could be very different probably in different browsers.

Manuel Lemos: Actually, they have different variants here, so you can see which one is probably faster using concat and join, different ways to join strings. It's like six ways.

Arturs Sosins: It's like 101 ways to join string.

Manuel Lemos: Yeah. I thought it would be just two. So in the end, what they say is that the fastest is like six...

Arturs Sosins: Mine says that Array.prototype.join is the fastest.

Manuel Lemos: Which one?

Arturs Sosins: Array.prototype.join is the fastest.

Manuel Lemos: Yeah, this is a bit weird, but OK.

Arturs Sosins: It is probably browser-dependent and it would change, so there is no right answer for this one, I think.

Manuel Lemos: Yeah, well, at least we know that concatenation of strings using the + sign or the concat, it's much lower. So if you're really obsessed with performance, you can come here and be convinced that you should use these tips.

Arturs Sosins: But that's quite interesting.

Manuel Lemos: Yeah.

Arturs Sosins: The only function that was meant to do concatenation is the slowest one doing it.

Manuel Lemos: Yeah.

Arturs Sosins: String.prototype.concat is slow in both results.

Manuel Lemos: Maybe the implementation should be optimized to avoid these problems.

Well, anyway, the next one is about Regular Expressions. There are several methods for the regex option. So there is exec, match and test. OK, where is it? Where is the result? Oh, here. So this one just says... Well, this one I've seen before. I know that the 'test' will be the fastest. But this is only for really, really performance-sensitive applications that should use this. But it's interesting that match is much slower than test.

Arturs Sosins: Yeah, it's like twice slower.

Manuel Lemos: Yeah. That's interesting. And they also commented about when you want to search for some text in a string, you could use indexOf or search, but search is regular expressions and... I don't... Regular expression is not really for constant strings, constant patterns.

Arturs Sosins: That's what we've...

Manuel Lemos: But still, it's not that much slower as in the other examples.

Let's see here, I think this is the last one, "Declare and Pass Local Scoped Variables". OK, wait, I can't... Here, run tests. It just say 'accessing global variables'.

Arturs Sosins: That is really the best practice when you're using variable very often than you should declare it, already the global... to global scope.

Manuel Lemos: Yeah, I don't know. I usually avoid the global variables just because it may be confusing variables with names. But here, it just says that it's like 8% or 9% slower, passing the global variable internally.

This is interesting. Anyway, the last one. Always this, the last one, "You don't need jQuery for everything".

Arturs Sosins: This should be interesting.

Manuel Lemos: Yeah. Well, it's ties to the topic that we've talked about in the last episode. They have a test here using selectors. Probably because inside...

Arturs Sosins: Wow.

Manuel Lemos: Yeah, 99% slower. Very much slower. Because jQuery is a library and internally, it probably does many tests to check what code it should run. It has many conditions. So this is really significant. So here is the evidence. Don't use jQuery for everything.

Arturs Sosins: Even if you kind of need to? Yeah.

Manuel Lemos: Yeah, well...

Arturs Sosins: Sometimes, people think, "I've already included jQuery in the project so I better use that function."

Manuel Lemos: Yeah, exactly.

Arturs Sosins: In this case, there is like two characters more to type, so it's really interesting.

Manuel Lemos: Exactly. I also have read about this in articles about developing mobile applications with... actually hybrid environment like PhoneGap and should avoid using jQuery if you can, because that will make the application heavier. So now, with this test that we've seen we have the evidence that is really significant, how much it may slow you down.

Arturs Sosins: Yeah, but just to mention we are not like diminishing jQuery as a tool.

Manuel Lemos: No. No. We don't even insist on it in two consecutive shows.

[Laughter]

Manuel Lemos: No. I think jQuery has saved a lot of grief to developers especially when the browsers that were in use were not very standardized, but over the years, things become faster. I mean, implemented natively in the browsers. Modern browsers implement standard APIs that make you no longer need jQuery.

Now, if you really need performance, you should avoid jQuery because it's heavier, which is natural because internally, as I mentioned makes a lot of tests to decide which library, which implementation they use in different browsers.

OK, there was one bonus tip, which is use "Web workers for heavy tasks", like creating parallel processes to run tasks in the background.

So this is interesting. This is yet another article of those that teach you tips that you probably were not aware. This time it was interesting because we could see it in numbers how much faster certain approaches can be.

Token Based Authentication for Single Page Apps using JSON Web Tokens (18:47)

Manuel Lemos: So moving on to the next topic... hang on... there is an article about something that is new for me, at least for me, which is related with JSON Web tokens. Let me share the screen here.

This article mentions the token-based OAuth authentication for single page apps. It mentions about the traditional way that applications access server resources using, for instance, cookies to identify a user that may be logged.

They mentioned that cookies can be a great way to implement sessions to identify the user, but security reasons, you should use HTTPS-only cookies... sorry, you should use HTTPS and then use HTTP cookies, so you can avoid eventual cross-site scripting attacks by stealing cookies, cookie values, and send them to remote servers.

Then, they started mentioning here something that for me is new, JSON Web Tokens. Well, I did not fully read this article. I did not have the time, but they mention the OAuth spec and the JWT, JSON Web Token specifications, which they already mentioned that it is dense, the specification.

Arturs Sosins: It associates this with Java Web Toolkit or something like that.

Manuel Lemos: Yeah, yeah, but that's not the case.

Arturs Sosins: Yeah.

Manuel Lemos: They mentioned that these are tokens that can be encoded in a base64 strings, and they have multiple parts... a part that identifies sort of a header, that identifies what the token is about. The second part is I think it's the value, the values that are passed in the tokens. And the third part is a sort of a signature that you can use to verify if the token is secure and valid.

Arturs Sosins: Well it depends then.

Manuel Lemos: Yes, exactly. This is as much as I could learn from this article, but I did not fully read this. One thing that I got, I think it sort of implements a way like there is in OAuth which is scope.

You can define the scope of a token when you request it, so you can restrict the APIs from a set of an APIs that you can access. So if you want to just access the data from the current user, you can just get the profile API. I meant restrict the scope to access only that profile API, so applications that need more permissions, they should change the scope.

I think there is more to say about this. Maybe we can get back to this in the future because this is interesting not only for single page Web applications, but probably mobile hybrid applications. So we'll get back to that.

Joyent Moves to Establish Node.js Foundation (22:58)

Manuel Lemos: So moving on the next topic, basically a set of topics that are somewhat related. First, an initiative of Joyent. Joyent is actually the company that manages the development of Node.js, and they associated with several other companies like IBM, Microsoft, PayPal, Fidelity, SAP and The Linux Foundation to create the Node.js Foundation.

This somewhat seems to be a reaction to the fork of Node.js, the so-called io.js, because if they are creating a foundation with several well-known companies, this is sort of to leave out the development of the fork of io.js. I don't know, this is just an opinion. Maybe I'm reading too much into this.

Arturs, did you look into this initiative? What are your thoughts?

Arturs Sosins: As well as I was using Node.js for quite some time now, looking at it from developer perspective, it still seems kind of way too immature especially when it comes on documentations and stuff like that.

Manuel Lemos: You mean Node.js or io.js?

Arturs Sosins: Yeah, Node.js. Node.js. But it is really a large community and you can get lots of help on answers in like StackOverflow and stuff like that. So probably, it is now an established environment to run your servers on, and it make sense that they make a foundation. It's like a core of the community, and I know like joining together with other larger companies that would support it and use it also.

But, I don't know if there would be any problems with io.js. As I remember, io.js was only developed because Node.js was to slow to adapt new changes, so V8 engine and stuff like that. As yet, I don't see any of the future release of io.js. I think that even on their GitHub account, it was mentioned that you should not use it in production yet. So while it's taking some pace, it's not yet useable, and that is something that...

Io.js Roadmap (25:42)

Manuel Lemos: Yeah, that's true. And this ties to the next... Well, it's not really an article. It's more a live document, which is precisely about the road map for the io.js. There are several plans mentioned here. We're not going cover these in detail but just to say that there is a road map being specified here. If you want to know what are the plans, you can just look here. This will be posted in the Show Notes for those that would like to take a look.

So despite they say it's not yet recommended for use in production, they have quite a solid road map here. Well, that's the way I see it. Arturs, what do you think about this?

Arturs Sosins: Well, for now, it seems more like, they are showing off their philosophy that there would be no backwards incompatible changes, which would always remain backwards compatible, and the scopes that they are going to improve and stuff like that.

Actually, I even saw an article comparing performance of io.js and Node.js and io.js was already faster than Node.js. So they are doing something right, but we'll see how well it will turn out.

Node.js and IO.js Reconciliation Proposal (27:24)

Manuel Lemos: Yeah, exactly. To make this story more complete, there is here yet another article. Actually, it's a message, which says it is a reconciliation proposal, which is interesting because they just got divorced.

The io.js community just formed, forking the Node.js project. The idea here is just to elaborate a proposal for a collaboration between the Node.js Foundation... or Joyent or whatever you want to call it... and the io.js community.

And this is I would say a bit ironic because it was not many weeks ago since they forked the Node.js, and they are already trying to merge the developments.

Arturs Sosins: The interesting part is that I don't think io.js introduced anything that would break compatibilities with Node.js. It still would drop in replacements, so merging should not be that difficult.

Manuel Lemos: Yeah, just to ditch those slow parts of Node.js, and it's all right. Well, I don't know.

Arturs Sosins: If they could do it, and take the best from both worlds, then I'm all up for it.

Manuel Lemos: Yes, I agree because open-source projects are made with the efforts of volunteers, and if you are splitting the community in two projects that could join forces and work together for a single goal, why bother splitting? It seems like somebody rage-quit the Node.js Project, and now, he's regretting, "Ah, maybe not. Maybe we should get back and collaborate."

Arturs Sosins: Yeah, but then again, if they don't agree on how the decisions made in Node.js, it could be similar to PHP core team, that they are deciding everything but they're doing it slow. And others are starting to catching up like Hack language, like stuff like that.

Manuel Lemos: Yes, that's true. I think you have a point there. But in the case, the PHP world was a bit different. The Hack language was created by Facebook has lots of money and they can reinvent the wheel in much less time than all PHP core developers together because they are volunteers. And in this case, it seems just somebody disagreed. A group of people disagreed with the way that Node.js was going and created a parallel project.

Anyway, this is just a proposal. It does not mean that there will really be a reconciliation, but personally, I hope so.

How NativeScript Works (30:52)

Manuel Lemos: OK. moving on with the next topic, which is about to comment something that we mentioned last month, that was going to be in the first days of March, which is a project called NativeScript.

Now that the project was launched officially, there was a sort of tutorial article just to tell how NativeScript works.

For those that are not sure, NativeScript is basically an alternative way to implement mobile applications. You would use JavaScript and I think you can also use CSS, but there is no HTML. There is no DOM object, DOM objects to define pages. Because now, pages are defined using objects directly. You don't describe them in a document.

So if you want to implement a simple Hello World application, this is the code that they have presented to show how simple it can be.

Well, this is simple because the application is simple. It's just an Hello World. I'm not sure if this, when you have a complex project, will be better or worse than having a document to manipulate. I think the advantage of having a DOM, a WebView, is that you can use existing JavaScript libraries that work on top of the HTML documents.

On the other hand, the advantage of the NativeScript is to make it more closer to the native platform APIs. Basically, it's JavaScript code that wraps around the native objects. The difference is that you only work with JavaScript.

Actually, I listened a bit to a tutorial, and it seems that the JavaScript code is interpreted at runtime. So it's not compiled to some native codes. It would not, I would say for instance, iOS, it would not be compiling to Objective-C. And Android, it will not be compiling it into Java Runtime Interpreter. I think that's the way it works.

I'm not sure if it's that interesting, but OK. What do you think, Arturs?

Arturs Sosins: Well, if that is the case, then you are not developing games. They're open applications, so performance may not be that an issue, and it could be interpreted also.

Manuel Lemos: Well, I think if it is performant for regular mobile applications, it can be as well for games. I just think that for games, probably, you need to work on top of dedicated libraries to simplify the whole development. Because what we see here, for now, is just user interface objects like buttons and frames and messages and so on.

Arturs Sosins: If I may, I would like to try to compare it with Appcelerator Titanium that we knew before. Their approach was trying to wrap the objects underlying in both iOS and Android into JavaScript. In this case, they are I think they know it would be a different approach. It's more like they built a bridge between JavaScript and native language of the platform.

As you see it based from the code, it's basically the same as you do in native language, so it has it's up sides and down sides. Up side is that you can use like documentations of native platforms like for Androids format, text format and... you could basically write it in JavaScript and it would work. In Titanium, you would need to write new API to be able to do that because they wrap in their own objects.

Manuel Lemos: Yeah.

Arturs Sosins: But again, the down side is that it would be... to create a button on a mobile phone... it would be completely different for Android and iOS, as I think they demonstrated here. Because they're using the native structure that they have... the classes, the class names, all the things... so there should be additional, and probably there will be additional wrapper around this to making a button instantiable in all the platforms that they support.

Manuel Lemos: Yeah, I think, for instance, here, let me share the screen again. I'm still trying to figure all things. Maybe I'm not getting all things right, but the way I see it... for instance, this UIAlertView is an existing class that wraps around the native object, so this should be portable. I mean, I think you would not write different code for Android.

Arturs Sosins: Yes, you would. Because in Android, you don't have UIAlertView class. You have android.view.AlertDialog class.

Manuel Lemos: Oh, so this object is different? Does not exist.

Arturs Sosins: Yeah. Apparently, it does not exist.

Manuel Lemos: Well, I took it that there will be a super class that would wrap similar things.

Arturs Sosins: Yeah, that's what I'm talking about. I'm waiting for something like this.

Manuel Lemos: Yeah. Well, I thought that was it. So if you are correct, so maybe this is not very interesting, at least for now. Maybe somebody writes some... Yeah. Probably with some adapters. Well, I don't know. Well, the idea was to make it simpler, and probably is not simpler than we hope.

Arturs Sosins: Current state that you can make it in JavaScript. That's the current state of the project, but it's not yet simple.

Manuel Lemos: Well, it's still a progress. Better than do it in the JavaScript than try to use parts of the code in different... Because you probably have common JavaScript that is not OS-specific and you can benefit from that level of reuse.

Well, let's wait and see because this is a very new project and probably there will be lots of other interesting development.

JavaScript Innovation Award Winners of December 2014 (38:31)

Manuel Lemos: With this, let's move on to the next topic which is to talk about the Innovation Award initiative. We're starting out with the nominees of December. They were voted in January, so in February, the results come out. So now, we can comment.

Arturs, which package would you like to comment?

Arturs Sosins: Let me share the screen first. It should be shared, right?

OK, so the one I wanted to comment is the package that is called Observer Pattern, which was developed by Chi Hoang from France. What this package does, it manages the list of observers that observe some changes in another object.

When I view the first example then, it did not make any sense to me. I don't know if you see anything, but basically those are some internal classes that they use. But when I run the example, it actually made quite sense.

It generates the list of observers that observe the changes in time class and get updated when it updates. So basically, that's the example of how it runs. I don't know why there are some internal classes that does it, but you have to draw basically the main classes, the list that handles all the observers.

OK, so Chi Hoang got also one year server license IP to country for this package.

Manuel Lemos: That's good. On my behalf, I would like to comment on another package, which is UniDOM.js from Joseph, from the United States. He developed a package that provides an abstraction to access DOM elements. But, usually, the existing APIs, even in the browser too, to get DOM elements, they use the exact names of the classes or identifiers.

So this package provides a different alternative that allows to use regular expressions. So if you want to match elements that start with some name, you can put a regular expression and search for it in that way.

Arturs Sosins: Query selector only with regular expressions.

Manuel Lemos: Exactly. That's a different alternative and for that, he was nominated. He did not pick a prize actually, because I tried to contact him, and so far he did not return. So Joseph, if you are listening to this, please contact back, so you can reclaim your prize.

JavaScript Innovation Award Championship Rankings of 2015 (41:48)

Manuel Lemos: So now, let's talk about the Innovation Award rankings. This time, we are already in 2015, and although we did not talk yet about the nominees of 2015, we can talk already about the rankings.

We only had one nominee in January. It was a low month. So far, there is not much to say than to say that Andras Toth is leading because nobody else participated in January, and for that, Hungary is leading also in the ranking by countries. So that's all we have to say about this ranking for this month.

Conclusion (42:41)

Manuel Lemos: Well, with this we reached practically the end of this hangout. I would like to thank you again, Arturs, for coming, taking a bit of your morning. You could be on the beach taking some sun, but you prefer to stay here recording.

Arturs Sosins: It's 31 degrees outside.

Manuel Lemos: Yes. It seems that the sun is shining on your window and should be out there in the beach or in the swimming pool or whatever. So thank you again for coming. On my behalf, that is all for now. Bye.

Arturs Sosins: Bye.

[Music]