DEV Community: Edwin

Native CSS nesting now supported by all major browsers!

Edwin — Tue, 29 Aug 2023 19:44:42 +0000

Today, Firefox version 117 has been released, which adds support for native nesting of CSS rules! With that addition, all modern desktop browsers now support it! 🎉

Do keep in mind that there are some mobile browsers that do not yet support it. Together, these account for about 3% of the global browser market share.

Now that this feature is well supported, we can ask ourselves if using a CSS pre-processor is still worth the hassle.

But first, a quick refresher.

CSS Nesting

CSS nesting allows you to group related selectors together and potentially reduce the number of rules you need to write:



/* CSS */
button {
   background-color: white;

   &.danger {
     background-color: red;
   }

   & img {
      width: 1rem;
      height: 1rem;
   }
}

/* HTML */
<button class="danger">I am red</button>
<button><img /></button>

It allows you to nest multiple levels, but please don't go overboard with nesting too deeply, as this adds up to the specificity of these CSS rules. This makes it hard to read and reuse your styles - nobody likes pyramids of doom! Deep nesting is simply unnecessary in most cases.

Do you really still need a CSS pre-processor?

Many people use so called CSS pre-processors such as SCSS or LESS that add fancy features to CSS, such as variables, mixins and functions, but they need to be transformed back to regular CSS during the build process of your app, so the browser can understand it.

The features they offer are:

Nesting - There are only small differences between native CSS nesting and LESS/SASS. CSS is a little more strict, because you need to prepend every nsted selector with & and you need to define regular styling before the nested styling.
Variables - Native CSS variables have good browser support for a while now. The benefit of using native variables is that they are available at run time in your browser, which allows you to easily tweak them in your developer tools.
Mixins - This allows you to reuse a set of rules inside another selector. I never really found a good use case for mixins. They were available to me when I was still using Bootstrap with LESS, but using them seemed a little complex, because you always need to look up what they do and the resulting CSS output is not always clear. If you're thinking of using them for browser prefixes (e.g. -webkit-transform), I would suggest checking out PostCSS autoprefixer instead.
Partials/Modules - CSS has an @import rule that works well enough (at the cost of an extra HTTP request). Combine imports with CSS layers and you have a pretty solid setup to modularize your CSS.
Functions - These allow you to write CSS in a similar fashion as functions in other programming languages. I always found that they bloat your CSS output and they are hard to read as well. I would avoid using functions unless you have a really good use case for it.
Operators - Need math in your styles? CSS calc gets the job done.

All in all, most features that pre-processors offer can nowadays be replaced by native CSS, so you can ask yourself whether an extra pre-processing tool in your stack is still worth it.

In large projects, it is still a good idea to use PostCSS, which will translate new CSS features to something that browsers understand today.

Practical CSS :has() selector examples

Edwin — Fri, 25 Nov 2022 15:12:28 +0000

This article showcases how the CSS :has() selector can be used in everyday use cases.

For more examples, click the menu button or open the Codesandbox fullscreen. The source code is here.

Browser support

Currently, the :has() selector is available in all modern browsers! 🎉🎉🎉

https://caniuse.com/css-has

Basics

In short, the :has() selector allows you to select a "parent" element based on a specific condition that you specify within the parentheses.

/** Select form that has a label */
form:has(label) {
   border: 1px solid #000;
}

/** x:has(a,b,c) --> x has (a OR b OR c) */
form:has(input[type="text"], input[type="checkbox"], input[type="number"]) {
   border: 1px solid #000;
}

/** x:has(a):has(b):has(c) --> x has (a AND b AND c) */
form:has(input[type="text"]):has(input[type="checkbox"]):has(input[type="number"]) {
   border: 1px solid #000;
}

This is interesting, because it allows us to select the <form> and apply styles to it based on a condition. From there, we can also select elements further down the chain again!

/** select input within a form that has a label */
form:has(label) input {
   border: 1px solid red;
}

This pattern opens up new ways of conditionally styling elements that were not possible before (without JS, hacks or workarounds). Things like:

Layout elements based on the contents of a container element.
Style a container based on the number of items inside it.
Applying styles to a container based on pseudo-classes (:hover, :disabled, :invalid) of a descendant.
Select the "previous sibling" element using :has(+ .other). Before, we could only select the "next sibling" element using the + operator.

Thoughts

CSS :has almost requires you to reset the way you think about selecting elements, as we could only write selectors that go further down the element tree, but now we can select elements back up as well.
Sometimes we need JavaScript to add classes to elements based on the state or data in our application. See the "Todo list" example, where we show a message when all checkboxes are ticked. The common way to achieve this is to iterate over the to-do item data, check if all items are 'completed' and conditionally render a message (or add a class) based on that data. But with :has(), we can apply styles to some element based on the UI state of a completely different element. For simple cases, you may no longer need JS at all!
When styling an element based on its contents, we need to think about separation of concerns. Adding some spacing to a <figure> element if it has an <img> or <figcaption> totally makes sense, but where do we draw the line? This applies to every type of CSS selector, I suppose, but with :has() you may be more easily tempted to write your CSS like a giant if-statement with a million cases.

What more?

Can you think of an awesome use case for :has()? let us know! 👇👇👇

Building a TODO app without a bundler

Edwin — Sat, 04 Jun 2022 17:27:56 +0000

Do you remember the time before front-end frameworks and build tools, where you would sprinkle some JavaScript on top of your HTML to create interactivity? Code up your HTML documents, preview them in the browser without tools like Webpack, then push them to your webserver using FTP?
I sure do. 👴

What if I told you, you can build modern web apps and have still have a smooth development workflow without any build tools?

In this article I'm going to implement the TodoMVC app without any build tools and only use native JS functions supported by evergreen browsers (sorry Internet Explorer, it's time for you to leave).

I will use some libraries related to React, but you could write the app using anything you prefer (or no library at all). What matters most is the fact that we simplify our development process by cutting out tools that are required to work with these modern day frameworks. The starting point is just a HTML document with a <script> that initializes our app, while SPAs often start from an index.js entry point and try to control the document from there.

Here's the source code and the end result:

Single Page Apps

When building an interactive web app, developers usually reach for frameworks such as React, Angular, Vue, Svelte, to name a few. These frameworks are mostly abstractions and best practises to help you create modular code while staying productive. They all come with a set of supporting tools to smooth out the development process: translate modern JavaScript features to something all target browsers understand, manage dependencies, optimize the output code, etc.

These interactive client side apps are often Single-Page Applications: a web application that loads a single document and then updates the page content using JavaScript by loading other modules and fetching data from a REST API.

Not every website needs to be a SPA, mind you. In fact, the approach below could be used in a good old multi-page website, where you sprinkle the JS on top of the page to create the interactive ToDo functionality.

Goals

We are going to build a simple TODO application such as this one, which is fully client side and has a clear scope.

Implement the TodoMVC app using this specification.
Use only native ES6 browser features.
No build tools (Babel, Webpack, etc).
We still want to be able to use NPM packages.
Supports latest stable version of Chrome, Firefox, Safari, Edge.

Why would you go buildless?

Let's start with the main reasons we still need bundlers in 2022:

The NPM ecosystem is built around packages being able to run in NodeJS, not primarily for the web. NPM packages are expected to use the CommonJS format to ensure everything is compatible with each other. Publishing a package using pure ES Modules would break that compatibility. Seems backwards, right?
Packages use a short-cut method of importing other packages by their package name, without an extension (bare imports), e.g.: import groupBy from lodash/groupBy instead of import groupBy from './node_modules/lodash/groupBy.js. Tooling is needed to fix the module resolution.
Bundlers take care of a lot of implicit stuff, like polyfilling missing features. A lot of NPM packages expect this stuff to just work.

Pika is doing an awesome job at rethinking this whole process and it questions why we need web bundlers today at all. Check out this great talk:

The reason to ditch all this tooling seems obvious: it simplifies development, because you only need to deal with native JavaScript. No tools to learn, no configurations to manage, no more waiting for your app to start up.

You get some additional benefits too:

Your development environment is exactly the same as your production environment, which can make debugging easier.
No security risk of installing third party code during development. NPM packages can basically run any code on your machine using post-install scripts.
Modules are cached individually. Updating a single module means other modules stay cached. This is more of a hassle when using Webpack.

Downsides of going buildless

No pre-processing, so you lose access to tools like TypeScript, LESS/SASS (for CSS).
No support for modular CSS yet. Import assertions are far from production ready.
No minification or tree-shaking of application code.
Slight performance hit compared to loading bundled JS. Large JS files still compress better than smaller individual files. So there is some benefit in bundling all code into a single file. HTTP/2 might resolve some of that issue, but I haven't seen concrete numbers yet. See also this discussion.
Managing module imports can become messy, resulting in long relative import paths ../../../module/subModule/component.mjs. Webpack has aliases to make your life easier. Luckily, JS import maps solve most of this problems and are available in all major browsers.

You win some, you lose some.

Using third party libraries in a buildless setup

Just because we aren't allowed to use build tools, does not mean we can't use any NPM libraries. To load them, we have several options.

Content Delivery Networks (CDNs) are free online services that serve NPM packages over the network. Examples are jsDelivr, unpkg and SkyPack. We will be using these services to import the libraries we want to use.

You can import those packages using a script tag, for example:

<script src="https://cdn.jsdelivr.net/npm/lodash@4.17.21/lodash.min.js"></script>

ES modules allow you to import directly from a URL:

import groupBy from 'https://unpkg.com/lodash-es@3.10.1/collection/groupBy.js';

Learn more about ES imports in this article

Libraries for the buildless route

We are looking for libraries that use ES modules, so we can drop them into our app and use them like any other library.

Lit Element which builds on top of the web components standard. (example app)
Vue Single File Component loader allows you to sprinkle Vue on top of any HTML document. (example app)
HTM - a library that lets you write components using JSX-like syntax using template string.
Symbiote - framework that allows you to write class based Custom Elements, focused on building complex widgets that you can then embed in other apps.

Here you can find a list that compares multiple no-build libraries.

HTM, Preact & JSX

I feel very productive writing front-end UI components in React using JSX, so I wanted to have something similar for this app. After some googling I stumbled upon HTM, which promises JSX-like syntax without bundling, so I decided to give that a try. HTM plays nicely with Preact (a leaner version of React with only slight differences).

When using Preact without HTM, you would need create components similar to how you would call React.createElement(), namely:

import { h } from 'https://esm.sh/preact';

const myH1Element = h('h1', null, 'Hello World!'); // <h1>Hello World!</h1>

HTM uses JavaScript's own tagged template syntax, so you can write JSX-like syntax:

import { h, render } from 'https://esm.sh/preact';
import htm from 'https://esm.sh/htm';

// Initialize htm with Preact
const html = htm.bind(h);

const MyComponent = (props, state) => html`<div ...${props} class=bar>${foo}</div>`;
render(htm`<${MyComponent} />`, container);

For convenience, HTM provides a module that does this binding for you. You only need to import from the preact/standalone module:

import { html, render } from 'https://esm.sh/htm/preact/standalone'

render(html`<${App} name="World" />`, document.body);

State management using Valtio

Valtio uses JavaScript proxies to wrap your state objects and track changes automagically. ✨

The state can be manipulated outside the React/Preact lifecycle too using vanilla JS. Persisting the app state to localStorage is also trivial.

The library is light-weight and easy to work with. Valtio is certainly not required for the no-build app, but it felt like a good match for this setup.

Implementing the TODO app

I would like to use a component based development approach without writing everything from scratch, so I decided to use HTM with Preact. This allows me to write JSX-like syntax without a transpiler.

I won't dive too deep into the implementation itself, but you can find the source on GitHub.

Getting started

Create an index.html file and add a <script> tag and point it to js/index.mjs - the starting point of the app:

<!DOCTYPE html>
<html lang="en">
    <head>
        <title>No-build ToDo app</title>
    </head>

    <body>
        <script type="module" src="js/index.mjs"></script>
    </body>
</html>

We can import the CSS for our TODO app directly from a CDN like so:

<link rel="stylesheet" href="https://unpkg.com/todomvc-common@1.0.5/base.css" />

In the index.mjs file we can import() any other modules that we need. From here we can start writing modular components as we would do when using React!

// js/index.mjs
import { html, render } from 'preact';

import { Header } from './Header/index.mjs';
import { Footer } from './Footer/index.mjs';

const App = () => {
    return html`
        <${Header} />
        <section class="todoapp">
            <!-- etc -->
        </section>
        <${Footer} />
    `;
};

render(html` <${App} />`, document.body);

Beware that we need to write the full path, including extension, when importing a module - this is how ESM works.

Importing third party modules

You might be wondering how we are importing preact, as we are doing on the first line:

import { html, render } from 'preact';

How does our browser know how to resolve preact? We are using a so called import map to define a mapping of a dependency to a specific URL. This URL can point directly to a CDN where this library is hosted.

In our index.html, we define a script of type importmap where we map all our dependencies:

<script type="importmap">
{
  "imports": {
    "uuid": "https://esm.sh/uuid",
    "preact": "https://esm.sh/preact",
    "preact/compat": "https://esm.sh/preact/compat",
    "preact/hooks": "https://esm.sh/preact/hooks",
    "htm": "https://esm.sh/htm",
    "valtio": "https://esm.sh/*valtio?alias=react:preact/compat",
    "proxy-compare": "https://esm.sh/proxy-compare",
    "use-sync-external-store/shim/index.js": "https://esm.sh/use-sync-external-store?alias=react:preact/compat"
  }
}
</script>

In this case we are using esm.sh, which is a CDN for NPM packages. It bundles the library in the URL with all of its dependencies, so they are ready to use in the browser.

See this article for more information about import maps.

ESM.sh aliasing

We need to tell ESM.sh that it needs to replace all imports of react with preact/compat, which is Preact's compatability library. We can do this by using the alias URL parameter:

https://esm.sh/valtio?alias=react:preact/compat

Issue with `use-sync-external-hook`

There is an issue with the use-sync-external-store package (a React hook that Valtio uses to synchronize state changes with React) when using ES Modules.

There are a few things that need fixing:

Tell ESM.sh that it should not rewrite module imports for use-sync-external-store. ESM offers a parameter external to mark an import as external, so it won't be bundled. This means we need to define it ourselves:

"valtio": "https://esm.sh/valtio?external=use-sync-external-store/shim/index.js"

The annoying thing is that we need to point to the complete path of the imported module (including shim/index.js). Instead, we can mark all dependencies as external by prefixing the package with an asterisk:

"valtio": "https://esm.sh/*valtio

This means we need to define import mappings for all of valtio's dependencies:

"proxy-compare": "https://esm.sh/proxy-compare",
"use-sync-external-store/shim/index.js": "https://esm.sh/use-sync-external-store?alias=react:preact/compat"

Issue with Preact standalone

For some reason the Preact standalone module breaks things due to a missing module. The solution was to import Preact and htm separately and create a module that initializes htm with Preact:

import { h } from 'preact';
import htm from 'htm';

export default htm.bind(h);

Then use this to render components:

import html from '../render.mjs';

export const Footer = () => html`<h1>Footer</h1>`;

Run the app

Now we only need to some kind of static file server so we can preview the app in our browser. You can use the VSCode Live Preview extension or use a simple static server like this:

npx serve

Conclusion

Creating an app without a bundler was a fun and overall a pretty smooth experience. ES6 has all the language features needed to create apps with a great developer experience. We've seen how dependencies can be imported from a CDN to add third party code to our app without the need for extra tools.

