About the Author:

Why You Need Test Coverage, But Shouldn’t Trust It

November 22nd, 2017

I’ve never heard someone say that unit tests—or any kind of tests—are useless. Practically everyone agrees that testing our software is a good idea. There are objections about the amount of time it takes to set up the testing environment and create tests, but let’s assume you’ve gotten past all of that and are actually writing tests. How do we know that we’ve tested everything we need to? Tests can’t help if there are parts of your code that aren’t tested. That brings us to the topic of this article: test coverage.

What Is It?

There are tools out there—probably for every programming language, but we’ll focus on JavaScript—that run alongside your tests and track which code is executed during the tests. Don’t ask me how it’s done; it’s all magic as far as I’m concerned, but it works, even on code that is compiled/transformed as long as there are source maps available. Most of these tools are able to give you statistics on which lines, statements, and code branches have been executed, so you can know what parts of your project could use more testing.

So how do you get started with integrating test coverage tools into your testing? In some cases, such as with the Jest unit testing framework or with scaffolding tools such as Vue CLI, it’s built right in so you don’t have to do anything extra to enable code coverage, at least for your unit tests. Apart from that, you can use popular test coverage tools like IstanbulBlanket.js, or JSCover. There are also tools that go beyond plain test coverage such as Sealights, which tracks coverage statistics over time and offers other enterprise-level features. However, it has a cost, so choose one of the free and open-source projects if you’re not looking for anything super advanced. To learn how to install the tools, you’ll have to check out each individual project’s site for their instructions.

The Problem With Test Coverage

While using test coverage tools can be considered by many to be essential, there’s something you’ll need to be aware of. Just because a test coverage tool tells you that something is covered, that’s not the end of the story. Coverage simply informs you what code was executed, not whether you are adequately testing to make sure the code produced the correct outcome.

Here are a few situations where coverage can be misleading:

if (a || b) {
  foo()
} else {
  bar()
}

In this example, if you test with a being true and b being false, and do another test where they are both false, then your results will come back saying that you’ve covered 100% of this code. But you haven’t tested the case where b is true and a is false. This may or may not be important depending on your code, but it’s important to test numerous cases to ensure there are no unexpected side effects.

Here’s another example:

eventEmitter.subscribe('event', () => foo('event'))
// ... more code ...
eventEmitter.trigger('event')

If this code is run by any of your tests, then your coverage tool will report that everything is covered, but if you don’t test to ensure that the execution of that event listener had the correct effects, then it isn’t fully tested.

Conclusion

Should you still use test coverage tools since they don’t give you perfectly accurate information? Yes! They may tell you something is tested when it technically isn’t, but if they say some code isn’t covered, then it certainly isn’t covered, and you’ll know to create tests that cover that code. This is quite useful even if sometimes they can give you a false confidence in your testing. In other words, if you aren’t checking your test coverage, it is likely in your best interest to do so.

About the Author:

Build a TV Series Tracker With Electron and React

September 25th, 2017

You can’t truly learn it unless you build something useful with it.

That is the rule I always try to adhere to whenever I want to learn anything new. And by useful I mean a finished product or at least a proof of concept, which can be used by everyday people.

When I finally got my hands on Electron, I had an idea in my head of a desktop app where you browse shows, add your favorite ones, and have a convenient dashboard with episodes coming out soon. There’s an API for that called thetvdb which I could easily employ. So I gave it a go. The end result can be played with right now on GitHub.

In this article, I’m going to walk you through the process of using Electron with React from the very beginning. We’ll start with the basics and cover the required setup for making friends with React and ES2015 (spoiler: it’s soooo much easier than you probably think). Next, we’ll use the React router and create some views (which are just good old web pages). Finally, we’ll learn how to download data and store it in a filesystem (yes, like grown-ups!).

But first, let me tell you why Electron is huge.

Electron overview

Electron is a platform widely used by tech companies, including monsters like ShopifySlackWordPress and of course Github’s Atom, for which it was initially developed.

