Web Developers Need More Usable Browsers - Lately in JavaScript podcast episode 21 - JS Classes blog

Contents

Listen or download the podcast, RSS feed

Watch the podcast video

Read the podcast transcript

Contents

Introduction (00:20)

Mozilla Shumway Flash VM Project (1:21)

jQuery 2.0 to drop support to Internet Explorer 6/7/8 (3:23)

JavaScript Usage Trends (7:10)

Resumable uploads with DNDUploader (14:00)

Chrome catching up on features for Web Developers (22:16)

Latest JavaScript Objects Published in the JSClasses site (36:46)

Upcoming articles in the JSMag magazine (45:06)

Conclusion (50:07)

Manuel Lemos: Hello! Welcome to the Lately in JavaScript podcast. This is episode 21. We're going to try once again to face the challenges of recording this podcast with Google Hangouts with Chrome.

Michael Kimsal: Did you say my face was challenging? Is that what you just said? Oh, sorry. Yeah.

Manuel Lemos: No, no. I was about to talk to you. Well, now that you mentioned it, hello, Michael.

Michael Kimsal: Hello!

Manuel Lemos: Actually, hello, Special K.

Michael Kimsal: Yeah.

Manuel Lemos: How are you doing?

[Guitar Playing]

Manuel Lemos: Oh, great, we have a live performance.

Michael Kimsal: Yes. There you go.

Manuel Lemos: Direct from Raleigh.

Michael Kimsal: Woohoo!

[Guitar Playing]

Michael Kimsal: OK, I'm done. For now.

Manuel Lemos: OK. Well, today we have a possibly very busy episode, so we are going to cover several topics very briefly because we want to pack them all in one hour of show. We'll try to not go out of the schedule.

Mozilla Shumway Flash VM Project (1:21)

Manuel Lemos: We are going to start talking about several JavaScript-related topics, starting about a project named the Shumway, I think.

Michael Kimsal: Shumway, yes.

Manuel Lemos: Shumway from Mozilla.

Michael Kimsal: I got jumped, I got roped into Shumway a while ago. This guy at work was trying to sell me on joining this pyramid. He said that if I get to the bottom, I could be at the top of the pyramid at some point. Oh, this is Mozilla Shumway. Totally different.

Manuel Lemos: Right. [Laughter] What were you thinking?

Well, anyway, this is basically a project which is a virtual machine for interpreting Flash movies or whatever are those called in the Flash domain.

I think Google had a similar project, right, for executing Flash movies in JavaScript? I don't know, I just do not remember the name, but it seemed to be.

Michael Kimsal: That was so long ago. Quit living in the past, man. Shumway is where it's at, because it's got a better name. And it works. I tried it. For me it worked.

Manuel Lemos: Well, what did you try? Anything worth mentioning?

Michael Kimsal: Well, they had a race car demo. They had a demo of a race car as a Flash game where you drove a car around. I'm doing this thing with my hands. I don't know. Am I being recorded if it's on you?

Manuel Lemos: Yeah.

Michael Kimsal: Oh, OK. Hello. It was a car that raced around and you could move with your keys. I'm thinking it was a regular SWF file that was just being interpreted by Shumway.

Manuel Lemos: Yeah. Well, I don't know, it seemed to be interesting. I don't know what is the future of that project, but I think it's yet another nail in the Flash coffin. It's one of those many JavaScript developers are working for so we can get rid of any Flash dependencies. Well, there's not much to say about that.

jQuery 2.0 to drop support to Internet Explorer 6/7/8 (3:23)

Manuel Lemos: We're going to move on to the next topic, this time about an announcement made by the jQuery developers.

Michael Kimsal: I've got the music for the announcement. OK, I got it. Ta-ta-da-dah! I didn't know what notes to play for that, so we'll just do that. That's ta-ta-da-dah! Pretend I was a trumpet. And blow me. Oh, sorry, that was...you're going to have to put an X rating on this now.

Manuel Lemos: OK. You convinced me. I almost believed it was a real trumpet.

Michael Kimsal: OK. [Trumpet Imitation]

Manuel Lemos: Anyway, talking more seriously about this topic, it was basically the announcement of the plans for future versions of jQuery. Basically, there will be, I don't know if I can call it two forks, 1.9 and 2.x versions.

Basically what distinguishes these versions is the support for older Internet Explorer versions. So basically for 2.x they intend to drop the support for Internet Explorer 6, 7 and 8, and the 1.9 version will have, as I would say, support to those Internet Explorer versions, but it will still be compatible.

So in the end it will be up to the developer to decide which versions of the jQuery do you want to use, depending on whether you want to support older IE versions or not. So I think this is an interesting approach, although it raised a lot of discussions on whether jQuery is dropping Internet Explorer support or not.

Michael Kimsal: Well, they are. They're dropping some IE support in it.

Manuel Lemos: I don't believe it was clear. They even had an article, a follow-up article to clarify this topic, but...

