The Fetch API to Succeed AJAX (XMLHTTPRequest) - Lately in JavaScript podcast episode 57 - JS Classes blog

Contents

Introduction (00:20)

ES6 Feature Performance (1:17)

Top Popular JavaScript projects (4:27)

The Fetch API to Succeed XMLHTTPRequest (7:26)

Non-blocking Asynchronous JSON.parse Using The Fetch API (9:21)

Web Components are an Endangered Species (10:20)

Don't use || to set default values in JavaScript (17:16)

How to Debug JavaScript Remotely With Vorlon.js (20:20)

Overcoming JavaScript Framework Fatigue (22:54)

How to Create a Node.js Cluster for Speeding Up Your Apps (26:31)

Bower versus NPM: Doubling Down on npm (31:11)

JSHint: A Formal Commitment to New Language Features (34:31)

JavaScript Innovation Award Nominees of May 2015 and Rankings (37:13)

Conclusion (38:54)

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, whatever. After a very, very long struggle with all sorts of excuse to start this Hangout, we are finally going to start recording with our buddy from Latvia, Art Sosins.

Hello, Arturs. How are you doing?

Arturs Sosins: All right. Well, this time we managed to do it a little bit earlier than in the PHP podcast, so we are getting better.

Manuel Lemos: We had also such problems, but we also don't have no more patience to start talking about it because it is so many issues including some problems with recording.

But we are here to talk about JavaScript, and that's what we are going to start to do first.

ES6 Feature Performance (1:17)

Manuel Lemos: The first topic that we are going to talk about is precisely about one interesting regarding performance of ECMAScript 6 implementations, or at least emulations if you can call it so.

So there is this article that talks about feature performance, and it shows the results of many tests, all sorts of tests. It shows how it went in terms of performance with some transpilers.

Well, I don't know what are all these. I knew about Babel. This Traceur, I don't know. About this Traceur, do you know Traceur, Arturs?

Arturs Sosins: No, but probably similar to Babel, emulating some kind of transpiling or something like that.

Manuel Lemos: Yeah. ES5 bind, it's probably another transpiler, right? ES6, I don't know. This could be a reference implementation, no?

Arturs Sosins: I think it's the native implementation that is only available in Firefox. As we see from results, it's really, really slow compared to emulations. So it's probably a Web test version, something like that.

Manuel Lemos: Yeah.

Arturs Sosins: One thing that we should notice is that under Node.js there seems to be a Node version and io.js version. io.js is the 2.3 one.

Manuel Lemos: I see. So the 0.10 is the actual Node and the 2.3 is the io.js fork.

Well, so what is the big conclusion about all these charts?

Arturs Sosins: That Internet Explorer development performs, like OK. Internet Explorer 12. Does it meant Edge already or is it actual Internet Explorer 12 version?

Manuel Lemos: Is there Internet Explorer 12, or is it what they call Edge?

Arturs Sosins: I think it's an Edge. That's why it's faster. They have rewritten it or something like that.

Manuel Lemos: Yeah, I see. Well, anyway, I think this is just a beginning of something. There is still a long way to go. Apparently, they are no longer calling it ECMAScript 6 or 7, or whatever. They just bind them to numbers of the year. So there is ECMAScript 2015 and ECMAScript 2016 when it comes.

It is probably confusing because we know that ECMAScript 6 provides different features, so I don't know how they are going to clarify what is what.

Top Popular JavaScript projects (4:27)

Manuel Lemos: Anyway, moving on to the next topic, and this one is just a curiosity, a chart of JavaScript projects that are in GitHub. They took the numbers of the forks and the stars, and they computed the ranking. I don't quite understand these numbers because I don't know if these numbers are changes.

Arturs Sosins: Probably, yeah. No, I don't know. It seems so because of the negative numbers also. It's quite interesting to see that AngularJS is on the first place, while for example, BackboneJS is only on the ninth, tenth place. These three visualization libraries is before Node.JS. io.js, for example, I think we can search there also.

Manuel Lemos: Well, I don't know. I thought jQuery probably would be the most popular.

Arturs Sosins: And it's on 3rd, 4th place but it's also combining out what's the different plugins and stuff like that, so it's hard to tell.

Interesting that the project I'm working on, Countly, is actually on 978th place which is kind of great. It's in Top 1000.

Manuel Lemos: Oh, really?

Arturs Sosins: Yeah. So I'm committing to it quite often.

Manuel Lemos: Oh, that's why. So you've been committing a lot just to cheat the stats.

Arturs Sosins: No, not like that. It's actually calculating from the stars and forks, so it's not related commits, but still that's interesting.