In a nutshell, Electron is a combination of a browser engine and a Node.js environment. The practical meaning of this is that the environment you write code in has both access to the DOM and the ability to work with the Node.js API. It allows the modest web developer like you and me build complex cross-platform desktop applications.

For example, you can do things like this:

$("a").on('click', () => {
  $("body").append($(`<h1>$(process.env)</h1>`));
});

You can both work with the app as you do with a web page and at the same time use the features of the OS like this is a native app. So you have all that flexibility of the web combined with the power of a native app, which creates fantastic opportunities.

How to read this tutorial

This is a step-by-step tutorial. I tried to make sure that after every step we have a runnable application with a working functionality. Every step has a link you can click on to see the whole commit.

The complete code is available on GitHub, so sometimes, when I omit some chunks to save the space, don’t hesitate to lookup the full version.

Enough words, let’s get to action.

Step 1. Let’s run an Electron app

Check the whole commit.

First, let’s start a new project with yarn:

mkdir tvtracker && cd tvtracker && yarn init --yes

Now let’s install the Electron package:

y add electron --dev

…and add the command to package.json

// package.json
// ...
  "script": {
    "start": "electron index.js"
  }
// ...

If you’re not familiar with the script directive, it allows us to create shortcuts to run the npm (or yarn) commands.

If you try to launch it now with yarn start, you’ll get an error. That’s because we don’t have index.js yet. Let’s create it.

// index.js

const {app, BrowserWindow} = require('electron');
const url = require('url');
const path = require('path');

let win; // global, as to protect from GC

app.on('ready', createWindow);
app.on('window-all-closed', onAllClosed);
app.on('activate', onActivated);

function createWindow () {
  win = new BrowserWindow({width: 1080, height: 600});

  loadPage();

  // release the pointer for the GC
  win.on('closed', () => win = null);
}

function loadPage() {
  // and load the index.html of the app.
  win.loadURL(url.format({
    pathname: path.join(__dirname, './src/index.html'),
    protocol: 'file:',
    slashes: true
  }));
}

function onAllClosed() {
  if (process.platform !== 'darwin') {
    app.quit();
  }
}

function onActivated() {
  if (win === null) {
    createWindow();
  }
}

OK, now this may look like too much. But actually this is just a boilerplate required to create a window. onActivated is here to simulate macOS behavior: when you click on the app in the dock, it opens a new window but doesn’t really quit when you close it. loadPage actually takes the index.html file and loads it into the browser. So let’s create it as well.

<!-- src/index.html -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>ElectroTV</title>
  </head>
  <body>
    <div id='root'>
      <h1>Greetings, sir!</h1>
    </div>
  </body>
</html>

Run it with yarn start and you should see our new shiny app.

Step 2. Introducing React into the mix

Check the whole commit.

I don’t think I need to tell you what React is when it’s become a de facto industry standard. What I’m going to tell you is how to setup it to work with Electron. Typically at this point, you will want to introduce webpack and spend tons of time configuring it right. But there’s a better way. Meet the electron-compile package.

yarn add electron-prebuilt-compile --dev

That’s kinda it. Now you can use ES2016, SASS, React’s JSX, you can use PUG templates for your pages, whatever you like. If it sounds incredible, that’s because it is. But the people behind that package managed to make everything to work seamlessly. All you need to do is add a file to the web page and provide a proper type attribute. Now let’s add a React entry point to our app:

<!-- src/index.html -->
<!-- ... -->
  <body>
    <div id='root'></div>
    <script src='js/bootstrap.js' type='application/javascript'></script>
  </body>

The src/js/bootstrap.js is going to be our app’s entry point.

// src/js/bootstrap.js
import React from 'react';
import ReactDOM from 'react-dom';

import App from './js/components/app';

ReactDOM.render(
  React.createElement(App),
  document.getElementById('root')
);

Note: when we import a file, the root dir in every case is src. All paths are taken relative to it because this is the directory in which our index.html file resides.