Still, I probably wouldn't go without a bundler for production apps in 2022. Choosing which tools to use is a trade-off between complexity of the build process and productivity + optimizations that you get by using these tools. Using third party libraries in a buildless app might prove hard if there is no ESM version available.

Pika is a great initiative that moves the complexity of build tools away from the app. It is a step towards a simpler development process. It's nice to see that the JS ecosystem is moving towards ES modules, which makes a lot of sense to me.

Sources

Internet Explorer retires on June 15 - what can developers do?

Edwin — Tue, 24 May 2022 16:12:15 +0000

Microsoft will finally stop supporting Internet Explorer 11 on June 15, 2022. That is ~~3 weeks from now~~ RIGHT NOW!

If a Windows 10 or Windows 11 user tries to open IE after this date, the Edge browser will launch instead (or the user will be taken to the download page for Edge).

There is an IE11 compatibility mode to support legacy apps, but it may not work exactly the same. This legacy mode is supported until 2029, so we won't be completely rid of Internet Explorer for some time. However, if you are a developer that is building modern web apps, I think it's better to drop support for Internet Explorer completely.

In this article, I will explain what the problems of supporting Internet Explorer are and how you can move to a better alternative.

What's the problem with IE11?

According to Microsoft itself, IE is not a browser but a compatibility solution for legacy apps. New browser features are not supported by it, which means new apps do not work out of the box in IE. By using IE, you are effectively going back in time to experience the web as if it were 2013 (the most recent updates being only security patches).

The global market share (desktop - April '22) of IE is as low as 0.4%, compared to 64% for Chrome, 10% for Edge, 10% for Safari and 7.9% for Firefox. So who is still using it? Mostly users of legacy applications, people who work at companies with strict browser policies and... Japan, apparently.

From a technical perspective, developers that need to support IE cannot make full use of new browser features in their apps that work out of the box in evergreen browsers such as Chrome, Firefox and Microsoft's newest Edge browser.

IE11 only works with an older version of JavaScript, namely ECMAScript 5 (ES5). Developers can use tools like Babel so they can still write modern JavaScript (ES6 and beyond), which gets translated back to ES5 so it works in every browser. This "transpilation" inevitably creates overhead in the resulting code bundle. Furthermore, some third party JavaScript libraries may only be available in ES6, so an app developer has to make additional effort to ensure those libraries are transpiled as well.

Other frameworks and tools are also abandoning IE11: Webpack 5 bundles for ES6 by default, React 18 and CRA dropped support, to name a few. If you want to stay up to date, that means you will need to make the decision at some point.

Dropping support for a browser means that you potentially lose revenue of its users. A bigger problem, however, is that supporting IE11 causes a degraded performance for all other browsers. It will also lock your app out of innovative new features such as Progressive Web App features (unless you apply graceful degradation).

Unsupported features in IE11

This page compares supported browser features between IE11 and Edge version 100. The length of this list is staggering, to be honest. Some notable features:

DOM manipulation methods
Full CSS Flex and CSS Grid support
CSS sticky
CSS filters
Input types for date and time and color
Service Workers and most other PWA related features
Fetch
Custom elements
Resize observer

Missing JS language features I personally use almost every day:

Transpilation example

Consider the following piece of code where I showcase some ES6 features:

const doStuff = async () => {
  const foo = "bar";
  let qux = `${foo} with extra ${foo}`;

  return await new Promise((resolve) => {
    resolve(qux);
  });
};

This code doesn't do anything useful, but if you press F12 in a modern browser to open your developer tools and paste it in the console, it will run just fine.

Now watch the result if we transpile this code using Babel to something that IE11 understands. If you scroll down to line 11 in the frame on the right you will see something that looks like our original function. All the cruft above it is required to make it run in old browsers.

var doStuff = /*#__PURE__*/function () {
  var _ref = _asyncToGenerator( /*#__PURE__*/_regeneratorRuntime().mark(function _callee() {
    var foo, qux;
    return _regeneratorRuntime().wrap(function _callee$(_context) {
      while (1) {
        switch (_context.prev = _context.next) {
          case 0:
            foo = "bar";
            qux = "".concat(foo, " with extra ").concat(foo);
            _context.next = 5;
            return new Promise(function (resolve) {
              resolve("baz");
            });

          case 5:
            return _context.abrupt("return", _context.sent);

          case 6:
          case "end":
            return _context.stop();
        }
      }
    }, _callee);
  }));

  return function doStuff() {
    return _ref.apply(this, arguments);
  };
}();

This example showcases how building for IE11 negatively impacts your bundle size, build time, total byte size sent over the network, parse time and page load time! More about transpilation bloat in this article.

Benefits of dropping IE11 in your web app

Use modern browser features (such as the ones listed above) out of the box.
No need to support IE11 quirks. Ugly hacks to make edge cases work on IE11 can be removed, which leads to cleaner code that is easier to maintain.
The JavaScript code that is served by your app in production can be optimized for modern standards, which means transpilers such as Babel have less features to polyfill. This can potentially reduce the size of your code bundle by as much as 30%!
Simplify your testing and quality assurance process.

How to phase out IE11

As a developer, you can lead the discussion about whether or not to support IE11 with technical arguments mentioned above. Make dropping IE11 support a company goal! Put it on a roadmap! This is not just a development issue, other departments should also contribute and inform customers about the plan. As with most things in life: communication is key!

Communicate the deadline for dropping IE support to your customers, so they can prepare if needed. Switching to different browser may not be an issue for them at all. The not so tech-savvy users may not be aware they are still using an outdated browser. Companies may have an outdated browser policy which only allows IE11 for legacy reasons (or no policy at all).
Show a banner at the top of your app to warn the user if it detects IE11 usage.
If possible, gather browser usage statistics for your app.
Document any features of your app that require IE11 support on your Wiki/Confluence/README. Are these features still relevant or can they be refactored to modern JavaScript?
Write a knowledge base article about the browsers your app supports and how users can switch to a safe alternative.

How to drop IE11 support from your web app

The following steps explain how to optimize your project to drop IE11 support. Sometimes we need to tell our build tools that they don't need to transpile code for older browsers. The production bundle will no longer include patches for missing features, which will save you some precious bytes.

Use browserslist

If you are developing a web application, you are most likely using technologies such as Babel with the preset-env plugin and Webpack to bundle your code. You can set a browserslist (docs) property in package.json (or .browserslistrc file) to set the browsers you want to target:

"browserslist": {
     ">0.2%",
      "not dead",
      "not IE 11"
   }
}

You can customize the query using this tool.

Remove redundant Babel plugins

Furthermore, some Babel plugins for ES6 language features can be removed from your project and from the babel configuration, if you were still using them. Check this list and remove them from your project.

Note: These plugins are all included in preset-env, so chances are small you were using them. Still worth checking though.

Specific tool examples

Most frameworks and tools will automatically use the browserslist configuration. Just because your framework says it does not support IE11 doesn't mean the code it produces is optimized for ES6. Sometimes you still need to set the browserslist yourself.

Here is the behaviour of some of those tools:

Create React App: generates a browserslist config for you, but you need adjust it to exclude IE11 (as above).
Next.js supports IE11, does not respect browserslist for JS (only CSS)! It seems you need a custom babel config and configure the preset-env targets option
Remix: no IE11 support, promises progressive enhancement
Angular: no IE11 support out of the box(?) 🎉
Svelte: ???
Vue 3: Configure browserslist as above. Also offers modern mode for differential serving.
Nuxt: need to build with the --modern option.
Ember 4: no IE11 support, set targets in ./config/targets.js using ember-cli
Webpack 5: You need to configure the browserslist as above.
Vite: targets ES6 by default and uses a browserslist query that does not target IE11 (so it works out of the box 🎉).