Manuel Lemos: Yeah, but are there so many people doing forks? Or is it just you creating many forks?

[Laughter]

Arturs Sosins: Yeah, that's me. All me.

Manuel Lemos: Yeah. It's like a project. How many other people are in the project besides you?

Arturs Sosins: A couple of people. Four maybe. There are other contributors since it's an open-source project. There are countless of contributors. So it has some trend, some tension.

Manuel Lemos: Well, OK, this is just a curiosity. Probably not a very meaningful chart because probably you'll find many top libraries that you don't use or don't know very well.

The Fetch API to Succeed XMLHTTPRequest (7:26)

Manuel Lemos: So moving on to the next topic on which we are going to start to talk about an API that is aimed to replace the traditional XMLHttpRequest library that we often call it AJAX.

There is an article talking about here, and there is also a specification going on and basically, the idea is to provide a clean implementation of a library that can perform HTTP Requests.

Arturs Sosins: Do we mean standardized?

Manuel Lemos: Yeah.

Arturs Sosins: The same API in all browsers because that's the most common problem with AJAX request, that you need to anticipate many different behaviors and options. That's probably why many of us use jQuery at least for the AJAX part.

Manuel Lemos: Well, XMLHttpRequest has been standardized. It doesn't mean that everybody follows it. The problem is that there were different versions, and browsers do not want to change whatever they have and is not compatible with the others.

So now, we have specification. Well, it's not done yet but people can already start working on its implementations. And talking...

Arturs Sosins: Yeah, and in case that for two more years, and maybe even five years, you would have to use both Fetch API and fall back to XMLHttpRequest just in case.

Manuel Lemos: Yeah, so now, you have twice of the problems.

[Laughter]

Non-blocking Asynchronous JSON.parse Using The Fetch API (9:21)

Manuel Lemos: So, anyway, there is already somebody that is working with this Fetch API. He implemented a JSON parse library that... Or, is it JSON, a new parse library or is it a way to make it work with the non-blocking asynchronous resource with JSON?

Arturs Sosins: I think it's not a library, just a way to use Fetch API to asynchronous load JSONs, because that's what they do. They make asynchronous request to read file and parse. So I think it's a built-in function in Fetch API to process it.

Manuel Lemos: Well, anyway, despite this is something that is being specified, there is already people that already have jumped on it, and it is interesting.

Web Components are an Endangered Species (10:20)

Manuel Lemos: OK, next topic, we are going to talk about something related with Web components. Actually, this is an opinion article that was written by this guy, Christian Heilmann. He was putting up a reflection on Web components.

Basically, he says they are an endangered species. Well, I don't know if this probably exaggerated or what. I know personally that I have tried Material Design with Polymer libraries and was very disappointed with it because the premise was good, like having a library of Web components that you could use to implement standard behaviors and could make the presentation somehow adapt to the underlying platform.

When I tried it, I realized this Polymer's a bit messy because there are several versions and the last version is not compatible with the previous versions. And whatever you built on previous versions will not work. If you are going to look at the existing documentation, it is confusing because the documentation, both versions co-exist, and that you don't know what to do to make it work.

But do I think it was worse? At least, in my opinion, because when I was trying to use it in a Cordova project and eventually, it would not work on the Web, same code because it's all JavaScript. It's that, for instance, you have errors or at least something does not work and it does not throw any errors, you have no clue why it is not working.

You will go for instance to GitHub, you will see there like 500 open issues and nobody is replying. It is like, "Oh, this is Google problem," but it seems that they don't have time or vocation to provide support to those people that are asking for support.

Then, I ended up giving up on Polymer, and ended up falling back many people to Bootstrap. So far it is working well. I don't have many issues and if I have issues, I'll just search on Google and often you fall in some StackOverflow question that somebody replied, and to solve issue that you found and you are done with it. You don't have much more struggle to deal with this.

Arturs Sosins: That's actually funny that you mentioned Bootstrap. First, the problem with Web Components are... For some listeners who don't remember what Web Components are, it's basically a way to create a custom HTML tag that would do something that you design it to do. They are available for like three, four years already, and nobody basically uses them.

I think the only popular example that everyone is representing is GitHub Time Component that they use to show time or something like that. Nobody...

Manuel Lemos: It's not very useful.

Arturs Sosins: Yeah. And I think libraries like Polymer are built upon the components and present lots of stuff upon it, but nobody's actually using the native component stuff to build something new.

What this article proposed in the end is to take the Bootstrap and replace all Bootstrap components with Web Components, and that would start a Web Component error that everybody would be building or extending the Bootstrap stuff like that. Basically, what they want to do is take the Bootstrap that you just said work normally and try to make it worse probably.

