People once thought the banking industry was too big to fail, some seriously big financial institutions ultimately proved that wrong during the Global Financial Crisis of 2008/2009 which saw many seemingly unsinkable companies go out of businesses.

Early 2019, after two deadly crashes of the allegedly bigger and better 737 MAX, the plane was grounded by countries around the world as people scrambled to find answers for what happened. After numerous investigations, the culprit turned out to be MCAS also known by its non-abbreviated mouthful of a name Maneuvering Characteristics Augmentation System.

The issue with the 737 MAX was engineers were tasked with fitting larger and heavier engines under the wing of the plane. The engines had to be moved slightly higher and moved forward, which ultimately caused a dynamically unstable airframe. The solution was MCAS which used a single sensor to determine if the nose of the plane should be pushed down (as a safety measure).

While the 737 MAX continues to collect dust in parking lots and warehouses, Boeing is bleeding money. Just recently, they announced they’re halting production of the MAX (which will only slow, not stop the money bleeding). The solution Boeing has come up with involves comparing data from two AOA (Angle of Attack) sensors and comparing the difference if both sensors cannot agree, the MCAS does not override the plane as detailed here.

The company was hoping to have the 737 MAX recertified by the end of 2019, but this has been pushed back to 2020. Understandably, this entire situation does not just reflect badly on Boeing, but also the FAA who allowed this to happen in the first place.

Too Big, Too Influential

For any other company, two tragedies and a grounding going on for almost a year would be enough to plunge them into bankruptcy and put them out of business. For Boeing, their stock has been affected a bit, but they’re still okay.

Boeing is a company that has been around for over one-hundred years. When it comes to the aerospace industry, you don’t get any bigger than Boeing. Since the ’90s, the presidential fleet of planes consists of two Boeing VC-25’s which are military versions of the workhorse Boeing 747.

In terms of employment size, Boeing is one of the largest American employers. They employ over 150,000 people, many of those work in the US. If Boeing were to go out of business, the US economy would be affected. Not to mention the supply chain Boeing has created rivals even that of a company like Amazon and its supply chain.

Fly on any major airline in most parts of the world and chances are you are flying on a Boeing built plane, most likely a variant of the Boeing 747.

To get an understanding of just how influential Boeing is and its importance to the US, look no further than the fact the CEO of Boeing (Dennis Muilenburg) still has his job (CEO’s have been fired or forced to step down over less) and has not been summoned to Washington to be grilled before the senate over the tragedies and mismanagement of the 737 MAX.

You don’t get any more influential than not being held accountable or even being questioned on why two tragedies in such a short space of time even took place (the 737 MAX tragedies were unprecedented). When the banking industry collapsed, bankers were dragged before congress to be held accountable.

Still Waters Run Deep, Boeing Runs Deeper

When you and I think of Boeing, we think of a company that makes passenger planes. However, Boeing has its fingers in many pies, it’s producing the pies, it’s eating them, it owns the pie factory, it owns the supply chain that is shipping the pies to stores and restaurants.

Not many people realise Boeing also props up other companies and industries. Their subcontracts with General Electric (GE) and United Technologies and Spirit Aerosystems are some of the biggest. You best believe Boeing is adding a few zeroes to the books of those contractors.

Boeing is entrenched in both civilian and military sectors. They sell planes, rockets, satellites, telecommunications equipment and even missiles. They are the largest exporter by dollar value in the US. As far as size is concerned, Boeing is a juggernaut, a core pillar of the aerospace industry.

They are already saying that the halting of the 737 MAX could affect the US’s GDP in 2020. Not many companies can lay claim to being so big they contribute to the overall GDP of a country.

Even if Boeing were to get into serious financial trouble, the US government would not even hesitate to bail them out. It would probably be considered a national security risk if Boeing were to go under given their influence and reach in the defence sector alone. Quite simply, Boeing could sustain many more missteps and accidents before it really affected them and forced the government to step in.

Well, this is a pretty frustrating bug. The other day I and a few other people in my team noticed something peculiar while debugging some Javascript. The ability to hover over variables and function arguments in Chrome Developer Tools had stopped working.

At first, we thought this might have been a Webpack configuration issue or an update to one or more of our packages breaking the way in which Chrome parses our Javascript. The issue turned out to be Chrome itself. There is an issue recently created where many voice their frustration (myself included) over this bug.

As a developer, the ability to debug is everything. As a result of this simple bug, the time required to debug has increased exponentially.

Fortunately, this bug appears to have been fixed in Chrome Canary Version 81.0.4001.2. Even many of the developers I know do not use Canary because it can at times be unstable or introduce new features that seemingly get removed. So, until an update is released in the next couple of weeks, frustration will ensue for many.