Progressive enhancement for modern browsers, fallback for IE

If you want to show at least something to IE users, instead of an empty, broken page, you could use the <script> tag with a nomodule attribute. This is only used by browsers that don't support JS modules, which happens to be IE!

<!-- Your ES6+ bundle for modern browsers -->
<script type="module" src="index.mjs"></script>

<!-- Fallback for IE -->
<script nomodule>
  console.error("No module support, could not load app");
  document.body.classList.add("has-old-js");
</script>

You could go down the path of creating one ES5 bundle for IE users and an ES6+ bundle for other browsers. This technique is called differential serving. But now that IE11 is no longer supported, you should really ask yourself if this is worth the effort.

Detect IE11 using JavaScript

Checking supported browser features:

!!window.MSInputMethodContext && !!document.documentMode

Checking the user agent:

navigator.userAgent.indexOf('MSIE') !== -1
|| navigator.appVersion.indexOf('Trident/') > -1

Conclusion

So should your app still support IE? Unless you are working on a legacy app for a customer with specific needs, the answer is probably not. Microsoft does not even support IE in its own Teams app. You should at least have a plan to move away from supporting IE and inform your customers about it.

Ask yourself: What is the cost of supporting IE11, in terms of time spent on maintenance, fixing obscure bugs, code complexity, technical debt, negative performance impact, exceptions in the build process and even testing?

It's time to move forward and start writing code for the modern web.

Sources

Format numbers in the user's locale using vanilla JS

Edwin — Thu, 07 Apr 2022 14:56:34 +0000

JavaScript has a built-in language-sensitive number formatting feature, called Intl.NumberFormat. This is useful if you want to format large numbers, use thousand separators, format currency values. It is supported by all evergreen browsers, except Internet Explorer.

Example

  const formatter = new Intl.NumberFormat('de-DE', { 
     style: 'currency', 
     currency: 'EUR' 
  })

  console.log(formatter.format(123456.789));
  // expected output: "123.456,79 €"

Playground

The NumberFormat documentation on MDN is not very clear about the available options, so I decided to build a playground that allows you to customize the formatting options and immediately see the result for a list of locales and input numbers.

In the sidebar you'll find some presets that showcase interesting use cases.

Note: The features marked as V3 will be implemented in a future version of ECMAScript. Therefore, they may not yet be available in your browser yet. I will add a polyfill as soon as it is available.

Open the Codesandbox fullscreen for easy editing. The playground is built in React using the Mantine component library.

React: automatic date formatting in translations (i18next + date-fns)

Edwin — Sat, 19 Dec 2020 17:16:46 +0000

Update April 2022

Since October '21, i18next has added support for formatting using native Intl API in version 21.3. You should probably check that out first, but I think this article can still be useful to you as it explains how to work with date-fns.

Intro

In this article I will show you how to translate your React app in multiple languages and how to automatically format dates in the user's locale.

Rendering a date using a localized format is important: for example, the US uses MM/DD/YYYY, while some other countries use DD/MM/YYYY.

We will be using React together with i18next and date-fns.

The naive solution would be to handle both concepts of translation and date formatting separately:



render() {
   return <span>
      {t('article.postedOn')}
      {format(article.date, 'MM/DD/YYYY')}
   </span>;
}

The end result of this article is that we can pass a Date object to our translation function and easily declare which date format we want to use:



// In our React component:
render() {
   return <span>
      { t('article.postedOn', {date: new Date()}) }
   </span>;
}

// In our translation bundle:
{ "article": 
   { "postedOn": "This article was posted on {{ date, short }}" }
}

And the user will see a message like: This article was posted on 12/19/2020.

React i18next

i18next is a popular solution to manage translations in your app. I won't go into detail how to configure it for usage with React, I used this guide as a setup for this article.

Using i18next in your app

The basic idea is that you can translate strings using a t() function. You pass in a translation key and i18next will look up the translation in its bundle for the currently active locale:



import { useTranslation } from "react-i18next";

const MyComponent = () => {
   const { t } = useTranslation();
   return <span>{ t('messages.welcome') }</span>;
};

Translation bundles

For each language that you support, you create a translation bundle as JSON and pass it to i18next:



{
    "en": {
        "translation": {
            "messages": {
                "welcome": "Welcome!"
            }
        }
    },
    "nl": {
        "translation": {
            "messages": {
                "welcome": "Welkom!"
            }
        }
    }
}

Setup i18next

Install the library:



npm install react-i18next i18next

Create a new module i18next.js where you configure the library:



import i18n from "i18next";
import { initReactI18next } from "react-i18next";

// Here we import the bundle file as defined above
import resources from "./translation.json";

i18n.use(initReactI18next) // passes i18n down to react-i18next
    .init({
        resources,
        lng: "en",

        interpolation: {
            // react already saves from xss
            escapeValue: false
        }
    });

export default i18n;

And simply import this file in your app.

Interpolation

It is common that you need to use a name or a date in your translated text. The position of the dynamic value in the translated string can vary between languages, so we use a template string with curly braces and pass the variable to the t() function:



t('welcome', {name: 'John'});

// translation bundle:
{ "welcome": "Welcome {{ name }}" }

This is called interpolation in i18next.

Adding date-fns

Date-fns is a modular library for working with dates in JS and a popular alternative to the monolithic MomentJS. To install:



npm install date-fns

Automatically format dates with i18next

In the i18next.js file, we need to import some stuff from date-fns:



import { format as formatDate, isDate } from "date-fns";
import { en, nl } from "date-fns/locale"; // import all locales we need

const locales = { en, nl }; // used to look up the required locale

Then add the following configuration to i18next:



interpolation: {
    format: (value, format, lng) => {
        if (isDate(value)) {
            const locale = locales[lng];
            return formatDate(value, format, { locale });
        }
    }
}

We simply check if the dynamic value is a date and then let date-fns format it. As the third options parameter of format(), we tell date-fns which locale object to use.

If we now pass a Date object in the options of our t() function, it will automatically be formatted. We can set the format inside the curly braces in the translation bundle:



{ "postedOn": "Posted on {{ date, MM/DD/YYYY }}"}

As I explained above, not every language uses the same date format. Luckily date-fns provides locale aware date formats:

So instead of MM/DD/YYYY we should use P. Don't forget to pass in the locale option to the format function.

To make our date formats easy to work with, we can predefine some formatters that we would like to use in our app:



format: (value, format, lng) => {
    if (isDate(value)) {
        const locale = locales[lng];

        if (format === "short")
            return formatDate(value, "P", { locale });
        if (format === "long")
            return formatDate(value, "PPPP", { locale });
        if (format === "relative")
            return formatRelative(value, new Date(), { locale });
        if (format === "ago")
            return formatDistance(value, new Date(), {
                locale,
                addSuffix: true
            });

        return formatDate(value, format, { locale });
    }

    return value;
}

Here we use powerful date-fns functions such as formatDistance and formatRelative to create a human readable representation of a date in the past.

And now we can simply choose from a set of formatters in our translation bundle:



{ "postedOn": "Posted on {{ date, short }}"}



import { useTranslation } from "react-i18next";
const { t } = useTranslation();

// 'Posted on 11/10/2021'
t('postedOn', { date: new Date() });

Simple React fade animation hook

Edwin — Sat, 28 Nov 2020 14:06:00 +0000

Hey you! Yea you! Do you need a quick and simple fade animation on your React component? Don't feel like installing a library?
Then let's go! 💨💨💨

Show me the code already! 👀

The hook returns [isVisible, setVisible, fadeProps], just like useState() hook, but you also need to set the fadeProps on the element you want to fade.