Manuel Lemos: Yeah. That's a funny comment because I think yet another attempt of Google trying to define how we create user interfaces based on the Web. In the past, it tried the Java Web Toolkit. I don't even remember what was the name they gave it. Basically, you'd program your user interface in Java and then it would spit HTML and JavaScript. That's fine except we don't use Java.

And now, this one is to use Web Components, I thought it was interesting because it introduces some quite nice behaviors that make user interface more usable. But when you face the real world, when you want support, there is nobody there. There is somebody that probably doesn't have a clue what is your problem. It's that bad.

Arturs Sosins: I'm sure. You, as a JS Classes admin, do you know if there are at least any classes that are Web Components actually? Or something like that?

Manuel Lemos: I think none. It's not that JS Classes is big, but none. But there is a package that try to emulate the ripple effect as we comment of the Material Design components, Polymer, or whatever its right name. So it emulated it but it doesn't use Material Design. It's just emulation of a visual effect.

So that's all for...

Manuel Lemos: No, no. So probably the guy's opinion, Components are endangered species is probably accurate. Oh, never mind. Probably, I'm not relying on them because I need to have control over my projects. If they're not working, it should be my fault, but I should be able to determine why they are not allowing me. At least, the Polymer implementation.

Don't use || to set default values in JavaScript (17:16)

Manuel Lemos: Anyway, moving on to the next topic on which we are going to talk just a very simple advice that I agree, and that I have tried using in the past and then got confusing and stopped using it, which is..

Arturs Sosins: And I do not agree.

Manuel Lemos: Personally, I don't use... I tried to use it several times, but then, "Oh, this won't work in this case," which is the use of the || operator to get default values for function. So if you don't pass a value to a function, a parameter, it will become undefined, and it would put the parameter name or some other value if it is undefined, the whole expression evaluate this value which would be taken as a default.

I think it is interesting but as the guy says in the article, this is not very readable. Well, not really readable for those that never tried it before, but the idea is to pay attention because if we have something like zero or false or an empty string, they evaluate false. So even if you pass those values there, they are taken as if they did not pass them there. That's the reason why he does not recommend to use this.

Arturs Sosins: Well, that's all correct. But I'm still kind of, like all the shorthanded version, you could write code shorthand and try to use it, helps to write code faster, and I think it's understandable.

Yes, there are situations where it won't work as you expected, but there are cases when you can use it normally. Most probably, I usually use it for enumeration types, like when I have enumerated sets of values and I know that no one would evaluate of them, I suppose. Then, I could use this operator to set a default value.

Since ECMAScript 2015 which should be able to provide default values in the function definition, it should not be troublesome.

Manuel Lemos: Well, but are you using ECMAScript 6 anyway?

Arturs Sosins: Not yet, yeah.

Manuel Lemos: Yeah. Are you going to use Babel?

Arturs Sosins: I think it would be easier with Node.js rather than with browser JavaScript because it probably just will be a specific Node.js version which will start with ECMAScript and it should...

Manuel Lemos: Right. You have more control.

Arturs Sosins: Yeah.

How to Debug JavaScript Remotely With Vorlon.js (20:20)

Manuel Lemos: Well, anyway, moving on to the next topic on which we are going to talk about the library that I didn't know, called VorlonJS, which should enable you to debug JavaScript remotely.

I didn't know about this. Arturs, did you know about this library... VorlonJS?

Arturs Sosins: No. Actually, I remember quite recently. NO, not that recent, maybe half a year ago... I needed to debug specific JavaScript code on to the mobile device. It was not working on Android standard browser for example, and it was so hard to do that. I could not find any good library that would help me with that.

With Apple devices, it is easier because you can debug it from Safari on Mac, but with Android, it was quite impossible, so if I would have known about it or maybe it was not yet through it then. It should help with this stuff a lot, and it's really annoying to debug specific stuff that does not work on mobile phones, for example.

So the way I see it, as it works, I did not try it, but from just skimming through the article, then it's a Node.js server that uses Socket.IO to connect to server from... Basically, you encode the VorlonJS script in your website and it connects to your local server, and through that connection, you can debug, inspect elements and see console output, just like in your browser.

It seems to be easy to set up, and if it works as he's describing it, it's really great.

Manuel Lemos: Yeah, and this could also work to debug Cordova projects. I try to debug them with the Android tools who provides them and it's just simply no-go, I could not figure what I was doing.

Anyway, to make this work, you need to change your code, but probably just one line. You probably do it this once, and then there you go.