All of this has just motivated me to consider moving back over to Firefox as my primary browser, given Google’s anti-ad stance and now a bug that should not have been introduced, I am driven by frustration.

In Aurelia 2, a new element called bindable has been introduced which is leveraged in HTML only custom elements. If you want a HTML only custom element which has one or more bindable properties, then you use the bindable element to specify them.

The ability to create bindables for HTML only custom elements existed in Aurelia 1, but was limited. The constraint being the bindable keyword had to be specified on the template element.

<template bindable="user">...</template>

In Aurelia 2, this now becomes something much more simple and clean because template is no longer a requirement for HTML only custom elements.

<bindable name="user" />

Besides the semantics changing, you can now also specify the binding mode for the defined variable. This was not possible in Aurelia 1 when creating HTML custom elements.

Now, simply adding a mode property and valid binding mode value, you can change how the binding works just like you can when configuring the binding mode inside of a view-model.

<bindable name="user" mode="one-way" />

If you are already familiar with Aurelia and have worked with Aurelia 1, then HTML custom elements are not a new concept to you. If you’re starting out with Aurelia 2, they might be a new concept to you.

How HTML Only Custom Elements Looked In Aurelia 1

We have a custom element called user-info.html which accepts a user object through a bindable property called user and we display their name and email.

<template bindable="user">
  <p>${user.name}</p>
  <p>${user.email}</p>
</template>

How HTML Only Custom Elements Look In Aurelia 2

The constraint of needing a template tag has been removed in Aurelia 2. It is now automatically handled for you by the framework, so now our HTML components look like this.

<bindable name="user" />

<p>${user.name}</p>
<p>${user.email}</p>

Because there is no template tag, you need to create your bindable properties using the bindable element and the name property to specify what it should be called.

Just like Aurelia 1, the file name itself (in our case it is user-info.html) becomes the name of our HTML tag without the .html file extension. If we called it user-block.html our element would be referenced using that name instead.

Importing & Using It

You created a HTML only custom element in Aurelia, now what? Now, you import the component.

<import from="./components/user-info.html"></import>

<user-info user.bind="user"></user-info>

If you want to follow along with a tutorial for creating a simple weather application in Aurelia which involves creating a HTML only custom element and importing it, I have a weather application tutorial here.

While Aurelia 2 is still not quite ready for release, you can use it right now as the basic core pieces are functional. I thought it would be fun to build a weather application using Aurelia 2.

If you don’t want to run through a tutorial and just want the final result, all of the code for the weather application can be found on GitHub here.

What Are We Building?

In this tutorial, we are going to be building an Aurelia 2 application that displays weather information. Original, right? You will learn how to create new Aurelia 2 applications, as well as work with the OpenWeatherMap API where we will consume JSON for the information.

Before we can continue, head over to the OpenWeatherMap website here and create a free account. This application will only be for personal use, so the limits of 60 calls per minute are perfect for us.

You will then want to generate an API key by heading over to the API Keys section once you are signed up and logged in.

A Note On Code In This Tutorial

Aurelia allows you to leverage conventions for things such as custom elements, value converters and whatnot. It also allows you to be more explicit in how you name and import dependencies.

For the purposes of this tutorial post, we will be leveraging conventions, but the code in the repository will leverage no conventions and use decorators for describing components. My personal preference is to be quite explicit in my Aurelia applications.

Getting Started

Unlike Aurelia 1, there is nothing to install globally (the aurelia-cli is not a dependency you need any more). To bootstrap a new Aurelia 2 application, you simply open up a terminal/PowerShell window and run:

npx makes aurelia

Because TypeScript is the future, I recommend choosing the “Default TypeScript Aurelia 2 App” option in the prompt. Then choose, “npm” for the package installer option and wait for your app to be created.

To confirm everything installed correctly, open up the generated application directory (in my case it is weather-app) and then run the application using npm start a browser window should open and point to port 9000.

Create A Weather Service

In an Aurelia application, using singleton service classes is a great habit to get into too. Singletons are easy to test and work well with Aurelia’s dependency injection (DI).

In the src directory create a new folder called services and a file called weather-api.ts which will handle making calls to the OpenWeatherMap API service.

import { HttpClient } from '@aurelia/fetch-client';
import { DOM } from '@aurelia/runtime-html';

const http = new HttpClient(DOM);

export class WeatherApi {
    private apiKey = '';
	private units = 'metric';

    public async getWeather(address) {
        const req = await http.fetch(`https://api.openweathermap.org/data/2.5/forecast?q=${address}&units=this.units&APPID=${this.apiKey}`);

        return req.json();
    }
}

