Do You Still Need jQuery? Maybe Not! - Lately in JavaScript podcast episode 51

Contents

Introduction (00:20)

Obscure Pitfalls of JavaScript (2:52)

JavaScript: Knowing which apps you’re breaking using static analysis (10:12)

You don't need jQuery Anymore (12:59)

One JavaScript: avoiding versioning in ECMAScript 6 (20:24)

NativeScript: Develop Truly Native Apps with JavaScript and CSS (23:10)

JSScrambler: protect JavaScript and HTML5 (29:44)

Gitlet: Git implemented in JavaScript (34:03)

10 Tips to Adapt PHP Web Sites for Mobile Devices (36:28)

JavaScript Innovation Award Winners of 2014 (58:48)

JavaScript Innovation Award Nominees of November 2014 (1:04:42)

Conclusion (1:10:57)

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 hangout. This is episode 51, a very special episode. And for this, I have here with me, Arturs Sosins directly from the cold Latvia.

Hello, Arturs. How are you doing?

Arturs Sosins: Hello. I'm good. You're saying cold like it's a bad thing.

Manuel Lemos: Yeah. No, for me, nowadays, cold is a very bad thing. I have no idea because over the years, I've became a true Brazilian, so I cannot stand cold. At least, that's what I felt in the last month that I recorded from Portugal.

Arturs Sosins: What part in Portugal?

Manuel Lemos: Yeah. I heard that after I left, it got even colder. I don't know. Did it get also cold over there in Latvia?

Arturs Sosins: Yeah, definitely.

Manuel Lemos: Well, you told me you have been sick in the latest days. You could not make it to the recording of the PHP Hangout as in previous months. So I hope you are better now.

Arturs Sosins: Yeah, much better. We had a flu. Everyone was kind of sick, but now it's better.

Manuel Lemos: Yeah. So, after all, cold is not that good, I think. Unless you just want to jump on the snow.

Anyway, we are here to talk about JavaScript, so that's what we are going to talk about. Today, we have a special episode because we have been talking about the Innovation Award winners.

As you may see here, these are the trophies of the Innovation Award winners. This one is the trophy for the winner of the year, Thomas Bjork from Sweden. He's going to get this trophy by mail. But anyway, we'll talk more about that later in this show, just to tell that they're going to get this nice awards, not only the main winner but also the country winners.

Obscure Pitfalls of JavaScript (2:52)

Manuel Lemos: So we are going to get started to talk about the usual JavaScript topics. Let me start sharing the screen here. We're going to start with an article that's sort of unusual because instead of common things that sometimes people already know, he comments on obscure things of JavaScript that most people I suppose are not aware.

So this is an article that talks about some obscure JavaScript pitfalls. And let's talk a bit about this very quickly, because there are quite a few. First, he talks about the array sort function sorts alphabetically the values even if the arrays are made up of numbers, which gives some weird effects like 10 being less than 2, which is sort of interesting.

Another interesting topic is that if you want to construct an array with a number of positions, they'll be there, but they are not initialized. So if you try to do something with those entries right away like calling the map function as they appear here, it will probably will not do anything because the array is practically empty, although the length is set to the specified number. So it does a certain length but it is empty, which is weird.

Other than that, he also mentions something about casting integers may cause overflows. I think this is probably an implementation issue. It probably will not happen in all implementations of JavaScript, probably some who are not thought to be to deal with integers larger than 32-bit. Well, that's my opinion.

And then, it talks about object enumeration order that is not well-defined. Sometimes, enumeration does not really make much sense depending on the type of values using an enumeration. Anyway, this is probably related with the sorting issue of arrays that may actually do it by alphabetic order. I'm not sure if it is the same thing.

Then, it talks about JSON.stringify which is also not well-defined. Well, I'm not sure what was really the problem. Arturs, did you get this issue here?

Arturs Sosins: I also experienced it myself. The problem is the same, this object enumeration. The properties may vary from different orders, and so when you JSON.stringify them, it stringifies them also in random orders. So you can't really, for example in tests, in the end, compare different JSON strings because the properties may be in different orders. You need to compare objects explicitly and stuff like that.

Manuel Lemos: Yeah. Well, it's a bit weird. But does it cause bugs or is it something unexpected?

Arturs Sosins: No, no. I think it's only... Well, it matter to me knowing the test when I was comparing the results of the test. I don't think it cause bugs.

Manuel Lemos: Yeah. Well, you're always learning about yet more weird things. And then, it talks about Date.getHours and getDate that probably will not make much sense probably on server side because on the server side, there is only one time zone, and that time zone is not the same as the user that probably is accessing via the browser because the server doesn't... Well, I think it could but it probably won't honor the time zone that the user is on the browser side because it's a different machine.

Well, as always, it is recommended to use the UTC functions, getUTCDate and getUTCHours because you'll know that UTC is always UTC, and it is not subject to daylight savings and things like that.

