Impact of Polymorphism on Component-Based Frameworks Like React

In this post, we take a bit of foray into the conceptual computer science behind JavaScript and component-based JS frameworks with a Google dev as our guide.

I just realized that this is going to be the very first blog post of 2018 that I write myself - versus bugging someone else to write a blog post. It’s been quite a busy year for me already, plus I was sick a lot, and so was my family. Anyways, here’s something I’ve been meaning to send out for a while. And while the title mentions React explicitly, this is by no means limited to React, but probably affects a lot of code out there, including a lot of Node.js code bases, where this impact is even more severe.

I’ve written a blog post on Surprising polymorphism in React applications earlier and this post goes in the same direction, although we’ll explore a slightly different problem here. For more background on the topic, you may want to read What’s up with monomorphism? and Explaining JavaScript VMs in JavaScript - Inline Caches by my colleague Vyacheslav Egorov.

A Motivating Example

So let’s dive right in with a code example. Imagine you have a component-based framework like React and you need to call certain methods on all components, like the render method in case of React. Here’s a simplified example of how this could look:

// Base class for all components.

class Component {

  render() { return ''; }

}

class HelloComponent extends Component {

  render() {

    return '<div>Hello</div>';

  }

}

class LinkComponent extends Component {

  constructor(target, text) {

    this.target = target;

    this.text = text;

  }

  render() {

    return '<a href="' + this.target + '">' + this.text + '</a>';

  }

}

class DOM {

  static renderAll(target, components) {

    let html = '';

    for (const component of components) {

      html += component.render();

    }

    target.innerHTML = html;

  }

}

const components = [

  new HelloComponent(),

  new LinkComponent('http://www.google.com', 'Search')

];

DOM.renderAll(document.getElementById('my-app'), components);

You call DOM.renderAll to render a collection of components to a part of the DOM. This is oversimplified of course, but you get the concept. Also note that this code doesn’t follow any of the security advice for dealing with HTML/DOM from JavaScript, so please don’t take any inspiration here.

The interesting code here is inside of DOM.renderAll, where we access the property component.render of different componentshapes (in V8 speak we don’t say shape but we use the term map or sometimes hidden class). In this simple example, we only have two different shapes of component: Either an instance of HelloComponent where render is found on the HelloComponent.prototype, or an instance of LinkComponent where render is found on the LinkComponent.prototype. So the property access component.renderin DOM.renderAll will be 2-way polymorphic.

Inline Cache States

Let’s use a simplified example components1.js here to illustrate this:

class Base { foo() {} }

class A extends Base { foo() { } }

class B extends Base { foo() { } }

function bar(instance) {

  return instance.foo();

}

bar(new A);

bar(new B);

bar(new A);

bar(new B);

Running this with d8 and the --trace-ic flag we can see that the LoadIC (inline cache) for the property access instance.foo goes polymorphic, indicated by the P state:

$ out/Release/d8 --trace-ic components1.js

$ tools/ic-processor

LoadIC (.->1) at ~bar components1.js:6:19 foo (map 0x8f24d80cca1)

LoadIC (1->P) at ~bar components1.js:6:19 foo (map 0x8f24d80cc01)

=====================

Load: 2

Store: 0

KeyedLoad: 0

KeyedStore: 0

StoreInArrayLiteral: 0

In V8 we have these five different states for LoadICs right now:

MARKERNAMEDESCRIPTION

0UNINITIALIZEDThe property access was not executed so far.

.PREMONOMORPHICThe property access was executed once and we are likely going to go MONOMORPHIC on the next hit.

1MONOMORPHICThe property access was always executed with the same shape.

PPOLYMORPHICThe property access was always executed with one of four different shapes.

NMEGAMORPHICThe property access has seen too many different shapes.

The initial 0->. transition is not shown with --trace-ic currently, because V8 does that internally on the fast path where no logging is hooked up right now. In the example above, we run through instance.foo with two different shapes for instance, either an instance of A with foo on A.prototype, or an instance of B with foo on B.prototype. Let’s beef up the example a bit and add more than four different shapes as is shown in components2.js below:

class Base { foo() {} }

class A extends Base { foo() { } }

class B extends Base { foo() { } }

class C extends Base { foo() { } }

