JavaScript performance optimization tricks - Lately in JavaScript podcast - Episode 2

By Manuel Lemos

manuellemos.net

<email contact>

Contents

Listen or download the podcast, RSS feed

Read the podcast transcript

Contents

Conclusion (59:59)

Manuel Lemos: Hello, welcome to the Lately in JavaScript Podcast. This is episode number 2, and I'm Manuel Lemos the regular host, as usual I have here as my co-host is Michael Kimsal.  Hi Mike.

Michael Kimsal: Hello, good morning!

Manuel Lemos: How are you doing Mike?

Michael Kimsal: I am super fantastic.

IndieConf JavaScript talks (0:38)

Manuel Lemos: How is it coming with your IndieConf event, too busy?

Michael Kimsal: Well, yes, it's coming along well.  We are, as many people predicted, the tickets are going up closer to the date and just because I've never done this before I get a little nervous but we're getting more people now.

It's three weeks from tomorrow on November 13th and it's coming along well, we're finalizing speakers, finalizing sessions probably over this weekend, and as it stands now we have 18 sessions, that's pretty good.

Manuel Lemos: And concerning the interests of this podcast audience, any JavaScript related speakers that you would like to mention?

Michael Kimsal: Well, the one that maybe of, what's the word I'm looking for here, maybe of some renown to some people is Rebecca Murphey, we're fortunate to have Rebecca living in this part of the country, she just lives probably a half hour, forty-five minutes from the conference center.

And Rebecca is very well known in the JavaScript community, hosted the TXJS event, I think she just spoke at the JSConf in Europe a couple weeks ago, very well known in the JavaScript community, and she's going to be coming and talking not just about JavaScript but about a lot of the tools that she uses for JavaScript and other projects that she works on, but she's going to be giving a lot of technical information about tools and so forth.

Manuel Lemos: Yeah, I think you mentioned before.

Michael Kimsal: Oh, yes, I forgot to mention she's also the host of the yayQuery Podcast, one of four people they do a wild and crazy podcast on a regular basis.

And before we go much further let me do a quick little plug for this.  This is IndieConf, indieconf.com . This is an event that I'm putting together, a conference for independent and freelance web professionals, designers, developers, writers and so on.

If anybody listening is interested in coming this is in Raleigh, North Carolina November 13th, so about three weeks from now, it's an all-day event on Saturday.  You can use the coupon 20off, that's 20off, to take 20% off the ticket price and it would be great to have you come to the conference, thank you very much.

Manuel Lemos: Oh, that's really nice.  Well, I hope you have a full house.

Michael Kimsal: So do I.

Accelerating slow pages which have JavaScript loaded from external sites (3:06)

Manuel Lemos: Well, that's sounds interesting.  Let's move on with our podcast, and in this episode I would like to comment about an interesting experience that it turned out to come with quite great results that I think it would be interesting to people that are focusing in front-end development, I mean developing web sites, pages that work efficiently.

Basically what I've actually been concerned about for quite a while, because not just concerning the JSClasses site because it's quite new, but the PHPClasses site which is the older brother site is for many years I have been getting complaints from users that are concerned that the site is sort of slow.

That aspect of performance is basically affected by several aspects but one that concerns the front-end is the elements in the page that sort of slow down the load of the whole page, specifically advertising that uses content that is retrieved dynamically from remote servers, from the ad server of the ad agency that serves the advertising, and that is done using JavaScript.

And what happens is that in the positions where the advertising appears it sort of stalls the loading of the rest of the page until the dynamic content is retrieved.

Michael Kimsal: I've seen it.  I didn't mean to cut you off there, but I've seen it not just on your site, I was mentioning it before, it's a common problem that I think almost anybody that has advertising served up by third party JavaScript or other widgets, not just adds but people that have the little things like "who's your friend in this network" sort of widgets, those sorts of things.

They all add load, and if your browsers that's trying to hit a server that's slow the whole page slows down.

Manuel Lemos: Yeah, exactly, not just advertising, the concern about advertising specifically in this site, it's sort of packed with advertising.

And on that aspect I would like to comment that I don't put advertising in the pages to annoy users, it is just necessary to generate revenue and keep this site financially viable.  So, if advertising sort of makes the user experience more annoying to the users it's certainly not on purpose, it's just the need to keep free content sites open and viable.