const MyFadingComponent = () => {
    // Just like useState() hook, the fadeProps go on the fading DOM element
    const [isVisible, setVisible, fadeProps] = useFade();

    // You can use isVisible to mount/unmount the component!
    return <>
        <button onClick={() => setVisible(!isVisible)}>Toggle visibility</button>
        {isVisible && <h2 {...fadeProps}>Now you see me...</h2>}
    </>;
};

And the hook! 🎣

It uses onAnimationEnd to delay setting the isVisible state to false, which allows the animation to finish before the component unmounts!

const useFade = (initial) => {
    const [show, setShow] = useState(initial);
    const [isVisible, setVisible] = useState(show);

    // Update visibility when show changes
    useEffect(() => {
        if (show) setVisible(true);
    }, [show]);

    // When the animation finishes, set visibility to false
    const onAnimationEnd = () => {
        if (!show) setVisible(false);
    };

    const style = { animation: `${show ? "fadeIn" : "fadeOut"} .3s` };

    // These props go on the fading DOM element
    const fadeProps = {
        style,
        onAnimationEnd
    };

    return [isVisible, setShow, fadeProps];
};

Styles 💅

@keyframes fadeIn {
    0% { opacity: 0; }
    100% { opacity: 1; }
}

@keyframes fadeOut {
    0% { opacity: 1; }
    100% { opacity: 0; }
}

What's the point? 🙄

If we would use the useState() hook and then apply the state with an expression like isVisible && <Component />, our component will unmount before the CSS animation has finished, which is not what we want! The useFade() hook delays unmounting until the animation is finished.

What's cool about this? 😎

The syntax is just like useState(), you can simply use an isVisible && <Component /> expression to mount/unmount the component.

Here's how you do it with React Transition Group, you need a wrapper component and wire the enter/exit animation to the state yourself, yuck! Framer Motion and React Spring are similar.

Room for improvement (please help!)

Toggling between two elements does not really work at the moment:

const [isVisible, setVisible, fromProps, toProps] = useFade();

{isVisible ? <ComponentA {...fromProps} /> : <ComponentB {...toProps} />}

I'm trying to pass the opposite fade animation to ComponentB, but can't figure out how to get it right. If you have an idea, let me know!

Why I prefer WebStorm over VSCode for web dev

Edwin — Sat, 10 Oct 2020 16:34:31 +0000

The reason is short and simple: WebStorm fits my workflow better. It shows me information that I need when I need it, which improves my productivity.

I'm not sponsored by JetBrains to write this, I just got the feeling that people regard VSCode as the 'go-to' IDE for web development these days. I hope this article can give you some insight into the stuff you are missing out on if you have never used Webstorm before.

Recently I tried switching from WebStorm to VSCode for work when we started working from home, but I felt something was missing, even with plugins.

In control of version control

WebStorm makes me feel in control of the changes that I'm making to the project that I'm working on. The differences between both IDEs are small, but they do add up. Both have great features for finding, editing and refactoring code. The main area where the developer experience of VSCode is lacking is version control.

Both editors show you which files were changed/added, but WebStorm offers some very useful additional features and a better overall developer experience:

Change Log of the React repository in WebStorm

I can organize my local changes in multiple changesets, which makes it easy to split my changes per feature or between client/server or isolate some experimental code that I want to revert later on.
Both IDEs have great tools for comparing versions of a file (diff tools).
WebStorm comes with a fantastic change log panel. It allows me to easily see the changed files of each commit and to get an overview of the state of all branches in the project. In VSCode, you need a plugin such as Git History to get the same overview, but it's just not as nice.
Fixing mistakes in my commits (that have not yet been pushed) is as simple as right clicking the actual commit and either undoing or rewording the commit message. It's the tiny things like these that speed up my work.
WebStorm has a dedicated panel for "shelves", which allows you to temporarily store uncommited code (useful for working with temporary changes). It's easy to manage multiple shelves and compare changes to the current version. VSCode only offers a basic implementation of Git stash.
You can bundle up your changes into a patch file and send it to someone else or import it in another project, without checking in to version control. This should not be your standard process, but every now and then this can save a bit of time.
Finally, when you are fixing a merge conflict, the 'magic wand' tool can automatically resolve all changes that do not cause any conflicts, so you can focus on the actual issues.

VSCode

One can argue that there are tons of plugins available for VSCode that can fill up these gaps or you could use some external app like Sourcetree or Git Kraken, but that's the whole point: WebStorm feels like a complete package right out of the box, I never have to leave my IDE during the whole development process (OK, just for debugging in my browser).

Conclusion

I prefer working with WebStorm over VSCode, because it speeds up my work and has great features that show me useful information when I need it most. VSCode feels lacking in this aspect.

It does come at a price for individual developers, but you should ask yourself if such a small investment is worth the time you save in everyday tasks such as version control. However, WebStorm is free for students of most universities.

Using HTML Frames in React

Edwin — Tue, 01 Sep 2020 00:12:46 +0000

Yes, you read that correctly: <frame>.

You know, that funny HTML tag that disappeared from the face of the internet at about the same time as <marquee>, GeoCities, guest book pages, animated "UNDER CONSTRUCTION" gifs and the rest of Web 1.0.

I wanted to see if it is possible to render a React component to a HTML <frame>. Here is the end result:

Frames 101

Documentation about frames is incredibly hard to find, so here's a quick refresher on how they work:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
  <HEAD>
    <TITLE>A simple frameset document</TITLE>
  </HEAD>
  <FRAMESET cols="20%, 80%">
    <FRAME name="menu" src="menu.html">
    <FRAME name="content" src="content.html">
  </FRAMESET>
</HTML>

Frames need to be inside a <frameset>, which replaces the <body> tag and defines how the frames are divided into rows and/or columns. The rows and cols attributes can take percentage values, absolute numbers (as pixels) or an asterisk to tell it to take the remainder of the space. Framesets can be nested inside each other, in order to create a layout with multiple dividers.

Using frames and framesets, you can create layouts where parts of the page remain visible (such as the header and navigation menu), while the main content of the website is replaced.

A frame has a name attribute, that can be used in hyperlinks to replace the content of that frame:

<a href="page2.html" target="content">Go to page 3</a>

Where did they go?

I remember building websites using frames years ago and I was wondering what happened to them. The short answer is that the <frame> element was introduced in HTML version 4.0 (1999) and deprecated in HTML5 (2014).

Frames break a fundamental principle of the web, namely that a page is a single unit of information that can be viewed and clicked/navigated to using a URL. The information that is shown inside frames, however, depends on a sequence of navigation actions by the user.

Perhaps the same thing can be said about modern Single Page Applications with their dynamic content in modal screens, sidebars and infinite scrolling lists, but that's a discussion for a different time.

It's the year 2020, which means you should use CSS to lay out the information on your webpage. Now that flexbox is supported by all major browsers, it is super easy to create these type of layouts with a bit of CSS and a few semantic HTML5 elements.

What Mozilla says about frames:

Deprecated
This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

Just because the internet says we should not use frames, does not mean it is forbidden to do so, right?

Using frames with React

I got inspired by the react-frame-component library that allows you to render a React app inside an <iframe> and I was curious if I could do the same thing for <frame>.

I wanted to create something similar to the react-frame-component library, where you can pass in any React component to a <Frame> component, which renders it inside its document. These components are abstractions that resemble the original frame and frameset elements:

<Frameset rows="20%, 80%">
  <Frame name="nav">
    <Menu />
  </Frame>
  <Frame name="main">
    <Home />
  </Frame>
</Frameset>

Instead of a src attribute of the frame that points to a page, you pass the child component that you want to render. It should also accept the original frame attributes, such as options to disable the frame border and (dis)allow resizing. The name attribute is used to target the frame for navigation purposes (see below).

Frameset

The <frameset> replaces the <body> tag, which is kind of an issue in React, since rendering a React app requires a DOM element container to render the app into. In the end, I decided to let the <html> be the root of the React app, which means the app won't have a <head> anymore (no styling, no title).

