DEV Community: 🇨🇵️ Nathan Graule

A colorful journey

🇨🇵️ Nathan Graule — Fri, 22 May 2020 13:22:10 +0000

Aahhh, computer color. Red, green and blue phosphors illuminated by an electron guided by a carefully-controlled
magnetic field, quick enough so that the human eye doesn't see the previous image dim down before the next is sent through... Wait this ins't the 80s anymore you say?

What is color, anyway?

Our eyes work in a fascinating way. Nature has devised a way to count how many photons enter it (though not literally, reality is much more nuanced). Whats more is that they don't count all photons the same way - we have different receptors for different frequencies of light - 4 of them in fact: Rods which react to pretty much any light ray in the visible spectrum, and Long , Medium and Short cones which react respectively to short, medium and long frequencies of light.

No, that's not confusing because when talking about light, we often use the term "wavelength" instead of frequency; and since the wavelength of a light ray is inversely proportional to its frequency, Short cones are sensitive to short wavelengths, and so on.

These cones each contribute a part of what we see as "color", while the rods in our eye sense more of a general brightness. The Short cone sense what we perceive as blue, the Medium cone if for greens, and the Long cone is all about the red color.

Formalizing color: XYZ

Back before any of this computery stuff had been thought of, in 1931, the Commission Internationale de l'Éclairage (International Commission for Illumination, abbreviated as CIE) ran a survey on vision and ended up on a method to map out spectral data (the intensity of light rays at a given wavelength, formally named Spectral Power Distribution or SPD) into how much each of our cones respond; and thus, the CIE XYZ color space was born.

The XYZ color space maps out spectral data by using color matching functions which represent the sensitivity of each color component to the spectrum of light. We can then calculate how much of the X, Y and Z components a particular SPD gives, and get a good estimation of the excitation level of each cone. This is useful in, for example, representing Black-body radiation on a computer monitor.

In more formal math terms, this means we integrate a product of our SPD and each of the color-matching functions over the entire spectrum to get an intensity of each channel. We can form a 3-dimensional vector with the resulting values, which we can then work on, and formalize the notion of color as a vector in a vector space with the "traditional" addition and products - encoding mathematically the notion of the additivity of color.

The idea of chromaticity and working with xyY

In the XYZ color space, because our Medium cones (green colors) is much more sensitive and covers a greater range of the visible light, the Y component works really well in approximating brightness (though, not quite, see LAB later). Therefore we can generate another color space that separates "colorfulness" and "brightness" - the result is still 3 components (forming a 3D vector still), but it has the added benefit that since brightness is kind of arbitrary, we can focus on the more interesting property of light: its colorfulness, or formally, its chromaticity (because we like big words!).

In other words, we can only work with XZ values by scaling the XYZ color so that the Y component is exactly 1.0, and we end up with a xyY space, which we usually only plot the x and y values into a 2D graph, as they are much easier to work with. What we end up with, is the famous (maybe?) "horseshoe" diagram, or gamut diagram:

The outer edge of the diagram, making out the horse-shoe shape, is the spectral locus, sometimes also called the monochromatic locus. They're basically the chromaticity values lasers of each wavelength would take. Inside, each chromaticity value corresponds to a color the human eye can see - outside this edge are colors we can't see, or at least not fully. If the chromaticity value is negative in either direction, the color is called "imaginary" - it can't be made in real life (it'd have a negative SPD, and negative intensities don't strictly exist).

The line in the middle with colors in the Kelvin scale is the Plankian locus - its the chromaticities of objects emitting black-body radiation - like our star, the Sun. The Sun emits a warm 5800 K which if you look it up on the gamut diagram, translates to a slightly yellow white. The Sun isn't white!

Note: the xy chromaticities have a third component, z, defined such that x + y + z = 1. This is a point that has some
value
in the
next section.

Making out color from primaries: RGB colors