src/js/components/app.jsx is the place where we’ll define our routes in the next step:

// src/js/components/app.jsx
import React from 'react';

export default () => (
  <div>Hello, React!</div>
);

Update the application and you should see the “Hello, React” text.

Step 3. Creating routes and building the layout

Check the whole commit

Our app is going to have just two routes. The first one is the dashboard, and the second is search page to look up new shows. We will use the react-router for that.

yarn add react-router react-router-dom moment

Note, that we also added moment.js. That’s because I’m very bad at dealing with JS dates.

// src/js/app.jsx
import React from 'react';
import { Router, Route } from 'react-router';
import { createHashHistory } from 'history';
import { NavLink } from 'react-router-dom';

import Home from './home';
import Search from './search';

const history = createHashHistory();

export default () => (
  <Router history={history}>
    <div className="window">
      <div className="window-content">
        <div className="pane-group">
          <div className="pane-sm sidebar">
            <nav className="nav-group">
              <h5 className="nav-group-title">Menu</h5>
              <NavLink to='/' className='nav-group-item' exact>
                <span className="icon icon-home"></span>
                Home
              </NavLink>
              <NavLink to='/search' className='nav-group-item' exact>
                <span className="icon icon-search"></span>
                Search
              </NavLink>
              <h5 className="nav-group-title">My Shows</h5>
              { this.state.shows.map(renderShow) }
            </nav>
          </div>
          <div className="pane padded-more">
            <Route path="/" component={Home} exact />
            <Route path="/search" component={Search} exact />
          </div>
        </div>
      </div>
    </div>
  </Router>
);

Wow. There are lots of things going on here. But before that, let’s add the Photon styles framework to make our app look more appealing (you may have already noticed that we use classes from that library in our layout).

<!-- src/index.html -->
<!-- ... -->
  <head>
    <meta charset="UTF-8">
    <title>ElectroTV</title>
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/photon/0.1.2-alpha/css/photon.min.css" />
  </head>
<!-- ... -->

Let’s now create placeholders for home and search components. We will work on them in the next part.

// src/components/home.jsx
import React from 'react';
import moment from 'moment';

export default () => (
  <h1>Today is <span className="firm">{ moment().format("DD of MMMM") }</span>, { moment().format("dddd") }</h1>
)
// src/components/search.jsx
import React from 'react';

export default () => (
  <div>Searh form is going to be here</div>
);

Now when you run the project, you should be able to navigate between the views using the side menu.

Step 4. Search for a show

Check the whole commit

OK, now we’re ready for some real work. What we’re going to do is create a simple form to look for a particular show in thetvdb database, using their public API. Then we can add the show to our local store (which means downloading and unzipping the XML file with the show’s information).

In order for the API to work, we’ll need an API key. You can get it here. Then you should export THETVDB_API_KEY variable, because our app is going to use it.

I’m not going to paste the whole file here (see the commit), but let’s take a quick glimpse at how the API works:

// some imports
import req from 'request';

const API_HOST = "http://thetvdb.com";
const KEY = process.env.THETVDB_API_KEY;

function search(q, cb) {
  const url = `${API_HOST}/api/GetSeries.php?seriesname=${q}`;

  get(url, (res) => {
    cb((res['Data']['Series'] || []).map(i => {
      const out = {
        id: i.id[0],
        name: i.SeriesName[0],
        overview: (i.Overview || [])[0] || 'No Overview'
      };
      if (i.banner) {
        out.banner = `${API_HOST}/banners/${i.banner[0]}`;
      }
      return out;
    }));
  });
}

function get(url, cb) {
  req(url, (err, resp, body) => {
    if (err) throw `Error while req ${url}: ${err}`;
    if (resp.statusCode != 200) throw `Error while req ${url}: code — ${resp.statusCode}`;

    parseString(body, (err, res) => {
      if (err) throw `Error parsing response from ${url}: ${err}`;
      cb(res);
    });
  });
}