Michael Kimsal: Yeah. Microsoft themselves have urged people to not use the older browsers and to get people to upgrade. Yes, they are offering support for it, but I think they're doing it somewhat under duress.

They would like people to move on to modern browsers to let them integrate, because you say 'IE' and some people will still think it's IE6 or IE7 maybe.

Development now, from my viewpoint, if you have a choice, you should be targeting IE8 or 9 and going forward. And I realize some people don't have a choice, they work in corporate environments. Well, then, they're only going to get one more good release of jQuery, which has been given to them for free, and it's only going to work for the next few years for them.

Manuel Lemos: Yeah.

Michael Kimsal: They've got to do it at some point and I'm glad that they've announced it, yeah.

Manuel Lemos: Well, it's up to you.

Michael Kimsal: They could go keep using Netscape 4 if they want as well.

Manuel Lemos: Well, I don't know if jQuery would work well at all in that browser version, but I think this is a reasonable decision in my opinion.

Michael Kimsal: Yeah.

Manuel Lemos: If you want to still support those older browsers, that's fine. And the advantage of this newer jQuery 2 releases is that it will be smaller because it won't include the code to support those older browsers.

I think it's wise because jQuery is getting reasonably large and they do not take care of packing on the size, they probably get too bloated library that nobody wants to use. So it seems to be the right thing to do. At least in my opinion, of course.

Michael Kimsal: I don't disagree with you. I wish I did, but I don't.

Manuel Lemos: OK. Actually it's good that you don't disagree because we don't have much time. We still have a lot of topics to cover.

Michael Kimsal: We'll just move on. Move on. There you go.

JavaScript Usage Trends (7:10)

Manuel Lemos: The next topic to just briefly mention, there is this page with trends on JavaScript usage in terms of what library versions are being used in different browsers. Actually, I'm not sure if there is a partition by browser, but... Sorry, I misunderstood this. This is jQuery usage by sites, not by browsers.

Michael Kimsal: Ah, OK.

Manuel Lemos: Basically you can see that jQuery is largely dominant and appears in many, many sites. Actually, I was joking with a friend that now there are less and less JavaScript developers, there are more jQuery developers.

Michael Kimsal: Yeah.

Manuel Lemos: Many people just are finding it hard to develop without jQuery because it solves a lot of, I would say, portability issues. You don't have to deal with all the conditional code that would be necessary to support different browsers. And this is very interesting, going back to the previous topic.

Michael Kimsal: A slight rant here. Yeah. Oh, go ahead. No, go ahead. Carry on.

Manuel Lemos: No, I just wanted to comment that now that jQuery is about to give people the choice to drop the older browsers and a lot of people have chosen jQuery to not have to deal with, I would say, the portability issues, it is interesting that this news of dropping the older versions is coming now.

But, anyway, the jQuery people made clear that they want to give developers this choice to support older browsers, keeping with the older version, or dropping the older versions of the browsers by using the newer jQuery 2.x that I wanted to mention.

Anyway, you were talking about something of a rant?

Michael Kimsal: Just briefly related, when you mentioned people are not JavaScript developers, they're jQuery developers. I used to get...'upset' is too strong a word. I thought it was a problem.

I don't think it's that much of a problem. I think it's that people want to make it a problem, but we have similar, especially in the PHP world, we have people who are WordPress developers, they're not PHP developers, we have people who are Drupal developers or Joomla developers, not PHP.

We have this largely in JavaScript with jQuery. People know jQuery; they don't necessarily know all the underlying stuff. The only problem comes is when they try to take that experience and do other stuff outside of jQuery.

Frankly, when I meet people who are really deep into jQuery, some of them are because they know JavaScript very well. But I do come across people that are just very talented developers who happen to focus on jQuery, and that's what they're best in.

Similar, I know some people who are just WordPress people and they're fantastic...I mean, I'm a much better PHP developer than they are, they're better WordPress developers, and it is a separate beast.

Manuel Lemos: Yeah.

Michael Kimsal: So I think the market, Web technology is such a large and influential market where it's being used everywhere these days that the idea of having specialists, or people that only know certain things, I really don't think it's that bad.

Manuel Lemos: Yeah.

Michael Kimsal: Again, I used to think it was a bigger problem, the craft was in crisis and all that. I think there's plenty of room for people that want to be the true masters of underlying technology versus just a particular tool set.

There's a lot of Ruby people who are not Ruby developers, they're just Rails developers. We need to get over this. That's just my rant.

Manuel Lemos: Yeah. Well, I think this is a natural consequence of the fact that there are so many technologies derived from the dominant technologies that you would need to know to be a developer who can handle everything, but it is hard. You would need to specialize on something...

Michael Kimsal: Yup.

Manuel Lemos: ...and embrace that area. That's why you see WordPress developers rather than PHP developers.

Michael Kimsal: In some ways that's where the money is, too.

Manuel Lemos: Right.

