The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

indiesquidge (2) [Avatar] Offline
Let's preface all of these reviews with the fact that this book thus far has been absolutely incredible. Steve Kinney is by far and away one of the best teachers I've ever had, extending well beyond this book to when I was first learning to write software and attended the Turing School where Steve is an instructor. His ability and propensity to teach has continued to be of unparalleled value as I learn and grow as a developer. Thank you so much for being awesome, Steve.


My goal is to try and refrain from correcting simple grammatical mistakes as I realize this book is in an early draft and will be put under linguistic and semantic scrutiny later in it's lifetime.

I would instead like to focus on high-level things, such as the flow of the chapter, the level of accessibility and inclusive design in the markup, confusions I may have about the way something is written, and perhaps certain errors I ran into that could lead others astray.

I will be doing these reviews chapter by chapter, so I apologize if something I remark is explained or corrected in a later chapter. I will do my best to return to these reviews if new information about a given critique or praise is brought to light. The reason I am choosing to do chapter by chapter is because

1) it will help keep the overall forum post smaller, which is easier to digest for other readers;
2) I'd like to present my commentary in a timely manner so that the author and editors will have time to look at it; and
3) hopefully, each chapter review post could start a containerized thread for all issues related to that chapter, thus creating a more central location for discovering material on a given chapter and avoiding duplicate posts.

(My review of Chapter 2 can be found here:

Chapter 3

Absolute Position on Body Element

Listing 3.3 Styling

body {
  margin: 0;
  padding: 0;
  position: absolute;

This is more of an inquiry than a critique, as I'm simply curious as to why one would set the position: absolute; on the <body> element. The only "answers" around this I can find is that it was to fix an IE 5.X bug when centering content, but that's obviously not an issue with our Electron app since we don't have to worry about cross browser support (yay!). (And also because who is still coding for IE 5? Lol.)

I'd just love an explanation as to when this would be useful, as I'm always curious about CSS quirks (I didn't know what the box-sizing: border-box; was useful for until about a month ago).


Using System Fonts

Listing 3.3 Styling

body, input {
  font: menu;

This is also not an appraisal of Chapter 3, directly, but rather than ambiguous drawbacks to the current state of trying to use system fonts.

The links below are definitely worth checking out and do a fantastic job of explaining different approaches and drawbacks to implementing system fonts.

The drawbacks for simply using font: menu; are largely based around mobile and different browser vendors, neither of which affect Electron apps. But it's worth noting in case you plan on taking the code here and trying to enforce the use of system fonts on other, non-Electron projects.



Removing an Element's Focus Indicator is an Anti-Pattern

Near the end of Section 3.3

By setting outline to none, we remove the unnatural glow around the active element.

textarea, input, div, button {
  outline: none;
  margin: 0;

This gets back to the point about accessibility. Without a focus indicator, how is a keyboard user supposed to tell which item they are interacting with? The WebAIM checklist states that it should be visually apparent which page element has the current keyboard focus (see: Sometimes the blue focus ring doesn't fit in with the design (e.g. if it's on a blue background, if it awkwardly wraps around elements like radio checklists, etc.), and obviously it can just seem super ugly, but if one is going to remove the focus ring because they don't like how it looks, it needs to be replaced with another consistent focus indicator.

One solution could be to use a box-shadow instead of an outline. (This is actually preferred since some browser vendors style the outline property slightly differently and just changing the outline color may not produce a consistent experience.) Something like this

textarea, input, button {
  margin: 0;

button:focus {
  outline: 0;
  box-shadow: 2px 2px 8px 2px rgb(144, 182, 177);

Note that we don't need the outline: none; now since we are targeting the :focus pseudo-selector, and we also don't need to include div in our list, as that is not a focusable element anyway.


I highly recommend people check out Udacity's course on Web Accessibility. This video in particular is very relevant to this situation (!/c-ud891/l-8085130355/m-8091490405).


Transition to Debugging Section is Jarring

3.5 Debugging an Electron application

I'd be curious to know what others have to say about this, but I personally felt like including the section on debugging at the end of this chapter was strange. In my opinion, one of the best ways to learn is to recognize a problem and have the capacity to articulate it before trying to implement a solution. There is nothing wrong with our Fire Sale app at this point, why are we all of a sudden learning how to debug something that is, for all intents and purposes, behaving just fine? I personally don't believe section 3.5 should be in Chapter 3; it should arrive in a more natural way; that is, once we encounter an error worth debugging in our application.


Configuring a New Task Runner

Figure 3.11

The first time a user selects the Tasks: Configure Task Runner command, VS Code will prompt her to choose from a list of task runner templates.

It's worth noting that the user should select Others in order to create a task which runs an external command.




Another wonderful chapter full of new information to soak up smilie

I absolutely love the use of numbered markers used in code snippets that are referenced in an explanations about that piece of code below. I first saw this in Secrets of the JavaScript Ninja and personally, I believe it is a wonder technique. It allows the writer to include large blocks of (possibly new and confusing) code and refer to parts of that code block later. As opposed to having to split the code block into many small parts and explaining everything along the way. This is often harder to read and focus can be muddled rather quickly. Nice job with that.

I appreciate you taking the time to read this.

Onwards, to Chapter 4!
yoonghm (12) [Avatar] Offline
Figure 3.7 "pain" -> "pane"
138211 (1) [Avatar] Offline
Late to the game but didn't want to create a new "Chapter 3" thread when there was already a great one here

One of the things that jumped out at me right at the start of the chapter in 3.2 is this:

In order to quickly generate this the app folder on a UNIX-based operating system. Alternatively, you can check out the master branch for this project on Github at

If you check out that repo... there is no file structure, the very next thing is a list of commands to generate the structure... which begs the question how does checking out the github repo "quickly generate this" when its primarily an empty repo sans the README and license?
Steve Kinney (33) [Avatar] Offline
@138211 That's fair. I'll update the prose.
12722 (1) [Avatar] Offline
Also replying here instead of starting a new thread.

I use WebStorm. The process for configuring WebStorm to support debugging the main process is fairly straightforward. This blog post from JetBrains outlines the steps: (Search for or scroll down to "Running and debugging Electron app.")
Steve Kinney (33) [Avatar] Offline
Awesome, thanks! I added this link to Chapter 3!
586835 (2) [Avatar] Offline
Me again,

proposed config in chapter 3 for debugging is not working - at least for me and my litte Unix system.

The official solution now looks like this, anyway:

    "version": "0.2.0",
    "configurations": [
        "name": "Debug Main Process",
        "type": "node",
        "request": "launch",
        "cwd": "${workspaceRoot}",
        "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
        "windows": {
          "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd"
        "args" : ["."]

This solution works fine.

The most obvious difference to the proposed launch.JSON in the book is the missing of the "protocol" attribute/property. So maybe you want to check and update your instructions according to the aforementioned source.
Steve Kinney (33) [Avatar] Offline
Thanks! I'll look into it. This part has changed like 100 times since I first started writing the chapter. I should have just taken it out completely, but oh well. smilie