And then, it talks about Array slice and Array splice, that they perform similar tasks but the Array splice actually modifies, while the Array slice doesn't, which is a subtle difference that once you realize that's the difference, you understand while there are two functions for similar purposes.

Well, this is interesting. I have not noticed any of these topics. You mentioned that you were aware at least one of those that affected your code, but what about the others? Were you familiar with them, Arturs?

Arturs Sosins: Well, I think yeah. I think that sorting behave like that, but it doesn't really worried me much. I don't know why. I don't use array constructor, probably for the same reason, but I don't know how to use it. Recently, I ran also into the problem of number overflow but for float, which was 2 in the 52nd power. So it also has its limits.

But, all in all, I would not say that they are such a pitfall. Yeah, maybe something that you need to be aware of, but it always reminds me of one video over... I can't remember the name. The guy showed different... What happens when you do arithmetic operations of different JavaScript types, and the results are unexpected. Those are short pitfalls.

But this, yeah, they might be obscure, but I don't know. I think the JavaScript developers mostly are aware that something like that is going inside and using the message or constructors accordingly.

Manuel Lemos: Yeah. Well, I think it's one of those things that probably we did not expect and sooner or later, you stumble on them, and you go, "Oh! Now, I know."

JavaScript: Knowing which apps you’re breaking using static analysis (10:12)

Manuel Lemos: Anyway, there are these articles that are always interesting. So we are going to move on to another article that talks about something interesting.

I think this is more Node.js related, which is basically about a way to know which apps you are breaking using static analysis. Static analysis, you can use to determine what sort of public symbols or objects or modules or variables you are exposing, and if you change something on those externally visible entries, you'll know the dependencies that may affect other modules or other parts of your code.

So, this article talks about using static analysis for that. I did not get much into this, but I know that there are a set of tools that can use static analysis for analyzing your codes and reach to some useful purpose.

Arturs, did you use any static analysis tools for any useful JavaScript-related purpose?

Arturs Sosins: I don't think, at least not like that. Here, the interesting part is that they have a really multiple end points for their application, Node applications, so it's like every page has its own root or something like that. And, in this case, it would be really hard to analyze it. That's why they even divided the result in three different modules.

Of course, one of them is that of which automatically finds the entry points, the modules that are not required by any other modules. But I don't think... Most of it, I usually have one entry point of JS and it all starts from there so it's not duplicated.

Manuel Lemos: Yeah, right. Well, it's always great to have those tools available because they are about an advanced topic. Personally, I would not be able to implement any static analysis tools because I'm not an expert on that topic. So it's great to have those tools at hand when you need them.

You don't need jQuery Anymore (12:59)

Manuel Lemos: Moving on to the next topic, let me share the screen here. It's about an article that talks about something that I suspect will be polemic. It starts with the statement, "You don't need jQuery. Free yourself from the chains of jQuery by embracing and understanding the modern Web APIs and discovering various directed libraries to help you fill in the gaps."

It is an article that claims that you don't need jQuery anymore. I think anymore refers to the fact that modern browsers implement modern APIs that you can rely. I mean, apparently, rely on different browsers because they would be available, so you would not need jQuery to deal with the browser differences.

Well, this is a big claim. I looked into this, and I'm not sure if it is fully true but anyway, the author talks about his story that for some project, he had to develop some code that could not rely on external libraries like jQuery, so he had to do it with existing browser APIs.

He thought it would probably be a pain, but in reality, he thought it would be a lot easier. Well, not easier, but at least it would not be an hell as it used to be in the past when you would not have all the APIs available on the current browsers.

In reality, this is an article that has many parts. It talks about different parts. The next part is about selecting elements without jQuery. Well, all the functions that you would use jQuery, you probably don't need anymore. Then manipulate DOM elements.

And then, the next article is about... let me see where this ends... making AJAX requests. I'm scrolling. I think I don't need to do it because there is a direct link there. Dealing with events, and I think I'm not sure if... The last part is about utility functions.

I don't know if it is all that true that you can rely on existing browser libraries and write browser code that will work on different browser, because at least some time ago, not a very long time ago, I had to work on a library that I have that would make Ajax request. So I still have to put some conditions to test the features of the browser, to see if I use some code or some other code depending on what the browser support.

So while I like to believe this claim that you don't like jQuery anymore is true, I think it is not that accurate. But I agree that nowadays, we are in better shape, in terms of dependencies on the modern browsers. Obviously, if you still are aiming to support IE6, you are in a lot of trouble. You need probably an old version of jQuery.

Anyway, that is my experience. Arturs, what is your experience on this topic?