And I have been thinking about this problem for quite a while, but I could not figure a solution because what happens is that with JavaScript you just don't know the content that will be retrieved because on each request to the ad server the content may be different.

It may follow the same template but the actual patterns, the actual tags of the HTML that is to be placed on the page may be different to track the users.  There may be information about the context of the ad that user is seeing, so this could not be done for instance with iframes.

Iframes would sort of make it less of a problem because iframes are now in current browsers are loaded in parallel with the rest of the page so they wouldn't stall the load of the page so much. 

But since each request to the ad server must be unique to consider the user and other specific context information like the actual page where the ad is showing it has to be done dynamically.

So what I've done, and as an experiment which fortunately turned out quite well, is to employ a technique that consists of, instead of placing the HTML tags with the JavaScript on them that will make the advertising appear in that position, I just put a div with a specific ID and let the rest of the page load.

And at the end of the page I load another div, in this case to be a hidden div because it will make the actual advertising load in a position of the page that the user will not see because it will be a hidden div.

And then when the advertising tags are finished loading I use DOM manipulation calls to switch the position of the ads so the ad appears in the original positions where it is intended to appear. 

And this turned out quite well. Well, there are a few side comments that do not make it perfect. It happens that for browsers like Internet Explorer and Opera that the tags that were served dynamically using this JavaScript, sort of bleed out of the hidden div that I put at the end of the pages.

So in the initial version of the code that I developed to implement this technique I had to not do this trick of putting the ads at the end, just make them appear in the original position if the browser is Internet Explorer or Opera.

Michael Kimsal: Ooh, okay.

Manuel Lemos: So the initial version is not perfect. And I recently published a post in the phpclasses.org site blog talking about this technique, and I explained what I did just like I just described it.

And I asked users of the site if they have another idea to solve this problem with Internet Explorer and Opera. And some suggested that it would work better for those browsers instead of making the div hidden to just put them in absolute position with a negative coordinate, so I would push the position of the ads outside the page so the user would actually not see them.

And currently I have not yet tried this technique, but by the time this podcast will go live I probably will have already tried that, and I will improve the JavaScript object that I developed to implement this in a systematic way and I'll consider this alternative.

But from what I was told this technique works quite well for those browsers, and I think it will make the solution perfect for this purpose of hiding, I mean delaying the load of the slow content that is loaded remotely, not just advertising but also widgets, like I have on all pages widgets to let the users click on the Twitter button to submit links to their Twitter statuses.

And it is also another element on the page that I also employ this technique of delaying the load of the page.  Michael, have you heard anything similar to implement this sort of hack?

Michael Kimsal: Well, it's funny you ask, maybe it's not funny ha, ha, but it's timely given that I'm on the show here. I was listening to what you were saying and I've been reading the article some, and the short answer is no I haven't seen this technique used.

An idea that was formulating in my head here would be for this technique to somehow be built into CMS systems of some sort; if there was a way that you could build this or build something like this into WordPress, for example, and have it scan and do automatic rewriting for some of the... and it would be you might have to do some powerful regular expressions, but looking at what you're doing here rather than trying to get people to... I mean certainly you can do what you've done by hand and go on and do it, but having it be something that automatically recognized certain codes, recognized certain JavaScript patterns that people use for common things like Twitter widgets and so on, and have that automatically rewrite to use this technique at least for browsers that you know that it works in, that would be a really interesting approach to get this adopted quickly.

Manuel Lemos: Yeah, I think it will be quite easy to develop a plugin for WordPress or Joomla or Droople that could do automatically that. I sort of have it already because I have encapsulated it in a JavaScript object named Fast Page Content Loader that basically does that.

And it practically has it already, you don't have to re-implement the JavaScript that does the trick. The object already encapsulates the functionality, you just have to make a few calls just to pass it the HTML and where the ads will appear and at the end of the page where the ads will be actually loaded.

And I think... I have to confess I'm not that familiar with WordPress or Joomla or Drupal or other components, but anybody could pick this object that I developed to use it in my sites, but the code license is BSD so you are free to copy, modify and distribute.