It turns out, you can make all the colors in the above diagram by taking 3 chromaticities that aren't aligned - this corresponds to taking 3 colors such that the third can't be made by mixing the other two. So if you've ever had an argument in whether green or yellow is a primary color; well the answer is both and neither, at the same time. This because you can take 3 xy points such that they for a triangle, and call that a color space - wether it's red-green-blue or red-yellow-blue or orange-turquoise-purple, they're all valid primaries, and therefore all valid color spaces.

There's an added complexity, though. Because the xy plane only defines color, we have lost the definition of black and white. If there is sort of a white color appearing in the above gamut, it's because it's the point where the x and y values are equal - but this does not define what "white" is.

Instead, this is left to us to define what we will consider as white, and out of the many definitions of white these 3 are the most used:

Illuminant E: E stands for Equal-energy and is the point where the x, y, and z chromaticity components are all equal at 1/3 - this is maybe the most natural white point given the gamut diagram, however it gives a warmer tint to the color space as the equal-energy point feels itself as having a blue tint.
Illuminant D65: D stands for Daylight, and 65 is for taking a blackbody radiating at 6500 K as the white point. This is also the color of the overcast sky.
Illuminant D50: A warmer Daylight white point taken as the blackbody radiation of 5000 K.

There are other categories and other illuminants, but these are the most used ones.

Choosing these 4 values (the red, green, blue and white points) is important as they define the amount of colors the color space can reproduce. Indeed, only colors inside the "gamut triangle" formed by the primaries can be encoded and reproduced.

An example: sRGB

sRGB is the standard color space devised by HP and Microsoft in 1996 and went on to be, as the name suggest, the standard color space of monitors, images and printers.

Out of the all the colors you can make, sRGB can only encode a small amount of them, which doesn't make it a very good color space. However at the time, CRT monitors were the best technology there was, and these were the colors they could reproduce.

The catch: RGB colors are not linear

The human eye is, unfortunately, far from perfect. Not only do you only see "correctly" for only 2° around the center of your vision, that your peripheral vision is only in black-and-white, but you don't perceive colors linearly. Indeed, if you have one light-bulb turned on, and you turn a second one on, suddenly everything is twice as bright. But if you turn on a 3rd one, the whole room is only a third brighter. However, to a camera sensor, or spectrometer, you still added one light-bulb every time.

We perceive light logarithmically, that is we are more sensitive to changes in low-light conditions than to the same changes in well-lit situations. This means, darker areas of an image would have more "brightness definition" than lighter areas. And with only 8 bits per channel to spare, this would quickly lead to artifacts in dark patches of images. Therefore, sRGB transforms the linear RGB values by gama-correcting them.

This is all fine until you want to manipulate images - as is the case with anything from adding a watermark to pictures to creating photo montages to editing blockbuster VFX on top of camera footage. Because by applying this gamma correction to our RGB values, the principle that "color is additive" is broken.