class D extends Base { foo() { } }

class E extends Base { foo() { } }

function bar(instance) {

  return instance.foo();

}

bar(new A);

bar(new B);

bar(new C);

bar(new D);

bar(new E);

bar(new A);

bar(new B);

bar(new C);

bar(new D);

bar(new E);

Running this through d8 again with --trace-ic we see that we stay POLYMORPHIC for the first four shapes, but then we go MEGAMORPHIC (as indicated by the N state) eventually (on the second instance of A in this case due to the initial PREMONOMORPHICstep):

$ out/Release/d8 --trace-ic components2.js

$ tools/ic-processor

LoadIC (.->1) at ~bar components2.js:9:19 foo (map 0x15581a58ce81)

LoadIC (1->P) at ~bar components2.js:9:19 foo (map 0x15581a58cfc1)

LoadIC (P->P) at ~bar components2.js:9:19 foo (map 0x15581a58d0b1)

LoadIC (P->P) at ~bar components2.js:9:19 foo (map 0x15581a58d1a1)

LoadIC (P->N) at ~bar components2.js:9:19 foo (map 0x15581a58cde1)

=====================

Load: 5

Store: 0

KeyedLoad: 0

KeyedStore: 0

StoreInArrayLiteral: 0

The MEGAMORPHIC state is the I don’t know what to do about this state of V8. Whenever a LoadIC reaches the MEGAMORPHIC state, TurboFan will no longer be able to inline any fast-path for it (except for some corner cases where TurboFan can find information about the object somewhere else), and will have to go through the inline cache logic all the time instead. MEGAMORPHIC also indicates that the inline cache will no longer try to cache information about how to access the property locally (i.e. on the property access site), but instead fall back to a global cache (the so-called megamorphic stub cache).

Scalability Issues

This megamorphic stub cache is a global cache of fixed size where all MEGAMORPHIC sites will try to cache the lookup information for properties. This is important to understand, especially for big applications, as that means you’ll likely have a lot of contention on this resource. Highly polymorphic sites like instance.foo in the example above are prime candidates for contenders, and you’ll only be affected by this non-local effect once you start integrating your applications or once you trigger a significant number of hash collisions on the global cache with a single property access site.

const N = 10000;

function test(fn) {

  var result;

  for (var i = 0; i < N; ++i) result = fn();

  return result;

}

test(x => x);

function makeNaive(klasses) {

  const instances = klasses.map(klass => new klass);

  return function naive() {

    let result;

    for (const instance of instances) result = instance.foo();

    return result;

  }

}

const DEGREES = [100, 300, 500, 700, 900];

for (const degree of DEGREES) {

  const KLASSES = [];

  for (let i = 0; i < degree; ++i) {

    KLASSES.push(eval('(class C' + i + ' { foo() { }})'));

  }

  const TESTS = [ makeNaive(KLASSES) ];

  for (var j = 0; j < TESTS.length; ++j) {

    test(TESTS[j]);

  }

  for (var j = 0; j < TESTS.length; ++j) {

    var startTime = Date.now();

    test(TESTS[j]);

    console.log(degree + ':', (Date.now() - startTime), 'ms.');

  }

}

The example above illustrates this problem, even with just a single access site instance.foo inside of the naive function, and varying degrees of polymorphism. Running this through d8 (in V8 6.6) you’ll see that the solution doesn’t scale very well:

$ out/Release/d8 components3.js

100: 43 ms.

300: 167 ms.

500: 1286 ms.

700: 1866 ms.

900: 2428 ms.

It actually scales very poorly since the VM spends more and more time missing on the global cache due to collisions. Notice especially the cliff when going from 300 different shapes to 500 different shapes.

A Potential Solution

Unfortunately big, component-based applications naturally have a high degree of polymorphism by design. So what can you do to mitigate the negative impact? The main problem is having property access such as instance.foo where instance can have a high number of different shapes. So if you try to not have that many of these accesses in your application, you’ll likely reduce the negative impact on the global cache.

One way to do this is to simply load the method ahead of time, remember it together with the object reference and then useFunction.prototype.call in the hot loop. A convenient way to avoid having to carry around the pair of object and function yourself is to use Function.prototype.bind instead.

const N = 10000;