Arturs Sosins: Well, I would say, as he say it his first block, of course, that there is trap. It's real. If you look a lot about StackOverflow questions in other websites, then there are many Web developers that have actually made a difference between JavaScript and jQuery. If you're like "OK, there is the jQuery, I don't know what the JavaScript is," or something like that. So the trap is real.

But in my experience, I actually went completely the other way. I was staying away from jQuery as much as possible. I was using JavaScript all the time that I could. I've learnt a lot about it. That time, it was all about the challenge. Now, it's about the speed and the time of implementation. So now, I'm just slamming jQuery all the time and the function, it all works. So it's the matter of the perspective.

There is also the website comic strip which post interesting comics about everyday satirical developer life, and one of them was dumping jQuery. Basically, this comic is about jQuery is so easy, why should you dump it? It's easy to use it. It saves you a lot of time. So that's how I feel about it now.

Manuel Lemos: Yeah, well, actually I also saw joke somewhere. I don't know if it was really Stack Overflow or it was a fake page. When somebody was asking how to add two numbers in JavaScript, and then the answers are like, "Oh, I think there's a function for that in jQuery."

[Laughter]

I'm not sure if it was real. I don't remember. It's a shame that I don't recall where I found that, but it was just these days. It's interesting.

Well, I tried to depend less on external libraries, not just jQuery everything, because there is also the versioning issue that more recent versions do not support all the browsers as they used to support in older versions of jQuery. If I can have code that works with past and future browsers, it's awesome. Although, it's like impossible mission, but at least we try.

Also, it's great when you can depend only on your code, because if there is a bug, it's your fault and you can fix it. On the other hand, I agree with you that nowadays, sometimes the time of development is more important than being such a perfectionist, "Now, I can do it without jQuery."

One JavaScript: avoiding versioning in ECMAScript 6 (20:24)

Manuel Lemos: OK, so moving on with the next topic, we are now going to talk about an article that somehow talks about something that we somewhat have already mentioned before. Here, it is talking about ECMAScript 6 where it is available. I mean, not in the browsers, but maybe somehow server-side implementation or...

Arturs Sosins: But it will be available in browsers also...

Manuel Lemos: Right. In the next Chrome version, it will be there.

And then, it tells you that you could have code that would deal with different versions of the JavaScript version that you have, for instance, on browsers, like having statements that use some code or other code depending on the version. It even show some syntax that you could use to run code if certain version is available or some use statement.

But, in the end, it recommends not relying on versioning, which basically is the same to say it's better to, if possible, rely on feature detection. Which I agree, it's always better to... Well, I don't say always, but it's often better to rely on testing the features if they are available and use what is available and not relying on version numbers.

Well, that's my opinion. Arturs, what do you think about this topic?

Arturs Sosins: Yeah, completely agree. Better to test feature than the version.

Manuel Lemos: Yeah. Except on the part that you have to know what to test, and there is some jQuery function that can do that by you. You can save time instead of learning how to properly test things.

Well, anyway, this is one topic that I suspect that most people agree with us, but there may be some people that have different arguments.

NativeScript: Develop Truly Native Apps with JavaScript and CSS (23:10)

Manuel Lemos: So moving on the next topic, now, we're going to just mention briefly something that is not yet launched, but it is being announced to be launched sometime in March... March 5th... and it even says March 5th at 11AM ET. Very important, this announcement time, which is the time of some launch Webinar of a project called NativeScript, which seems probably not such a new concept which is basically to allow to develop native applications. I suppose they mean native mobile applications using JavaScript and CSS.

The idea is to have 100% success native platform APIs using JavaScript and it seems to be aiming to be device-independent. Well, this is not exactly a new proposal. The only detail that I noticed, they just say JavaScript and CSS. They don't mention HTML 5.

So I suspect this is not relying on some WebView, because to be a truly native applications you need to access the APIs that render on the screen, or things like that, not something inside a WebView which would allow HTML 5.

I don't know, that is my interpretation. Arturs, did you look into this? What is your perception of this project?

Arturs Sosins: Yeah. The company itself, Telerik, was popular for allowing to create enterprise-level hybrid apps, and yeah, now they seem to get on to the native apps which as you said, won't use a Web view. I think the underneath would be a breach between JavaScript and underlying language.

As we can see in some examples that they have, that basically, there would be native classes, UI button for iOS and widget button for Android, and they would wrap it in the same button class for both platforms. So it would be much more towards what actually Appcelerator Titanium had done, rather than what PhoneGap does.

Manuel Lemos: Yeah.

Arturs Sosins: So it would really be a native app, yeah, as you said.

Manuel Lemos: Right, well, they say this does not rely on HTML 5, but it seems to rely on some XML definition of pages and screens and stuff, which looks pretty much like ASP.NET. I don't know because these guys are too attached to the Windows world.

Arturs Sosins: No, no, no. Android has similar XML definition, so it's probably going more for Android here. But yeah, Titanium Appcelerator has also Alloy, which also provides a way to define all the UI in XML. It's a common practice now.