However, for a long time (and even in Photoshop at least up until recently), image manipulation programs have taken the naive approach to work on gamma-corrected color directly, leading to unnatural results when applying filters (such as blurring an image) or layering (the "Add" blending mode really isn't additive, and the "Screen" blending mode is a pale attempt at making a "visually decent" additive blending mode while still working with gamma-corrected values). Ideally, if you juxtapose a red and a green square, and blur the resulting image, ideally you should see a slight yellow tone emerge (the red color "transitions" linearly from the red square to the green square in the xy plane, therefore passing by yellow hues). Instead, when working on gamma-corrected values the naive way, the blending yields darker values. See this page for examples and a more in depth look.

More formally, gamma correction isn't a linear map, and therefore the XYZ or RGB vector space will lose the properties of additions and multiplication defined in those input spaces. Simply put, the resulting vector space is not linear, and therefore linear addition/multiplication operations will not work as expected.

Conclusion: In practice

If you worry about me researching about computer color just to write a blog post about it, don't worry - this is the compilation of the few weeks I've spent gathering around data to write a Rust crate working with raw color; and I
needed this crate for a project that I didn't really finish, but was about rendering black holes, and needed to generate colors from black body radiation, straight from spectral data, computed from Plankian equations. Fun!

All in all, computer color is a mess; and there's no sign of anything that can be done here. Given all the variables
that exist in capture, storage and display technology, getting to represent colors as accurately as they happen in
reality is something closer to black magic wizardry than engineering. This is why working with colors is so hard
, and why working as a digital artist involves complicated pipelines.

And this also means that nobody, especially myself, should do what I did: implement it all from scratch.

Appendix

Cover photo by Ajeet Mestry on Unsplash

Gamut diagram from Wikipedia

sRGB gamut diagram from Wikipedia

A beginner's tutorial to Preact - Part 4: First steps with Preact

🇨🇵️ Nathan Graule — Sun, 11 Aug 2019 12:37:49 +0000

Now that we have reviewed everything we need to know prior to launching ourselves with Preact.

What is Preact?

Preact is a 3kb library which allows developers to write applications using the same patterns we saw earlier. Preact provides its own implementation of the h function which outputs Virtual DOM (the "pure JavaScript representation of DOM nodes" we have talked about earlier), and uses an efficient rendering algorithm to try and make as few changes to the web page as possible. It also boasts many more features that we will look at later.

The canonical "Hello World" application

Dependencies

Let's start by creating a project. I'm going to use CodeSandbox (as I have already for the examples) as it allows me to embed the project into the post directly for you to run and tweak. So, either start a new "Vanilla (+ TS)" project, or start a new npm project (npm init).

The second thing to do, of course, is to install Preact. We're going to use version 10, which at the time of writing is still in Release Candidate, but is a complete rewrite of Preact itself, and writing a tutorial with a well known expire date isn't all that useful. Use preact@next if in beta, or just preact if you're reading this after version 10 was released as stable.

Next, if you're not using CodeSandbox, install Parcel as a development dependency: npm i --save-dev parcel, and optionally TypeScript (npm i --save-dev typescript). This is to replicate the CodeSandbox environment

The index.html file

Next, we're going to need to create a basic index file for the browser to load - it will point to the script, and have an identified div element for us to render the application in.

CodeSandbox already provides that by default, although we'll need to change the script extension from js to jsx (or ts to tsx).

Here's the contents of index.html

<html>
  <head>
    <title>Parcel Sandbox</title>
    <meta charset="UTF-8" />
  </head>

  <body>
    <div id="app"></div>

    <script src="src/index.tsx"></script>
  </body>
</html>

The JavaScript entry-point of the application

Next, we need to create the file referenced in the script element - CodeSandbox users can rename the existing file in src, while local users can just create it at src/index.jsx or src/index.tsx.

Eitherway, if any, remove all contents, and let's start with our necessary imports:

import {h, render} from "preact";

Here, we import Preact's implementation of the h function, and also a render function - we'll use that later.

Our first component

Next, we need to write something for Preact to render. For this we need to write a component. We'll talk more about components in the next part, but in short, components are the reusable pieces of code that ca be passed props, and have state - they are the reusable elements that are at the base of reusability in modern JavaScript framework applications.

Components come in two variants - function-based, or class-based. More and more projects use function-based components, especially now that Hooks are getting more popular (more on that later). We'll use a function-based component, and name it Application. Let's add it in our index file:

function Application() {
  return <p>Hello world!</p>;
}

That's it. This function accepts no props (as they are given through the arguments), and simply return a paragraph element (actually, it's Virtual DOM equivalent).

We need to use that new component somewhere, and that's why we also have imported the render function.

Rendering our component

Since Preact deals with Virtual DOM through its h function, we need a way for that Virtual DOM to become, well, real. This is what the render function does - it inputs a Virtual DOM node, and a DOM element to insert the generated DOM into. We already have a div tag in our index.html made for the purpose of hosting our application - so let's use that. Then, we need a Virtual DOM node to pass into the render, and that Virtual DOM will come from our component. Remember that Preact's h function returns Virtual DOM, but what you may not know (but probably have guessed), is that the function can also take components instead of tag name as first parameter. This is how we reuse components in Preact. And, where we can use h, we can also write JSX - therefore that's how we'll pass the Application component to the render function.