Michael Kimsal: People, when they put an ad job out, they don't say, 'We want a JavaScript person.' They say, 'We want a jQuery person,' because they've got two years' worth of jQuery code and they need somebody to come in and maintain it and extend it. That's what they need.

Manuel Lemos: Yeah, exactly. It is interesting, the one thing that I notice in the job postings, well, I didn't have many job postings in JS Classes, but in PHP Classes, practically all jobs require something related with JavaScript.

Michael Kimsal: Yup.

Manuel Lemos: And we can see clearly that jQuery is one of the most requested capabilities from Web developers in general.

Michael Kimsal: Yeah.

Manuel Lemos: Also on the PHP side, WordPress is quite dominant, and this is probably a bit frustrating for all those fans of those frameworks that would hope that their framework preference would be preferred in the end, but the market is demanding for WordPress developers.

Michael Kimsal: Yup, yup.

Manuel Lemos: I don't know if you can even call WordPress a framework. Well, it's more a platform, maybe inside the platform, I would say.

Michael Kimsal: Yeah. In the right hands, there's a lot that can be done with it. Frankly, when I look under the hood, I still don't like a lot of what I see, but it's pragmatic, it puts food on people's table. Let them be.

Manuel Lemos: And it's what the market is asking.

Michael Kimsal: Yeah.

Manuel Lemos: And in the JavaScript world, I would say that jQuery is clearly dominant. Personally, I do not use it much. Actually, I don't program so much on the JavaScript side, but I can understand why jQuery is so dominant.

Michael Kimsal: Yeah.

Manuel Lemos: That's the way things go, and whoever prefers some other library, too bad, then. The last, which is a bit different than the...

Michael Kimsal: Well, really. You had it up on the screen. The pie chart has spoken. jQuery is it. The big red pie chart there showed it. We really don't even need to talk about it. The pie chart spoke. Move on. There you go. I didn't even need to speak.

Manuel Lemos: I imagine that you are happy because you said before that you have become such a jQuery fanboy lately.

Michael Kimsal: Well, 'fanboy' is a little strong of a term, but, yeah, I do partake in jQuery.

Manuel Lemos: Yeah, but you are not alone, I suppose.

Michael Kimsal: Well, I am. Well, actually, right here I am, I think.

Manuel Lemos: I mean in the world of developers that prefer jQuery library.

Michael Kimsal: Well, yeah.

Resumable uploads with DNDUploader (14:00)

Manuel Lemos: Well, but that is just one topic that we planned to cover. Michael, you also want to comment on an interesting library?

Michael Kimsal: If I may?

Manuel Lemos: I think it's a library, right?

Michael Kimsal: Yeah. Was this what you... You had resumable uploads. OK, let me see if I can share my screen. Screen Share. Can I do that?

Manuel Lemos: Yeah.

Michael Kimsal: I'm trying. I'm trying. We shall see.

Manuel Lemos: Sure. You showed the link to me before and I looked at it, and I think what could summarize that library is that it does something that's somewhat new, which is resumable uploads, right?

Michael Kimsal: Yup. So I'm sharing my screen. Are you seeing it here?

Manuel Lemos: Yeah, sure.

Michael Kimsal: 'Sharon'. Look at that. That's my aunt's name. Hello, Aunt Sharon, who just had a birthday a couple of weeks ago, same day as my mother. Seven years apart. Happy birthday, Mom, who's in Moscow. Hello. Matt, if you're watching, [Russian].

I found this a few weeks ago and I mentioned it on my other podcast. This is a resumable uploader and it's called dndUploader. You can see it here. I don't have any large files to demonstrate with this right now but you can also take a look at filad's dndUploader GitHub page.

The interesting thing here, that resumable aspect is that it uses the local file system access, so older browsers like your, your IE 6 and 7 I don't think would have access to it, but you drag your file in, and it uses HTML5 JavaScript access to the file system and it will read the file in and it will break it up into chunks and store those chunks in local storage.

So if you had, say, a 40-meg file you're uploading, it's going to chunk it up into multiple smaller chunks and upload each of those, and they're going to negotiate the upload of each one of those sequentially. But if you only upload, say, two-and-a-half of these things and then you close your browser or you lose your internet connection, you come back a day later, it can send up the rest of the files and you can process them on your server once you get all of them.

And the guy who wrote this had said, I had initially found some discussion on this on Reddit and then I've linked here to his page here, he said somewhere that he didn't think, he'd found another example of other people trying something similar, but they didn't work very well and he thinks his works pretty well.

I bumped into this a while ago and I thought, from a kind of a JavaScript and HTML 5 client side engineering thing, it's a nifty hat, if nothing else.

I don't know how many people need something like this on a regular basis. It may be, though, that it's not one file that's chunked up but you could use a similar technique to just queue up, say, you're uploading 30 files, just drag and drop, and then let it process in the background until you're completely done.

Anyway, I don't want to rant too much about it, but it was a really neat tool, I thought.