I could not pass the cols and rows to the <frameset> element as props using React, so I have to use a ref and set the attributes using JS. I still don't know why.

class Frameset extends React.Component {
    constructor(props) {
        super(props);
        this.ref = React.createRef();
    }
    componentDidMount() {
        if (this.props.cols) {
            this.ref.current.setAttribute("cols", this.props.cols);
        }
        if (this.props.rows) {
            this.ref.current.setAttribute("rows", this.props.rows);
        }
    }
    render() {
        return (
            <frameset ref={this.ref}>{this.props.children}</frameset>
        );
    }
}

React will also show us a nasty warning that we cannot nest frameset elements, which I believe is incorrect:

Warning: validateDOMNesting(...): <frameset> cannot appear as a child of <frameset>.
    in frameset (at Frameset.js:45)

Frame

Implementing the frame itself is a bit more complex. We need to access the frame's document and render the React component to it.

The document can easily be accessed using the contentDocument property.

The react-frame-component library used document.write() to overwrite the content of the document. This works, but it is not recommended by modern browsers:

let doc = this.frameRef.current.contentDocument;
doc.open("text/html", "replace");
doc.write(
    '<!DOCTYPE html><html><head></head><body style="margin:0"><div id="root"></div></body></html>'
);
doc.close();

I tried simply rendering a new React component tree to the body of the contentDocument, but then the page briefly displayed the content and disappeared again, resulting in an empty page. Waiting for the onLoad event of the frame is not possible using React, but a delayed render using setTimeout() seemed to do the trick.

React again complained, this time that we should not render the app directly to the document body, so I manually inserted a container element. Then, we can render our component to this container on every componentDidUpdate():

ReactDOM.render(this.props.children, this.rootRef.current);

Replacing a frame's content

I ended up with a component that renders a component to a target frame, similar to the <a target="content"> in HTML:

<Link target="main" component={Home}>Go Home</Link>

To make this work across component trees, I used a React Context inside each <Frameset> component, that keeps track of which component is rendered inside each frame by it's name and a function to replace the component of a target frame.

Styling

The fact that every frame has its own document completely breaks importing styles in components that are rendered inside a frame. I came up with a custom useStyle() hook that adds a stylesheet from the public assets directory to the frame's document. Not pretty, but good enough for this project.

End result

The basic functionality of HTML frames was successfully implemented. It is possible to nest framesets and create a layout with multiple dividers. The implementation required some hacks and I really doubt sharing state across components works. I have not even tested it in production mode, but it was never meant to be used in production anyway.

The full app is here:

Fallout hacking minigame in JS

Edwin — Fri, 26 Jun 2020 17:26:33 +0000

Here is a follow-up of my completely pointless but incredibly fun side-project to create a retro CRT screen in JS and CSS.

This time I decided to build the hacking minigame from the Fallout game series, which was also the inspiration to start this project in the first place.

Check the full Sandbox for a bigger screen.

The goal of the game is to find the password that is hidden in this garbled mess of characters. You can click a word or move with the arrow keys and use the enter key to confirm. Incorrect guesses will result in a hint indicating how many letters the password has in common with your guess.

Some of the stuff I've learned

Hexadecimal numbers (0xffff) can be used as regular numbers in JS, so you can easily add and subtract them. Seems obvious, just never thought about it.
The CSS ch unit (width of one character) combined with a monospace font is super useful for building these kind of text based interfaces, where I want to have a maximum of exactly 80 characters on every line.
CSS columns is something I rarely use, but works perfectly here. The column-fill: auto property was crucial for filling columns one by one, instead of in a balanced manner.
To word-break the passwords and highlight them over multiple lines, I first tried putting a password in a single span with the word-break: break-all property, but later switched to one <span> per character, since that makes the whole thing easier to control using JS and also easier to position. I then assign some data attributes to the span to keep track of which word is being clicked and highlighted.

Any cool ideas?

What should I build next? Know any other games with terminal screens like these? Let me know! 👇👇👇

Retro CRT terminal screen in CSS + JS

Edwin — Fri, 21 Feb 2020 00:38:17 +0000

As a fun project, I decided to create a terminal interface that has the look and feel of an old CRT monitor.

The terminal is responsive, but it might be easier to work with on a larger screen (and it will provide a hint for the login).

Now, it's time to boot that terminal!

Goals

My goal is to build the whole thing using modern ECMAScript 6 features (without any transpiler such as Babel). Sorry Internet Explorer, it's time for you to retire.

During this project, I learned about a lot of topics:

ES6 features such as modules, dynamic import and async/await
CSS border-image, background gradients, animation and variables
JavaScript Audio and SpeechSynthesis APIs
Handling DOM elements using pure JS

There is too much going on to do a full tutorial, but in this article I'll explain the most important parts. Later on, I might do a follow up article about the details, such as individual components and how I organized the project. In the examples I often leave out some of the final code for clarity, but you can always view the source on Codesandbox.

Inspiration

I drew most of my inspiration for this project from the Fallout 3 game, where you can "hack" your way into computers by playing a mini game on one of these terminals:

Skeuomorphisms

Mimicing attributes of real life objects (such as the material or shape) in a design is called a skeuomorphism. The reasoning is that by making a design look like an object that the user is familiar with, it might become easier to understand. Apple used it a lot in their apps, such as the book store apps that showed your books on a 'real' shelf or a compass app that showed a spinning compass pointing to the direction you are facing.

This style has fallen in to disuse mostly due to the popularity of flat design, where extreme minimalism seems to be the norm. Most software still contains some skeuomorphisms though. For example, the simple unstyled HTML <button> on a webpage will resemble a hardware button, which should give the user a clue that this element can be pressed. Navigational tabs look like a physical tabbed folder.

Another great example that I recently encountered is this polaroid camera:

📸✨ Polaroid Camera In CSS

Sarah ・ Jan 31 '20

#codepen #css #html

Coding a CRT

So how do we make our CRT resemble the real deal? We're gonna need a few parts:

Scanlines, the visual pattern of alternating horizontal lines that this type of monitor used to have.
A huge rounded bezel, to make it look like one of those tiny portable TV sets.
Some buttons, such as a power switch. I feel that manually switching on the device and actually seeing the device boot increases the immersion of the whole experience.
A text based interface where the user can type in commands.

Building the screen 📺

The basic HTML is pretty simple, it's just a <div> for each part:

<!-- the actual device -->
<div id="monitor">
    <!-- the rounded edge near the glass -->
    <div id="bezel">
        <!-- the overlay and horizontal pattern -->
        <div id="crt" class="off" onClick="handleClick(event)"> 
            <!-- slowly moving scanline -->
            <div class="scanline"></div>
            <!-- the input and output -->
            <div class="terminal"></div>
        </div>
    </div>
</div>

I might cover the button controls in a future article.

The scanlines

The horizontal black and semi-transparent lines from this Codepen seemed to do the trick:

#crt:before {
    content: " ";
    display: block;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    background: linear-gradient(
        to bottom,
        rgba(18, 16, 16, 0) 50%,
        rgba(0, 0, 0, 0.25) 50%
    );
    background-size: 100% 8px;
    z-index: 2;
    pointer-events: none;
}

The :before pseudo class, combined with position: absolute, allows us to overlay the line pattern on top of the element. The linear-gradient fills the background for the top half with an opaque dark line and the bottom half with a semi-transparent black. The background-size property makes it full width and 8px high, so each individual line becomes 4px. This background is repeated vertically to create the alternating line pattern.

This article describes a way to create a really realistic scanline pattern, which even includes a screen door effect: a mesh-like appearance where you can see the gaps between pixels on the screen. This causes the screen to really flicker, which was very straining on my eyes, so I decided not to use that. I did use the color separation effect for the text, which adds an animated text-shadow to the terminal text which makes the text appear to move around a bit:

@keyframes textShadow {
  0% {
    text-shadow: 0.4389924193300864px 0 1px rgba(0,30,255,0.5), -0.4389924193300864px 0 1px rgba(255,0,80,0.3), 0 0 3px;
  }
  5% {
    text-shadow: 2.7928974010788217px 0 1px rgba(0,30,255,0.5), -2.7928974010788217px 0 1px rgba(255,0,80,0.3), 0 0 3px;
  }
  /** etc */
}

Then there is also a scanline moving over the screen from top to bottom every ten seconds. It uses a similar, but larger linear-gradient and an animation to make it move from top to bottom.

.scanline {
    width: 100%;
    height: 100px;
    z-index: 8;
    background: linear-gradient(
        0deg,
        rgba(0, 0, 0, 0) 0%,
        rgba(255, 255, 255, 0.2) 10%,
        rgba(0, 0, 0, 0.1) 100%
    );
    opacity: 0.1;
    position: absolute;
    bottom: 100%;
    animation: scanline 10s linear infinite;
}

The animation is out of view for 80% of the time and moves from top to bottom in the remaining 20%:

@keyframes scanline {
    0% {
        bottom: 100%;
    }
    80% {
        bottom: 100%;
    }
    100% {
        bottom: 0%;
    }
}

The bezel 🖵

To create the rounded edge, I use a border-image, a CSS property that I have never even heard of before! The idea is that you create a background image that is sliced up automatically into several regions, one for each edge and corner.

You can indicate how much of the image is actually used by the unitless border-image-slice property. It uses the value as pixels for raster images and as percentage for SVG. In our case, we want 30px from the edge. Defining the border: 30px solid transparent property seemed necessary to make it look OK in Android Chrome.

#screen {
    position: relative;
    width: 100%;
    height: 67.5vmin;
    border: 30px solid transparent;
    border-image-source: url(./bezel.png);
    border-image-slice: 30 fill;
    border-image-outset: 0;
    overflow: hidden;
}

Your browser will then automagically use the border image and scale the middle sections for varying width and height of the element. ✨

Screens

To create an experience where the user can interact with the terminal and have some screens where all the output is automatic and others where there is alternating input/output, I created one function for each of the screens:

boot - the start-up sequence
login - a very secure authentication mechanism
main - where the user can type commands

Boot

The boot screen just outputs a lot of text on the screen. To achieve this, I created a type() function, which returns a promise that resolves when the typing animation is finished. It is crucial to make it an asynchronous function, because we want to wait for the typing animation to complete before we let the user type his input. How the function works is explained further below.

In all of my functions, I use a simple async/await pattern that is shown here, so I can build my screens in a synchronous flow, which keeps the code very readable.

In the boot() function, I can then just await the typer() function to finish and move to the next screen:

async function boot() {
    clear();
    await typer("Hello world");

    login();
}

The clear() function just empties the terminal div by resetting the innerHTML. I will skip the login screen for now and explain the main loop.

Main

The main() function shows the input and waits for the user to type a command. The command is then parsed and based on a lot of if/else statements, we can call a function and/or show some output to the user. When the command has finished, we start over by recursively calling the main() function!

async function main() {
    let command = await input();
    await parse(command);

    main();
}

I just love how concise and readable this code is, despite the fact that we are using an imperative style of programming. Creating and updating DOM elements manually is a bit of a chore, but quite manageable in our case.

Input/output ⌨️

The CSS for the input and output text is pretty simple, the only interesting thing to mention is the pixely VT323 font and all text is transformed to uppercase:

@import url("https://fonts.googleapis.com/css?family=VT323&display=swap");

.terminal {
    font-family: "VT323", monospace;
    text-transform: uppercase;
}

Animated typing for the output

This is the part where most of the JavaScript stuff comes in. I started out using a library called TypeIt to create an animated typing effect for the command line output. It's quite versatile - you can just pass it a container element and an array of strings and off it goes!

new TypeIt('#container', {
    strings: ["Hello", "world"],
    speed: 50,
    lifeLike: true,
    startDelay: 0,
    cursorChar: "■"
}).go();

After a while I decided to roll my own typing function, because I wanted to add a fancy animation when characters appeared on the screen (try clicking the red button). The core of this functionality is a while loop that adds one character to the screen and then pauses for a short while:

async function type(text, container) {

    await pause(1);

    let queue = text.split("");

    while (queue.length) {
        let char = queue.shift();
        container.appendChild(char);
        await pause(0.05);
    }

    await pause(0.5);
    container.classList.remove("active");
    return;
}

The while loop keeps running as long as the queue string has length > 0 and the String.shift() function removes the first character and returns it.

The pause function is a glorified wrapper for setTimeout(), returning a Promise so we can wait for it using async/await - nifty! Usually you want to postpone executing a callback function using setTimeout, but here we just want to pause the code execution, to simulate the terminal processing your command. Thanks Stackoverflow.

function pause(s = 1) {
    return new Promise(resolve => setTimeout(resolve, 1000 * Number(s)));
}

One second is the default argument, because that is how I wanted to use it most of the time.

Handling input commands

In a very similar fashion, I let the user type a command by creating an input element that returns a resolved promise when the user presses the enter key.

async function input(pw) {
    return new Promise(resolve => {
        const onKeyDown = event => {
            if (event.keyCode === 13) {
                event.preventDefault();
                let result = event.target.textContent;
                resolve(result);
            }
        };

        let terminal = document.querySelector(".terminal");
        let input = document.createElement("div");
        input.setAttribute("id", "input");
        input.setAttribute("contenteditable", true);
        input.addEventListener("keydown", onKeyDown);
        terminal.appendChild(input);
        input.focus();
    });
}

The input is actually a <div> with the contenteditable attribute property, which allows the user to type inside the element. This may come in handy if we want to do fancy HTML stuff inside the div, which is mostly not allowed inside a regular <input> element.

The blinking caret 🟩

The blinking square at the end of a line really adds to the whole typing animation (credits to TypeIt for the inspiration). It is nothing more than a character placed in the :after pseudo class!

#input {
    position: relative;
    caret-color: transparent;
}
/* Puts a blinking square after the content as replacement for caret */
#input[contenteditable="true"]:after {
    content: "■";
    animation: cursor 1s infinite;
    animation-timing-function: step-end;
    margin-left: 1px;
}
/* Inserts the > before terminal input */
#input:before {
    content: ">";
    position: absolute;
    padding-left: 1.5rem;
    left: 0;
}

The animation-timing-function: step-end makes the cursor change its transparency discretely to make it blink, rather than as a linear fade.

Then I also place a > character before the input to indicate that he user can type there. A neat little trick is settings caret-color: transparent; on the actual element itself, to hide the default caret. This will break moving the cursor if the user clicks in the middle of the text, but it does not bother me all too much.

Executing commands

I started off with a large if/else block to handle all the different commands, but that got out of hand quickly, so I needed something more modular.

This is where I decided to use dynamic imports. Another ES6 feature that has great browser support, now that Chromium version of Edge is released!

You probably know static imports, where you import your dependencies at the top of your own module:

import moment from 'moment'

A dynamic import can be used anywhere, even conditionally, with variable paths and will require the specified resource on demand! Just what we need! The import will return a Promise with your module. If you use async/await, you can access any of its exports directly:

const { format } = await import('date-fns');

So here is how I used imports in for parsing commands:

async function parse(command) {

    let module;

    // Try to import the command function
    try {
        module = await import(`../commands/${command}.js`);
    } catch (e) {
        console.error(e);
        return await type("Unknown command");
    }

    // Type the output if the command exports any
    if (module && module.output) {
        await type(module.output);
    }

    await pause();

    // Execute and wait for the command (default export) to finish
    if (module.default) {
        await module.default();
    }
    return;
}