This simple service will allow us to query the API for weather information. But, we are not using TypeScript to its full potential here. Let’s write some interfaces and type the response.

import { HttpClient } from '@aurelia/fetch-client';
import { inject } from 'aurelia';

@inject(HttpClient)
export class WeatherApi {
    private apiKey = '';
    private units = 'metric';

	constructor(private http: HttpClient) {

	}

    public async getWeather(latitude: number, longitude: number): Promise<IWeatherResponse> {
        const req = await this.http.fetch(`https://api.openweathermap.org/data/2.5/forecast?lat=${latitude}&lon=${longitude}&units=${this.units}&APPID=${this.apiKey}`);

        return req.json();
    }
}

interface IWeatherResponse {
    cod: string;
    message: number;
    cnt: number;
    list: IWeatherResponseItem[];
}

interface IWeatherResponseItemWeather {
    id: number;
    main: string;
    description: string;
    icon: string;
}

interface IWeatherResponseItem {
    dt: number;
    main: {
        temp: number;
        feels_like: number;
        temp_min: number;
        temp_max: number;
        pressure: number;
        sea_level: number;
        grnd_level: number;
        humidity: number;
        temp_kf: number;
    };
    weather: IWeatherResponseItemWeather[];
    clouds: {
        all: number;
    };
    wind: {
        speed: number;
        deg: number;
    };
    rain: {
        '3h': number;
    };
    sys: {
        pod: string;
    };
    dt_txt: string;
}

Now, there is one thing I want to point out with the above example. We’re hard-coding the API key into the singleton class, in a real application, you would and should never do this. Anyone who has your API key will be able to make requests and blast through your limits quickly. Never store API keys client-side.

We now have the class we will use to query for weather information. I won’t go into super specifics around markup and whatnot as those things can be seen in the GitHub repository for this tutorial here.

Leveraging Dependency Injection (DI) To Import Our Service

Now that we have our weather API service, we need to include it for use in our application. We will be editing the generated my-app.ts file as part of the Aurelia application creation process.

We want to replace the entirety of our my-app.ts file with the following:

import { WeatherApi } from './services/weather-api';

export class MyApp {
  private weather;

  constructor(private api: WeatherApi) {

  }

  attached() {
    navigator.geolocation.getCurrentPosition((position) => this.success(position), () => this.error());
  }

  async success(position: Position) {
    const latitude  = position.coords.latitude;
    const longitude = position.coords.longitude;

    this.weather = await this.api.getWeather(latitude, longitude);
  }

  error() {

  }
}

