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.

Chapter 2

Difficulty Copy/Pasting Code Snippets

This is not related to a specific part of this chapter (or any chapter, per se), but it is very difficult to copy any code from the examples from the PDF. Copy-pasting a block of HTML, let's say, will result in a minified version of the example listing with a bunch of ^M's (literal newlines). I am not sure if this is an intentional behavior to force the read to write everything out themselves explicitly, or if it only affects macOS users like myself, but I thought I would bring it up.


Directory Structure

2.1.1 Structuring Our Electron Application

In this book, we’ll put all of our applications in an ./app directory and all of our static assets in an assets directory. For our purposes, let’s agree upon a file structure for the remainder of this book. We’ll have an app directory where we’ll store all of our application code. We’ll have an assets directory where we keep our static assets like style sheets and images.

This is just a comment on consistency. I noticed here that we are agreeing to create an assets directory for stylesheets and images, but we never end up creating that directory. Perhaps in Chapter 2, this could just be a simple grammatical mistake in Listing 2.10, which says to create our stylesheet under app/style.css, and instead meant to say assets/style.css. But, looking ahead, the folder structure of Chapter 3's Fire Sale application also does not make use of an assets directory (style.css is placed alongside the other app files under lib/).

I am not going to offer any advice on the "proper" way to organize a folder structure (mostly because I don't have super strong opinions that can be objectively backed up, but also because there is no "proper" organization for Electron apps as has been stated, but mostly because this can easily turn into a bikeshedding discussion), but I would like to point it out for the sake of consistency.


Label vs. Placeholder - HTML Input Accessibility

2.4 Implementing the User Interface

The HTML of Listing 2.12 looks very semantically elegant; I love seeing the use of things like <section> instead of <div>. The only thing I would comment on is, if we are shooting for the most semantically accurate and accessible code, using a <label> with our "new-link-url" <input> would be a better option than using the "placeholder" attribute.

The "placeholder" attribute has a poor contrast ratio by default (harder to read), keyboard users must read ahead of the current focus to see what the <input> is asking for, some older screen readers do not understand "placeholder", and the WCAG specification even notes that "placeholder" should not be used as a substitute for a <label>. Not only is this semantically less useful, but even from a standard user's viewpoint placeholders can be a pain as they obscure the purpose of the input once tabbed into that field (see:

I recognize that this application is incredibly small and thus one could argue "who cares?", but it's more the principle and promotion of accessibility that is meaningful and worth talking about.


Links to External Resources

2.4.2 Parsing Responses

Having links to the APIs of things such as Chromium's DOMParser, along with other external references, could be nice to have in a footnote perhaps. At least on the PDF version, where links are clickable within the document.


Overall, this chapter is extremely well written. It has a great sense of flow, it talks clearly and plainly about what Electron is (and is not), it shows off the undeniable glamour of Electron (e.g. Node vars and browser APIs in the same script files, a module system for client-side code with no build tools), and introduces the reader to the technology with a simple app they can walk away with that they built themselves. All fantastic.

I appreciate you taking the time to read this.

Onwards, to Chapter 3 (!
323720 (4) [Avatar] Offline
Functions or Variables?

Listing 2.15 Add helper function to clear output

code is entered here as

const clearForm=() =>{
newLinkUrl.value = null;

Listing 2.21 Current contents of app/renderer.js now has all the functions declared as functions not variables. please clarify.

function clearForm() {
newLinkUrl.value = null;
Steve Kinney (33) [Avatar] Offline
It should be variables. Let me double check what happened. At one point I decided to update the code style to be more consistent with the Electron documentation (which I updated to ES6).
323720 (4) [Avatar] Offline
xboxremote (6) [Avatar] Offline
Just curious - why variables and not functions? Is there any reason other than how it reads?

xboxremote (6) [Avatar] Offline
Nevermind - I got a pretty good explanation here:

I guess the biggest advantage is the immutability it brings to functions.
586835 (2) [Avatar] Offline
Just to add my feedback after reading and co-coding chapter 02

2.1.1 Structuring Our Electron Application

I, too, find it most irritating that we do NOT use the structure we just agreed on.

2.1.3. Downloading and Installing Electron in Our Project

Figure 2.4 and the feature of an application icon is not working under Linux, it seems. After a quick search this is a known limitation as long as the icon as no context-menu, as far as I understood. Anyhow, this should be clearly stated as many readers are supposed to work on Linux.

2.3 Creating a Renderer Process

Why do we use the
method if there exists a
method that is better suited for the job at hand and is semantically more correct as we are indeed including a file and not a web resource? I propose to switch to loadFile.

2.4.2 Parsing Response

Some code statements are not closed/ended with a semicolon, see Listing 2.19 and 2.21

Great work so far!

Steve Kinney (33) [Avatar] Offline

I agree on 2.1.1—it looks like I changed the file structure to match future applications and missed fixing this prose, missed fixing it again in the proofing, and so on. I'll get that paragraph adjusted. Thanks for pointing that out!

With [loadFile] and [loadURL]—that makes sense. [loadFile] is new and didn't exist when I first wrote the chapters and not something I originally noticed when it was added as a method. The book is going through typesetting now, but let me see if I can still squeeze that change it.

I'll also follow up on the semi-colons and Linux icon.