Doing this kind of stuff directly in the browser without any transpiler such as Babel and a code bundler like Webpack is very cutting-edge. It gives the developer a lot of freedom to only load resources whenever they are needed, preventing your main app from getting bloated. This is one of the main features that will make it easy to write modular, lightweight apps in native JavaScript.

Commands 👨‍💻

Every command is simply a JavaScript module with a default export function that is executed when it is loaded. It can also directly output some text when the user presses enter by adding an output named export, as explained above. If we return a Promise here, the main() function will wait for the command to be finished.

const output = "Hello world.";

const helloWorld = () => {
   // do whatever...
};

export { output };

export default helloWorld;

Now that we can add commands in a modular way, we can go completely crazy and write any cool stuff we can think of.

I'm trying to free your mind, Neo. But I can only show you the door. You're the one that has to walk through it.

-- Morpheus

Next time...

In the next part of this article, I will explain more about how I added sound, control buttons and theming! For now, have fun hacking!

Creating dice using CSS grid 🎲

Edwin — Sun, 02 Feb 2020 20:59:49 +0000

Recently, I felt like creating a game as a nice little side project. The game involves dice, so I needed some way to visualise them. This article will explain how you can create dice using only HTML and CSS.

Flexing with CSS 💪

Why reinvent the wheel if other people have already solved the problem for us, right? A quick search around the web led me to this article by Landon Schropp, which describes how to make great looking dice using CSS flexbox.

He implemented the face of a die by simply positioning a span element for each pip of the die inside of a div. The div.column contains the vertically aligned pips.



<div class="fourth-face">
  <div class="column">
    <span class="pip"></span>
    <span class="pip"></span>
  </div>
  <div class="column">
    <span class="pip"></span>
    <span class="pip"></span>
  </div>
</div>

These pips are positioned using flexbox and pushed to opposite sides of the die using the justify-content: space-between property. His final solution requires quite a bit of CSS to correctly style every possible face value.

We can do better with CSS grid 🔥

While I was playing around with the code, I realised that the pips of a traditional die are aligned in three rows and three columns, which is a great opportunity to use CSS grid.

Imagine the face of a die as a 3x3 grid, where each cell represents the position of a pip:



+---+---+---+
| a | b | c |
+---+---+---+
| d | e | f |
+---+---+---+
| g | h | i |
+---+---+---+

CSS grid is supported by all evergreen browsers, but as you may expect, Internet Explorer offers only very basic support. The final result will therefore not work in IE11.
For a full guide on CSS grid, please refer to the amazing Grid by Example, by Rachel Andrews.

Creating the grid layout

To create a simple 3 by 3 grid using CSS, the only thing we need to do is set a container element to display: grid and tell it that we want three equally sized rows and columns:



.face {
    display: grid;
    grid-template-rows: 1fr 1fr 1fr;
    grid-template-columns: 1fr 1fr 1fr;
}

The fr unit allows you to set the size of a row or column as a fraction of the free space of the grid container; in our case we want one third of the available space, so we use 1fr three times.

Instead of writing 1fr 1fr 1fr we can use repeat(3, 1fr) to repeat the 1fr unit three times. We also use the grid-template shorthand property that defines rows / columns:



.face {
    display: grid;
    grid-template: repeat(3, 1fr) / repeat(3, 1fr);
}

The only HTML that we need is a div.face container with the above CSS and a span.pip for each pip:



<div class="face">
    <span class="pip"></span>
    <span class="pip"></span>
    <span class="pip"></span>
    <span class="pip"></span>
</div>

The pips will be automatically placed in each of the cells, from left to right:

Positioning the pips

Now we get to the point where we need to position the pips for each of the dice values. It would be nice if the spans automatically flowed to the correct positions in the grid for each value. Sadly, we will need to set the position of each of the pips individually.

Recall the ASCII table at the beginning of the article? We are going to create something very similar using CSS. Instead of labeling the cells in the row order, we use this specific order so we only need a minimal amount of CSS to fix the edge cases:



+---+---+---+
| a |   | c |
+---+---+---+
| e | g | f |
+---+---+---+
| d |   | b |
+---+---+---+

Two of the cells are left empty, because they are never used on our dice.

Grid template areas

We can translate this layout to CSS using the magical grid-template-areas property (which replaces the grid-template used above):



.face {
    display: grid;
    grid-template-areas:
        "a . c"
        "e g f"
        "d . b";
}

So instead of using traditional units to size our rows and columns, we can just refer to each cell with a name. The syntax itself provides a visualization of the structure of the grid, just like our ASCII table. The names are defined by the grid-area property of the grid item. The period in the middle column signifies an empty cell.

Placing pips in an area

We use the grid-area property to give a name to this grid item. The grid template (above) can then reference the item by its name to place it in a specific area in the grid. The :nth-child() pseudo selector allows us to target each pip individually:



.pip:nth-child(2) {
    grid-area: b;
}
.pip:nth-child(3) {
    grid-area: c;
}
.pip:nth-child(4) {
    grid-area: d;
}
.pip:nth-child(5) {
    grid-area: e;
}
.pip:nth-child(6) {
    grid-area: f;
}

We are getting pretty close!

As you can see, the values 1, 3 and 5 are still incorrect. Because of the order of the grid-template-areas that we chose earlier, we only need to reposition the last pip of each of these dice. To get the result that we want, we combine the :nth-child(odd) and :last-child pseudo selectors:



.pip:nth-child(odd):last-child {
    grid-area: g;
}

And we have our final result!

Setting the position of each element individually does not scale well. But for our goal, the number of cases is very limited, it works for all dice values and it allows us to keep our HTML simple. It feels like a cleaner solution than the flexbox version above. It is also easier to translate into components using a JavaScript framework such as React as you will see below.

Final result 🎲

The implementation above only uses HTML and CSS, but I also created a very basic React app to show how you can use the dice as components.

DEV Community: Edwin

Native CSS nesting now supported by all major browsers!

CSS Nesting

Do you really still need a CSS pre-processor?

Practical CSS :has() selector examples

Browser support

Basics

Thoughts

What more?

Building a TODO app without a bundler

Single Page Apps

Goals

Why would you go buildless?

Downsides of going buildless

Using third party libraries in a buildless setup

Libraries for the buildless route

HTM, Preact & JSX

State management using Valtio

Implementing the TODO app

Getting started

Importing third party modules

ESM.sh aliasing

Issue with use-sync-external-hook

Issue with Preact standalone

Run the app

Conclusion

Sources

Internet Explorer retires on June 15 - what can developers do?

What's the problem with IE11?

Unsupported features in IE11

Transpilation example

Benefits of dropping IE11 in your web app

How to phase out IE11

How to drop IE11 support from your web app

Use browserslist

Remove redundant Babel plugins

Specific tool examples

Progressive enhancement for modern browsers, fallback for IE

Detect IE11 using JavaScript

Conclusion

Sources

Format numbers in the user's locale using vanilla JS

Example

Playground

React: automatic date formatting in translations (i18next + date-fns)

Update April 2022

Intro

React i18next

Using i18next in your app

Translation bundles

Setup i18next

Interpolation

Adding date-fns

Automatically format dates with i18next

Simple React fade animation hook

Show me the code already! 👀

And the hook! 🎣

Styles 💅

What's the point? 🙄

What's cool about this? 😎

Room for improvement (please help!)

Why I prefer WebStorm over VSCode for web dev

In control of version control

VSCode

Conclusion

Using HTML Frames in React

Frames 101

Where did they go?

Using frames with React

Frameset

Frame

Replacing a frame's content

Styling

End result

Fallout hacking minigame in JS

Some of the stuff I've learned

Any cool ideas?

Retro CRT terminal screen in CSS + JS

Goals

Inspiration

Issue with `use-sync-external-hook`