Anyhow, let's get some generated DOM into our web page. We'll get a reference to the <div id="app"> element in the DOM, and pass it to the render function:

const root = document.getElementById("app");
render(<Application/>, root);

Our component displays "Hello World!" onto the web page! 🔥

Nesting components

Let's create more components, shall we?

Components are good for several things - but at their most basic, they allow to create reusable elements; for example, a button component we'll write next.

Leaving the implementation to next part, let's use this hypothetical Button component into our application. We want this component to be customizable to a certain degree, which can be done through propertiess. We can pass any value through those props, which includes functions (as functions are values). This will be useful in keeping our Button component generic and therefore reusable - we will expose a "onClick" prop which expects a callback function which will get called when the user clicks on the component.

Let's use this specification for the accepted properties (often abbreviated as props) of this Button component:

interface ButtonProps {
  /** Any CSS color string, from names to hex codes to HSL, HSV or RGB(A) functions */
  color: string;
  /** Changes the button elevation by altering the shadow property of the button */
  elevated?: boolean;
  /** Callback function which gets called when the user clicks on the button */
  onClick?: (ev: MouseEvent) => void;
}

Note: This is valid TypeScript which I use in the source code to define the component properties, see the CodeSandbox examples

With this, we can create an application with two buttons to showcase how they can each be customized separatedly. In the following code, each button gets assigned a random color; the first button has a callback which shows an alert box on click while the second doesn't have any callback; also only the first button is elevated (as it is by default), the second button has its elevation turned off.

Below is the code with its accompanying CodeSandbox example:

function Application() {
  const color1 = colors[Math.round(Math.random() * colors.length)];
  const color2 = colors[Math.round(Math.random() * colors.length)];
  return (
    <div>
      <p>Hello world!</p>
      <Button color={color1} onClick={() => alert("First button was clicked!")}>
        Learn more
      </Button>
      <Button color={color2} elevated={true}>
        Another button
      </Button>
    </div>
  );
}

In the next part

We will look at how to implement this Button component (though you can peek into the CodeSandbox source code by yourself if you want to figure it out). We'll cover the two ways to write components, as well as several useful techniques.

A beginners' tutorial to Preact - Part 3: JSX

🇨🇵️ Nathan Graule — Sun, 11 Aug 2019 12:37:27 +0000

We saw on the previous part how to make it much easier to create content from JavaScript, however we are still left with a rather tedious way to express our DOM nodes. Let's see how we can make this a bit better.

JSX, or as it should be called, XML-in-JS

The current h function has lot lot going for it. It creates a tree of DOM elements on the fly, in a way that's concise and not so different visually than the tree it generates.

However, all that "function-calling" will quickly become an eyesore and a keyboard-sore - navigating complex elements quickly becomes mentally straining. What if I told you we can bring the HTML back into the JavaScript?

This is exactly what JSX is. It allows developers to write the h function calls in an HTML-esque (or rather, XML-esque) way. Not only is there less to write, but JSX code emphasizes data and structure more clearly than the mess of function calls any regularly-sized piece of code would be.

What does it look like? Let's revisit our project from the last part:

const root = (
  <div id="app">
    <header>
      <h1>My custom-generated web page</h1>
      <h2>How neat is that?</h2>
    </header>
    <section>
      <div class="container">
        <p class="content">That's pretty neat.</p>
      </div>
    </section>
  </div>
);
// Prepending here because scripts should ideally be at the end of the body
document.body.prepend(root);

We can clearly see how this "simple syntax sugar" trick immediately improved the readability of our function.

If you try that using our custom-defined h function (more on that later), however, you'll see the following error:

TypeError: Can't convert null to object

This is because when a tag doesn't have any attribute in JSX, instead of passing an empty object as argument, the transformed JS uses null instead. We need to account for that and check for null before applying attributes:

/**
 * Creates an element and returns it
 * @param tag Tag name, like the HTML tag
 * @param attrs Object of attributes to add to the node
 * @param children Children nodes to append into the created element
 */
function h(
  tag: string,
  attrs: object | null,
  ...children: (HTMLElement | string)[]
) {
  const el = document.createElement(tag);

  // **ADDED**: Append given attributes (if defined)
  if (attrs !== null)
    for (const key of Object.keys(attrs)) {
      el.setAttribute(key, attrs[key]);
    }
  // Insert children
  for (const child of children) {
    // Text is special in the DOM, we must treat it accordingly
    if (typeof child === "string") {
      el.appendChild(document.createTextNode(child));
    } else {
      el.appendChild(child);
    }
  }
  return el;
}

Using JSX in your project

The problem with JSX, is that you can't use it directly. If you do, your JavaScript engine of choice will complain - because JSX isn't part of the JavaScript language - it's a trick placed on top of JavaScript to help with writing nested h functions. This is where Babel comes in.

Babel has plugins to turn your JSX into h function calls, which in turns makes the JavaScript valid again. A proper introduction to Babel isn't in the scope here, and if you don't know about Babel, you should definitely check it out as it has become part of the everyday tooling of the JavaScript developer.

Another solution to enable using JSX is with TypeScript. The TS transpiler has support for JSX, and you can convert it using it. Again, configuring TypeScript is outside the scope, and the documentation for the project is awesome, so do check it out if you need it.

In the next part

We're going to step outside of the boring but necessary theory and create our first project, using what we learned on top of Preact!

A beginners' tutorial to Preact - Part 2: The DOM, and Hyperscript

🇨🇵️ Nathan Graule — Mon, 10 Jun 2019 15:56:45 +0000

How to birth HTML DOM from JavaScript

Before we dive into writing "HTML", let's clarify something.

The Document Object Model

The DOM is, in effect, what the browser translates the HTML to when loading the web page into memory. The DOM contains all information about the current document. It's a tree, branching out from a root element (as represented by the <html> tag in HTML). HTML is the written representation of the DOM, and JavaScript manipulate the DOM instead of the HTML, because it is faster to modify the content tree than write HTML for the browser to parse again.

Creating DOM nodes from JavaScript

Ideally, we want a fast way to type the DOM that we want to insert as part of the reusable elements that will be the foundation of our applications. In a nutshell, a DOM node must be created, setup and appended to the page as a child of another node for it to appear in the browser window. A vanilla JavaScript solution would look like this:

const element = document.createElement("div");
element.classList.add("foo");
element.appendChild(document.createTextNode("I am the visible part of the node iceberg");

document.body.appendChild(element);

This will create the following DOM (as represented in HTML):

<div class="foo">I am the visible part of the node iceberg</div>

And a second version with a paragraph element nested inside the div:

const divEl = document.createElement("div");
element.classList.add("foo");
const parEl = document.createElement("p");
parEl.classList.add("content");
parEl.appendChild(document.createTextNode("I am the visible part of the node iceberg"));

document.body.appendChild(element);

will render the following DOM:

<div class="foo"><p class="content">I am the visible part of the node iceberg</p></div>

Seeing as this is the quintessential pattern for inserting content into the page (or, more generally, "DOM manipulation"), we can clearly do better.

Let's define a function that will create the element with the given tag and class list, and return it.

Note: The types come from TypeScript, which I'll use in this series. Stip the types away (after the colon) to make it into regular JavaScript.

/**
 * Creates an element and returns it
 * @param tag Tag name, like the HTML tag
 * @param classes List of CSS classes to apply
 */
function createElement(tag: string, classes: string[]) {
  const el = document.createElement(tag);
  for (const klass of classes) {
    if (klass === "" || klass === undefined) continue;
    el.classList.add(klass);
  }

  return el;
}

Okay, but that's not helpful. We still need to manually insert them into the page. We can do this two ways: either add a parent node as argument to the function, or a list of children to add to the element being created.

The first solution means we will need to first define the parent node in order to pass it to children, to avoid duplication and to ensure the children all have the same parents. This introduces boilerplate.

The second solution doesn't suffer from the disadvantages of the first; furthermore, you can simply nest calls to the createElement function to create both the parent and the children nodes at once. The node returned by the top-most call to createElement can directly be appended to an existing node, inserting the whole sub-tree into the page.

How to text

The DOM is a tree structure, meaning that everything is a node. Plain old text is, therefore a node. But it's treated differently from other nodes in the DOM, particularly because of its inability to have children.

Note: Technically, a TextNode is almost nothing like other HTML elements, as a TextNode inherits Node, whereas HTMLElement inherits Element which inherits Node itself. Therefore, an HTMLElement ends up being much more "rich" than a TextNode. Read more about Text and HTMLElement

This means we have to make way in our function to treat this special case. We're going to allow strings to be passed in lieu of HTML elements, which will get turned into Text Nodes inside.

Our function turns into this:

/**
 * Creates an element and returns it
 * @param tag Tag name, like the HTML tag
 * @param classes List of CSS classes to apply
 * @param children Children nodes to append into the created element
 */
function createElement(
  tag: string,
  classes: string[],
  ...children: (HTMLElement | string)[]
) {
  const el = document.createElement(tag);

  // Append given CSS classes
  for (const klass of classes) {
    if (klass === "" || klass === undefined) continue;
    el.classList.add(klass);
  }
  // Insert children
  for (const child of children) {
    // Text is special in the DOM, we must treat it accordingly
    if (typeof child === "string") {
      el.appendChild(document.createTextNode(child));
    } else {
      el.appendChild(child);
    }
  }
  return el;
}

We can now recreate the DOM from above, with nested createElement calls:

document.body.appendChild(
  createElement(
    "div",
    ["foo"],
    createElement("p", ["content"], "This is the tip of the node iceberg")
  )
);

Which gives us the same results as previously:

What about images?

There is a serious limitation with our current function however, is that we can't include other attributes into the tags. We need to generalize our function so that it accepts an object of attributes to add to the element.

/**
 * Creates an element and returns it
 * @param tag Tag name, like the HTML tag
 * @param attrs Object of attributes to add to the node
 * @param children Children nodes to append into the created element
 */
function createElement(
  tag: string,
  attrs: object,
  ...children: (HTMLElement | string)[]
) {
  const el = document.createElement(tag);

  // Append given CSS classes
  for (const key of Object.keys(attrs)) {
    el.setAttribute(key, attrs[key]);
  }
  // Insert children
  for (const child of children) {
    // Text is special in the DOM, we must treat it accordingly
    if (typeof child === "string") {
      el.appendChild(document.createTextNode(child));
    } else {
      el.appendChild(child);
    }
  }
  return el;
}

What we have created, more or less, is hyperscript. Hyperscript is a small library which does what we've just done: it encapsulates DOM elements creation into nested function calls. For this reason, and to shorten the name of the function, let's rename it to h, for hyperscript.

With that done, let's create and insert some DOM into the page!

const root = h(
  "app",
  { id: "app" },
  h(
    "header",
    {},
    h("h1", {}, "My custom-generated web page"),
    h("h2", {}, "How neat is that?")
  ),
  h(
    "section",
    {},
    h(
      "div",
      { class: "container" },
      h("p", { class: "content" }, "That's pretty neat.")
    )
  )
);

// Prepending here because scripts should ideally be at the end of the body
document.body.prepend(root);

Conclusion

We now have a powerful generic function to construct any DOM tree that we want. There is one last thing to know that applies on top of that h function, which is used in almost all Preact projects, and which comes back full circle in a way.

A beginners' tutorial to Preact, without prior React knowledge (Intro)

🇨🇵️ Nathan Graule — Mon, 10 Jun 2019 15:55:36 +0000

This series of posts will make up a tutorial for Preact that does not assume knowledge in React, or any other application framework. I found this specific area lacking when it comes to tutorials, as myself someone who has never used React.

The tutorial assumes that you know the basics of JavaScript, and know how to install npm packages. We'll use the Parcel bundler to bundle and serve our code during development, though you do not need to know Parcel as I'll explain everything as we go. We'll use Babel to allow us to actually use JSX in the browser. You don't need to know it either, though I won't spend a lot of time on it. Finally, I'll use TypeScript for the code snippets as I believe static typing offers educational value both reading the code snippets, and also while writing code. You may absolutely want to stick to JavaScript, in which case just strip the types off of the code and be on your way. As with Babel, I will not spend a lot of time on TypeScript either; if you want to dive deeper on any of these, feel free to go learn more about any (or all) of these projects before going back here to follow the tutorial.

Introduction
DOM Garderning
JSX, or as it should be called: XML-in-JS
First steps with Preact
Components, props, state, and context
Testing components
Get hooked, Capt'n!
To CSS and not to CSS
Route it, link it, match it - technologic
Manual Server-side Rendering
Workshop: A music catalog application

A dive into modern JavaScript application development

JavaScript was not really designed as the main foundation atop which the modern web would be built. In fact, the web itself was never designed as an application framework - This is all evident in the way we interact with it: we request and visualize documents, which are described by a particular subset of XML: HTML. They provide the semantic view of the document, that is what the text means and how it is structured. HTML defines hierarchy much like a book can have parts, chapters, headings and paragraphs - because the web was designed to be a digital equivalent to a library, where websites were books you could peek in.

This is where the "modern" view of the web clashes with its implementation. The modern web of web applications view a website as an application, from which its web pages are the multiple entry points. HTML, then, define the elements which compose the particular application, and how it is structured.

Alleviating the pain from the document-centric workflow

There is a way to, if not resolve, at least help bridge the gap between the early design and modern use of the web. By taking a step back from the HTML itself, and focusing instead on composing "elements" which render themselves into HTML. We can then stop thinking about "how will I write HTML in order to build my application?", and start thinking about "How can I break down my application into manageable chunks?", and this is the first step towards building applications that scale while staying maintainable.

However, this is not a perfect solution, as the technicalities of the document-centric workflow tend to creep up into these elements quite quickly (one being the "cascade" I mentioned earlier, which you'll understand if you have any experience with CSS, however styling is outside the scope of this series).

The solution: JS frameworks by the dozen

This very thinking led to the popularization of JS frameworks promising to implement this abstraction of HTML into reusable elements in a way that would benefit the developer. React, Angular, Vue, Elm, Svelte, dozens of frameworks each try to innovate on the above recipe in their own way.

Conclusion

This sets the stage and hopefully the mindset towards understanding the thought process behind the design of the technologies we are going to use throughout the series.

In the next part, we are going to look at the first layer of abstraction over HTML that has become standard for JavaScript application development. I hope you're hyper-excited!

DEV Community: 🇨🇵️ Nathan Graule

A colorful journey

What is color, anyway?

Formalizing color: XYZ

The idea of chromaticity and working with xyY

Making out color from primaries: RGB colors

An example: sRGB

The catch: RGB colors are not linear

Conclusion: In practice

Appendix

A beginner's tutorial to Preact - Part 4: First steps with Preact

What is Preact?

The canonical "Hello World" application

Dependencies

The index.html file

The JavaScript entry-point of the application

Our first component

Rendering our component

Nesting components

In the next part

A beginners' tutorial to Preact - Part 3: JSX

JSX, or as it should be called, XML-in-JS

Using JSX in your project

In the next part

A beginners' tutorial to Preact - Part 2: The DOM, and Hyperscript

How to birth HTML DOM from JavaScript

The Document Object Model

Creating DOM nodes from JavaScript

How to text

What about images?

Conclusion

A beginners' tutorial to Preact, without prior React knowledge (Intro)

Contents

A dive into modern JavaScript application development

Alleviating the pain from the document-centric workflow

The solution: JS frameworks by the dozen

Conclusion