The only thing I ask is to keep the URL that is in the comments of the code that point to the original page in the JSClasses site where the object is available just so anybody that is interested to get updates knows where to find them.

But I think it would be very easy if you are an experienced with developing plugins for these content management systems. And if you actually develop a plugin for those systems I will be happy to publish it in the package page for that object and also mention in the next podcast. So anybody interested to do that feel free to contact me.

jQuery Mobile (16:21)

Manuel Lemos: Okay, moving on with our podcast, Michael, you have mentioned that you wanted to comment about jQuery Mobile.

Michael Kimsal: Yeah, you need to excuse my coughing here, it just will not go away.  I noticed that I think it was about almost a week ago that jQuery Mobile had its first alpha release. And this seems to be the space where some of the JavaScript frameworks are moving.

ExtJS was effectively rebranded or reformed themselves as Sencha and got a lot of investments a couple months ago, and they're refocusing and providing JavaScript toolkits and developer toolkits for mobile devices. jQuery is now doing the same thing.

jQuery Mobile 1.0 Alpha 1 released, I'm going to try to look for the date on that, but I think it was last Saturday or Sunday, so I think it's been in the last week, and we just had a discussion about this, a very, very brief discussion, at our PHP user group meeting Tuesday at NC State, and the consensus was there were a lot of people that were interested in looking at it and at that point no one had.

So I was hoping to have gotten a bit more information from people at that point and I hadn't, but there is a site up, jquerymobile.com, and I suspect that over time more of us will be looking at it.

I was actually working on, I was involved in iPad development a couple months ago and using the Titanium framework, which allows you to use your JavaScript skills and build mobile apps both for iPad and iPhone and Android and I think Blackberry is coming soon, I believe you'd probably be able to implement this jQuery Mobile, or integrate jQuery Mobile into that environment but it's too early for me to tell, I haven't actually had a chance to play with it yet.

Manuel Lemos: Yeah, but tell me one thing, when you say jQuery Mobile it's still web based, right?

Michael Kimsal: Yeah, yeah, it's still a web framework but my impression here is there are two things going on, one, that some of the widgets that are provided are optimized for smaller screens and more common mobile UI idioms or UI concepts, ideas.

And also there are a lot of things in if you think about a lot of, what's the word I'm looking for, a lot of CSS, a lot of JavaScript have things for the concept of hover, there's a lot of CSS hover stuff where you're hovering over something and something happens or context click, a lot of toolkits have given you ways of capture the context click on a mouse and then we'll do a menu.

Well, if you have a touchscreen you don't have the concept of a right click or a left click or context click or hover for that matter, so this whole notion of how best to do mobile UI's is really still up for grabs.

As polished as the iPad is and some other products that are coming out we're really just in the early stages still.

Manuel Lemos: But it's different from Titanium and Appcelerator that actually generate native applications, right?

Michael Kimsal: Yeah, yeah, from what I can see on this, this is more something that you would write your app and the jQuery Mobile would be a library that you would use in your mobile app to provide it with the common and the standard sort of UI and some touch enabled features but still have the JQuery that we all know and love at our fingertips literally.

Manuel Lemos: Yes, so that sounds interesting and personally I feel quite happy that the world of web development is moving towards that direction because more and more people are using more user friendly mobile phones, not just iPhones, the latest breed of Android phones is also awesome, and not to mention Blackberry and the latest Nokias, and I think it's quite promising.

NodeCasts.org - Node.js Screencasts (20:54)

Manuel Lemos: But, moving on with another topic that you also mentioned to me previously about a new site for screencasts about Node.js.

Michael Kimsal: Oh, yeah, this was something that was announced, I saw it initially I think on HackerNews 10 days ago or 12 days ago, maybe around that time, and David Calhoun, our new news editor at JsMag, put it in our news roundup last week at jsmag.com/blog, you get how I just slipped that in there.

But there's a series of screencasts about how to use node.js and how to get started, what is it, how do I use it, and those are available at nodecasts.org.

So, I had downloaded one, I think I got it on my iPhone and I was trying to watch it while I was doing my, what do you call it, well, what do I call it, I call it a workout, most people would call it just hardly breaking a sweat, but I found it a little hard to watch one of these while I'm on my gazelle doing my hands going back and forth, but I will find time to watch more of those. 