function test(fn) {

  var result;

  for (var i = 0; i < N; ++i) result = fn();

  return result;

}

test(x => x);

function makeNaive(klasses) {

  const instances = klasses.map(klass => new klass);

  return function naive() {

    let result;

    for (const instance of instances) result = instance.foo();

    return result;

  }

}

function makeCall(klasses) {

  const pairs = klasses.map(klass => {

    const instance = new klass();

    const method = instance.foo;

    return {instance, method};

  });

  return function call() {

    let result;

    for (const {instance, method} of pairs) {

      result = method.call(instance);

    }

    return result;

  }

}

function makeBound(klasses) {

  const fns = klasses.map(klass => {

    const instance = new klass();

    return instance.foo.bind(instance);

  });

  return function bound() {

    let result;

    for (const fn of fns) result = fn();

    return result;

  }

}

const DEGREES = [100, 300, 500, 700, 900];

for (const degree of DEGREES) {

  const KLASSES = [];

  for (let i = 0; i < degree; ++i) {

    KLASSES.push(eval('(class C' + i + ' { foo() { }})'));

  }

  const TESTS = [ makeBound(KLASSES), makeCall(KLASSES), makeNaive(KLASSES) ];

  for (var j = 0; j < TESTS.length; ++j) {

    test(TESTS[j]);

  }

  for (var j = 0; j < TESTS.length; ++j) {

    var startTime = Date.now();

    test(TESTS[j]);

    console.log(

        degree + '|' + TESTS[j].name + ':', (Date.now() - startTime), 'ms.');

  }

}

Running this with V8 6.6, both approaches scale equally well and avoid the problem of hot MEGAMORPHICproperty accesses.

So the takeaway here is that a high degree of polymorphism is not bad per se, but if you have a lot of MEGAMORPHIC property accesses on the critical path, then eventually your application is going to spend a lot of time fighting for entries in the megamorphic stub cache (at least with how V8 works currently). For component-based systems, there are ways to avoid this situation by preloading methods used in hot code later.

Update

Just ran the same test again with V8 6.7.0 (candidate) as of today, and it seems that it does scale better, although I’m unsure what changed in this area recently (I have to admit I haven’t worked on this area of V8 a lot).

Using React, Firebase, and Ant Design to Quickly Prototype Web Applications

In this guide I will show you how to use Firebase, React, and Ant Design as building blocks to build functional, high-fidelity web applications. To illustrate this, we'll go through an example of building a todo list app.

These days, there are so many tools available for web development that it can feel paralyzing. Which server should you use? What front-end framework are you going to choose? Usually, the recommended approach is to use the technologies that you know best. Generally, this means choosing a battle-tested database like PostgreSQL or MySQL, choosing a MVC framework for your webserver (my favourite is Adonis), and either using that framework's rendering engine or using a client-side javascript library like ReactJS or AngularJS.

Using the above approach is productive -- especially if you have good boilerplate to get you started -- but what if you want to build something quickly with nearly zero setup time? Sometimes a mockup doesn't convey enough information to a client; sometimes you want to build out an MVP super fast for a new product.

The source code for this example is available here. If you're looking for a good IDE to use during this guide, I highly recommend Visual Studio Code.

A React Development Environment Using Create React App

React is a javascript library for building user interfaces. The library is "component based" meaning you can create building blocks and compose your interface out these reusable components. Create React App, on the other hand, is a zero-configuration React environment. It works out of the box with one shell command and keeps your environment up to date.

To get started, install Node.js for your system by following the instructions here.

Then start your new Create React App project:

npx create-react-app quick-todo && cd quick-todo

Now, you can run the development webserver with:

npm start

Visit http://localhost:3000/ in your browser and you should see this:

Great! You now have a functional React development environment.

Integrate Firebase with Your Application

Now that you have a React development environment, the next step is to integrate Firebase into your app. Firebase's core product is a real-time database service. This means that your users do not need to refresh a page to see updates to the state of the application and it takes no extra effort on your part to make this happen.

Head over https://firebase.google.com and create an account if you haven't already. Then create a new Firebase project called quick-todo.

Once you have your Firebase project, provision a "Cloud Firestore" database:

Here we're using no authentication on the database because we're building a prototype. When you build a real application, you'll want to create proper security rules but let's not worry about that for now.