Nothing too fancy is going on here, apart from the fact that we’re using the node API (the request module), not the browser’s. This is so we don’t have to deal with CORS issues or other related stuff. It’s just like server-side code.

Let’s add some more npm dependencies:

yarn add xml2js unzip react-addons-css-transition-group

We also added some more styles, but I’m not going to include them here in the interest of not wasting space. You can look it up in the commit.

// src/components/search.jsx
import React from 'react';
import _ from 'lodash';

import api from '../api';
import Show from './show';

import ReactCSSTransitionGroup from 'react-addons-css-transition-group';

const Search = React.createClass({

  getInitialState () {
    return {
      loading: false,
      results: []
    };
  },

  changed({ target: { value } }) {
    loadDb(this, value);
  },

  render() {
    return (
      <div>
        <form>
          <div className="form-group">
            <input type="email" className="form-control" placeholder="Search for a TV Show"
              autoFocus onChange={this.changed}></input>
          </div>
        </form>
        <section className='results'>
          {this.state.loading ? Spinner() : renderResults(this, this.state.results) }
        </section>
      </div>
    );
  }
});

function renderResults(vm, res) {
  return (
    <ReactCSSTransitionGroup
      transitionName="fade"
      transitionAppear={true}
      transitionAppearTimeout={300}
      transitionEnterTimeout={500}
      transitionLeaveTimeout={300}>
      { res.map(i => ( <Show show={i} key={i.id} /> )) }
    </ReactCSSTransitionGroup>
  );
}

const loadDb = _.debounce((vm, q) => load(vm, q), 500);

function load(vm, q) {
  vm.setState({ loading: true, results: [] });
  api.search(q, (res = []) => {
    vm.setState({ loading: false, results: res });
  });
}

function Spinner() {
  return (
    <div className="spinner">
      <div className="double-bounce1"></div>
      <div className="double-bounce2"></div>
    </div>
  );
}

export default Search;

We added a simple input field. When the text in it changes we use the API module to search in thetvdb API, and then we put the results into the results instance variable. Notice the invocation of setState. That’s the way to tell React that the state has been updated, so the view should be re-rendered. For every show we render a Show component. Let’s add it as well:

// src/components/show.jsx
import React from 'react';
import store from '../store';

export default class extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      show: this.props.show,
      loading: false
    };
  }

  componentDidMount() {
    const show = this.state.show;
    show.followed = store.isFollowed(this.state.show.id);
    this.setState(Object.assign(this.state, { show }));
  }

  render() {
    const i = this.state.show;
    const ovw = i.overview.length > 128 ? i.overview.substring(0, 128) + "..." : i.overview;
    return (
      <div className="series card">
        <img src={i.banner} />
        <h3>{ i.name }</h3>
        <p> { ovw } </p>
        <div className='action'>
          <button
            className={ cl(this.state.downloading, this.state.show.followed) }
            disabled={this.state.downloading}
            onClick={e => follow(this, i)}>
            <span className="icon icon-star"></span>
            <span className='f1'>FOLLOW</span>
            <span className='f2'>FOLLOWING</span>
            <span className='f3'>UNFOLLOW</span>
          </button>
        </div>
      </div>
    );
  }
}

function cl(downloading, followed) {
  const out = ['btn', 'btn-large', 'btn-primary'];
  downloading && out.push('downloading');
  followed && out.push('followed');
  return out.join(' ');
}

function follow(vm, i) {
  vm.setState({ downloading: true, show: i });
  store.add(i.id, () => {
    vm.setState({ downloading: false, show: i });
  });
}

Notice the line show.followed = store.isFollowed(this.state.show.id). We know that the show is followed if we have the corresponding XML file in our store directory (more on that later). That’s what the store module is for. The second time we use it is when we “follow” the show, which means we are downloading the show file from thetvdb database to our local directory.