Arturs Sosins: Or you have it in development version and production version, you just automatically encode in development version, stuff like that.

Manuel Lemos: Yeah, that's it. Well, I think there is hardly more time to take a look.

Overcoming JavaScript Framework Fatigue (22:54)

Manuel Lemos: So, moving on to the next topic on which we are going to comment about... let me scroll here, I'll put it in place... something that I'm sure all JavaScript developers went through which is to make up your own mind about what libraries are you going to use.

Are you going to use frameworks? If it's frameworks, are you going to write it all from the scratch and deal with it? Or, are you going to pick one of many libraries?

This is really annoying because now that everybody and his mother wants to develop their own framework, there are many frameworks and many of them are very popular. When you look at it, you don't know which one you should use for each case that you want to deal.

So in this article, the author overcome the framework fatigue, gives some advice like telling people that things will change, so you have to keep up with things that change.

Arturs Sosins: To keep up with things that change...

Manuel Lemos: Yeah. You just listen to the podcast and become even more confused what to use. Plus, we're just giving here are things but there are millions out there that have their own opinions. Basically, you have to keep up with the things that you may use or not and decide for yourself.

Also, another comment is that it says that just because some libraries seems to be an alternative to another library doesn't mean that one of them is necessarily better, everyone has value.

Arturs Sosins: ...for example.

Manuel Lemos: Yeah, don't tell me about those because I really don't even bother to study them.

Arturs Sosins: Oh, really?

Manuel Lemos: Yeah.

Arturs Sosins: It works great when you get to know them.

Manuel Lemos: Yeah, for now, I am in that phase that I decided that, well, I'm going to do most things on my own so I have control. But probably I'll rewrite it later, but that's some other story.

Arturs Sosins: Says the guy who owns the JS Classes Web site of reusable components.

Manuel Lemos: But at least, I use Bootstrap. And Bootstrap is jQuery, so we ended falling to the jQuery benefits or trap, or whatever you want to call it, good or bad.

Arturs Sosins: There is no... No, OK, there are alternatives to jQuery like Prototype, for example. Yeah, there are also alternatives, true.

Manuel Lemos: There are several alternatives, Zepto and others, but it's a struggle. Well, let's deal with one project at a time. Probably, we use some library in one project and future project, "Oh, no I'm going to use something else."

How to Create a Node.js Cluster for Speeding Up Your Apps (26:31)

Manuel Lemos: OK, moving on to another topic, and this is more about Node.js. It is interesting because it somehow teaches how to get over...

Arturs Sosins: How to make Node.js better than PHP.

Manuel Lemos: No, I don't know if it will be better. At least make it work the same because the idea here is to create a cluster of processes to deal with simultaneous request but then do not rely on asynchronous I/O to deal with the problems that could eventually come up. For instance, you lose some intensive processing on request and probably will delay all the other request. So the idea is to have a cluster.

So this is a built-in Node.js module right?

Arturs Sosins: Well, yeah, it's a core module that comes together with any Node.js installation. The basic idea, the usual usage is to spawn so many processes as there are CPUs in your server. So each CPU will handle a single process, so it could handle a separate request separately.

So you can fork them. You can trace them. You can see if any of them stops so you can re-fork them again, like you turn an error or something like that. You can message between them if needed.

But there are some down sides to it, too. For example, they would have separate global scopes, so if you would want to have some shared configurations, shared values between them, you would have to store it either into file on database or something like that.

So it's also something that you need to anticipate with working with multiple processes, but... Oh, no, I think that's standard procedure for all the Node.js services I see, is to spawn its own processes as much as there are CPUs and thus handle much bigger loads.

Manuel Lemos: I don't know if that logic is very good because just because you have as many processes as CPUs, it doesn't mean that all CPUs will always be available to Node.js because there are other things running on the machine.

Arturs Sosins: Yeah, if it's your server, then there are not much additional things running. But, yeah, it's actually true, what you said, because on some recommendations I read that you need to spawn one less process than you have CPU, so the master cluster would use the one process and other spawners would use the other CPUs. It would scale more eventually and not have a master cluster and another process on the same CPU.

Manuel Lemos: And you also have to take in account that each process will take its own memory space, and if you create more process than you have in RAM, it will start using the swap and it will slow down. So, also, you have to be careful with that.

Arturs Sosins: There is actually a limit of I think... What was that? One process, Node.js process can take up to 1 gigabyte or 2 gigabytes of...

Manuel Lemos: Yeah, but it's not like every request will take 1 gigabyte of RAM.

Arturs Sosins: Yeah, but it is per process. So it can't use more than that, so if you have like four processes and 8 gigabytes of RAM, it should be...