Ok, now that your Firebase database is provisioned, let's get it integrated into your React app. In your project directory, run the following command to install the necessary dependencies:

npm i --save firebase @firebase/app @firebase/firestore

Then, in your project, add a new file in the src directory called firestore.js with the following contents:

firestore.js

import firebase from "@firebase/app";
import "@firebase/firestore";

const config = {
  apiKey: "<apiKey>",
  authDomain: "<authDomain>",
  databaseURL: "<databaseURL>",
  projectId: "<projectId>",
  storageBucket: "",
  messagingSenderId: "<messageingSenderId>"
};

const app = firebase.initializeApp(config);
const firestore = firebase.firestore(app);

export default firestore;

Make sure you insert the apiKey and other parameters from your own project. You can find these in your project's settings:

Ok! Now we have access to a real-time Firebase database anywhere in the app by importing our firestore.js utility:

import firestore from "./firestore";

Install Ant Design

Ant Design is a comprehensive design system that includes a full suite of React components. Because React is component-based, it's fairly simple to use Ant Design's React components as building blocks to quickly put together a prototype.

To start using Ant Design's React component system, install antd:

npm i --save antd

Pulling It All Together

We now have all all the tools we need to build our prototype. Let's use our environment to build a high-fidelity prototype of a todo app.

First, let's clean our slate. Modify App.js and App.css so that they look like this:

App.js

import React, { Component } from "react";

import "./App.css";

class App extends Component {
  render() {
    return <div className="App" />;
  }
}

export default App;

App.cs

@import "~antd/dist/antd.css";

.App {
  text-align: center;
}

Notice how we've imported the css for antd.

Now, let's setup some basic structure for our todo app. We can use the antdLayout component for this:

App.js

import React, { Component } from "react";
import { Layout } from "antd";

import "./App.css";

const { Header, Footer, Content } = Layout;

class App extends Component {
  render() {
    return (
      <Layout className="App">
        <Header className="App-header">
          <h1>Quick Todo</h1>
        </Header>
        <Content className="App-content">Content</Content>
        <Footer className="App-footer">&copy; My Company</Footer>
      </Layout>
    );
  }
}

export default App;

App.css

@import "~antd/dist/antd.css";

.App {
  text-align: center;
}

.App-header h1 {
  color: whitesmoke;
}

.App-content {
  padding-top: 100px;
  padding-bottom: 100px;
}

With these changes made, we can run our development server. You should seed something like this:

Now, we can utilize our firestore.js module that we create earlier to start adding todos to our real-time firebase database. You can read more about how to use Firebase Cloud Firestore here.

Let's walk through the following changes to our source code:

App.js

import React, { Component } from "react";
import { Layout, Input, Button } from "antd";

// We import our firestore module
import firestore from "./firestore";

import "./App.css";

const { Header, Footer, Content } = Layout;

class App extends Component {
  constructor(props) {
    super(props);
    // Set the default state of our application
    this.state = { addingTodo: false, pendingTodo: "" };
    // We want event handlers to share this context
    this.addTodo = this.addTodo.bind(this);
  }

  async addTodo(evt) {
    // Set a flag to indicate loading
    this.setState({ addingTodo: true });
    // Add a new todo from the value of the input
    await firestore.collection("todos").add({
      content: this.state.pendingTodo,
      completed: false
    });
    // Remove the loading flag and clear the input
    this.setState({ addingTodo: false, pendingTodo: "" });
  }

  render() {
    return (
      <Layout className="App">
        <Header className="App-header">
          <h1>Quick Todo</h1>
        </Header>
        <Content className="App-content">
          <Input
            ref="add-todo-input"
            className="App-add-todo-input"
            size="large"
            placeholder="What needs to be done?"
            disabled={this.state.addingTodo}
            onChange={evt => this.setState({ pendingTodo: evt.target.value })}
            value={this.state.pendingTodo}
            onPressEnter={this.addTodo}
          />
          <Button
            className="App-add-todo-button"
            size="large"
            type="primary"
            onClick={this.addTodo}
            loading={this.state.addingTodo}
          >
            Add Todo
          </Button>
        </Content>
        <Footer className="App-footer">&copy; My Company</Footer>
      </Layout>
    );
  }
}

