HTML5, CSS3, jQuery, JSON, Responsive Design...

State Of JS 2018 — Bad News for Angular

Michael Brown  December 3 2018 04:00:30 AM
By me on Medium.

The 2018 State of JS Survey results are now out, and they had some harsh home truths for Angular, saying "it’s hard to see how it will ever regain its place atop the front-end throne".

They report that 33.8% of Devs who'd used Angular would never use it again.  That's compared to only 6.7% saying the same for React and 2.8% for Vue.

Chromebook Linux Apps for Web Developers! (Medium)

Michael Brown  November 24 2018 08:57:36 PM
By me, on Medium.


By junking a Linux dual-boot or Crouton, I got back 4 Gig of storage from my Chromebook.  But I was able to do some proper Web Development, with Node/NPM, Git, SSH,  SublimeText and the GIMP installed as native Linux apps!

Your code’s bug-free, or maybe not. Don’t trust Angular to tell you either way!

Michael Brown  September 28 2018 04:27:03 PM
My article on Medium.


If you don’t know what you’re doing with Angular, it may have a nasty surprise up its sleeve as you put your code into Production.  Angular's AoT (Ahead of Time) compilation mode, which is what the Angular Team tells you that you should be aiming to use for your Production builds, will flag errors in your code that its default JIT (Just in Time) mode doesn't!!!

Your code’s bug-free, or maybe not. Don’t trust Angular to tell you either way!

Running node/npm scripts sequentially on Windows

Michael Brown  May 5 2018 10:44:06 PM
Note: this same article also published on Medium yesterday.

So this is how I’ve traditionally been running node/npm scripts in my package.json file:

"scripts": {
"testRun": "node ./runtest.js && node ./runreports.js",

So running npm run testRun or yarn testRun will run the runtest.js script followed by the runreport.js script…sometimes! The catch is that the && part of this formulation is actually a Boolean logical AND. Which means if the first script returns an error code, such as Exit code (1) it evaluates to false and so the second script won’t run at all.

So I tried changing it from a logical AND to a logical OR, like so:

"scripts": {
"testRun": "node ./runtest.js || node ./runreports.js",

Now my second script runs when the first one errors, but it only runs if that’s the case. If the first script doesn’t return an error then the second one doesn’t run now; not much of an improvement!

Googling around, it seems that a semi-colon is the correct syntax for the second script to run irrespective of what the first one does, e.g:

"scripts”": {
"testRun": "node ./runtest.js; node ./runreports.js",

Great! Or it is if you’re running a unix-style OS such as Mac OS X or Linux. Unfortunately, I was using Windows due to my having committed terrible sins in a former life. Sadly, the semi-colon syntax just won’t work on Windows, because it’s, well…Windows. (Note: I was using the Git Bash shell on Windows 7. I understand that Windows 10 has a proper bash shell of some sort, so maybe the semi-colon syntax does work there.)

I thought about it some more and it occurred to me that because it’s Boolean logic problem, then there ought to be some kind of Boolean logic solution. Indeed, there was!

Now in boolean logic something OR true always results in true, e.g:

true OR true = true
true OR false = true
false OR true = true

Applying that logic to my package.json script, I came up with this:

"scripts": {
testRun: "(node ./runtest.js || true) && node ./runreports.js",

By wrapping the first script call with in some brackets and Boolean ORing it with a true, the result of that bracketed section must always be true. Now my runreports.js script will run no matter what the runtest.js script does.

Further Reading:

(Includes a comment from me, offering the solution above. Strangely, nobody there has recognised my genius thus far, but it’s surely only a matter of time!)

Develop React Native apps on a Chromebook

Michael Brown  October 22 2017 09:08:14 PM
Surley it's not possible to develop Android and iOS apps using React-Native on a Chromebook, right?  Well, it is!  Kind of...if you cheat a bit!

First off, you'll need to enable Developer Mode on your Chromebook and then install a full Linux desktop environment, either as a dual boot or as a crouton (allows Chrome and Linux to run side by side).  See for instructions.

Next, you'll need to install Node and NPM in your Linux environment.  When you've done that, you can install the Create React Native Application (which I'll abbreviate crna from here on in) tool via NPM.  See here for instructions on how to do that:

Once you have a crna app all set up, you'll be able to have it appear on your iPhone or Android phone via a mobile app called Expo, which you'll need to download from your respective app store.  Your phone will need to be on the same wifi network that your Chromebook is on in order for this to work though.

There's one more important step for this all to work on a Chromebook though: you'll have to open the Chromebook's firewall settings to allow the two ports that Expo needs to work.  These are ports 19000 and 19001.  Here's how to do that:

Opening Chromebook Firewall Ports
  1. On your Chromebook, open Crosh tab (Ctrl->Alt->t)
  2. Type `shell` at the Crosh prompt
  3. Enter following two lines at the prompt
sudo iptables -A INPUT -i wlan0 -p tcp --dport 19000 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -i wlan0 -p tcp --dport 19001 -m state --state NEW,ESTABLISHED -j ACCEPT

That should have opened the two ports on your Chromebook firewall.  Note: these settings are not sticky.  The next time you restart your Chromebook, they'll be forgotten.  (This is actually a good thing, security wise.)   You'll just need to enter them again before starting your Linux crouton.

Now in your Linux crouton, kick off your crna bundle within it, e.g. `yarn start`, then try to connect via your phone’s Expo client (e.g. by scanning the code).

You may get a red screen, saying “Could not connect to development server” at this point.  If so, check the console on your Linux crouton and see if it’s finished building the JavaScript bundle yet.  Chances are that this will take a minute or two, unless you have a super new Chromebook Pixel!  Most Chromebook's processors won't have enough grunt to finish the compiling task that quickly, so you just need to wait a bit.  If crna is still building the bundle, wait for it to finish and then hit the reload link on your phone’s screen.

Obviously, this only gets you so far with development.  You're still limited to using the Expo app on your mobile device.  If you want to check it out natively on a device, then you have to eject from the crna environment.  You'll then need a Mac to put your iOS directly onto your iPhone/iPad, and to roll it out to the App Store.

Getting npm-check-updates to update global packages

Michael Brown  August 19 2017 09:34:25 PM
I often use the npm-check-updates package to check the whether my npm packages are up to date.  Particularly, my globally installed npm packages, such as...well, npm-check-updates itself!!!

It does have one rather annoying limitation though: -u option, which forces the packages to upgrade, only works with locally installed (i.e. at a project level) packages.  It won't work for your global packages.  So if you issue this command in your terminal (NB: ncu is an alias to npm-check-updates):

ncu -g -u

you'll see this error: ncu cannot upgrade global packages. Run npm install -g [package] to update a global package.  This is a pain, because the npm install -g command requires you specify the packages' names, and there might be a few of these.  For example, when I just ran ncu-g on my home Mac, it flagged the following packages as out of date:

create-react-app         1.3.3  →  1.4.0
create-react-native-app  0.0.6  →  1.0.0
eslint                   4.2.0  →  4.5.0
eslint-plugin-react      7.1.0  →  7.2.1
jsdoc                    3.4.3  →  3.5.4
npm                      5.0.3  →  5.3.0
prettier                 1.5.2  →  1.5.3

To update them all, I would have to type out npm install -g followed by the full list of the packages' names.  That's a lot of typing and/or copying and pasting to get the package names that I need.  So I Googled around to see if there was a way of formatting ncu's output to produce a more update friendly list.  This is the command that I found (sorry, I can't remember where now!):

ncu -g | awk '{print $1}' | paste -sd " " -

Issuing the above command gave me straightforward list of packages to update, like so:

"create-react-app create-react-native-app eslint eslint-plugin-react jsdoc npm prettier"

All I need to do is still an npm install -g in front of that string, and I'm away.

It's not a particularly easy command to remember, so you may want to put it in a script and run it from there.

    Random User Generator

    Michael Brown  July 16 2017 02:19:03 AM
    Hey, we all need one of these at some point in our Development careers!!

    The Random User Generator is, to quote their blurb: "A free, open-source API for generating random user data. Like Lorem Ipsum, but for people".  Just make an Ajax call to their API, and back will come a list of random users in JSON format (XML, CSV, or YAML).

    I came across this handy resource while checking out Spencer Carli's React Native Flatlist Demo on Github.  Here's a screenshot of that running in the iOS Simulator.

    Image:Random User Generator
    The data shown here is being pulled from the Random User Generator by an Ajax call.

    Hide the ***** footer on posts!!

    Michael Brown  March 14 2017 01:47:38 AM
    I'm a big fan of the Medium publishing platform, but hate the way that it (and its various offshoots) display a fixed footer bar.   You know, the one that says "never miss an update from [whoever]", and that has a *Get Updates* button on it?    Yeah, guys, I've got that now.  So can I please close the darned thing and get some of my screen real estate back?  It seems not; Medium doesn't give you a way of doing that.

    Add Footer Close Button Extension

    So, I put together the Add Footer Close Button extension for Google Chrome.  It adds a button that hides that footer bar whenever it detects one.  That's all it does.  There's no options.

    It currently works on itself, and also  I'll add more offshoot sites as I come across them.  (It's just a matter of updating a permissions file.) footer showing my close button

    React without build steps - Babel Standalone

    Michael Brown  January 19 2017 02:00:05 PM
    When I got started with React, over two years ago now, we had the JSX compiler tools.  All you had to do was load this JavaScript library into your HTML file, along with the React JavaScript library itself, of course, and you were done.  All of the React transpilation took place on the fly, within the browser itself.  Easy!

    I don't know what I'd have done if I'd been told that to start with React you need to install Node and NPM, then spend two hours fiddling about with your Webpack config file before you can write a line of your application code.  Something tells me though that I would not have had a positive reaction!  Unfortunately, that's largely what new developers are told to do now, since Facebook deprecated the JSX Tools in favour of Babel, and then the latter dropped their own in-browser transpilation tool (browser.js) in Babel 6.

    Fortunately, help is at hand in the shape of Babel Standalone.  To set it up, you simply add the babel.js (or babel.min.js) library to your HTML as a script tag, just after your main React and ReactDom script libraries.  Then, when loading your own JavaScript library (see simple-list.jsx in the code below) you set it type to "text/babel", then add any transpilations in the script tag's data-presets property.

    That's it; you're done!!:
    <!DOCTYPE html>
    <meta charset="utf-8" />
    <title>babel-standalone Hello World example</title>

    <div id="main"></div>
    <script src="//"></script>
    <script src="//"></script>
    <script src="//"></script>

    <script type="text/babel" data-presets="es2015, react, stage-2" src="js/simple-list.jsx"></script>

    Here's the contents of that simple-list.jsx file:
    const MyListElement = ({ listElement }) => (

    class MyList extends React.Component {
    render() {
    const { listArray } = this.props;
    const list = => {
    return <MyListElement listElement={member} />;
              <h2>Man in the High Castle Characters</h2>
              <ul>{ list }</ul>

    var myObj = window.myObj || {};
    myObj.listArray = ["Joe Blake", "Juliana Crane", "John Smith", "Frank Fink"];

          title={myObj.title} />,

    It's a very simple app, which just displays a list of characters from Amazon's superb adaptation of Philip K Dick's The Man in the High Castle.  I've implemented two React components here: MyListElement as a function component, and MyList as a full ES6 class.  (I know that  both could have been implemented as function components, since they don't require any React life cycle hooks, but I wanted to show how Babel Standalone handles both component types.)  Demo here.

    You don't get module bundling/loading, of course, because Babel is not a module loader; you'll need Webpack or Browserify for that.  So you'll have to manage the script tag order yourself, and that's a pain.  But for getting devs started, that's not a show stopper in my book.

    Angular Release Candidate 5 - "major breaking changes"???

    Michael Brown  August 31 2016 05:13:55 AM
    Who’d be an AngularJS Developer?  Well, quite a lot of people if the stats are to be believed!  But oh Lordie, they really seem to be having a really rough time it with the upgrade to Angular 2.

    I've just listened to a recent Adventures in Angular podcast, entitled Angular RC5 and Beyond.  I’m not much fan of a fan of Angular, as you can probably tell, but I like to keep up with it anyway.  If for nothing else, it’s good to have reasons to show people/bosses that moving to Angular would be a truly terrible idea.  The Angular 2 rollout is giving me plenty of those!

    Of Release Candidates

    Anyway, RC5 refers to Angular Release Candidate 5.  "Aha", I thought; "they must be pretty close to release if they're on a fifth Release Candidate!"  However, I was disabused of this thought within the first few minutes, in which we’re told that Release Candidate 5 of Angular 2 contains “major breaking changes from release candidate 4”.

    Say what?  Major breaking changes in Release Candidate?  Thankfully, a couple of Google people are on hand to explain that in GoogleLand, things work a little differently.  A Release Candidate isn't a candidate to be release, as in the gold release; you know, how the term is applied by just about every other software company in the world.  No, it seems that for Google, Release Candidates are actually the first serious test releases geared towards public consumption.   Alphas and betas are mainly for internal testing, within Google only.  Angular 1 had seven Release Candidates, apparently.   Well, that's one approach, I suppose.

    There's a telling moment about half way through the podcast.  As one of the Google guys is detailing change after change in RC5, the podcast host pauses proceedings to ask one of the other participants why he hasn’t spoken much yet.  “Oh I’m just sitting here all grumpy, thinking of all the code I have to change...across hundreds of projects”, comes the reply.  Quite so.  And I don't think he was referring to Angular 1 code, either.

    NG Modules

    One of the big new things in RC5, apparently, NG Modules.  These are a way of breaking up your application in some more manageable fragments or components.  (So like React has had from the get go then.)  It seems that Angular 1 had some kind of modules thingy in it too.  These were originally removed for Angular 2, but they’re back now.   Only they’re not quite the same as they were in Angular 1, but "it helps if you think of them that way”.


    Almost as an afterthought, the Google guy drops another bombshell during the podcast's closing moments:  "did I mention that Angular 2 is now moving from SystemJS to Webpack?", he asks, laughing at what I took to be a joke, at first.  But no, he was serious: they really are moving to Webpack.  That may be all to the good, because Webpack rocks, IMHO.  But really, they want to be making a change like that in the fifth Release Candidate?  (Oh, I forgot; they're not really really Release Candidates, are they!)