Manuel Lemos: Right.  I think it's great, a good idea, because we covered Node.js in the previous podcast, and Node.js while it looks to be, seems to be a promising technology, for those people that are used to traditional programming, web programming using server side languages, it uses a different paradigm, asynchronous programming, which makes it very efficient for certain types of applications.

But it completely changes the way you think in terms of the work flow of your code for applications because it's all based in call backs and any events that actually trigger those call backs invocation asynchronously and you have to rethink the way you do your programming.

So these screencasts are quite welcome and I was not aware about that site but I'm looking forward to taking a closer look later when I have more time.

Michael Kimsal: Yeah, I think in the last episode you were kind of big into Node, I think being a proponent of it I should say, and I think, I have to say I think part of the reason that it gets as much attention as it does is the name.

And that sounds really corny and people might say that I just don't know what I'm talking about, but it's a very short name, it's very easy to say, and they got in early with a short, easy-to-remember name that... and it's not just the name, it does what it says it does, but I think very early on it's a simple name, it's a simple concept, and they've been able to get a bit of play just around that.

And I feel like I'm trivializing all the efforts going on at server side JavaScript, I'm not meaning to. Helma, I love you guys, but Helma just sounds like a bit of a weird name relative to something like Node.

So it's got JS in the name, you can tell exactly this is a JavaScript sort of thing, you go to their site and its got some basic documentation you just need a code and say this is what this is about. 

But I'd have to agree with you, and we probably talked about this before a bit, the whole idea of asynchronous programming for better or for worse I think this is where a lot of new development is going.

It probably, I don't know enough about the underlying architecture, but the idea of asynchronous stuff, asynchronous development, might be something that scales better across multiple cores, somebody that actually knows something about computer engineering or hardware engineering might... if we were on a live show right now and somebody was paying attention they would call up and tell me I'm an idiot, but I think as we get into multiple CPU's, multiple cores and distributed stuff, I think the change in how we think about development like, well, these are just asynchronous call backs, okay, at some point maybe that has to be in the same CPU space right now, maybe that can be distributed later.

I might be thinking too much about Erlang, but I did some Erlang a couple summers ago and this whole idea of everything is just its own little tiny process and they can be scattered across multiple CPUs at the same time is when you start to really think about that and then you go back to, oh, say PHP for example, it's like having cold water thrown on you.

Manuel Lemos: Well, actually, Node is a way to fork processes. You do not necessarily have to be restricted to a single process that triggers all the events, for instance, you can accept a server connection and pass it to a process that will handle it and there will be a main process just like with an Apache server.

And what's good about Node it not only replaces the server side language that you would traditionally use, could be PHP, Java, Python, Ruby or something else, but you can actually replace the whole web server if you have all the features of protocol implemented there.

Michael Kimsal: I'm actually looking at the Node site right now, and it says, "What about multiprocessor concurrency?  Aren't threads necessary to scale programs to multi-core computers?"  And they say, blah, blah, blah, blah, blah, "In future versions Node will be able to fork new processes which fits well into the current design."

So, it looks like they're definitely looking at the problem or the opportunities with large-scale scalability right now, they're taking that into account right now.

So it will really be interesting to see, A) how that pans out over the next six months to a year, how to me it will be interesting to see how, if all, it has any impact on some of the day-to-day work that I do, because right now it doesn't yet but I'm staying away from server side JavaScript for production work that I do; I don't have the time to experiment yet but maybe next spring I will.

Manuel Lemos: Yeah, well, I might be mistaken but I thought I have seen some calls to actually fork processes, and I wonder what those complaints mean. Maybe they want better control to which core of the available CPUs forked processes will go.

Anyway, I mentioned before that article that I wrote in the PHPClasses site blog about accelerating the page load using a technique of delayed load of slow content, it's part of a series of articles that I'm writing called Unusual Techniques to Speedup Your Web Development Environment, sorry, I did not mean web development, I mean your actual web production environment.

And one of the articles which will be precisely focused on asynchronous programming, but since it will be published in PHPClasses blog I'll focus on the resources of the function calls that PHP provides to do some asynchronized programming.

Unfortunately in the current version of PHP it's something that is not so well structured as in Node.js because there are only a few calls that you can perform some asynchronous programming namely to access files and network connections.