export default App;

App.css

@import "~antd/dist/antd.css";

.App {
  text-align: center;
}

.App-header h1 {
  color: whitesmoke;
}

.App-content {
  padding-top: 100px;
  padding-bottom: 100px;
}

.App-add-todo-input {
  max-width: 300px;
  margin-right: 5px;
}

.App-add-todo-button {
}

With these changes, you can see that we now have an input on our application to add new todos.

Adding todos doesn't yet show up in the UI, but you can browse your Firebase database to see any todos that you add!

The last step to having a fully functional todo app is to show the list of todos and allow the user to complete them. To do this, we can use the Listcomponent from Ant Design to show incomplete todos. Take the following source code for example:

App.js

import React, { Component } from "react";
import { Layout, Input, Button, List, Icon } from "antd";

// We import our firestore module
import firestore from "./firestore";

import "./App.css";

const { Header, Footer, Content } = Layout;

class App extends Component {
  constructor(props) {
    super(props);
    // Set the default state of our application
    this.state = { addingTodo: false, pendingTodo: "", todos: [] };
    // We want event handlers to share this context
    this.addTodo = this.addTodo.bind(this);
    this.completeTodo = this.completeTodo.bind(this);
    // We listen for live changes to our todos collection in Firebase
    firestore.collection("todos").onSnapshot(snapshot => {
      let todos = [];
      snapshot.forEach(doc => {
        const todo = doc.data();
        todo.id = doc.id;
        if (!todo.completed) todos.push(todo);
      });
      // Sort our todos based on time added
      todos.sort(function(a, b) {
        return (
          new Date(a.createdAt).getTime() - new Date(b.createdAt).getTime()
        );
      });
      // Anytime the state of our database changes, we update state
      this.setState({ todos });
    });
  }

  async completeTodo(id) {
    // Mark the todo as completed
    await firestore
      .collection("todos")
      .doc(id)
      .set({
        completed: true
      });
  }

  async addTodo() {
    if (!this.state.pendingTodo) return;
    // Set a flag to indicate loading
    this.setState({ addingTodo: true });
    // Add a new todo from the value of the input
    await firestore.collection("todos").add({
      content: this.state.pendingTodo,
      completed: false,
      createdAt: new Date().toISOString()
    });
    // Remove the loading flag and clear the input
    this.setState({ addingTodo: false, pendingTodo: "" });
  }

  render() {
    return (
      <Layout className="App">
        <Header className="App-header">
          <h1>Quick Todo</h1>
        </Header>
        <Content className="App-content">
          <Input
            ref="add-todo-input"
            className="App-add-todo-input"
            size="large"
            placeholder="What needs to be done?"
            disabled={this.state.addingTodo}
            onChange={evt => this.setState({ pendingTodo: evt.target.value })}
            value={this.state.pendingTodo}
            onPressEnter={this.addTodo}
            required
          />
          <Button
            className="App-add-todo-button"
            size="large"
            type="primary"
            onClick={this.addTodo}
            loading={this.state.addingTodo}
          >
            Add Todo
          </Button>
          <List
            className="App-todos"
            size="large"
            bordered
            dataSource={this.state.todos}
            renderItem={todo => (
              <List.Item>
                {todo.content}
                <Icon
                  onClick={evt => this.completeTodo(todo.id)}
                  className="App-todo-complete"
                  type="check"
                />
              </List.Item>
            )}
          />
        </Content>
        <Footer className="App-footer">&copy; My Company</Footer>
      </Layout>
    );
  }
}

export default App;

App.css

@import "~antd/dist/antd.css";

.App {
  text-align: center;
}

.App-header h1 {
  color: whitesmoke;
}

.App-content {
  padding-top: 100px;
  padding-bottom: 100px;
}

.App-add-todo-input {
  max-width: 300px;
  margin-right: 5px;
}

.App-add-todo-button {
}

.App-todos {
  background-color: white;
  max-width: 400px;
  margin: 0 auto;
  margin-top: 20px;
  margin-bottom: 20px;
}

.App-todo {
  /* position: relative; */
}

.App-todo-complete {
  font-size: 22px;
  font-weight: bold;
  cursor: pointer;
  position: absolute;
  right: 24px;
}