Manuel Lemos: Yeah, because each process will deal with more than one simultaneous request, because it's all asynchronous. While one is serving the file, the other can be processing the next request. It's all the same process.

But OK, this is an interesting topic, but it's not a trivial one to understand all the nuances, but there is this nice article here that gives you some ideas to things that you should be concerned.

Arturs Sosins: How to do it, yeah.

Bower versus NPM: Doubling Down on npm (31:11)

Manuel Lemos: So moving on to the next topic, we're going to talk about the problem of the installers. Shall we use Bower or shall we use NPM? Last time I did this, I used NPM to install power and then use Bower to install everything else. Except maybe fork a few things.

Arturs Sosins: On the client-side JavaScript, right?

Manuel Lemos: Well, yes, yes. That's what I... Client-side, including Cordova projects that you can also think of client-side because all the code runs on one side if you can call it the client. Well, a mobile device is still a client.

So the idea of this article is to stick to everything on NPM. Probably, it would be a good solution if everybody followed it, right? Because sometimes, you go to a site, let's say a tutorial about Bootstrap, you take a look at that, "Oh, use Bower to install it." And then, you realize that you need...

Arturs Sosins: You need to install NPM to install Bower.

Manuel Lemos: Yeah. Well, that's always the case. But from then on, which one are you going to install what? Bower is typical for client-side projects, and NPM is typically for Node.js projects, regardless if you can call them server-side or browser-side.

So this article was telling you that you can run both, but ideally, you'd use NPM alone.

Arturs Sosins: Since I think they announced a Beta of the NPM 3 release, and as far as I understood, that it would also support installing client-side browser, so it would replace Bowers functionality. But it's still in Beta, and I didn't try, don't know how it works.

Because, well, when comparing to current situation that you could use NPM and Bower, then Bower installs it in different directory that you could automatically make public available from the browser side, so you could include those JavaScripts, and it could be handy.

But if NPM would put all of them in single directory, again it would be a mess to understand which is meant for client-side, which isn't meant for server-side and how it all ties up together.

Manuel Lemos: Like the previous article said, you have to evaluate one project at a time and then you decide which one.

JSHint: A Formal Commitment to New Language Features (34:31)

Manuel Lemos: Now, we're going to talk about one last topic about these things that'd been published recently, which is an article on the JSHint site, telling which version of ECMAScript they will support or not, because there are people who want them to support the more recent versions, it seems ECMAScript 6 was renamed an ECMAScript 2015.

The position that they announced in this article is only support language extensions that are at least at "Stage 2" of TC-39's standardization process.

From what I got from this, this is like saying the specification should be at a mature level. So they are not going to check the code, everything else in your code, at the level of the language that is not yet mature, because it probably can change. That's basically what they are saying here.

Personally, I agree. What do you think, Arturs?

Arturs Sosins: Yeah, that's one of the thing, that it be mature. Other thing, that JSHint is an open-source project and with new ECMAScript changes, there are lots of things which breaks the JavaScript syntax as it is... new key words, new ways to define functions.

I think it would be really hard to implement them in JSHint as it is now. Doing it just so it might change later again would be really a waste of time for developers working for free for open-source project.

Manuel Lemos: Right, right. They should focus on a stable target, not something, "Oh, it's going to change next week."

Arturs Sosins: Yeah. It would be actually cool if JSHint would have plugins to do something like that. But also, as it's described in this blog post, then it's really hard to implement in this state of JSHint plugin menu.

Manuel Lemos: right. Probably, very complex.

JavaScript Innovation Award Nominees of May 2015 and Rankings (37:13)

Manuel Lemos: Well, with this, we practically reached a section of the podcast on which we would comment on the Innovation Award nominees and rankings.

If you are seeing this, it's because there was a problem with Google that didn't allow us to download and edit the video, so we can assemble parts of what we already mentioned in the PHP Classes podcast that also covers the Innovation Award winners of JavaScript world.

So, if you are seeing this, it's because Google did not fix the bug that prevent us to download and edit the video anyway that we want.

Arturs Sosins: Oh, there.

Manuel Lemos: Exactly, we need to go and check what we said in the other podcast that would be published in the PHP Classes site, because it's presently part of what we said.

If you are actually seeing this, it's because there is no recording of the edited one, and you need to go and see the other recording. So far, Google did not fix the problem. We don't know if by the time we publish this, the problem would be fixed, so we can't edit the videos.

Conclusion (38:54)

So with this, we practically ended this podcast. Many topics were covered today, very interesting ones.

Well, on my behalf, that is all for now. Bye.

Arturs Sosins: Bye.

[Music]