But, for instance, in Node.js there are already modules to access databases and perform queries and establish connections asynchronously, and that is great because sometimes you access a page that is written to perform some database queries and what takes most of the time is the actual query that is being executed on the server.

So the client which will be the server side code will have to wait sometimes for a few seconds, and during those seconds it could actually do something in parallel and make the outcome of the web script access be returned sooner because it could parallelize several tasks in such a way that the result will come in parallel much faster than if you have to perform a database query and wait, another database query and wait, which would be the serialized way of accessing databases that we are most used to nowadays.

So I'll be writing that article for focusing the current asynchronous programming support in PHP for the PHP Classes site blog, but I will give the examples of the possibilities of Node.js as something that I think that PHP should evolve in future versions of the language because I think the Node.js example is quite a good thing to follow.

Michael Kimsal: We can hope.  We can hope.

Manuel Lemos: Yeah.  But moving on to...

Michael Kimsal: NodePHP, that's the name, Node.js is JavaScript, you could have Node PHP and I'm throwing the challenge out there, if somebody does that and actually builds a... I know we've seen PHP servers, some web servers, but if somebody built something that is equivalent to Node but does it all of PHP I'll PayPal you a hundred dollars, how's that?

Manuel Lemos: Well, if you go to the PHP internal list and suggest that everybody will say no, that's a bad idea, which is a common reaction when somebody comes with such a....

Michael Kimsal: It probably is a bad idea, but I'd like to see it anyway because sometimes bad ideas evolve into good ideas.

Manuel Lemos: Usually good ideas when they are presented for the first time they always turn out to be bad ideas according to the people that are in the core of developers that push most of the new features to the language, so they usually will say, oh, write some code and then talk about that to us later.

So, I think it can be accepted if you have something proven to show.  I think Node.js is already a proven solution to show, and I think you just need to show it as a good thing in the scope of web programming in general.

Latest objects published in the JSClasses site (33:09)

Okay, but moving on with our podcast, as usual we have a segment towards the end of the podcast in which I try to cover the latest components that have been published in the JSClasses site.

Personally I'm quite happy that the site is growing a lot despite it's just two months old. So far about 25 components have been approved. And it seems quite promising, but we don't have the time to cover all the components that were published. I just would like to cover a few and, Michael, if you lately you have noticed other interesting components besides what I mentioned you can fee free to...

Michael Kimsal: I was looking at the one that you ended up mentioning, I'll just mention it here first, XBSDB, a cross browser JavaScript database library.  And I think last time we talked I had picked out another component that had to do with database type access or doing I think it was managing SQLite stuff, yeah.

And it's interesting to me that other people are trying to tackle this problem; it seems a problem that is going to never quite go away, people want ways to deal with client side storage whether that's I'm going to do SQLite, I'm going to use a full database or something more like this which is emulating a database and gives you some SQLite functionality but it's not requiring a full engine.  It just seems like we're going to keep seeing these and I think that's a good thing.

Manuel Lemos: Actually this is the full engine for accessing a sort of database using a SQL language, but let me just give you the full scope, this object was written Alexey Znaev, I'm not sure if I'm pronouncing his name right because he's from Russia.

And basically what he has developed is quite an extensive package that builds JavaScript arrays as a storage format for storing all sorts of information. And on top of that he wrote a SQL parser that you do all the basic queries, select and insert, update and actually also create and drop table to manipulate these entries of information that will be stored in a database.

And personally I think it's great because everybody's used to work with SQL being MySQL, PostgreSQL, SQLite, Oracle, etcetera, and providing an API to actually perform these queries but manipulating the data on the browser side, as you mentioned, it's a great way to provide an API that could even evolve into something more abstract like ORM, Object Relation Mapping, to make your client side programming even more productive.

And I think it's interesting because besides what I mentioned this is already showing the maturity of the developers that are working hard on the client side because in the beginning we would see the developers that were working on the client side were often I would say sort of ex-web designers, they were not really programmers.

But I think the reality has totally changed. Now we see certainly very skilled developers that provide sophisticated implementations to perform many types of tasks that are useful for browser side programming I would say.