With these final changes, we can see the todos that are added in our application as a list:

And there we have it! Using React, Firebase, and Ant Design, we were able to quickly create a high-fidelity web application. Using these tools can help you create something functional and aesthetically pleasing in no time.

This can be very valuable when you need to demonstrate functionality of an app to someone without spending too much time building it.

This guide focuses on using tools to quickly build prototypes but I think this approach can also be used to create production-ready web apps. Ant Design can be themed and Firebase is extremely scalable.

The only question of using Firebase over a traditional webserver is cost. For applications with many users, Firebase may get expensive quickly; however, using the traditional approach of webserver and database can also be costly to host. Additionally, you also need to take into account the time and cost of building, configuring, and managing your webserver and database!

Originally published at nrempel.com

Make your code easier to read with Functional Programming

Pure functions are easier to read and understand. All the function’s dependencies are in its definition and are therefore easier to see. Pure functions also tend to be small and do one thing. They don’t use this, a constant source of confusion.

Chaining

Chaining is a technique used to simplify code where multiple methods are applied to an object one after another.

Now let’s look and compare the two styles: imperative and functional. In the functional style, I’ll use the basic toolbox for list operations filter() and map() by chaining them together.

//Imperative style
var filteredTasks = [];
var task, i;
for(i=0; i<tasks.length; i++){
    task = tasks[i];
    if (task.type === "RE") {
        filteredTasks.push({ id : task.id, desc : task.desc });
    }
}

//Functional style
function isReviewTask(task){
   return task.type === "RE";
}

function toTaskViewModel(task) {
   return { id : task.id, desc : task.desc };
}

var filteredTasks = tasks.filter(isReviewTask)
                         .map(toTaskViewModel);

Notice the callbacks for filter() and map() as pure functions with intention revealing names.

Partial Application

Next I want to look into how we can improve readability and also reuse an existing function. Before doing that, we need a new function in our toolbox.

Partial application refers to the process of fixing a number of arguments to a function.

It’s a way to go from generalization to specialization.

We can create the partialRight() function and make it available to all functions by adding it to the Function.prototype . Or we can use one from a library like underscore.js or lodash.js.

Let’s say we want to refactor the flowing code to a functional style:

var priorityTasks= [];
var task, i;
for(i=0; i<tasks.length; i++){
    task = tasks[i];
    if (task.type === "RE" || task.type === "NC") {
        priorityTasks.push(task);
    }
}

As I said, this time we want to create a generic function that can be used for filtering by any task type. Below we can see isTaskOfType() as the generic function, and how partialRight() can be used to create new predicates that will filter by specific types.

A predicate function is a function that takes one item as input and returns true/false based on whether the item satisfies a condition.

var isTaskOfType = function(task, type){
   return task.type === type;
}

var isNewContent = isTaskOfType.partialRight("NC");
var isReview = isTaskOfType.partialRight("RE");

Next I’ll use the two new predicates. Notice the filter’s callback. It has a name expressing its intention. It’s code may change and get more complex, but when I’m reading tasks.filter(isAPriorityTask) I clearly understand what kinds of tasks I’m selecting.

function isAPriorityTask(task){
   return isNewContent(task) || isReview(task);
}

var priorityTasks = tasks.filter(isAPriorityTask);

Reduce

I’ll start a new example using a shopping list, and I’ll compute the total price and also the price for fruit only. Below is the imperative style:

var totalPrice = 0, fruitsPrice = 0, i, line;
for(i=0; i<shopingList.length; i++){
   line = shopingList[i];
   totalPrice += line.units * line.price;
   if (line.type === "fruits") {
       fruitsPrice += line.units * line.price;
   }
}

Taking the functional approach in this case will require the use of reduce() to compute the total price.

The reduce() function is used to accumulate all values of the collection into one value.

As we did before, we’ll create new functions for the required callbacks and give them intention reveling names : computePrice() and areFruits().

function computePrice(totalPrice, line){
   totalPrice += line.units * line.price;
   return totalPrice;
}

function areFruits(line){
   return line.type === "fruits";
}

var totalPrice = shopingList.reduce(computePrice, 0);
var fruitsPrice = shopingList.filter(areFruits)
                             .reduce(computePrice, 0);