Manuel Lemos: Yeah. It seems interesting, but I did not quite understood how it would work if you got into the details. Does it rely on some standard browser features or is that?

Michael Kimsal: Yeah. It needs to have local storage support, which most browsers have some local storage support, and it needs access to the file object. I'm not sure what the actual technical term is.

There's a file object which can actually read, you give it a file name and it can read the data from that file and the file system into local memory, into JavaScript memory. It will then parse that out and chunk that up into various chunks in the local storage. So it's a neat approach.

Manuel Lemos: So it relies on having access to the file from JavaScript?

Michael Kimsal: Yeah. Well, if you're uploading a file from your drive, you have access to it, and modern browsers would also have access to the data client side before it's uploaded.

Manuel Lemos: Yeah. Well, I was just wondering because, for security reasons, JavaScript code never has access to the contents of the file itself. It can't access the meta data. So I was wondering.

Michael Kimsal: Yeah. It's had it for a while. Two years ago, I think, or a year and a half ago, I wrote something, well, I think we even talked about it on this podcast, but I wrote an image shrinker that, if you were uploading a large file, it would shrink it or resize it client side and then upload the thumbnail.

So rather than trying to upload a 6- or 7-meg file. Again, it doesn't work in the IE6s of the world, I don't think it would work on Firefox 3 or 3.5, but it works on modern Safari, WebKits, Chrome, modern Firefox, modern IE, I believe. IE9 it worked on, too. That one might require IE10.

Manuel Lemos: Yeah. So it probably uses the file API on the browser side?

Michael Kimsal: Yes.

Manuel Lemos: And on the server side, does it require any special treatment of those resumable uploads?

Michael Kimsal: Yeah. He had some sample code there. Effectively, you're just uploading multiple chunks of data, so something on the server needs to know to piece them together into one file. So you're going to need to stitch them together.

But, again, you've got those things to do, but if you're getting around this real problem of maybe bad internet connection, flaky internet connection, and to have something continuously trying to upload in the background, for you is probably a very useful tool in some cases.

Manuel Lemos: Yeah. Well, that's interesting, though, because I was thinking that it probably was playing with headers, request headers, to send the file and to tell the server side which chunks of out file it was sending.

Michael Kimsal: Yeah. That may be going on as well, but I would imagine that something still needs to intelligently grab and parse those headers and deal with it. Because if my connection drops for 20 minutes and I come back again, I have not used it. I haven't had any large enough files where I've even had a need for this right now, so I just thought it was a cool thing to share with people.

Manuel Lemos: Sure. That's quite interesting and innovative because I have not seen anything like that, and probably other people will find it interesting because the problem of dealing with very large file uploads is very old and I don't think the current breed of browsers is solving it very well.

Well, at least there are some solutions to show some progress bars, but I don't know what happens if for some reason my file upload stops in the middle.

Michael Kimsal: Two minor points here. One, because I did a mobile file upload project back in April, just using mobile Android and having it take a picture and then upload that.

A picture that the camera takes is only a few megabytes, but especially over, maybe if your connection goes in and out, being able to do this in modern mobile browsers, I don't know if it works, but if it doesn't, I'm assuming it probably will at some point. It seems to work on modern browsers and WebKits would probably be fine.

Second thing is, this might be a bigger issue at some point, in the Fall, iOS 6 for mobile devices will allow file upload in the browsers, in Safari. Finally. It only took them four years to get this thing out.

But I think we'll probably see more file upload processing happening from mobile devices, and because of the intermittent connectivity of that or the potential for that to be on and off, even if you're switching cell towers, something like this will probably be more required in the next year or two.

Manuel Lemos: Well, actually, more in the past than currently, because in the past you would have even weaker internet links. Now, at least in some parts of the world, there are already 4G connections.

Michael Kimsal: Yeah.

Manuel Lemos: Not here where I live, definitely, but at least now there are better links.

Anyway, this is an interesting topic. Maybe we can get back to this in the future because I'm sure it addresses the needs of many developers.

Michael Kimsal: Yeah.

Chrome catching up on features for Web Developers (22:16)

Manuel Lemos: OK, we're going to move on with the next section of this podcast, now mentioning an article that I wrote just recently. It's basically about matters related to the browsers, evolution of the browsers.

Michael Kimsal: I don't think we can talk about evolution on this podcast, can we?

Manuel Lemos: Well, at least of the browsers I think we can talk a bit about...

Michael Kimsal: That's totally... Just a theory. Go ahead.

Manuel Lemos: Anyway, the idea of the article was more to talk about the features of the browsers that have been evolving on matters that interest developers.

The article basically is a follow-up to another article that I wrote last year, which was about the top 10 features, I mean, my own top reasons why Firefox is still better than Chrome for web development despite, as I mentioned also in another article two years ago, I have switched to Chrome because I could not stand the fact that...

Michael Kimsal: That was an 'F' for Firefox. That was an 'F'.