Manuel Lemos: Yeah. The only thing is that you cannot use a real browser to preview this, I think. I don't know. I don't know because it's not HTML 5. But they probably will provide some kind of emulator.

Well, although this is a commercial project which means it will cost money... I'm not sure if there will be basic free version... personally, I like the idea because I don't feel like going through the pain of developing code that needs to be very close to native and Java for Android Objective-C for iOS. They also support Windows Phone. I'm not sure what is the share of Windows Phone these days. Probably very small, but OK, I don't think it will hurt.

Anyway, personally, I like the idea. Probably, this may be interesting also for commercial developers because they probably will provide a way to develop commercial components that can be sold to other developers and save time of development, even if they cost some money to acquire.

I did not read this. I'm just jumping to conclusions, but I think the idea could be interesting. So let's wait until March 5th and let's see what comes up from there. Although, all my life, I've been using and developing Open Source code, I think existing commercial products do not hurt. If you don't like commercial close-source software, just don't use it.

Arturs Sosins: NativeScript actually is Open Source. The base that...

Manuel Lemos: Yeah, probably not totally open source, because this is a company that needs to make money somehow. So let's wait and see how open is the source. I don't believe in miracles. I know every company has the right to make money somehow. Maybe it's not the implementation of this but could be some other way. Let's wait and see what exactly it will be.

JSScrambler: protect JavaScript and HTML5 (29:44)

Manuel Lemos: So moving on with the next topic which is about also a commercial tool, but has a free version, which is to scramble JavaScript code. It's called JScrambler. It seemed interesting. Let me put this in English. For some reason, it assume that I want it in Portuguese.

Arturs Sosins: I wonder why.

Manuel Lemos: Probably because I am in a Portuguese-speaking country.

Anyway, the idea of scrambling is taking your code and rewriting it somehow that it will be unreadable for somebody that just arrives here and takes a look at it, changes lots of the names of variables. It makes it harder to understand for people that may not want for some reason to understand it, like some boss that wants to edit your code and is not even a developer.

[Laughter]

Manuel Lemos: I heard stories, horror stories of customers of consultants that have developed projects, and for some reason, the person that paid for the work, thinks he knows about programming and goes and mess up the code directly. So although, unscrambling is always possible, it would be hard for those bosses to fiddle and make a hell of your life messing your code when you didn't want them to do it.

So this JSScrambler has a free version. I'm not sure how this work. Is this a Web service or not? Well, it supports... There is a free version up to 25 files per project. I don't know how many projects it supports. Oh, it's an API. OK, now I get it. It's an API to do the scrambling. It also not only does... It can do optimization.

OK. Well, it is interesting. It's a commercial project again. But it may be useful when you really would rather pay for a solution that does not causes you problem with the nosy bosses.

Arturs Sosins: I don't think that actually would be the main reason. I think the main would be if you're selling scripts online, then with both PHP and JavaScript the code is open and everyone can save them somewhere and upload the tutorials, stuff like that. This kind of security prevents them from doing that because you can embed some license checks inside and stuff like that.

Manuel Lemos: Yeah, that's true. That is also a possibility. I'm sure people that are willing to sell scripts would like to avoid also that problem. Although, one problem of shipping scrambled code is that if there are some errors, probably the line numbers get messed up, the variable names are totally different. And for debugging it is probably not very useful, but OK, I will get either one thing or the other. So, well, you can't get everything just doing this scrambling.

Gitlet: Git implemented in JavaScript (34:03)

Manuel Lemos: So moving on to the next topic which is about a library. I'm not sure if this would be useful for everybody, but I thought it was curious, just to mention it briefly. It's called Gitlet. It is basically Git implement in JavaScript. They only say Git implementation, they mean Git client because it uses a protocol... client-server protocol... that I think it will just implement the... I mean, this library just implements the client-side, which is still useful I think, for some reason you want to use Git for some purpose.

I don't see a personal purpose for my own projects, but maybe other people find it useful. Arturs, what do you think? Do you find this useful for any project of yours?

Arturs Sosins: I don't know, I'm just looking at the code and it seems it still uses Gitlet from the common knowledge. So what does it exactly have to do with JavaScript?

Manuel Lemos: I think that probably, it's a library that you can call it from JavaScript code, probably Node.js based code. It also generates an executable command that you can call from the command line. Well, that's me guessing because I didn't look at inside of this. It's either that, or it is just a funny way to say I'm not using Git. I'm using it all from JavaScript but it is from the command line.

Well, I don't know. It may have its purpose.

Arturs Sosins: Yeah.

Manuel Lemos: It's just for you to know you can use the Git without having the Git program installed. As long as you have Node.js installed, it will work fine. Well, that's what I got. I'm not sure if this is the way this project was meant to be.