Conclusion

Applying Functional Programming to list operations will break the operations in steps like: filter, map, reduce, and sort. At the same time, it will require you to define new pure small functions to support those operations.

By combining Functional Programming with the practice of giving Intention Reveling Names to these new functions, we can greatly improve the readability of the code.

Web Components — the right way

From about two years we have been heard about web components, well this article will not explain how they work (for that there is Google), but rather we will address the purpose of this technology, when and how use it.

We can consider web components as a tool to extend HTML, not to replace it. The available technologies follow the same rules that we are all used to —from always— see in the most famous language markup in the world.

Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilise them in your web apps.
— MDN

HTML — Accelerated course

Every web developer knows — or at least should — the basics of HTML and how to define the markup of a web element that will be represented by the browser in a certain way and with a specific behaviour.

In the above example, like the greatest part of HTML elements, the node can accept a content that will be shown (and stylised) by the browser or by CSS user. But as we all know, it exists also elements that can not accept children nodes (well known as void elements) —for example the <img> and <input>tags — and other tags that require only some types of nodes.

The <select> element, like more other, is a node that uses a shadow DOM similar logic; for this reason, if you want, you can see the content of these elements in the same way as per web components:

This is approximately the mechanic beyond this language, so we can define two different HTML element models:

• Modular elements — Allow children nodes (normal elements)
• Self-closing elements — Does not allow children nodes (void elements)

Custom elements

As we wrote, the technologies beyond web components aim to extend HTML, not to replace it. What does it mean? That we have tools to create new HTML elements that would not naturally exist if not implemented by user-agents (browsers), or to extend the behaviour of those ones already existing by adding functionalities and custom styles.

When?

The answer is easier than you expect. Define new HTML elements is necessary when the available ones do not meet functionality and design needs.

If we need to create a new <my-button> element with a customised style, we must think about the progressive enhancement. So we should add functionalities and styles, rather than completely recreate the element from scratch.

The wrong way

If we surf on the Internet, we can find some pattern libraries fully composed by custom elements (using or not some frameworks, like Polymer), tests, examples, playgrounds …and they all have one thing in common, they are all created using a wrong pattern. Do you remember? We are extending the HTML, so we should follow its paradigms and its composition. Here some examples:

An entire app inside the shadow root. It’s the same as putting the app inside the <input> tag.

A native <button> element wrapped… inside another custom button. It’s the same as putting a <button> inside another <button>.

Does this image really need a description? Think about the <select>example above.

They are many other wrong examples around, but these are the most misleading that I found, compared to the fundamental HTML principle, the composition (read more about it).

Composition is one of the least understood features of shadow DOM, but it’s arguably the most important.
— Google Web Fundamentals

The right way

When we develop a web component, we must consider the two models described above. So we can create custom elements that allow children nodes (through the <slot> tag), or create self-closing elements (voidelements).

For example, let’s consider to create a custom element that shows a tooltip balloon near any element passed as a child, as we would do with the HTML.

The above <my-tooltip> element, if we want, can allow users to customise the tooltip balloon style— that it is in the #shadow-root — only through a set of custom properties, if we define them inside the :host selector. You can read more about defining CSS api (or style-hooks) here.

Go on with a more complex example and define a custom element that allows only one type of child node, as per <ul> and <li> tags to generate a list:

In conclusion

Composition. Web Components are useful to create new HTML elements that will compose web interfaces, as we have always done. Custom and native html elements are the ”tree leaves”, so it is an error consider them as a “big” app containers, or as application data containers. For more info, I suggest you to read the official documentation written by Google guys, in which you will find all about web components, custom elements, shadow DOM and best practices.

Cover image Building Blocks by Ola Tandstad

Developers love trendy new languages but earn more with functional programming

And most feel that AI morality is management’s problem.

Developer Q&A site Stack Overflow performs an annual survey to find out more about the programmer community, and the latest set of results has just been published.