Manuel Lemos: ...Firefox was sort of at least and Chrome was much better in terms of performance, so I have decided to switch. And this seemed to be the general feeling, at least in my opinion of other developers. They have been switching to Chrome. And not just developers; users in general.

The article shows the evolution of the browsers, at least in the latest months on which the Chrome for the generality of the users have been growing a lot and even finally beating Internet Explorer. I think it was on May or early June. Anyway, the article is more about the usage of the browsers for web developers.

In terms of market share for web developers, the article shows some statistics based on the usage of browsers by developers that visit them at the PHP Classes site. This article is published on the PHP Classes site because it is a follow-up to two other articles I published that's a lot related to JavaScript. It was published there.

And the figures it shows are based on statistics of that site, and they show that basically Firefox and, I don't know if it is very clear or not, actually, probably it is not even any clear at all because the image seems to have a blank.

Michael Kimsal: It looks clear on this end. It came through.

Manuel Lemos: Yeah. For a moment I lost your voice.

Michael Kimsal: I wasn't saying anything.

Manuel Lemos: Yeah.

Michael Kimsal: I. Was. Not. OK.

Manuel Lemos: OK. Anyway, now I'll get back to showing the actual page of the article. I don't know if it is clear enough for everybody to read, but those that cannot read it can see the actual numbers on the page.

Basically, the article shows that Firefox is still the preference of the majority of the developers, despite it has lost almost 10% for Chrome in the last year.

The article basically mentioned reasons why Firefox is still better for web developers. It mentioned several reasons that I have covered in last year's article, but this year I had the opportunity to talk with a Google, Renato Mangini from Google Chrome Developer Relations team that I met in an event that Google held recently here in Brazil.

The event was not about web development, but it was interesting because he covered several interesting features of Chrome that are, I would say, available, and some of them overcome some of the complaints that I presented in last year's article.

But what I still wanted to comment on this article is that some features are still not addressed very well and the other features were addressed with some enhancements that are somewhat, I would say, hidden or maybe provided in some obscure way, like buttons that are available and buried in Preferences pages that, even if you are a developer, somebody has to tell you that the feature is there and you won't be able to know.

For instance, now there is the possibility in the Chrome browser to switch the user agent identification, so you can pretend to be accessing from a different browser to test your server side application.

This is just one of the several of the issues that I mentioned. And in the latest Chrome versions, it is possible to switch the user agent name to something else that you want to emulate, but if Renato did not tell me that feature was there, I wouldn't know.

Michael, did you read the article? What did you think about the issues and the comments that were presented?

Michael Kimsal: Well, you actually gave, you had sent me something a little bit before that about, that you were, I think, going to be talking to him. Is that right? Whoever, Renato, I think?

Manuel Lemos: Yes. Actually, just to clarify, I met Renato in the event and I told him about this article, the top 10 reasons, the article of the past year, and he wanted to know what I was raising as issues.

Later, after the event, I sent him the article link and right away he commented on those topics. Those comments that he sent are in italics in the article.

Michael Kimsal: Yeah. Chrome is taking off for a number of reasons. It's fast. It has a strong compatibility with Safari, if you write something for Safari, it's going to look good there. Mobile Chrome on Android.

There's a lot of reasons why Chrome is taking off that aren't necessarily to do with it being better for developers or not, in an abstract sense, but if it helps you make a better Android app or it helps you with making sure your stuff works in WebKit and looks good on Safari, you're going to use that regardless.

I was not overly impressed with some of the stuff, but Chrome isn't doing this very good, I don't think any browser makers are doing this very good, the idea of preferences and just...

Man, I'm looking at Firefox right now, the Nightly at Firefox, which is, I'm several versions in the future, and when I go to Preferences, I get eight icons. It is just confusing as heck and everything is equal.

Manuel Lemos: Yeah.

Michael Kimsal: This idea is, this thing is, what you said, you can't turn off JavaScript, oh, well you can go in here and go in here and do this, and users can do this. My goodness, there's a few major things that everybody in the world, well, for developers, many of us care, JavaScript or not, to me, the biggest thing is cookies, and Chrome, from a user experience, still takes a very engineer's developer-centric viewpoint on cookies. Safari does.

Nobody has a good view on this at all, and until they make things that are really, really easily understandable in plain user English or Portuguese, whatever it may be, plain user language, I'm not going to be really impressed with this stuff.

Yeah, technically, they've got faster this and they've got that feature and all that, but you just caught me in a bad mood right now. I don't really care for any of the browsers. [Laughter]

Manuel Lemos: No, I perfectly agree with you. The usability of these browsers, even for developers, is getting a nightmare precisely because they have so many features and they are so buried somewhere deep in the user interface that each one is hard...

Michael Kimsal: Yeah. Standard things that I might want to do all the time are buried way, 'buried' is the wrong word, but they're given equal weight with everything else.

Manuel Lemos: Yeah.