10 Tips to Adapt PHP Web Sites for Mobile Devices (36:28)

Manuel Lemos: OK, now moving on to another topic which is about an article that I wrote precisely because I've been working on something that I must say, it was painful which is adapting a Web site to make it more mobile friendly. So this article is basically to tell what I learned.

So for the last three months, actually more, I've been working on making PHPClasses and JSClasses mobile friendly.

So this article tells you about ten tips, but in reality, there are more tips than these ten. The ten tips that I mention is about make it responsive, but the site tells you first about the motivation to make a site mobile friendly.

Well, in the case of PHPClasses, JSClasses, over time, they had been accessed mainly by desktop users because developers that are accessing the site, they want to download components. So they are not going to download mobile phones or tablets, except maybe for some types of pages like blog articles that people just want to read and probably want to read it from mobile device, like for instance this article.

So, over time, only like 8% of the users are using it from mobile devices. But still there was a growth... last year it was 6%, now, it's 8 %. The mobile use is growing, but not still a typical site used from mobile devices.

But what motivated this development, at least it was the trigger, was that Google announced that sites that are not mobile friendly, they eventually will be penalized soon in the next weeks, months. We don't know. Google never pre-announces the updates in their algorithms. So if you fear that your site may be penalized because your site is not mobile friendly, maybe making it mobile friendly is the time.

Anyway, the article starts saying that making the site mobile friendly should be done for your users, not for Google. Because, Google, whatever they are changing in their algorithms is always to motivate developers to make the sites better for their users, so you should always be concerned with your users, not with Google.

And then, the article talks about different approaches to address better the needs of your mobile site users. And it talks about four approaches that you can follow. It's just three approaches and then, one alternative solution which is not really about the site.

The first approach is to create an alternate site for mobile site users, which basically is practically like having the same efforts that you have to create the site for non-mobile users because you have to create eventually different layouts, but serve them in a separate site.

The second solution is to use dynamic serving, which is basically the same except that the mobile and non-mobile versions will be served from the same URLs. Again, this is also like having the effort to create a new site.

And the third solution is to create responsive Web pages. They are basically Web pages that only have one version of your HTML code, and then they use things like media queries and things like that to adapt your pages layout to your site users.

And then, the fourth approach, which is not really to change your site, is more to implement a mobile app and that probably makes more sense when the interactions with your users are very intensive for mobile devices, probably transactional web sites like sites that implement services, personalized services, not just showing pages that will be the same for different users.

Well, this is a different approach, not really adapting your site, but I put it here because you may also consider creating a mobile app and also adapting your site to mobile users using these approaches.

So in the case of PHPClasses and JSClasses site, it was used the approach to implement responsive Web pages, which is basically the core of this article, which are the ten tips that fall below.

Before moving on, just to comment about this, Arturs, what is your experience with adapting sites to mobile users? Did you ever have to go through the work of converting the site to make it mobile friendly or your efforts were more just to begin with a site that is mobile friendly from the start.

Arturs Sosins: Mostly, they are either mobile friendly from the start or if client wants a responsive Web site, then it also gets a new design. So it's also created from the start. I actually can't remember any work that I would have to convert existing design because it would be a very, very hard thing to do.

Manuel Lemos: Yeah, tell me about it.

Arturs Sosins: Hats off to you because you could break many things, you could do a lot of stuff there, and that's really a complicated task. It's better to build from the scratch.

Manuel Lemos: Well, I don't think it's better to create from the scratch because that's even more work.

Arturs Sosins: But it's easier, I mean.

Manuel Lemos: Yeah, well, in the end, I realized that it's not that hard but it's still a lot of work when you have lots of different types of pages, which is the case of a site that is reasonably old like PHP Classes and JS Classes. There is code that was written there in 1999. It's really, really old.

But the idea of this article is to teach some tips that you could apply to make it less of a pain, because it will always be a pain no matter what, regardless of your approach. It will always be a pain if you have to start with a site that was not mobile friendly from the start.

So I wrote this to tell about these ten tips. Just to cover it here very briefly. The first tip is to help you to decide what is the priority, because when you have many types of pages, you ask yourself, "Where am I going to start?" The first tip gives you a need which is to start with your most visited type of pages.

It talks about there is a tool inside the Google Webmaster Tools that gives you the list of the top pages that are getting traffic from Google. So if you are in a rush, you don't want to get caught by any penalties, the sooner you'd address those pages, the better. So those should be the pages that you should get started. But not just for Google also, because those are the most visited pages by your users. So, the sooner you fix those pages first, the better.

And it tells you about these report of search queries that shows top pages. They are not grouped by URL because Google Webmaster Tools have no notion of URL patterns, but here I mentioned a PHP class that I developed that can retrieve that report, the top pages that are visited, and then you can put them in an array and probably sort them, so you can be more certain which are the groups of pages that are more visited.

