Cay Horstmann

Is your question how to run Mocha from inside VS Code? Would this article help?

Cheers,

Cay

Thanks for having me, and don't hesitate to drop me an email if you have further questions.

Cheers,

Cay

For web design, check out Chrome's code coverage tool: https://developers.google.com/web/tools/chrome-devtools/coverage/

Hi Paul,

I purposefully do not cover specific libraries other than those that are ECMA-standardized. I don't want to rewrite the book whenever the library landscape changes, which seems to happen with distressing regularity.

As for jQuery, I stopped using it some time ago. I actually write a fair amount of "no library" web UI, and found that you can target all non-IE browsers just fine with a single code base. (Except of course for the !@#$ iPad. Don't get me going.) If you are still using jQuery, visit http://youmightnotneedjquery.com/ and see if you actually need it.

Of course, most people use a UI framework: React, Angular, Vue, etc. If you do front-end work, you'll need to learn one of them. Resistance is futile.

I just realized that the Google search "javascript frameworks 2020" produces an unending stream of information-free articles, each with shallow observations about mostly the same frameworks. Pages and pages of those articles. Maybe Google has some AI that produces them faster than I can scroll.

Cheers,

Cay

Hi Krystian, it is indeed the same style. Why mess with a winning format :-)

There is a sample chapter at the InformIT site, or if you have a Safari Books subscription, you can check it out there.

Cheers,

Cay

Which coding standard are you following? E.g. https://standardjs.com/ has a VS Code plugin: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs. (Includes support for automatic formatting.)

I think Visual Studio Code is a good choice for JavaScript. I've never seen the need for a JS IDE, but I am interested in hearing what others say.

Cheers,

Cay

I suppose somewhere out there someone must still support IE. In the market where I work (educational software), there has been zero pushback in the last three years to exclude IE from the list of supported browsers. More tellingly, Microsoft's Office cloud apps will no longer work with IE.

I dislike interview questions that probe things that programmers should not normally be doing--like asking what the value of [3] * true is. But here are a few questions that I think are pretty good.

1. What is a after the following?
let a = [1, 2, 3, 4] for (i in a) { if (i > 0) a[i - 1] = a[i] }

This just tests understanding of the in operator.

2. What is a after the following?
let a = [1, 2, 3, 4] for (i in a) { a[i - 1] = a[i] }

That's more interesting. What happens with a[-1]?

3. How about
let a = [1, 2, 3, 4] for (i in a) { if (i !== 0) a[i - 1] = a[i] }

This brings up an interesting fact about array indexes...which should allow the candidate to ace the following:

4. What is a after the following?
let a = [1, 2, 3, 4] for (i in a) { if (i < a.length - 1) a[i] = a[i + 1] }

Which brings up the depressing reality how hard it is to avoid cruft from the ages.

In Java, we use null for a reference to no object. JavaScript gives us two "bottom" values: null and undefined.

When I first learned JavaScript, I dutifully tried to make a distinction between "intentionally non-existent" (null) and "non-existent for some other reason" (undefined). But I always ended up in pointless metaphysical discussions and gave up. Now I always use undefined, except of course, when an API gives me null.

I am curious how others feel about this.

Cheers,

Cay

It may be that the most common approach is to check if (!a), but it does not mean that it is a good approach.

That test also passes if a is 0 or "", which can really bite you if that's not what you expect.

If you write what you mean, your code will work and it will be comprehensible. If you need to check for null, the best solution is if (a === null).

Cheers,

Cay

That's another sweet thing about modern JavaScript. You don't worry about IE.

We agree on the Java version. But back to JavaScript.

Looking at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String, there is nothing about counting code points. You could loop over the code points

{let i=0;let l=0;while(i<s.length){l++;i+=s.codePointAt(i)<65536?1:2}return l} >

That's 78 characters.

What about regular expressions? I can get it down to 42 characters by replacing all matches of /[ -\uFFFF]/ug

Cheers,

Cay

Ok, maybe we need firmer ground rules.

In Java, you need 44 characters just for

public static int length(String s){return ;}

Then you can complete the function with another 27 characters. (At least that's the shortest that I can come up with.)

In JavaScript, you need 14 characters for

let length=s=>

and then you can complete the function with another 13 characters. (At least that's the shortest that I can come up with.)

Cheers,

Cay

Hi Scot, that is a good question. When I had to learn JavaScript in a hurry, I looked at a lot of online information. It is astounding how much there is, and how incomplete and depressingly inaccurate much of it can be. Also, so many posts focus on "new in ES x", assuming that you know what came before. That's where a book still has the edge. An author has to think through the facts and present them in an accessible way, and there is a team of reviewers to spot inaccuracies.

There is some good stuff online. I think the best online material is Axel Rauschmayer's https://exploringjs.com. Maybe you all can add your favorites.

Cheers,

Cay

Of course, safety is a big subject. But let's start with the basics. When you use a language that isn't statically typed, it is much more common to write code that runs and then does something unintended. JavaScript makes it worse by silently allowing type conversions instead of throwing an exception. Lots of values can be converted to numbers, and everything can be converted to strings, and there are confusing rules what gets converted when.

My recommendation is to program as if you used a statically typed language. In your head, and in your documentation, have a fixed type for each variable, function parameter and return value. And don't rely on conversions.

It is ok to say "this parameter is a string or a list of strings". That is common in JavaScript. Just be sure to document it.

I draw the line at "this parameter is a number or a string containing a number". Just constrain it to a number, and pass parseFloat(str) if you have a string.

And it pays off to be very clear about "string or undefined", or "string or null", or "string or null or undefined". Don't be tempted by shortcuts with == or "Boolishness".  

Isn't that an advertisement for TypeScript? It would be if TypeScript was better aligned with modern JavaScript.

Of course, getting the types right is only one part of safety. You still have to worry about cross-site risks, cookie theft, injection attacks, etc. That is independent of the language.

Cheers,

Cay