Michael Kimsal: I have to somewhat know that cookies are in Privacy, because they didn't use to be there, and then they got moved under something called Privacy. I don't think of cookies as, oh, that's privacy, and that's scary, that's secure data. It's a cookie! It's just a key value pair.

Just make a button that says, 'Want to see your cookies? Press it,' and have a little thing on the side that's always floating that says, 'Here's your cookies and values. You want to delete them?' I think Ghostery or something, some ghost or some plug-ins that do some of this stuff.

But these sorts of things could be standard as part of what, because if people understand pretty quickly, 'Oh, the Home button is this, the Back button is this, the Reload button is this,' and if you had a browser maker that was man enough, to be sexist here, man enough to just say, 'We're going to introduce a couple of things to educate people so they actually understand what the hell is going on...'

Manuel Lemos: Oh, precisely.

Michael Kimsal: ...instead of, 'Let's bury it. Let's make it really hard to find. Let's make it confusing. Let's throw a bunch of technical terms,' and what do you end up with? You end up with the kind of legislation that we have in Europe that says, 'Oh, cookies! The word "cookies". Oh, my gosh, we're going to have to have laws. You can't do cookies. Can't do cookies.' It's insane.

Manuel Lemos: Yeah.

Michael Kimsal: So browser makers, I think you've all dropped the ball. You're about 10 years behind where you should be in terms of things that actually help people get stuff done. We're fighting you.

Manuel Lemos: Yeah.

Michael Kimsal: There you go. OK. You asked me what I thought.

Manuel Lemos: Yes. Let's start a movement to make browsers more usable, at least for developers. I cannot even imagine for regular users because it's probably even worse.

Michael Kimsal: Yeah.

Manuel Lemos: Well, I agree, and I think they are so much obsessed with the competition between browsers that they forget to make things usable. Well, despite this, there is the possibility to use extensions that bring back more usability, like putting some button to turn off JavaScript or turn on, depending on what you want to do, right in the button bar instead of below seven pages of Preferences. We need to realize where they are.

Michael Kimsal: Because we all know, regular users install plug-ins all the time for their browsers, especially ones that say, 'Hey, this thing isn't signed. Do you want to do it? Anyway, it's not signed. It could break your computer. Wait nine seconds and click Install. Are you really sure?'

Manuel Lemos: Well, I think regular users do not even read. They just go on the 'next > next > finish' protocol and they move on and hopefully nobody invades their computers and no security hazard happens. But sometimes that may happen.

Michael Kimsal: Well, you caught me in a bad mood. And I could rant for another three or four minutes, but we should probably move on because people don't want to hear my rants anymore.

Manuel Lemos: No, actually I totally agree with you, and that is basically my main concern about this.

This article is about browsers evolve, but there are now so many features that it seems that the browser developers do not know what is important for each type of audience. And if I tell them that it's not easy to find a button to turn off JavaScript, they say, 'No, there is in that page and that page.'

Well, for Chrome's credit, at least, I don't know if Firefox is anything similar, there is a search box in the Preferences page when you want to know where is JavaScript being enabled and disabled so we don't have to figure, oh, about 30 tabs that you have to go through.

But at least it's just a small pain reliever because we have still to find an option, but at least it cuts down a few aspects, if you already realize that the feature of searching for Preferences is there, because I'm sure many developers has experienced as developers usually are, probably they also have not figured that possibility.

I don't know, the last version that I tried for Firefox does not even have that possibility to search for settings.

Michael Kimsal: No. No, it doesn't.

Manuel Lemos: So it is yet another point that Firefox also has to catch up. It's not just Chrome.

Michael Kimsal: Yeah.

Manuel Lemos: Well, at least there are many extensions that make our lives better, and if it was not for articles like this and also the cooperation of Renato that fortunately I met in person and he was kind enough to share all those information details, and I wrote this article in the hope that, since it's helped me to make a better use of Chrome, hopefully it will help other developers to also make good use of the browser features and not get so much buried in user interface bureaucracy.

Well, that's also my rant, too.

Michael Kimsal: There you go.

Manuel Lemos: Anyway, I think I made clear my point the things in the article that usability of the actual browsers still has to improve now that they include more complex features and they will include even more in the future versions.

Michael Kimsal: Sure.

Manuel Lemos: Well, there will be a lot more to say about this article, but we don't have the time.

Latest JavaScript Objects Published in the JSClasses site (36:46)

Manuel Lemos: We need to move on to our next, one of the final sections of the podcast on which we comment on the latest classes, objects published on JS Classes site.

Michael, would you like to start?

Michael Kimsal: Well, there's a couple that jumped out at me.

One is recent, just a couple of days ago. This is l.js, which is a very short name for a loader. This is from John, can I say John Gotti? Jonathan Gotti? I hope I'm saying that right. I don't think it's John Gotti. From France.