Obviously, in case PHPClasses top visited pages are the ones that are for package pages, but then I was not sure which ones would the next types of pages would be. With this tool, I realized it would be the blog pages that also get lot of accesses. And then, other individual pages like the home page and others of authors, and groups, categories, and files, and so on.

Then, the next tip is to use browser developer tools to preview your pages in small screens so you can look at them, how they look in your browser, for instance. You can use the Google Developer tools nowadays. They have this thing of previewing your pages in the size of different types of mobile devices.

I think Firefox Developer Edition has a similar tool. I don't know about browsers. Arturs, I think you use Opera, right?

Arturs Sosins: I have used it a lot, but I'm more on the Chrome, too, basically.

[Laughter]

Manuel Lemos: You gave up.

Arturs Sosins: Yeah.

Manuel Lemos: I don't know if Opera has anything like this these days. Maybe it has. You can go here and just do this and adjust the size of the screen for certain devices, and then you can see that it adapts.

There are several tricks applied here that I mentioned and other tips, like how to adjust things like images, so they still look properly scaled up. But OK, let's move on the other tips.

The second tip would be that to use to the browser developer tools to preview your pages small screen and start fixing your page.

The next tip is to fix the viewport definitions to adapt to the screen size. The viewport is the visible part of the browser. Meaning that for instance, if the pages does not fit on the viewable part of the browser, it will show some scroll bars. The viewport is only the visible part and using this meta tag, you can make it adjust the device width, and then it probably adjust the zoom scale to make it fit that or not. It will depend whether your page fits or not.

The next tip is about starting with page headers and footers because if your site is big, you have to start from certain point. But usually, sites have something in common. Different pages have something in common, which is the page headers and footers.

So that's what I did. The first thing that I did is start adjusting the headers and footers of all pages so they can fit, and start converting menu bars into buttons, which is the next topic. For instance, if you have wide navigation bars like you have in this site, where these navigation bars. On the top, you also have this navigation bar, so when I adjusted to the mobile size, these navigation bar is turned into menus.

OK, let me get back to the point. The next point tells about how to build these menus. In reality, this is one of the disadvantages of the responsive approach. Sometimes, you cannot use the same HTML and put some media queries and make it all fit well in mobile screens, small screens.

So what I had to do is to put two types of menus, one for mobile and one other for desktop. So when the screen is too small, it will show one. When the screen is large enough, it will show the other. That's what happens here. This was a trick.

The next point here related with these menu buttons is that it also teaches a trick how to create a menu with some DIV statements, so you do not need to use any JavaScript to toggle the menu to show and hide. You use an hidden checkbox and certain CSS files trigger depending on the state of the checkbox, whether it is checked or not.

So those menus that I've shown here, they're in reality have this icon of the many ways label with an image, and when you click on the label, you toggle the state of the menu using some CSS that is given as an example here.

The next tip is what are you going to do to start fitting things that will not fit on small screens. You have to start sacrificing less important information. For instance, information that is probably repeated. You start sacrificing, for instance, these menu bars here. They would be shrunk to the point they would disappear when the screen is too small, so they can start adapting until all fits.

The recommendation, at least for Google Tools, is to keep shrinking until you reach the size of the iPhone 3GS screen which is 320 x 480. Once you have fit all on that screen, you can stop going further and make it fit in smaller screens because, nowadays, nobody is using screen that small.

Arturs Sosins: Yeah, true.

Manuel Lemos: At least for smart phones, I think.

And then, the next topic, the next tip is to use Google Page Speed Insights to figure any pending issues that you might have. For instance, if you have adapted your page and you think, "Now, I think I'm done," then you can test the page, put the page in production and pass the URL to the Google Page Speed Insights tools, and it will really tell you if you have fixed all topics or not.

Sometimes, you'll realize there are still issues like buttons that may be still too close, and that probably is not a very good thing. You need to sort that issue, too. Using this tool, you find what are the pending issues that you still need to fix.

The next tip is about adapting images to fit on the page width limits. For instance, this article has images. When they get too small, they would not fit. So the tip here is to use some media queries to make the width be as large as possible, 100%, and then you use the auto-height, so it will keep the proportions, resize the images and keep the proportions. This is an interesting tip.

Another thing, that I mentioned is when you try to fit things in small screens, you probably will find the links or buttons that are too close. So you need to put enough padding around so when the user touch on those links or buttons, it will not touch the next button by accident.

You should have enough padding around those links or buttons to make them be separated enough, not just horizontally, which would happen with text if you just define some pixels of padding, but also vertical lines should be spaced enough. So if you put the line-height style to 200%, it will address that problem.