Michael Kimsal: I think there's another reason for that, well, probably multiple reasons, but another factor in I think seeing more client side JavaScript tackling harder problems is that a lot of the easier ones have been dealt with.

Ten years ago if you wanted to do any sort of just to think of animation of any sort, I want to move this box around on the screen, I want to move this image around on the screen or make it bigger or smaller, that was a big task.

And over certainly in the past five years, and jQuery wasn't really the first but I think it was the catalyst that started a lot of people's re-interest in, "hey, we can abstract this, it runs on multiple browsers, and we can make a lot of this stuff reusable and simpler", so a lot of the design oriented things, a lot of the things that we take for granted now, let's do some fade, let's do some sliding stuff around, that's pretty easy to do.

And we have a choice, you can use JQuery, Dojo, YUI, EXT, MooTools, Raphael, we have different tools for these.  And the sorts of tools that people are... like this example of the XDSDB tackling, we don't have, the major libraries have not come up with standard ways of dealing with this yet to everybody's satisfaction.

Yeah, there's client side SQLite already, some of these things have been solved, but I don't think there are defaults that everybody has accepted to tackle these problems yet.  So, it's interesting to see where bright young minds are focusing their efforts.

Manuel Lemos: Yeah, and this solution in particular is useful because its cross browser, you don't have to rely on a certain version of the browser to support HTML5 or whatever is the storage API that the browser supports.

And eventually you can use... because it can generate adjacent strings, you can store them in cookies if browser side local storage is not available on the browser, so I think this is quite exciting because the solutions for browser side development are maturing a lot.

Michael Kimsal: Yep, agreed.

Manuel Lemos: Yes, and this goes along the lines about the next component I would like to mention, it was published on JSClasses site, which I'm not sure where this name comes from, it's Crossley Mancunian.

And this name does not tell anything about what the component does, but let me just give you an overview.  What it does it actually uses jQuery, it's a sort of plugin for jQuery that using a div that you would define somewhere in your page it can load the content on that page using AJAX requests, and after the content is loaded it changes links, and I suppose also forms, the URL's of links and forms, it changes in such a way that when you click on those links instead of redirecting the browser to the link URL it issues a new AJAX request so the content is loaded again inside the div.

So I see this as sort of an emulation of iframe except that it does not use an iframe. I try to avoid using iframe in pages because it makes them quite heavy, but at least it's my perception that a page becomes heavy when you for instance use crawl page as an iframe in it, it seems that the iframe area does not scroll at the same time, the browser is sort of refreshing it not on the same page as the rest of the page.

So this solution seen as an alternative to implement divs, sorry, iframes, it seems quite clever, and using AJAX requests to load remote content makes the user experience quite smooth and I think it's a very good solution.  What do you think Mike?

Michael Kimsal: I'm checking it out right now trying to check out the code and see if I can run it.  Now I have to go into here and say local host.

Manuel Lemos: While you check it let me just comment on another thing, in the other podcast you suggested to have a category to include jQuery plugins and other frameworks that probably deserve a category for their own, and I actually did this, and it's interesting that there are already several components that I think you can see them as jQuery plugins that were already made available.

There is another component that uses jQuery to submit forms using AJAX requests, it's a very simple component but it may be useful for people that are using jQuery.

And I also created other categories for other frameworks or environments like Node.js and Adobe Air. We don't have many components yet but I think in the future we'll see more and more interesting components in these categories.

Michael Kimsal: Hmm, well, I'm looking at the xLoader function, strange, because the view source doesn't quite look like what I'm seeing on the screen.  I guess I'm not quite, I thought I was understanding what this does, it wasn't what I thought it was, based on the description it's not doing what I thought it was, but I've just taken a quick moment at it.

I was thinking that it was when you were saying that it uses... oh, oh, oh, oh, I see, load it in the new window, okay, that's where there is it looks like a div of some sort that comes up and it's pulling in content from a different URL.

I was thinking that this might be able to be used as a previewing tool, so rather than going to the URL entirely it could show you a preview of it, I guess you probably could, that's maybe a use of it but I don't think that's the intended use of it which is where my thought initially went.  Anyway, trying to do live programming or live demo running on the Web and it's not doing what I'm thinking.