There's actually a ReadMe that explains a little bit more about what's going on with the documentation, but it's just an extremely small JavaScript and CSS loader where you can define what files you want to be loaded and in what order, and it will do them in parallel to the best that it can, and you can define callbacks to be executed after each thing is successfully loaded or not.

So if you are into the idea of loaders, there have been a lot of loader systems that have come out in the JavaScript world the past several years to make it easier for you to programmatically say, 'This has to be loaded before this,' and so on. This is a good example of just, there's mechanics of writing something to be very, very tiny.

Manuel Lemos: Yeah. It also, as you somewhat suggested, not only is it able to let you define the order of loading but it also avoids loading some libraries more than once in case you have dependencies, different components on the same library.

Michael Kimsal: Yep.

Manuel Lemos: But we make it confusing, but it addressed the problem, too.

Michael Kimsal: Yep. That's definitely another good point. Yeah.

Loaders have never been my thing, but I have not focused on some of the performance gains and what not that you can get, or the dependency management. I guess I'm just not doing JavaScript enough to be at that level of complexity where that would be a real benefit to me, but it certainly is to some people. And I thought that was a good example from Jonathan Gotti, thank you, from France.

And also Daniel Martinez from Spain, or España, as they call it in Spain, has contributed an Image Cropper which I was playing with earlier. I like the example used to this. I might be able to bring up a screen share of this, if I can, which is... Come on.

Manuel Lemos: If the browser doesn't crash.

Michael Kimsal: I don't think it will crash.

We've all seen image croppers. You get the idea of, I can select a certain part of an area, I can resize this to make it smaller, and we see the values over there. So we can click 'Get values' and we'll get a JSON object that tells us specifically what area was cropped, and we could send that to the server or do something on the client side, whatever we wanted to do.

Again, this isn't earth-shattering, it's not 'Oh, my gosh, this is a game-changer.' We've seen these sorts of tools before. But I thought it was done nicely. And if only to learn how other people look at these sorts of things and learn from them, this would be a great thing to look at. But you may actually need this sort of thing, too.

It's surprising because there's a lot of tool kits out there that I see, a lot of JavaScript tool kits, that don't include something like that. The big boys have it in a lot of their online tools, image-editing tools, but there's a lot of JavaScript tool kits that don't come with something like that. So if you need it, there it is.

Manuel Lemos: Yeah. That's really cool, although as you said, it's not really innovative. There have been many components to do this. But this one looks practically nice, and kudos to Daniel for sharing yet another great component...

Michael Kimsal: Gracias.

Manuel Lemos: ...along with others that he sent before.

On my part, I would like to comment also on a couple of components. We have more to comment about. Unfortunately, we don't have the time. Just to comment on a couple of components.

One basically is yet another component by Artur Sosins. This one lets you stack elements of a container in different layers and do some animation effects with the layers.

The demo is quite impressive. Unfortunately, I do not have the time to show it in detail, but it shows an egg being peeled, just playing with effects of layers, the pictures on top of others. It's quite interesting. Very impressive. Kudos to Arturs for yet another impressive component.

Michael Kimsal: Yes.

Manuel Lemos: But now moving on to another interesting component. This one is not so evident what it does. It's a component from Martin Barker. He has been contributing several components to assist in development of games, regular features that you will need in games like manipulating objects in Canvas.

In this case, despite the name of the package, Canvas Game FPS Engine, includes the name Canvas, it's not exactly about Canvas. It's more about adjusting the rendering frame rate.

If you have a game that you need to update several objects that appear on screen and you want it to appear smoothly, you have to assure that the frames of the game are updated at a minimum rate to make it smooth.

But if you have enough CPU power or graphics power, you can probably update it even on a much faster rate than it would be necessary. But in that case, it would probably be wasting too much CPU that would be used better for other purposes.

So this component lets you adjust the frame rate of a game to a certain limit and assure that it is smooth enough but not faster than it needs to be.

This is in fact an advanced component, right? I'm sure that those that have dealt with games probably see the need for this. I'm not sure if the others that never program games will find it interesting, but it's still a very useful component via Martin Barker from the UK, so kudos for him.

Michael Kimsal: Thank you, Martin.

Manuel Lemos: Michael, you were going to say something?

Michael Kimsal: I was going to say, I said, "Thank you, Martin." I said, 'Gracias, Martin.' Martin Barker.

Manuel Lemos: Oh, I think he understands the English. [Laughter]

Michael Kimsal: Well, yeah, that's why I said, "Thank you."

Manuel Lemos: Yeah. I was wondering if you were going to emulate a British accent.

Michael Kimsal: Ah, keep trying, mate.

Manuel Lemos: [Laughter] OK.

Well, there are many other classes being published. Fortunately, the site is ramping up, also thanks to the initiative of the Innovation Award Challenge that hopefully sooner rather than later we will get to the goal of reaching 200 classes being published before the end of the year.

And as prize, the five top developers that published more notable packages until that goal will get a nice elephant that will be given as a symbolic prize.