And the one final tip is to figure how much you have done in your site and how many pages you still have to do, is to use Google Webmaster Tools Mobile Usability reports that tell you how many pages you still need to fix, and what type of issues they have, so you can sort your priorities and try to address as much as possible in the least time possible and address most of the issues sooner, if possible.

Well, this is quite a long and detailed article. Arturs, I don't know if you have read the article before. I don't know if you have any other tips, any other things you wanted to comment that would be worth mentioning regarding this topic of adapting to mobile?

Arturs Sosins: The first thing I wanted to say, yeah, it's a really a detailed, really great article that really provides the insights of what have to be done and what to look for.

Maybe, the only thing that you could have mentioned... but knowing you, you wouldn't mention it... is some kind of third-party scripts that could help you with that, like Twitter Bootstrap framework or others could help. Not that everyone uses them, not everyone needs them, so maybe it was not also for such an issue.

Manuel Lemos: Yeah, that's true. I didn't... I thought about that but since I did not use those solutions, because usually those solutions are great when you are getting started with mobile friendly site which is not the case. I was adapting an existing site. It was not done from the beginning with Bootstrap or some other library, so probably it would not make sense.

But I agree with you. If you can get started with one of those libraries, it probably would be less of a pain because many matters are already sorted, and you probably can reach to a more mobile friendly users solution to users that will access your sites from a mobile device.

Not just for mobile sites, but also for hybrid application that you can install in a mobile device, but since it is a HTML 5-based and CSS-based, you could use it to make it fit the layout fine on mobile devices and still be a native app. Well, actually, an hybrid app.

JavaScript Innovation Award Winners of 2014 (58:48)

Manuel Lemos: OK, given that, let's move on to one final topic, one of the regular section on which we comment about the Innovation Award nominees, but this time, as I mentioned, we are going to talk about first the Innovation Award winners of 2014.

The last nominees of the year published the classes in December, so they were voted in January. In February, the final results came out. The big winner of the year is Thomas Björk from Sweden. Congratulations to Thomas.

By the way, Thomas, if you are listening to this hangout, I hope you can get in touch because I've been trying to get in touch with you since the beginning of the month, because he's entitled to one of these prizes.

Let me show you again. This is the trophy. As you may see, I don't know if you can read it. It says JavaScript Innovation Award, the name Thomas Björk, and he's going to win this nice trophy that was done with a lot of love and care to all the winners.

When I say all the winners, I mean not just Thomas, because Thomas won individually, but also all these other four trophies are for the winners of the country that won by country. So Thomas won individually.

Arturs Sosins: He won as an author.

Manuel Lemos: Yes, exactly. He won with four packages and 15 points. Many other authors participated like David Castillo from Mexico, Pierre FAUQUE from France, Jimmy Bo from Canada, Andoitz Jordan Marmolejo from Spain, Emmanuel Podvin from France, Andras Toth from Hungary, John Diaz from Colombia, Jakub Krol from Poland, and Raul from Brazil. They all did great, but Thomas got more packages and more points for his participations.

But, by country, the country that won was France with 6 packages and 23 points. So collectively, France won. Thanks to the contributions of several authors, actually four... Pierre FAUQUE with 12 points, Emmanuel Podvin with 8 points, Chi Hoang with 2 points, and Jonathan Gotti with 1 point.

All of them are going to get these trophies, which are slightly different. They say JavaScript Innovation Award winner, the name of the winner, and Team France, as they won the championship by country.

Other than these trophies, they are also going to get one of these PHP elePHPants. There are no JavaScript elePHPants, unfortunately. I don't know if there is a mascot for JavaScript. It would be interesting, I don't know.

Arturs, have you heard of any JavaScript mascot?

Arturs Sosins: No, not really. I've been looking into that sometime, but I also didn't find anything.

Manuel Lemos: Well, every popular language deserves a mascot. If anybody cares, really cares about JavaScript, let's not give PHP elePHPants to JavaScript developers. They deserve some JavaScript elePHPants, maybe, or some other animals, some other mascot.

Anyway, congratulations to them all. I know, but only a few have... I contacted them all by email, but unfortunately, not all of them have replied. So if you're listening to this, please get in touch because I need your addresses, so I can send you all these nice prizes.

OK, as I was mentioning, many other countries did well but did not make it to the first place, like Sweden (4 packages and 15 points), Mexico with 2 packages and 13 points, Spain (3 packages and 12 points), Canada with 4 packages and 11 points, Italy (3 packages and 8 points), Hungary (2 packages and 7 points), United States (3 packages and 6 points), India with 2 packages and 6 points, and Brazil (1 package and 5 points).

The Innovation Award contest of 2015 is already going on. There are already nominees in January, and I hope in February, more winners, more potential nominees submit their packages so they can be nominated to the Innovation Award.

JavaScript Innovation Award Nominees of November 2014 (1:04:42)