Manuel Lemos: Well, it basically does that that I described. It just sort of emulates an iframe without actually using one.

Michael Kimsal: I see that.  I see that now, but the purpose of what I thought was going to go, the data I thought was going to go in there is not what I was expecting to see but I get it.

Manuel Lemos: And I think that this component also shows the evolution in terms of maturity of not just the JSClasses site that just started, but also the evolution of the complexity of what JavaScript components are doing nowadays, some relying on existing libraries like jQuery, others doing on their own, and this is quite interesting and I think in the future you can expect more promising components that do even more complex and useful tasks.

Michael Kimsal: Yeah.

Manuel Lemos: Well, before moving to the next section of this podcast, I just would like to make a comment, not specifically on anymore classes besides those that we already mentioned, but actually about an author that has been submitting a number of packages to the JSClasses site that is above the average.

His name is Rafael Lúcio. He has submitted so far 6 objects, some very useful. We do not have time to comment on all of them but I would like to comment and actually thank to Rafael for his contributions because the number of packages that he has submitted so far also helps encouraging other authors to submit more packages useful to everybody.

Next JSMag magazine articles (47:56)

Manuel Lemos: Well, moving on with our podcast now towards the end, Michael, I think you had a few articles to comment on the latest issue of JsMag.

Michael Kimsal: Well, I would actually prefer to talk about what's coming up in November, we've just got a couple weeks until the next issue's out, and we've got a continuing series on server side JavaScript development with Helma, not Node, with helma.

Mike Schwartz is, he's got the fourth element in that series, and what he's done in some of the ones in the past is setting up server, setting up your development environment, and so on, and now he's getting into this installment is going to be a lot more of the actual programming of the JavaScript language itself, so those of you that have been waiting for it to get to that in more detail it's getting there.

We've got another series, actually this will be the second installment in the series, Jason Gilmore, I mentioned him last month, he's continuing his series on mapping and how to integrate mapping tools and techniques with JavaScript into your client side apps.

Looking here, he's got a kind of interesting one, and I read a bit of the brief but I haven't read the whole thing yet, on alternatives to block conditionals and loops in JavaScript.  Certainly it's very easy to read but apparently there are some performance considerations where if you rewrite your code and rethink how you write your code you can get somewhat better performance, it avoids some of those more traditional old school approaches.

I'm not sure I'm ever going to get rid of loops in my JavaScript, I'm not sure I'm ever going to get rid of conditional checks or block conditionals, but interesting little mind trick there I think that might be of interest to some people.

Manuel Lemos: Yeah, well, those articles that you mentioned are for the upcoming issue of November, right?

Michael Kimsal: Yep.

High Performance JavaScript book review (49:56)

Manuel Lemos: And another interesting thing that I would also like to comment on now towards the end of our podcast, but I could not avoid commenting on this because despite it was already a few weeks ago I published a review on a book that goes precisely to address something that you just mentioned about rewriting your code to make it faster, your JavaScript code, which is a book that I reviewed named High Performance JavaScript with a subtitle Build Faster Web Application Interfaces.

And one of the chapters precisely covers that topic of rewriting your code, your loops, your conditions to actually achieve code that will work faster, and that is just one of many chapters that this book covers.

And one conclusion that I came to about this book is that, well, there are many details that you can sort of concentrate your efforts to improve the performance of applications that need to be made faster to make more user friendly interfaces with JavaScript, and basically this book covers almost all aspects that you may want to know, and there are many chapters that focus on aspects that I would not expect that would be worth investing on focusing your efforts of optimization.

But all this to say this is quite a good book for those that are concerned about optimizing your JavaScript, your web pages, in order to run faster code or at least code that results in faster user interfaces and better user experience.

Michael Kimsal: This is from Nicholas Zackas, I hope I'm saying his name right and it's probably from O'Reilly if I'm remembering the book correctly.  Interesting to me that I guess in some ways that it took this long, but it also does show yet one more element of JavaScript maturing in terms of people taking it seriously because there have been a number of books over the years about high performance websites and how to optimize your site and make it faster, and so many of them have focused on HTTP caching and focused on reducing your images and CSS Sprites and content delivery networks and all that sort of stuff.