The store module is responsible for storing and retrieving data from the filesystem. Since thetvdb API gives us the show’s data as zipped files, we will store those files in a special dot-directory ~/.eltv. You can find the complete code for store on GitHub, but here’s a quick glimpse of the store.add method.

function add(id, cb) {
  if (!fs.existsSync(BASE)) { fs.mkdirSync(BASE); }
  if (!fs.existsSync(BASE_STORE)) { fs.mkdirSync(BASE_STORE); }

  api.download(id, `${BASE_STORE}/${id}`, () => {
    cb();
  });
}

Here we are checking if the local storage directory exists and if not, creating it before downloading the file. The magic of Electron is that we can use the fs module here to work with the filesystem.

Run the project now, and you should be able to look for a show and add it to your list of shows.

Step 5. Displaying added shows in the sidebar

Check the whole commit

Let’s now display the shows we’ve already added in the sidebar. To do that we have to change the app.jsx component. When the component is mounted, we will read all shows that we have downloaded.

// src/js/components/app.jsx
import React from 'react';
import { Router, Route } from 'react-router';
import { createHashHistory } from 'history';
import { NavLink } from 'react-router-dom';

import Home from './home';
import Search from './search';

const history = createHashHistory();

export default class extends React.Component {

  constructor() {
    super();

    this.state = {
      shows: []
    };
  }

  componentDidMount() {
    store.readAll((err, shows) => {
      this.setState(Object.assign(this.state, {
        shows: shows.map(show => {
          const s = show.Data.Series[0];
          return { id: s.id[0], name: s.SeriesName[0] };
        })
      }));
    });
  }

  render() {
    return (
      <Router history={history}>
        <div className="window">
          <div className="window-content">
            <div className="pane-group">
              <div className="pane-sm sidebar">
                <nav className="nav-group">
                  <h5 className="nav-group-title">Menu</h5>
                  <NavLink to='/' className='nav-group-item' exact>
                    <span className="icon icon-home"></span>
                    Home
                  </NavLink>
                  <NavLink to='/search' className='nav-group-item' exact>
                    <span className="icon icon-search"></span>
                    Search
                  </NavLink>
                  <h5 className="nav-group-title">My Shows</h5>
                  { this.state.shows.map(renderShow) }
                </nav>
              </div>
              <div className="pane padded-more">
                <Route path="/" component={Home} exact />
                <Route path="/search" component={Search} exact />
              </div>
            </div>
          </div>
        </div>
      </Router>
    );
  }
};

function renderShow({ id, name }) {
  return (
    <NavLink to={`/show/${id}`} key={ id } className='nav-group-item' exact>
      { name }
    </NavLink>
  );
}
Step 6. Home view

Check the whole commit

Finally, we’re going to create a home view with several blocks showing new episodes released from the last week, coming up later this month, and the next month. For that we’re going to read the data from the show’s files we downloaded earlier, parse it to JSON and make some basic date comparisons. I’m not going to post the whole file this time since it’s huge, but feel free to refer to the commit.

// src/js/components/home.jsx

// ... imports

export default class extends React.Component {
  constructor() {
    super();

    this.state = {
      loading: false,
      groups: []
    };

    this.renderFeed = this.renderFeed.bind(this);
  }

  renderFeed() {
    if (this.state.fetching) {
      return (
        <h3 style={ {textAlign: 'center'} }>Fetching Data From <span className='firm'>thetvdb.com</span>...</h3>
      );
    } else {
      return (this.state.groups || []).map(renderGroup);
    }
  }

  render() {
    return (
      <div className="pane padded-more">
        <h1>Today is <span className="firm">{ moment().format("DD of MMMM") }</span>, { moment().format("dddd") }</h1>
        { (this.state.loading ||  this.state.spinner) ? Spinner() : this.renderFeed() }
      </div>
    );
  }

  fetch(cb) {
    this.setState(Object.assign(this.state, { fetching: true }));
    store.updateAll(() => {
      this.setState(Object.assign(this.state, { fetching: false }));
      cb();
    });
  }