It's not really related to JavaScript, it's more about PHP, but I just wanted to mention that the elephants are about to arrive. I supposed they would arrive today so I could show them, but unfortunately they did not arrive. They probably will arrive tomorrow. But I'm sure next month they will be here.

Michael Kimsal: Mañana, mañana.

Manuel Lemos: I'll probably pile them here on my back to show to everybody else.

Upcoming articles in the JSMag magazine (45:06)

Manuel Lemos: Anyway, finally we're going to one final section on which I hope you, Michael, are ready to talk about the latest issue.

Michael Kimsal: Oh, I've got a couple of things here.

One, JavaScript Magazine. Actually, I repeat this and I get people occasionally reaching out from the podcast here.

We're always looking for writers for JavaScript Magazine, JSMag.com, as well as GroovyMag. Probably most people watching or listening to this are not into Groovy, but if you are, please reach out. We'd love to have you contribute.

I'm actually going to the GR8 Conference, GR8, in Minneapolis. I'm leaving Sunday, going to be there Monday and Tuesday, and I'll be there next Wednesday. If anybody who happens to watch this would like to meet for lunch next Wednesday, Minneapolis, let me know.

JSMag, we have some things coming up for our August issue. We have Mike Schwartz continuing his series of talking about his SilkJS. He wrote a, I think it's a OSGI or JSGI style web server using just Pthreads and the V8 JavaScript engine. So he details some of the mechanics of what he worked on and how he did that.

We have Jonathan LeBlanc, who has written for us in the past, doing a piece on Node.js, a mashup of Node.js and ql.io, and ql.io is a tool that I think was originally built by eBay and it's a way of consuming large amounts of data and, I don't want to say doing a mashup, but consuming large, large amounts of eBay's amounts of data and processing that. The article is about processing that with Node.js.

We have the second half of an article from Robert Fischer about his jQuery periodical updater, which was a port of the earlier prototype periodical updater. We've got a piece from Dr. Jeanine Meyer about SVG. She's done a few pieces on SVG techniques with JavaScript manipulation.

So we've got those. We may have a couple of other things coming up as well, but that's what's slated for August. I can't believe it's almost August already.

And lastly, it's time, Indieconf, our freelance conference, which is going to be November 17th. We have a call for papers open through mid-August. We're going to have 20 or 21 speaking sessions so far. That may change, but it will probably be 21 like last year. One full-day event, three separate tracks.

Right now we've got, I think, 10 or 15 that have come in in terms of actual sessions that have been proposed, and there are some others. We've got about, total, there's about 20 that I'm sorting through right now, but there's another couple weeks, and I hope to have a few more to have to cull through. I'd like to be able to say no to more people. We said no to a lot of people last year. I'd like to say no to more people this year.

Not that I like saying no, but it just means that everybody else we said yes to was that much more on-topic.

Manuel Lemos: Yeah. And what exactly will be those three tracks that you?

Michael Kimsal: Well, they're not necessarily three tracks, I should say. We have three rooms. We have separate sessions. It's largely the business side of freelancing: the finance, the legal, the business, the marketing, the accounting, things like that.

We probably will have, we had a workshop on public speaking last year, we had some SCO stuff. There will probably be some technical things. We've had Zoe Gillenwater, who's written a great book. I think she's done a couple books for Peachpit Press on CSS3. Phenomenal, very well-attended presentation last year.

We may have some of those videos up. We have a few videos up from last year. I have them finally in digital format, but processing and uploading takes a while. But we've got four up from last year which give a pretty good cross-section of things.

Talking to some people who are mobile game developers, like Indie Studios, who are just a couple of guys that work on that. They may be coming and sharing their story.

I've been able for the last year to reach out to more people who are indie businesses who work on the Web and they have a technical background but they're not just doing software development. That's a portion, but they're not just doing contract work for hire, which I think a lot of people in my position that do contract work for hire are looking for 'How do I make that transition into building more of a stable business?' So I think we'll have a bit more of that this year than we've had in the previous couple of years.

But call for papers, indieconf.com, please submit by mid-August.

Manuel Lemos: OK. So mid-August is the deadline for call for papers.

Michael Kimsal: Yup.

Manuel Lemos: Then the choice of the talks will be announced when?

Michael Kimsal: I don't know exactly. Probably end of August.

Manuel Lemos: Yeah. And the event exactly, what is the date?

Michael Kimsal: November 17th, which is a Saturday.

Manuel Lemos: Oh, that's fine. There's plenty of time.

Michael Kimsal: Yeah.

Manuel Lemos: OK, well, I hope you have a crowded event once again.

Michael Kimsal: So do I.

Conclusion (50:07)

Manuel Lemos: Well, this has been an interesting show. Unfortunately, we do not have much time, but we will always be getting back next month with more interesting topics. Feel free to contact us if you want to submit articles, not just for the JSMag but also for the JS Classes.

Michael Kimsal: Yeah.

[Music]