But we haven't seen much on making your JavaScript code faster directly. We focused on all the other stuff and that's important, but it's actually surprising to me that it took until 2010 for their to be a book published specifically about things like how to reorganize your code and how to rethink your programming to make it faster too.

Manuel Lemos: I think that's sort of a result of the fact that maybe only now you actually see big names investing hard on optimizing the browser experience, and also related to that I would like to mention, then later I will publish a link to a video of I think it's Steve Sounders of Google in the Google I/O event of I think it's 2009.

And it focused precisely on this topic of making your web faster.  And it is amazing the level of detail of optimization that Google is doing precisely on Chrome and the V8 engine in order to make the execution of the resulting code even faster, even if it's just a few milliseconds because at the end all added it completely changes the user experience, and not only are they very mature and experienced.

They seem to be obsessed with this aspect of making the user experience even faster, and it's another aspect that makes me quite excited with the future of the Web and JavaScript and whatever are the applications that you can develop using these technologies.

Michael Kimsal: Oh, it will keep getting better, sometimes just little baby steps, little minor versions, browser versions, little minor whatever, and then we'll see a breakthrough now and then.

I think we'll probably start seeing this same sort, I think Google's doing this some, and I think not just them, we're starting to see as you mentioned this focus on really optimizing the JavaScript engines.

I'm wondering to what extent that they're focusing on runtime changing of code, we see that with the JVM, Hotspot was a big deal ten years ago, let's re-optimize the byte code as the code is executing.

As we get into browsers running for longer times where if I'm like in Gmail if I have that open for a few hours is there something that is going to be able to re-optimize the JavaScript running in my browser in that tab to respond to how I'm using the application.

Now, I'm not enough of a under the hood guy to know if that's happening right now already, I suspect that it's not or it's not happening terribly well yet, and I think that's probably the next area for a lot of optimization to happen.

Manuel Lemos: Well, regarding Chrome that's what I'm telling you, it's actually happening right now because they are sort of so obsessed with performance optimization, not only it uses the V8 engine which is basically a compiler that compiles JavaScript into native code, they are optimizing it I suppose everyday because the level of optimization that they are reaching now it's quite amazing.

And it's not just Chrome, I think all this discussion of pushing towards HTML 5 sort of awakened Microsoft that besides HTML 5 and everything that comes with it and faster JavaScript engine, they sort of were pushed to give the next step ahead which use as much as possible harder acceleration for all sort of tasks where harder could be used as graphic rendering and such, and all of a sudden they claim they have the fastest browser to render complex graphics on browsers.

And then Google tries to catch up with Chrome 7 which by now is still Beta or Alpha or whatever they are calling it, unstable I think, and they are trying to do that and probably do something else that you get even faster.

And in the end this competition is quite beneficial for anybody that works and uses the Web.

Michael Kimsal: Yep, as I was saying, we see little increments and we see big increments every so often, the one thing that really doesn't surprise me too much is when something surprising comes out because I just think it was going to happen, maybe I'm just too blasé about it, but there's going to be another breakthrough whether its hardware, software, something is going to make the next round of the JavaScript experience better, but I just don't know when that is because I'm an outsider.

Manuel Lemos: Yeah.  Well, just for a minute you watch that video, which it's no longer from 2010, it's 2009 I think, and from Google I/O, and I'm sure you'll be impressed as I was when I watched it.

Michael Kimsal: Yeah, I've seen some of Steve's stuff in the past, I saw him live about three years ago when he was at Yahoo, I don't think I've seen the one that you're talking about but he is, when you were saying before you were impressed with all the minutiae, he's one of those massive names in front-end engineering optimization. I think he was the guy behind YUI Slow or YSlow a few years ago, yeah, anything with his name on it you know it's going to be good.

Manuel Lemos:  Right.  Well, all this to say what I just said which is the future looks quite promising for everybody that is working and using the Web.

Conclusion (59:59)

Manuel Lemos: Well, I think we just reached the end of our podcast, and it was great, and anybody that is listening that would like to add any comments, posts, suggestions for upcoming shows, feel free to post a comment on the comment section of the podcast page here in the JS Classes site.  I think that's all for now.

Michael Kimsal: Yeah, well, Manuel thank you very much again for organizing this and I will talk to you soon.  Thanks everybody, bye.