  componentDidMount() {
    this.fetch(() => {
      this.setState({ loading: true, groups: [] });
      store.readAll((err, shows) => {
        shows.forEach(s => {
          const title = s['Data']['Series'][0]['SeriesName'][0];
          s['Data']['Episode'].forEach(e => e.show = title);
        });
        const eps = _.flatten(shows.map(s => s['Data']['Episode']));
        this.setState({ loading: false, groups: group(eps) });
      });
    });
  }
}

Notice that we do store.updateAll every time on componentDidMount. That’s because we need to make sure that our downloaded files are up-to-date. This logic, of course, could be smarter, but I don’t want to complicate it any further.

While the downloading is in progress we put a placeholder saying “Fetching Data From thetvdb.com.” Then we read the files from the filesystem, parsing them and grouping them according to the release date.

function group(eps) {
  return [
    {
      title: 'Released Last Week',
      episodes: ready(eps)
    },
    {
      title: 'Coming Up Later This Month',
      episodes: thisMonth(eps)
    },
    {
      title: 'Next Month',
      episodes: nextMonth(eps)
    }
  ];
}

function ready(eps) {
  return withinPeriod(eps, moment().add(-2, 'week'), moment());
}

function thisMonth(eps) {
  return withinPeriod(eps, moment(), moment().endOf('month'));
}

function nextMonth(eps) {
  const start = moment().add(1, 'M').startOf('month');
  const end = moment().add(1, 'M').endOf('month');
  return withinPeriod(eps, start, end);
}

function withinPeriod(eps, start, end) {
  return eps.filter(e => {
    const d = moment(e['FirstAired'][0]);
    return d.isSameOrAfter(start) && d.isBefore(end);
  });
}

And that’s mostly it!

Conclusion

Hopefully, by this time you understand the real power of Electron.

By combining the web-dev mentality and the mighty node.js engine, Electron allows for quick development of rich desktop applications and gives that opportunity to a wider audience of web developers. People can build apps even if they don’t necessarily know or care about the platform’s underlying details, and they don’t have to know Objective-C or C#.

We are now able to create desktop apps with only our knowledge of web technologies. That’s just pure magic to me.

5 links for diving deeper

About the Author:

What’s Driving the Need to Learn JavaScript?

March 28th, 2017

The 2017 DevelopIntelligence Developer Learning Survey Report uncovered a number of insights and trends on how, what, and why software developers want to learn and be trained on in 2017. One of the major discoveries that stands out from the report is the enormous demand for training on JavaScript. 55% of survey respondents say they want more training JavaScript and 27% want training on ES6, the newest version of JavaScript. Our survey also uncovered a strong training demand for JavaScript frameworks, libraries, and related tooling–e.g., 42% desired Angular 2 training and 38% of developers reported a desire to learn React (a Facebook-driven UI library). What accounts for this robust training demand? Why is everyone either on or jumping on the JS train?

It’s worth considering a bit of history on the language. Brendan Eich invented JavaScript in 10 days around May 6-15 in 1995. The language, originally called Mocha, started as a simple client-side scripting language. It allowed developers to create simple interactivity in the browser. This was when the web was used by tens of millions of people vs. the billions who use it now. This web was originally invented to share simple documents over the wire. Consider what ESPN looked like in 1999:

And here’s what ESPN looks like in 2017:

We ask a lot more of the web than we used to. It needs to be able to do animations, video, social interactivity, eCommerce, and a multitude of other things that we do in our browser in 2017. JavaScript (and JavaScript developers) had to evolve a lot to keep up with this. Here’s a couple of the major milestones of that evolution:

Ajax – 2004

Ajax stands for asynchronous JavaScript and XML. Ajax allows developers to fetch data from a server without doing complete page refreshes. Ajax made things like Gmail and Kayak.com possible. It allowed browsers to feel much more like a desktop application instead of jumping from page to page. They could stay on the same screen but receive new data from a data source somewhere. This allowed for a much smoother and more interactive user experience.