Manuel Lemos: So given this, we are going now to move on with commenting on the nominees of the last months. Actually, now, we are going to talk about the nominees of November 2014. They were voted in December, and then in January, the results come out, so that's why we are only talking about them now so not to influence the voting process.

So Arturs, which ones would you like to comment about? There were four nominees, which ones would you like to comment?

Arturs Sosins: Let me first comment on my own.

Manuel Lemos: Oh, exactly, you were nominated.

Arturs Sosins: Yeah. So basically I had a purpose. There was a user registration and in most case by default, users do not submit avatars. So the idea was to create a class that would generate an image from the name or surname that they provide. Basically, what it does, it takes a hash from your name and generates color from that hash, then it uses your initials and puts in a complementary negative-like of the color of the text so they stand out from each other.

This way, from your name, there is generated an avatar that is used in your profile. I think many sites are using it, but I didn't really find the script that would be available to use it, so I had to make my own here.

Manuel Lemos: I have seen sites that use sort of QR code or some abstract drawing.

Arturs Sosins: That's probably from Gravatar. You need to provide an email address and then you can generate different global avatars.

Manuel Lemos: Oh, it's Gravatar, OK. Well, I think your package is simpler but it makes more sense because after all it's the initials of the author name that are there.

Arturs Sosins: Yeah. The second one I wanted to comment on is from Mehdi Safavy from Iran, and what he does we can also demonstrate. I love the Demos tab. So sometimes you have links in the Web page which... Let me find one. No, it's not this one. There are links in the Web page that jump to...

Manuel Lemos: I think it's the links from those at the top table of contents.

Arturs Sosins: Yeah, they did not seem to be... They seem to be waiting to something. Oh, yeah, this one, there's the content. I actually think... Yeah, wow. So you see?

Manuel Lemos: Yeah, it's awesome, and it's a very nice effect. It's not just scrolling. It's just shows your flying arrow.

Arturs Sosins: Yeah, that is just awesome. Actually, retrieving the event is already hard. You need to override the default browser behavior to avoid some tricks but the effect is just wow.

Manuel Lemos: Yeah, that's true. That's really impressive. Congratulations to Mehdi Safavy, and for that he won a license of the IP to Country database. Congratulations to him for...

Arturs Sosins: Yeah, building FlyMe.

Manuel Lemos: So on my behalf, I also like to comment about the other two packages that were nominated, specifically one that is very interesting... WebCodeCam... which is basically a jQuery plugin that can use the Webcam that you have on your computer or mobile device or whatever. What it does, it can capture the image from the Webcam and put in on a Canvas and try to decode the code that is there, either being a bar code or a QR code.

So this is a very interesting package from Andras Toth from Hungary. I found it interesting. I'm not sure. I could demonstrate it but I cannot use my Webcam here. But OK, it has also demo. It's great that now authors are always providing viewable demos because it helps demonstrate what the package does.

So, for this, Andras is entitled to a prize that he picked to be one book of choice from O'Reilly, actually an e-book.

And then, the other package that I wanted to comment is called JavaScript CSS Generator. It's from Jimmy Bo from Canada. What it does, it generates CSS ties dynamically, which can be very useful in certain circumstances on which you need to alter certain characteristic of your styles dynamically.

With this package, it sorts of provides an API to do that. It is useful for many purposes. So kudos to Jimmy Bo, and for that, he picked one book of his own choice by Packt.

Conclusion (1:10:57)

Manuel Lemos: So, with this, we practically reached the end of this Hangout, podcast. Once again, congratulations to all the winners of the Innovation Award who got these trophies and that JavaScript elePHPants.

[Laughter]

Arturs Sosins: We should have our own mascot, JavaScript mascot. And, I think anyone else would accept it.

Manuel Lemos: That's the thing I'm going to do when I finish to make the whole site mobile friendly.

[Laughter]

Arturs Sosins: OK.

Manuel Lemos: After many months of work.

Arturs Sosins: You can start like I know submission box, so others could submit their ideas and drawing.

Manuel Lemos: Actually, this elePHPant is not really the original PHP elePHPant from Vincent Pontier. This one was created by a contestant that won a design contest for the PHP Classes site like in 2009 or 2010. Not only they wanted to provide a new template in CSS, the icons design, they also wanted to add a new logo. So I thought it would be interesting to convert the logo into elePHPant mascot because the elePHPant mascots that's based on the Vincent Pontier design, they were hard to find by then, so I find it to be better if I could produce them.

So it ended up working well. I already contacted the winners that are going to get them. Many of them are very excited to get one of these elePHPants, so even though some are for JavaScript contributions, that's all fine. Most of them are also PHP developers, so they will appreciate.

So once again, congratulations to all and keep sending your innovative packages so you can win the 2015 award.

So with this, we practically reached the end of this podcast, and on my behalf, that is all for now. Bye.

Arturs Sosins: Bye.

[Music]