Voice Controlled Web Apps Pt. 2 (Windows)

NodeJS, Client Side Javascript, and Google Speech API

Part 2 in a 5 part series. Part 1 is here.

This section of the tutorial introduces “client side javascript” — running code alongside HTML in a web browser. We won’t be building a beautiful site. Instead, I’m going to introduce as little as possible to get results so you can move onto controlling lamps and motors and other internet-connected-things. Hopefully you can combine this with your own knowledge or other tutorials to build the application you want.

At this point you should have two files, a server.js and an index.html sitting in the same directory.

https://gist.github.com/jazzyjackson/6ae764d24ead285f9ba1https://gist.github.com/jazzyjackson/fed240a94065486427fa

For this part, we’ll just be working with index.html, so you could simply point your web browser to C:/your/file/path/index.html and it will work fine, but why not get in the habit of starting your node server? You’ll see changes to index.html reflected when you refresh the page either way.

The history of HTML is a jumbled one with many actors. Lots of people were taking stabs at building websites and lots of people were writing web browsers that did their best to render a useable website from everyone else’s code. The modern day result of this is that the web browser is a very forgiving platform that lets you leave all kinds of stuff out, and lets mistakes go without complaining too much. That’s actually one reason why I’ve heard some people discourage javascript as a first programming language: you can make a lot of mistakes and there’s not a compiler to tell you what you did wrong, the web browser will try to run anything it can and ignore whatever doesn’t work.

Use the “Inspect element” to find out how Chrome interpreted our 4 lines of HTML:


Our file only contained <h1> tags and the <script> tags. <html>,<head>, <body>, and this mysterious “#shadow-root” were all added by the web browser before rendering. On top of that, in the bottom-center there’s styling added on to the <h1> element: all of this display: block; font-size: 2em; -webkit-margin-before etc. is added by Chrome to make our barebones HTML code look presentable. So like I said, you can leave a lot out and modern web browsers will figure out how to render your page anyway.

OK, I promised an interactive web page, so let’s change that header <h1> into a button <button>. If you don’t know: in lots of text editors Ctrl+H will bring up a “find and replace” menu. We’ll also add an “id” attribute inside the opening button tag: this is a name you give individual elements so you can write javascript that acts (or listens to) those elements.


Here, ‘onclick’ listens to that ‘myButton’ element, ready to react to a click at any moment. This is different than, for instance, programming an Arduino, where we’d have to check whether a button is pressed continuously in an infinite loop. Instead, we can write a function that executes only in response to the web browser noticing that the user clicked their mouse while hovering over the button element. This is “Event driven programming.” (You actually can do event driven programming with Arduino, if you know about hardware interrupts.)

While chaining those identifiers and functions all together on one line works OK, programming like that quickly gets hard to read. It’s much better practice to break it into pieces.

https://gist.github.com/jazzyjackson/485a3e771b6488f85f77

  1. Create a variable called button and assign it the myButton element.
  2. Create a function called speak, which calls on the alert function to say hi.
  3. Attach the ‘onclick’ event listener to the button variable and assign the function named ‘speak’ as its action.

I included two ways you could create the speak function here that would work equivelantlly in this case. There are specific cases where you should choose one or the other that involve global vs local scope (great info on the subject here), but for now it’s just important to know that there’s more than one way to do it. Hopefully keeping that in mind will make reading other people’s javascript examples less confusing.

Buttons default to ‘block-inline’ style, and appear on the same line

Let’s move on to a button that changes the background — this will set us up for turning a lamp on and off. The buttons have separate IDs, and each button is assigned to a new javascript variable.

https://gist.github.com/jazzyjackson/b6b0ca575a6d295bcc6c

Header elements default to ‘block’ style and appear on separate lines

By the way, you don’t have to have a button element to be able to click on it. I like the look of h1 better, so I’ll just click on those. I’ll change the color style of the h1 elements with each click as well. (side effect: button elements default to a block-inline style whereas header elements default to block style)

https://gist.github.com/jazzyjackson/f5b280709ea785d8812b

In the next section, we’ll plug a lamp into an Arduino:


Recommended Reading:

http://eloquentjavascript.net/13_dom.html
http://eloquentjavascript.net/13_dom.html

Note: “Handling Events” recommends using ‘addEventListener’ instead of ‘onclick’, which is a better way to do it. Onclick events are limited to one-per-element, whereas you can ‘addEventListeners’ as much as you want. But for a simple example I like the syntax of .onclick better.

Leave a Reply

Your email address will not be published. Required fields are marked *