Source: By DanielSHaischt, via Wikimedia Commons

Get JavaScript Training for Teams

jQuery – 2006

jQuery is a cross-platform JavaScript library designed to simplify the client-side scripting of HTML. jQuery made it much simpler for web developers to build applications that worked equally well on all browsers. This was the era when Internet Explorer had annoying quirks that other browsers didn’t. jQuery also made web development easier, in general, as it would give developers shorter/simpler ways of doing common tasks. They could get the same thing done with much less and much more readable code.

Here’s how to do relatively simple aJax request in jQuery:

$.getJSON('/my/url', function(data) { 

});

Here’s how you would have to write it in JavaScript

var request = new XMLHttpRequest(); 
request.open('GET', '/my/url', true); 

request.onload = function() { 
if (request.status >= 200 && request.status < 400) { 
// Success! 
var data = JSON.parse(request.responseText); 
} else { 
// We reached our target server, but it returned an error 

} 
}; 

request.onerror = function() { 
// There was a connection error of some sort 
}; 

request.send();

The source of this code is a site called you might not need jQuery. They are arguing that jQuery is being overused. This might be true but it’s worth considering how many lines of code developers can save.

MVC Frameworks (Backbone, Angular, etc.) – ~2009-2013

Web applications continued to get larger and more complex. jQuery works well for simple applications but quickly turns into spaghetti code as an app grows. The tooling needed to evolve to accommodate this.

This is where the MVC (Model-View-Controller) frameworks like Backbone and Angular came out of. MVC was an existing popular way to organize code projects (in other languages) and adhere to what’s known as the separation of concerns. One area of the code would contain the templates that users would see, one would contain the logic of what functions would be called when users did different actions, and another part would contain the data that ultimately drove the app. This worked and worked really well for a variety of web applications.

This short video shows the power of Angular 1. It allows for accomplishing many common tasks with ease:

While Angular shines in simple smaller apps, it struggles to perform well and be maintainable as it grows. This created the need for a better paradigm.

Component Frameworks (React, Vue) – 2013-Now

Facebook released the React.JS UI library in 2013. Facebook was struggling to make existing frameworks/libraries support their complex app so they rolled out their own. React (and similar libraries) break a web application down into components. Every little widget or separate area of an app/page is a component and, thus, developed independently. React handles the task of keeping the data in sync with the user interface (e.g the like button has the correct number of likes).

Component-driven development greatly simplifies the application development and makes it easier to avoid common types of bugs that plagued the MVC frameworks.

Here’s a great clip, from 2013, that explains the React paradigm from a high-level:

No wonder developers want to learn more JavaScript!

As you can see, JavaScript has come a long way. There are variety of powerful tools to build simple and complex applications. But the tools keep changing and evolving, forcing developers to constantly be learning new things. Developers need regular training in multiple formats to keep up with this landscape.

DevelopIntelligence javascript offers expert-led, hands-on courses on all of the latest JavaScript libraries and frameworks. Our Developer Survey Report goes even more in depth on the front-end training landscape and you can download it here.[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

About the Author:

Back-end vs. Front-end Programming Explained

May 26th, 2016

Programming and web development are often divided into “back-end” vs. “front-end” development. This is because most software is divided between the data/information being used or sorted and the interface that a person is using to interact with this data. This “separation of concerns” is actually a codified software design pattern and best practice for building maintainable systems.

Back-end programming typically refers to writing code for things like servers and databases. Front-end programming refers to building intuitive, attractive, and easy to use interfaces for people to click on, type into, and mouse around on.

A familiar example of this would be liking a Facebook post. The front-end would deal with making the like button look good and respond to mouse clicks or touches. The back-end would deal with correctly storing and retrieving who liked the post from the database. When you click (or touch) the like button, the front-end sends your ‘like’ across the Internet as JSON (a data format) to a REST Web service (a type of backend interface), which then process the ‘like’ and stores it into a database.

(more…)