JavaScript remains the most widely used programming language among professional developers, making that six years at the top for the lingua franca of Web development. Other Web tech including HTML (#2 in the ranking), CSS (#3), and PHP (#9). Business-oriented languages were also in wide use, with SQL at #4, Java at #5, and C# at #8. Shell scripting made a surprising showing at #6 (having not shown up at all in past years, which suggests that the questions have changed year-to-year), Python appeared at #7, and systems programming stalwart C++ rounded out the top 10.

These aren't, however, the languages that developers necessarily want to use. Only three languages from the most-used top ten were in the most-loved list; Python (#3), JavaScript (#7), and C# (#8). For the third year running, that list was topped by Rust, the new systems programming language developed by Mozilla. Second on the list was Kotlin, which wasn't even in the top 20 last year. This new interest is likely due to Google's decision last year to bless the language as an official development language for Android. TypeScript, Microsoft's better JavaScript than JavaScript comes in at fourth, with Google's Go language coming in at fifth. Smalltalk, last year's second-most loved, is nowhere to be seen this time around.

These languages may be well-liked, but it looks as if the big money is elsewhere. Globally, F# and OCaml are the top average earners, and in the US, Erlang, Scala, and OCaml are the ones to aim for.

Visual Basic 6, Cobol, and CoffeeScript were the top three most-dreaded, which is news that will surprise nobody who is still maintaining Visual Basic 6 applications thousands of years after they were originally written.

Stack Overflow also asked devs about one of today's hot-button issues: artificial intelligence. Only 20 percent of devs were worried about AI taking jobs (compared to 41 percent excited by that possibility—no doubt the Visual Basic 6 devs hope that one day computers will be able to do their jobs for them), but a remarkable 28 percent were concerned by AI intelligence surpassing human intelligence, and 29 percent concerned about algorithms making important decisions more generally.

Among developers that actually know what they're talking about, however, the concerns seemed to shift: data scientists and machine-learning specialists were 1.5 times more likely to be concerned about algorithmic fairness of AI systems than they were any singularity.

Even if AI is evil, most developers don't think it's the fault of the programmers. Fifty-eight percent say that ethics are the responsibility of upper management, 23 percent the inventor of the unethical idea, and just 20 percent think that they're the responsibility of the developer who actually wrote the code. If the Volkswagen emissions scandal is anything to judge by, the developers may not be completely off the mark; thus far, arrests appear to have been restricted to executives and engineers who designed the emissions test-defeating software, leaving the people who wrote the code unscathed

Fantastic youtube channels, with top-quality learning for software engineers

Video training is undeniably one of the most popular methods, for self-taught programmers and according to Forbes, the most popular, amongst millennials.

Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. The greatest thing in life is to keep your mind young. (Henry Ford)

As far as I know, many people are relying on one or more of the most popular video training platforms like Pluralsight, Udemy or Coursera but they use accounts funded by the company they are working for.

But what about those who don’t have that great benefit and cannot allow a budget around 300$/year for such purpose? Thankfully, youtube is hosting quite a few channels which offer top-quality material for software engineers. Below are my favorites, in no particular order.

Even master yoda agrees

1. DerekBanas: Derek is providing a diverse set of tech courses. From assembly and design patterns to Django, Rails and UML. His extremely clear accent makes subtitles useless. What I like about this channel, is that is not purely technical, but has a good grasp on the soft skills side of a developer’s life, like negotation and sales techniques.
2. thenewboston With 4350 videos, at the time of writing this article, this guy is literally recording while he is sleeping. Like Derek Banas, thenewboston(or Bucky Roberts as known in the real world) is providing tutorials on a wide variety of subjects. Programming courses are taking the lion’s share of the channel’s library but there a few for math, biology, and gaming.
3. FreeCodeCamp talks A great — and relatively recent — initiative from FreeCodeCamp, where various passionate people give talks on modern technical topics. You can even send your talk there, to be published. There is no reason to consume your time here, given there is a great article answering all the questions.
4. Success in Tech Ramon Lopez, the owner of this channel is a great software engineer I am following for some time now. Initially, I was attracted by his system design articles, but later I loved his career advice playlist too. It looks paused for a while now, I hope it will be refreshed soon.
5. Traversy Media A channel whose ower is heavily involved with web programming. A quick scroll in his playlists will leave you with no doubt. :) He is mostly focusing on Node.Js and vanilla Javascript but there is some fair share of PHP, Python, and CSS. My favorite part here, are the long videos he has created, where you can get a good grasp of the tech he is talking in about an hour, like this one.