Because my-app.ts is a rendered custom element (as can be seen inside of index.ejs we get DI automatically when we use TypeScript. This means we don’t have to use the inject decorator to inject things.

All dependencies get passed through the constructor and using TypeScript with a visibility keyword, they get hoisted onto the class itself for use. It’s a nice touch and one of my favourite things about TypeScript.

The attached method is a lifecycle method that gets called in components once the DOM is ready. This is where you handle interacting with the DOM or calling various API methods. We call the getCurrentPosition method here to request the users latitude and longitude.

The success callback is called via the navigation position callback on success. This is where we get the latitude and longitude values, then we make a call to our injected API class and call the getWeather method.

You might also notice we are using async/await here which allows us to wait for the results of a promise and get the data. We assign the value to the class variable weather which will be referenced in the view template shortly.

Creating A Value Converter For Formatting Dates/Times

We are going to use the date-fns library for working with dates and formatting them. One of the values the weather API returns is a date string which we will parse and then format for display purposes.

You might not have worked with date-fns before, but it is similar to Moment.js which is a heavier and often unnecessary option to go with.

To install date-fns all we need to do is run:

npm install date-fns

In Aurelia, a value converter is exactly what it sounds like. It converts values to something else (either to the view or from the view). In our use case, we only want to convert a value in the view.

For resources, I highly recommend creating a resources directory which exports an array of resources to make global.

Create a file called src/resources/value-converters/date-format.ts and add in the following:

import { valueConverter } from '@aurelia/runtime';
import { format } from 'date-fns';

export class FormatDateValueConverter {
    toView(date): string {
        return date ? format(new Date(date), 'MM/dd/yyyy - h:mm bbbb') : date;
    }
}

Inside of the resources directory create a file called index.ts with the following:

import { FormatDate } from './value-converters/format-date';

export const resources = [
    FormatDate
];

This exports an array of one or more resources. For the purposes of this tutorial, we are only exporting one resource to make global. In a real application, you might have several. If you worked with Aurelia 1, this paradigm will look familiar with you with an array of resources that get globalised. Except, globalResources is no longer a thing.

Inside of src/main.ts we want to import those resources and register them:

import Aurelia from 'aurelia';
import { MyApp } from './my-app';
import { resources } from './resources';

Aurelia
    .register(resources)
    .app(MyApp)
    .start();

The Markup

We now have the basics in place, let’s start with our markup and styling. We are going to use Bootstrap 4 because it has a good grid system and will make styling things easier.

Install and Configure Bootstrap

npm install bootstrap

Before we start adding in any HTML, we need to import the main Bootstrap CSS file into our application.

At the top of src/main.ts add the following import:

import 'bootstrap/dist/css/bootstrap.css';

We now have the styling we need for marking up our columns and aspects of the grid system.

Creating A Weather Component

Breaking your application into components is a great way to create applications. Smaller components are easier to test, they are also easier to maintain and neater.

Inside of the src directory create a new folder called components and create a component called weather-item which we will import and use to display our weather information.

Now, we want to create the HTML file for our custom element: src/components/weather-item.html

<bindable name="data" />

<p><strong>Date:</strong> ${data.dt_txt | formatDate}</p>
<p><strong>Clouds:</strong> ${data.clouds.all}%</p>
<p><strong>Temperature:</strong> ${data.main.temp}&deg;</p>
<p><strong>Feels Like:</strong> ${data.main.feels_like}&deg;</p>
<p><strong>Humidity:</strong> ${data.main.humidity}%</p>

A brief explanation of what is happening here, we just created a HTML only custom element. The bindable element at the top is telling Aurelia that we have a custom element which accepts a bindable property called data which allows data to be passed through.

You will notice below when we import and use our element, we are binding on the data property by specifying data.bind. Inside of our custom element, we reference this bindable value specifically to get pieces of data passed in.

If you have experience working with other frameworks or libraries such as React, you might know of these as “props” in Aurelia they’re bindable properties.

If you want to build custom elements with business logic that extends beyond simple bindables, you will want to consult the documentation on creating custom elements that leverage a view-model (something we do not need to do here).

<import from="./components/weather-item.html"></import>

<div class="container spacer-v">
    <form class="mb-4">
        <h2 class="mb-3">Weather. Whenever.</h2>
    </form>

    <div if.bind="weather && weather.cod === '404'">
        <h3>Error</h3>
        <p>${weather.message}</p>
    </div>

    <div class="row" if.bind="weather && weather.cod !== '404'">
        <div class="col-md-3">
            <div class="row">
                <div class="col-md-3"><img src="http://openweathermap.org/img/wn/${weather.list[0].weather[0].icon}.png"></div>
                <div class="col-md-8">
                    <h3>${weather.city.name}, ${weather.city.country}</h3>
                </div>
            </div>
        </div>
        <div class="col-md-8">
            <div class="row">
                <weather-item data.bind="item" class="col-md-4 mb-3" repeat.for="item of weather.list"></weather-item>
            </div>
        </div>
    </div>
</div>

The first line is simply using the import element to include our component for use in our view. The import element works like a Javascript import, except it can also import HTML files as well as CSS files. If you have experience with Aurelia 1, this is the same element as require.

The rest is standard Aurelia templating, if you’re familiar with Aurelia v1, this will look familiar to you already.

If you’re new to Aurelia, I highly recommend reading the documentation to get a better understanding of how to author Aurelia templates and work with the templating.

To complete the styling, open up my-app.css which is a CSS file included automatically by Aurelia (matching the name of my-app.ts using conventions).

.spacer-v {
    padding-top: 50px;
}

Running The App

Provided you followed all of the steps correctly, to run the application simply type the following in the project directory:

npm start

A browser window should open and you should see an application that requests your current location and shows you the weather. It should look like this.

There are some improvements you could make on your own like a field that allows users to type addresses, a map or more detailed weather information, adding in routing to view specific fine-grain information. This is a quick and basic tutorial showing you how easy it is to build in Aurelia 2.

The front-end space over the last six years or so has really heated up, you could say superheated. As browsers become more powerful, devices continually improved and innovation a constant thing, no language is more popular and widely used than Javascript.

And yet, as learning resources have become more easily accessible and coding boot camps have become a thing, newcomers are being taught to lean on frameworks and libraries straight out of the gate.

This puts some newcomers into an interesting situation. They might have a good grasp of React or Vue, but lack basic fundamental knowledge of the language itself. It is all well and good to rely on a library, but the moment it can’t do something you want to do, you’re stuck.

While React and Vue might seem like safe bets, I can assure you that people said the same things about Knockout, ExtJS, AngularJS, jQuery and a whole list of other frameworks and libraries that have come and gone over the years.

People will tell you things are different these days, maybe they are. But what happens when Hype.js becomes the popular option and you’re forced to learn a new library with limited Javascript knowledge? You get left behind, that’s what happens.

The only constant is Javascript

The common theme here amongst these rising and falling trends when it comes to technology on the front-end is Javascript. While WebAssembly has high hopes of shifting some responsibility from Javascript, it will remain the number one choice for client-side scripting.

As tempting as it might be to learn React Hooks or try Vue 3, the more you rely on a tool and use it as a language crutch, the further you’re falling behind. Learn Javascript and the rest comes naturally.

If you are an experienced developer, you should be learning new frameworks and libraries, leverage your knowledge of Javascript to widen your skillset and pad out your C.V. If you’re a junior who graduates college or a coding boot camp, learn the language first.

Staunch functional proponents will fire up at the mere mention of classes or any form of object-oriented programming. These arguments go way back to before Javascript was even a thing or as popular as it is now.

Let’s clear the air and point out that classes in Javascript are not real classes. They’re often compared to the likes of Java and other languages that promote OOP-style programming, but classes in JS are unlike those implementations. Javascript has prototypes and prototypes are not classes.

When the ES2015 Javascript standard was released (its biggest update ever), a plethora of new and exciting features came with it. New syntax and API’s, in the mix, was classes (sugar over conventional prototypal inheritance). Perhaps the most controversial addition of them all.

Here is the one thing that class opponents forget: classes in Javascript are optional. They’re not being forced on developers, you either use them or you don’t use them. It is really that simple. And yet, the arguments and noise around their inclusion (especially 2015/2016) you would be forgiven for thinking they’re a requirement to program in Javascript.

Inheritance

One of the biggest downsides to object-oriented programming and classes is inheritance. I am a fan of OOP style programming and even I agree that inheritance can be a nightmare and paint you into a corner.

But here is a secret that functional programming proponents don’t want you to know: inheritance is optional.

I use classes in my Aurelia applications and I avoid inheritance whenever possible. If I do use inheritance (which sometimes I do) I will be strict about it and only have one level of inheritance (parent-child relationship). More than one level of inheritance is a recipe for a bad time. I also try and avoid super calls as well.

Not all uses of inheritance are bad, it can be useful when you want to avoid duplicating code between multiple classes. If you’re building a widget-based component UI and your components all share similar implementation details except for a few configuration-specific pieces of data, inheritance works well here.

In many cases, I use classes as structs for modelling specific pieces of data in my applications, for example:

export class UserModel {
    constructor(name, email) {
        this.name = name;
        this.email = email;
    }
}

I actually prefer the aesthetics of a class over a function. I also love how I have to use the new keyword to explicitly create a new instance of my UserModel.

But the argument that you shouldn’t use classes because it is easier to fall into certain traps is nonsense. Javascript is a language full of traps that extend beyond the likes of classes which are quite low on the scale of JS gotchas.

If you are also working with TypeScript, the benefits of classes are even better when you throw collections and generics into the mix. The development experience just makes sense. I let the TypeScript compiler decide if my classes should be transpiled to functions, prototypes or classes.

I’ve read quite a lot on the subject of OOP and the main argument always seems to boil down to inheritance, followed by personal preference.

Composition <> Inheritance

Whenever the classes vs functions debate arise, people take sides and stances on one side or the other. The truth is you should not and do not have to choose a side, you can use both.

You can still use classes where they make sense and in other parts, use functions where they make sense. Sometimes you just need simple functions and other times, you might like the semantics of a class for organising your code.

If you are implementing a feature/writing code and a function feels appropriate, write a function. If a class feels more appropriate, use a class instead.

Web Components

If you head over to the Google fundamentals for creating custom elements or Mozilla MDN in Web Components, surprise surprise you will find classes are what you use to author custom elements.

Sure, you could just directly write the prototype chain yourself, but it’s going to result in ugly code that is just painful to maintain. The sweet syrupy abstraction that classes provide here is immediately obvious from an aesthetics perspective.

I think classes make a lot of sense when creating custom elements. You’re extending the inbuilt element type and creating your own variant of it. One of the things that classes do well.

Frameworks + First-Class Citizens

Angular and Aurelia are two fully-featured front-end frameworks that have leveraged Javascript classes since the beginning in 2015. I have quite a few Aurelia applications in production, all leveraging classes, sprinkled with a function or two.

The rewrite of Angular (Angular 2+) also treats classes as a first-class citizen. While React might be the most popular option out there, in the enterprise and government sectors, Angular is the king. A lot of Australian government agency applications are built using Angular.

I have not seen or heard of any developer, agency or company running into any kind of problem as a result of classes being a requirement to build Aurelia or Angular applications. If you have, I would love to know.

In instances where classes cause problems, it is because the developer using them is to blame. A bad mechanic blames their tools.

Ignore The Noise, Form Your Own Opinions

I don’t pretend to have all of the answers or be the worlds greatest coder, but I know what works for me based on my years of experience. Be wary of anyone who argues there is only one right way to develop in Javascript because there isn’t.

There are quite a few prominent figures in the JS community who will vehemently argue against classes. They will tell you they have seen companies lose millions, go bankrupt and projects completely scrapped because of classes.

Most of the anti-class crowd have an agenda. You will discover the common thread amongst most anti-class dev-influencers is they’re selling training courses and other material. They will tell you there is only one way to do something and to signup for their “Right Way of Doing Things” course for developers.

One person’s right is another person’s wrong.

The hype surrounding Svelte right now is inescapable. Every blog post comment section, the article comment section on Dev.to or Twitter thread/hot take seems to solicit a response about Svelte.

If you are not familiar, Svelte is a Javascript library which leverages a compiler to turn your Svelte code into plain old Javascript and HTML. You write your applications inside of .svelte files and they get compiled to something that has no runtime.

This puts Svelte into a similar league alongside Elm, Imba and a few others, not directly in line with React or Vue. However, being compared to React or Vue seems to be unavoidable in 2019 and will continue to be the case into 2020 and beyond.

In many ways, Svelte is an indirect competitor to the likes of React and Vue, both options which like to tout their small bundle and application sizes. On that front, they can’t compete with Svelte.

Where Svelte differs from other options like React and Vue is that it does not have a virtual DOM, no runtime or anything else non-standard after it is built. Syntactically, your applications end up looking like old-school AngularJS and Vue syntax and a little sprinkling of React’s JSX syntax thrown in:

<button on:click={handleClick}>

A lot of the examples you will see for Svelte highlighting its simplicity are not indicative of real-world applications. This rings true for many framework and library examples, showing as little code as possible. You don’t want to scare away users.

Where things start to look less HTML and Javascript-y is things like loops or conditional each statements. The following is an example of iterating over an array of users.

<ul>
    {#each users as user}
    <li>{user.id}: {user.name}</li>
    {/each}
</ul>

If you have ever worked with Handlebars templating in Javascript before, then this syntax will take you back to the mid-2000s right away. This is one example of a few other uses which also resemble Handlebars in Svelte.

Syntax aside, it is by no means a large criticism of Svelte. Every framework and library deals with looping over collections differently, except maybe for React and JSX which the community mostly uses a map to loop over items in collections.

In React’s JSX you will find the following approach is the most widely used:

    <ul>
      {users.map((user, index) => {
        return <li key={index}>{user.name}</li>
      })}
    </ul>

I actually would have loved to see Svelte adopt Aurelia’s approach to syntax instead of going down the path of Vue-like syntax and throwing in that Handlebars syntax.

In Svelte binding the value of a text input looks like this:

<input bind:value={name} placeholder="enter your name">

And in Aurelia, binding a text input value looks like this:

<input value.bind="name" placeholder="enter your name">

I realise my Aurelia bias is starting to show here, but in my opinion, I think the Aurelia approach looks a heck of a lot nicer and more JS syntax-like than the Vue bind:value approach. Not having to type a colon is a huge plus and it just looks neater.

Anyway, moving on. We are nitpicking here.

It is Fast.

There is no denying that Svelte is fast. The lack of runtime is the contributing factor here. The closer you are to the bare metal of the browser, the faster things will be.

The truth is, all frameworks and libraries are fast. When it comes to speed and performance, the contributing factor is rarely the framework or library itself, it is the user code.

Start pulling in various Node packages like Moment, adding in features such as validation and routing, and ultimately your bundle size is going to grow significantly. The end result might be the framework or library itself (even those with a runtime) accounts for 10% of your overall application size.

This is why I always tell people to be wary of benchmarks. Sure, benchmarks might look impressive, but they are not indicative of real-world conditions where things like latency, bundle size, what libraries you are using, and how you write your code are really the determining factors.

I think considerations to how a framework or library lets you author components and write code, what its features are, and what it allows you to easily and not easily do are more important than its speed.

To put things into context, there are still many AngularJS 1.x applications out there in production, which are still working fine. I also know of many Durandal, Knockout and Backbone applications still being used which are also working fine.

The generated code I have seen from Svelte applications is surprisingly readable as well. Usually compiled code is not easy to read (for humans) at all, so I was really surprised.

Svelte Exposes The True Complexity of React

For years, React has hidden behind the claim that it is the V in MVC, that it is a simple and a humble view component library. Anyone who has ever worked with React on an actual application will tell you that you never just need the view part.

I cannot recall a time where I have ever built a web application that didn’t have at least:

• Routing (the ability to define routes to different screens)
• The need to work with data from an API
• Form validation (not always, but more often than not)

If you want to add these features into a React app, you have to glue them all together. Because React utilises a Virtual DOM, the ability to just drop in and use any library that touches the DOM is not possible.

The problem with React itself (without turning this into a post bashing React), is that it is too heavily invested into itself. It is also responsible for perpetuating FUD in the front-end ecosystem on quite a few fronts.

React popularising Virtual DOM (and later on, Vue) would result in a lot of FUD around the DOM. When people tell you that the DOM is slow, they’re responding as a result of being programmed by the React community which drunk the “DOM is slow Koolaid” a few years ago.

Svelte has proven that the DOM is not slow. Although to be fair, Aurelia has eschewed the Virtual DOM (in favour of reactive binding) since it launched in 2015 and managed to keep step with other frameworks and libraries for years (upcoming Aurelia 2, even more so).

Now that React has introduced the concept of hooks into their library, it is yet another thing for developers to learn. Solutions like Svelte which do not require you to learn abstractions and ways of authoring applications definitely feel lighter and saner in the face of React.

Cognitively React requires a few React-specific ways of working which just adds to the learning curve. The React of 2019 is not the React of 2014, that is for sure. Authoring applications using Javascript and HTML is kind of refreshing.

Lack of ability to functionally compose views

This is one of those downsides of Svelte that some developers will struggle to look past. It requires you to use script tags and HTML to build your Svelte components. This means you are forced to use its templating syntax like #if, having to use #each for looping.

For developers who have had a taste of “pure components” where all components are written in Javascript, this is going to be a hard pill to swallow.

No TypeScript Support (Yet)

Right now, there is no official support for TypeScript in Svelte. If you are not a TypeScript user or perhaps you work with Vue 2 which admittedly is not much better at supporting TypeScript, then this will not be a dealbreaker for you at all.

If you are like many other developers who realise the future is TypeScript and have switched over, the lack of TS support is going to be a dealbreaker for you. Some developers have gotten it to work sort of using hacks, but not ideal support by any means.

Conclusion

I think what Svelte has brought to the table is going to kickstart some innovation and competition in the front-end space. While React has been trudging along for quite a few years now and Vue picking up popularity as well, it’s nice to see some new thinking that doesn’t revolve around a Virtual DOM or leaky abstraction.

Rest assured, you best believe that other frameworks and libraries are not going to sit idle while Svelte comes in and pulls the table cloth right off the dinner table.

The AOT compiler coming in Aurelia 2, for example, is going to optimise your Aurelia applications to a high degree stripping away runtime and unneeded code. Angular has been focusing their efforts on improved AOT compilation with the Ivy compiler and renderer and other options are also focusing their efforts on the compilation as well.

Even after playing around with Svelete just briefly, the lack of resulting code and marketing spin was refreshing to see after years of other players in the industry seemingly perpetuating immense amounts of hype.

Having said that, the safety and stability that I get using a featured framework (in my case, Aurelia) still feels too hard to beat.

I think Svelte is definitely going to get more popular and for non-complex UI’s it would be a great choice over React or Vue, but I still have hope that one day that Web Components becomes the norm and we see light abstractions on-top of WC that just compile to Web Components behind the scenes.

I would love to see how Svelte scales in a large-scale web application. Not specifically in performance (because I think it would remain fast), but rather code organisation, maintainability, testability and how easy it is to bring new team members up to scratch with an existing codebase.

Massive kudos to Rich Harris and everyone else who has worked on Svelte. I can definitely see the hype around Svelte is more than warranted and in the end, competition is healthy. We need fresh thinking and solutions to help drive standards and the ecosystem forward as a whole.

Aurelia’s robust binding system allows you to not only bind values into your custom attributes and elements, but also the ability to pass in callback functions as well. While your first instinct might be to try using <my-element callback.bind="myFunction" you will quickly realise that this will not work because of scoping issues.

This is where .call comes in. Using .call allows you to pass in callback functions to your bindables, and when they get called, their scope is retained.

Callbacks Without Parameters

Say we have a custom element we have created called my-custom-element and it has a bindable property called callback defined inside of the view-model using

@bindable callback = () => {}

Then our custom element callback binding looks like this:

<my-custom-element callback.call="someCallbackFunction()">

Inside of our custom element, when the callback bindable is fired, it will call our callback function and the scope of someCallbackFunction will be retained (the view-model it is defined in).

When you are not using parameters things are easy enough. You just need to define your callback with the circular function brackets like you would if you’re using click.delegate or other more event-type bindings.

Callbacks With Parameters

This is where I see developers get caught out quite a bit, passing parameters to callback functions. Using our above function, let’s say that our callback accepts two parameters: user and item.

<my-custom-element callback.call="someCallbackFunction(user, item)">

Inside of your custom element, when you call the callback you might try something like this if you didn’t read or understand the documentation correctly:

this.callback(this.selectedUser, this.selectedItem)

Because of how the .call feature works, this will not work (as you might have possibly already discovered). This is because you need to pass an object to the callback with your parameters matching the names you use in your HTML.

In our case, we are expecting two parameters: one called user and one called item to be passed into the callback.

Inside of our custom element, we need to pass them like this:

this.callback({user: this.selectedUser, item: this.selectedItem})

Now, our values get passed correctly and the callback retains its scope.

It is almost the year 2020, and you are still not using Aurelia, say it isn’t so. No more excuses, it’s time to charge up your Bluetooth keyboard and mouse batteries, make yourself a coffee and start using Aurelia.

Version 2 is coming and it’s going to be FAST

While Aurelia 1 is plenty fast, Aurelia 2 is a complete rewrite of Aurelia from the ground up. It not only focuses on JIT (Just In Time) runtime performance but also sees the introduction of AOT (Ahead of Time) compiling support which will yield upwards 100x speed improvements in your applications.

Aurelia 2 will take the learnings of Aurelia 1, along the way the features that many developers love and supercharge them, as well as add in new features that modern web applications require.

Low Learning Curve, Highly Extendable

The low-learning curve of Aurelia is unrivalled by any other framework. Show me a fully-featured client-side framework that can build ambitious large-scale web applications that require minimal documentation diving to use.

I have helped upskill developers from all facets in Aurelia and it truly speaks for itself. Just recently two backend developers at my work started moving into the front-end and within the space of just a week were writing and shipping Aurelia code.

Besides the ease-of-use, the extensibility is once again unrivalled. From the dependency injection through to templating, routing and compiling, every part of Aurelia can be overridden and replaced.

Dependency Injection

There are too many benefits of Dependency Injection to list, but there is no denying that DI is immensely useful and powerful. Aurelia has a great DI layer allowing you to pass around dependencies in your applications and specify the type of injection mode they should use.

One of the great benefits of Dependency Injection is unit testing. Because dependencies are passed through the constructor in your components and view-models, it allows you to easily mock them or my favourite approach of overriding the value in the container with a mocked version.

While it is possible to shoe-horn some semblance of DI into other libraries and frameworks, Aurelia provides a true Dependency Injection layer which can be used in your applications and keeping in line with the mantra of “easy to override” you can configure whatever way you want too.

First-class TypeScript Support

I have been working with Aurelia since 2015, I have been using it with TypeScript since 2016 and Aurelia has always supported TypeScript without the need for anything additional to be installed. The framework ships with strong typing support and in Aurelia 2, TypeScript is even more supported. The codebase of Aurelia 2 is completely written in TypeScript.

Long-term Support // Minimal Breaking Changes

Some of us Aurelia veterans have been running production applications since 2015 when it was an alpha release. As time went on and Aurelia reached beta, then release candidate stages before stable 1.0, while the framework was improved and changed, the core design stayed the same.

In its almost five years of existence, there has not really been one single breaking change. The core architecture and vision of Rob has remained untouched. There are not many frameworks and libraries that can boast continual improvement without some form of breaking change or convention.

Flexible Binding Approaches

Despite what some developers believe, there is no denying that two-way binding is amazing if used correctly. The ability to bind values to a view-model from a form input is immensely powerful. Unlike something like React which forces you to litter your code with change function callbacks to update values.

• One way
• Two way
• From view
• To view
• One time

Batteries Included

Why waste your time deciding what Router library to use, what state management solution you should use, whether you want to write in some XML like HTML syntax or how you will deal with validating some form inputs?

Aurelia is a glue-less framework that provides you with all of the modules you’ll need to build web applications. Let’s not get it twisted, it is quite rare that you just need the view component, most web applications we build generally require routing, validation, state management and templating.

Do you really want to wake up to the sound of tears on Christmas day because you forgot to buy the batteries and all of the shops are closed?