DEV Community: Matt Levy

Model web component behaviour with XState

Matt Levy — Wed, 20 Jul 2022 14:42:40 +0000

XState is a library for creating, interpreting, and executing finite state machines and statecharts.

Finite state machines (or 'state machines' for short) and statecharts are a visual language used to describe the states in a process. You may have used similar diagrams in the past to design user flows, plan databases or map application architecture. They are perfect for modelling web component behaviour.

State machines and statecharts provide a visual way of using boxes and arrows to represent behaviour. These flows are also executable code that can be used to control the logic in your application and that makes it more predicable and testable.

In this post, we're going to look at how to model behaviour in web components using state machines and statecharts in FicusJS.

State machines vs statecharts

What is the difference between state machines and statecharts? Understanding state machines is almost the same as understanding statecharts. Statecharts are the “bigger brother” of state machines and is essentially a state machine that allows any state to include more machines, in a hierarchical fashion.

Benefits of using state machines

There are many benefits to using state machines or statecharts, including:

The behaviour (when things happen) is decoupled from the actual component (what happens).
They produce lower bug counts than traditional code.
As the complexity of your program grows, statecharts scale well.
You explore all the possible states of your program.

Designing state machines

The first step in designing state machines is to use a whiteboard or pen and paper and write down the possible states of the component you want to create. This is an important part of the process and should involve UX designers, product owners and developers. Talking through the behaviour of the component and writing down all the states helps to identify all the possibilities up-front.

Once you have a list of identified states, create a visual state machine to check that the behaviour works. Using a visual tool helps all stakeholders to understand the state machine and the behaviour of the component.

An example

We are going to create a visual depiction of a simple state machine. It is a model of a simple on/off switch.

To view the visual model and interact with it visit https://stately.ai/viz/04fcf47e-df9f-4f78-b3b9-4826c24b2df9

The visual model is a simulation which helps to refine the behaviour through defining the states and transitions of the state machine.

It consists of two states, “on” and “off”. This machine can therefore be in exactly one of the two states at any point in time. In other words, the transitions between states are instantaneous.
The “flick” event causes it to transition between states.
When the machine enters the “on” state, a side effect occurs. A light is turned on.
When the machine exits the “on” state, another side effect occurs. A light is turned off.

The definition of the machine is as follows:

{
  id: "switch",
  initial: "off",
  states: {
    off: {
      on: {
        FLICK: {
          target: "on",
          actions: "turnLightOn",
        },
      },
    },
    on: {
      on: {
        FLICK: {
          target: "off",
          actions: "turnLightOff",
        },
      },
    },
  },
}

Creating a state machine

In order to create a state machine, you import the createMachine function and pass it a machine definition object.

FicusJS decorates the @xstate/fsm package to provide additional features like extended state getters. You can also use the full XState library with FicusJS, See the state machine docs for more information.

import { createMachine } from 'https://cdn.skypack.dev/@ficusjs/state@3/xstate-service'

const machine = createMachine({
  id: "switch",
  context: { bulb: 'off' },
  initial: "off",
  states: {
    off: {
      on: {
        FLICK: {
          target: "on",
          actions: "turnLightOn",
        },
      },
    },
    on: {
      on: {
        FLICK: {
          target: "off",
          actions: "turnLightOff",
        },
      },
    },
  },
})

Creating side effects

Our state machine has two side effects. These are actions that are invoked when a transition is received.

Actions are passed as options to the createMachine function.

import { createMachine } from 'https://cdn.skypack.dev/@ficusjs/state@3/xstate-service'

const definition = {
  id: "switch",
  context: { bulb: 'off' },
  initial: "off",
  states: {
    off: {
      on: {
        FLICK: {
          target: "on",
          actions: "turnLightOn",
        },
      },
    },
    on: {
      on: {
        FLICK: {
          target: "off",
          actions: "turnLightOff",
        },
      },
    },
  },
}

const options = {
  actions: {
    turnLightOn: assign({
      bulb: 'on'
    }),
    turnLightOff: assign({
      bulb: 'off'
    })
  }
}

const machine = createMachine(definition, options)

Interpreted state machines

We can use an interpreted state machine to keep track of the state for us. To create an interpreted state machine, pass the machine created with createMachine into the interpret function. The result of the interpret function is called a service (a running instance of the machine).

const machine = createMachine(definition, options)
const service = interpret(machine)

Component usage

The service created with interpret can then be passed to a web component for it to react to state changes and therefore allow you to render UI based on the current state.

To pass the service to the component, use the withXStateService component extension.

import { html, renderer } from 'https://cdn.skypack.dev/@ficusjs/renderers@5/uhtml'
import { createCustomElement, withXStateService } from 'https://cdn.skypack.dev/ficusjs@5'

createCustomElement(
  'switch-state-machine',
  withXStateService(service, {
    renderer,
    onChange () {
      this.fsm.send('FLICK')
    },
    render () {
    }
  })
)

The result

The following Codepen is an implementation example of the switch state machine used to turn on/off a light bulb.

Summary

State machines and statecharts reduce complexity, bugs and inconsistencies in UI development by helping you define components using a behaviour-driven model. This ensures that what is designed through the visual model, is the same output that components provide through the implementation of XState.

State machines are a great fit if you need to control the application’s flow carefully. If you start using XState, it does not mean that everything will have to live inside the state machine. Some things need to be controlled on a local level inside a component rather than on a global level inside a state machine. That goes for both the state and the side effects.

Make smaller state machines rather than one enormous state machine. Programming is about composability, making larger things from smaller things — and state machines compose well.

Breakpoint rendering in web components

Matt Levy — Wed, 01 Dec 2021 21:31:54 +0000

Tailoring a user experience for different devices can get complicated. There are many approaches to rendering a different view for mobile, tablet and desktop users.

This post presents a way to offer a tailored render for different breakpoints in the same component.

The benefit of this approach is useful when you need to render the same content components in an app and have them render a specific set of HTML based on viewport size.

Define the breakpoints

Firstly, the breakpoints need defining. This sets the viewport widths and the render function to use at this breakpoint.

const breakpointConfig = {
  reactive: false,
  breakpoints: {
    992: { method: 'renderTablet' },
    768: { method: 'renderMobile' },
    1200: { method: 'renderDesktop' }
  }
}

The reactive property will make the component automatically re-render when the viewport width changes - this is optional.

Each breakpoint has a number key for the width followed by an object containing a method to use at that viewport breakpoint.

The above config results in the following media query list.

only screen and (max-width: 768px)
only screen and (min-width: 769px) and (max-width: 992px)
only screen and (min-width: 1201px)

Component usage

Using the above breakpoint config, a component can be created with render methods for each breakpoint.

import { createCustomElement, withBreakpointRender } from 'https://cdn.skypack.dev/ficusjs@3'
import { html, renderer } from 'https://cdn.skypack.dev/@ficusjs/renderers@3/uhtml'

createCustomElement(
  'breakpoint-component',
  withBreakpointRender(breakpointConfig, {
    renderer,
    renderTablet () {
      return html`<span>Breakpoint render tablet</span>`
    },
    renderMobile () {
      return html`<span>Breakpoint render mobile</span>`
    },
    renderDesktop () {
      return html`<span>Breakpoint render desktop</span>`
    }
  })
)

To view the component in action see this Codepen - https://codepen.io/ducksoupdev/pen/WNZbWbq?editors=1010

Try resizing the Codepen panel!

Summary

Conditionally rendering HTML based on the viewport width can be a powerful way to offer a tailored user experience.

Some examples of using this approach are:

Render a table on desktop and list view on mobile
Conditionally hide functionality on smaller screens
Show tabbed navigation on mobile and sidebar on desktop
Maintain state within a component presented in different ways

For more documentation visit https://docs.ficusjs.org/extending-components/with-breakpoint-render/

Try it in your next project!

JSX for web components

Matt Levy — Sat, 21 Aug 2021 05:40:44 +0000

Love it or hate it, JSX is a great technology for rendering HTML using Javascript. It is available for most frameworks but did you know that you can use it for rendering web components too?

You can use JSX with or without transpiling your code.

Without transpiling

Tagged template literals can be used directly in the browser. The htm library provides a JSX-like tagged template literal for rendering HTML.

Here is how you can use it in a FicusJS web component.

import { createCustomElement } from 'ficusjs/custom-element'
import { html, renderer } from '@ficusjs/renderers/htm'

createCustomElement('hello-world', {
    renderer,
    render () {
        return html`<p>Hello world!</p>`
    }
})

Template literals are literals delimited with backticks, allowing embedded expressions called substitutions. Tagged template literals call a function (in this case the html tag function) with an array of any text segments from the literal followed by arguments with the values of any substitutions.

This example uses the @ficusjs/renderers package which provides a browser-ready ES module using the htm library.

Clone this Snowpack starter to see it in action - https://github.com/ficusjs/ficusjs-snowpack-starter

With transpiling

As JSX extends Javascript, one of its best features is the ability to transpile it.

Transpiling removes the overhead of loading the renderer and parsing the JSX at runtime. It would be used as a production step to remove the renderer.

The babel-plugin-htm Babel plugin compiles tagged template literals using htm to hyperscript. This is the same process React/Preact use in transpiling JSX for production.

Here is an example.

import { h } from '@ficusjs/renderers/jsx-dom'
import { createCustomElement } from 'ficusjs/custom-element'

createCustomElement('hello-world', {
    render () {
        return html`<p>Hello world!</p>`
    }
})

It is very similar to the without transpilation example except that no renderer function is imported and the h pragma is imported for transpiling the JSX.

What is the `h` pragma?

By default, Babel will transform <p>Hello world!</p> to React.createElement("p", null, "Hello world!");. Pragma h will generate instead as h("p", null, "Hello world!");.

Pragma is the name to describe the function used by Babel to transpile the JSX.

In this example, pragma h is the function used by Babel to transpile JSX to Javascript to build the DOM rendered by the component.

By default, the FicusJS web component render function expects a DOM element for rendering. The pragma imported from the @ficusjs/renderers/jsx-dom library creates a DOM element for rendering in the component.

This is the output of the transpilation.

import { h } from './_snowpack/pkg/@ficusjs/renderers/jsx-dom.js';
import { createCustomElement } from './_snowpack/pkg/ficusjs/custom-element.js';
createCustomElement('hello-world', {
  render() {
    return h("p", null, "Hello world!");
  }
});

Clone this Snowpack starter to see JSX transpilation in action - https://github.com/ficusjs/ficusjs-compiled-templates

Summary

Using JSX in your web components allows you to use tagged template literals in development and then transpile it away for production resulting in smaller optimised components.

The htm library gives you JSX-like syntax but goes even further.

Spread props: <div ...${props}> instead of <div {...props}>
Self-closing tags: <div />
Components: <${Foo}> instead of <Foo> (where Foo is a component reference)
Boolean attributes: <div draggable />
No transpiler necessary
HTML's optional quotes: <div class=foo>
Component end-tags: <${Footer}>footer content<//>
Syntax highlighting and language support via the lit-html VSCode extension and vim-jsx-pretty plugin
Multiple root element (fragments): <div /><div />
Support for HTML-style comments: <div></div>

Try it in your next project!

Keep your app smooth and responsive with web workers

Matt Levy — Tue, 20 Jul 2021 14:19:15 +0000

How do you keep your web app smooth and responsive?
How do you ensure a steady and sufficiently high frame rate? How do you ensure the UI responds to user interactions with minimal delay?

These are key factors in making your app feel polished and high-quality.

The web is single-threaded which makes it hard to write smooth and responsive apps. JavaScript was designed to run in-step with the browser's main rendering loop which means that a small amount of slow JavaScript code can prevent the browser's rendering loop from continuing.

Web applications are expected to run on all devices, from the latest iPhone to a cheap smart phone. How long your piece of JavaScript takes to finish depends on how fast the device is that your code is running on.

Web workers can be an important and useful tool in keeping your app smooth and responsive by preventing any accidentally long-running code from blocking the browser from rendering. Web Workers are a simple means for apps to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface.

Web workers have not been widely adopted and there isn’t a lot of guidance on architecture for workers. It can be hard to identify which parts of your app will work in a worker. In addition, due to the asynchronous way of communicating with a worker, adoption of workers requires some architectural adjustments in your app.

Application state in a web worker

A key architecture change you can make in your app is to manage data in a worker and keep rendering updates to a minimum.

By moving your application state to a worker means you move complex business logic and data loading/processing there too.

State can be managed effectively in a web worker as proxies and fetch are available - both essential APIs for loading data and reactivity.

To communicate with the user interface, data is sent between workers and the main UI thread via a system of messages — both sides send their messages using the postMessage() method, and respond to messages via the onmessage event handler.

A typical store for managing application state in the UI thread could look like this.

import { createAppState } from 'https://cdn.skypack.dev/ficusjs@3'

const store = createAppState('worker.test', {
  initialState: {
    text: 'hello world'
  },
  setText (text) {
    this.state.text = text
  }
})

Lets create an equivalent web worker store for managing application state.

Create a worker file worker.js:

// import the web worker friendly app state creator function
importScripts('https://unpkg.com/@ficusjs/state@1.2.0/dist/worker-app-state.iife.js')

// Initialize the store using the ficusjs.createAppState function
const store = globalThis.ficusjs.createAppState({
  initialState: {
    text: 'hello world'
  },
  setText (text) {
    this.state.text = text
  }
})

// a function for communicating with the UI thread
function postState () {
  globalThis.postMessage(Object.assign({}, store.state))
}

// subscribe to store changes
store.subscribe(postState)

// listen for actions to invoke in the store
globalThis.onmessage = function (e) {
  const { actionName, payload } = e.data
  store[actionName](payload)
}

// post the initial state to any components
postState()

UI components

Create components that are only responsible for rendering UI using the withWorkerStore function to extend the component with the worker.

import { createCustomElement, withWorkerStore } from 'https://cdn.skypack.dev/ficusjs@3'
import { html, renderer } from 'https://cdn.skypack.dev/@ficusjs/renderers@3/htm'

createCustomElement('example-worker-component',
  withWorkerStore(new Worker('./worker.js'), {
    renderer,
    onButtonClick () {
      this.dispatch('setText', 'This is a test')
    },
    render () {
      return html`
        <section>
          <p>${this.state ? html`${this.state.text}` : ''}</p>
          <button type="button" onclick="${this.onButtonClick}">Dispatch worker action</button>
        </section>
      `
    }
  })
)

The withWorkerStore function provides a this.state property within the component as well as a this.dispatch() method for invoking store actions.
It also makes the component reactive to store changes as well as handling automatic store subscriptions based on the component lifecycle hooks.
It will also refresh computed getters when store state changes.

Conclusion

The investment in workers can provide you with a way to make your app smooth and responsive as well as supporting the range of devices that your app is accessed from.

To view documentation on using web workers with FicusJS, visit https://docs.ficusjs.org/app-state/web-workers/

Delay font loading using Javascript

Matt Levy — Wed, 19 May 2021 12:20:08 +0000

Achieving 100% across the board in Lighthouse can be tricky to do.

One of the assets of any web application is fonts. Loading fonts can have an impact on page load times and directly affects Lighthouse scores.

Fonts are often placed in the page <head> using a <link> tag.

<link href="https://fonts.googleapis.com/css2?family=Roboto&display=swap" rel="stylesheet">

Whilst this is the recommended way to load fonts, style sheets loaded in the <head> block rendering and impact page load times.

A simple solution

Whilst Javascript shouldn't be used in place of HTML or CSS, it does offer the ability to create a simple solution that doesn't impact load times and takes one step closer to the 100% Lighthouse score.

The following snippet delays the loading of fonts until the page has loaded. This means that fonts are not available whilst the page is being rendered, they are rendered after page load.

['https://fonts.googleapis.com/css2?family=Roboto&display=swap'].forEach(function (f) {
  const gf = document.createElement('link')
  gf.rel = 'stylesheet'
  gf.href = f
  gf.type = 'text/css'
  const gd = document.getElementsByTagName('link')[0]
  gd.parentNode.insertBefore(gf, gd)
})

This snippet of Javascript relies on an existing <link> tag to exist in the <head> so it can attach the font stylesheet. If you are using Google fonts or other CDN, it is recommended to use a rel="preconnect" link tag to tell the browser to establish an early connection with that origin.

<link rel="preconnect" href="https://fonts.gstatic.com">

How to use

Copy the following Javascript into a file named fonts.mjs and include URLs to the style sheets you want to load:

['https://fonts.googleapis.com/css2?family=Roboto&display=swap'].forEach(function (f) {
  const gf = document.createElement('link')
  gf.rel = 'stylesheet'
  gf.href = f
  gf.type = 'text/css'
  const gd = document.getElementsByTagName('link')[0]
  gd.parentNode.insertBefore(gf, gd)
})

Add a <script> tag to your HTML page pointing to the Javascript file:

<script type="module" src="/path/to/fonts.mjs"></script>

11ty and web components, an awesome combination

Matt Levy — Sun, 02 May 2021 10:59:29 +0000

11ty (Eleventy) and web components is an awesome combination. It is one of my go-to solutions for building web apps.

Setting up a project with 11ty is pretty simple. You can set it up from scratch or you can use an 11ty starter project.

This post shows you how to get started using 11ty with FicusJS. FicusJS is a set of lightweight functions for developing applications using web components.

The tool we are going to use creates a starter project quickly and easily using 11ty and FicusJS. The tool of choice is Create Ficus App. It is a simple tool that makes creating new projects quick and easy.

The project will contain:

11ty development set-up
FicusJS web components
Unit testing with Ava and JSDom
Build tooling for production optimisation

Getting started

Create Ficus App lets you focus on code, not build tools.

To create a project called my-app, run this command:

npx create-ficus-app my-app

Once the my-app directory is created, all you need to do is install NPM packages using NPM or yarn:

cd my-app

# use NPM
npm i

# or use yarn
yarn

Starter projects

Depending on what you need to build, Create Ficus App offers a selection of starter projects.

More to follow soon!

Basic app - a simple, single HTML page with inline scripts
11ty app - a Jamstack site based on 11ty

If you want to choose a starter project, run this command and follow the prompts:

npx create-ficus-app

Summary

Having a simple tool like Create Ficus App can save a lot of time when creating new projects. It gives you a headstart and allows you to incrementally add new tools and features as your project grows.

If you have any feedback on the tool, please visit the Github repo.

Unit testing web components with ava and jsdom

Matt Levy — Sun, 11 Apr 2021 17:02:06 +0000

Unit testing web components is tricky. The customElements API is required (or a polyfill of it) to create web component instances for testing.

Due to this friction and complication, I typically use an E2E testing framework like Cypress which runs tests against a real browser like headless Chrome.

Whilst an E2E framework is a fantastic tool for testing web components, I've wanted a suite of unit tests like I have for a back-end API - a comprehensive suite of fast tests for validating web components.

With Node v14, this can now be achieved through the native support for ES modules.

This post provides an example of how to set-up web component unit testing using ava and jsdom.

A repo containing the source code for this example is available at https://github.com/ducksoupdev/ficusjs-ava-test.

Dependencies

The following dependencies are used for this example.

Ava

Ava is a lightweight, fast test runner for NodeJS.

Jsdom

Jsdom is a pure Javascript implementation of HTML and DOM. Starting with v16, jsdom provides a customElements API implementation.

Set-up

Firstly, initialize a new NodeJS project to create a package.json file using npm init.

Copy the following properties to the package.json file.

{
  "scripts": {
    "test": "ava"
  },
  "devDependencies": {
    "@ficusjs/renderers": "^3.1.0",
    "ava": "^3.15.0",
    "ficusjs": "^3.2.3",
    "jsdom": "^16.5.2"
  }
}

Secondly, create an ES module (.mjs) test file at test/component.spec.mjs.

Copy the following to the file.

import { JSDOM } from 'jsdom'
import test from 'ava'

test.before(t => {
  const dom = new JSDOM('<!DOCTYPE html><html><head></head><body></body></html>')
  globalThis.window = dom.window
  globalThis.document = dom.window.document
  globalThis.customElements = window.customElements
  globalThis.HTMLElement = window.HTMLElement
})

This contains the basic structure of a unit test:

Imports jsdom and ava
Initializes a new DOM and exposes global properties required during testing

Create a web component

Create an ES module file at src/component.mjs and copy the following contents into it.

import { createComponent } from 'ficusjs'
import { html, renderer } from '@ficusjs/renderers'

createComponent('basic-comp', {
  renderer,
  render () {
    return html`<p>Basic component</p>`
  }
})

The example is a web component created using FicusJS and the uhtml renderer. It is a basic example that renders a <p> tag internally.

Writing a test

Lets test the component.

Open the ES module test file test/component.spec.mjs.

Copy the following to the file after the existing content.

test('render basic component', async t => {
  await import('../src/component.mjs')
  const document = globalThis.document
  const basicComp = document.createElement('basic-comp')
  document.body.appendChild(basicComp)
  t.is(document.querySelector('basic-comp p').textContent, 'Basic component')
})

The following is happening in this test:

Import the component ready to test
Create a new instance of the component and append it to the <body>
Assert that the component renders the <p> tag internally

The component is imported within the test and not at the top of the file because the global properties must be initialized for the component to work. Importing the component during the test means that the required global properties are available for the component to register itself with the customElements API.

Run the test

To run the test, type npm test.

If all is successful, you should see the above output from ava.

Summary

The opportunity to unit test web components this way is exciting. However, there are some caveats with this approach that might make it difficult in certain scenarios.

It follows NodeJS ES module guidelines that may not be compatible with the browser.
Files must be named with the .mjs extension or provide a package.json top level property type of value module if the extension is .js.
Importing libraries from a URL is not natively supported but can be achieved through a custom HTTPS loader.

ES module support in NodeJS is relatively new and I'm sure will get better in time.

For applications that use NodeJS build tools such as Rollup or Webpack, this could provide a unit testing approach to validate web components bundled together.

Want to get started with web components?

Matt Levy — Wed, 07 Apr 2021 19:49:29 +0000

Browsers have improved greatly. Many of the reasons to reach for a big framework like React or Angular have gone away.

You don't have to rely on a complex build system, bundlers, or other tooling to ship your Javascript to users anymore.

Browsers have support to import Javascript modules directly. You don't have to template your components in JSX and add all the baggage and complexity of a build tool - you can use Javascript tagged template literal syntax.

If don't want to pull in the complexity of a large framework like React or Angular, but still want to build applications with components, FicusJS is for you!

FicusJS is a set of lightweight functions for developing web applications. It is focused on creating web components, managing application state plus a pub/sub event bus.

What are web components?

Web components are a set of browser APIs that allow you to create new custom, reusable, encapsulated HTML tags for use in web applications.
Web Components work across modern browsers and can be used with any JavaScript library or framework that works with HTML.

Go build-less

Browsers have improved a lot over the past years. It's now possible to do web development without requiring any build tools, using the native module loader of the browser. We think this is a great fit for FicusJS, and we recommend this as a general starting point.

Aligns with standards

FicusJS aligns with standard browser APIs which means it is not based on any proprietary code or libraries.

As it is based on standards, it has longevity and is a good choice for enterprise web applications.

Try it out

The easiest way to try out FicusJS is using a hello world example.

Create an index.html file and copy the following between the <body> tags.

<hello-world></hello-world>

<script type="module">
import { html, renderer } from 'https://cdn.skypack.dev/@ficusjs/renderers/lit-html'
import { createComponent } from 'https://cdn.skypack.dev/ficusjs@3/component'

createComponent('hello-world', {
  renderer,
  handleClick (e) {
    window.alert('Hello to you!')
  },
  render () {
    return html`<div>
<p>Test component</p>
<button type="button" @click="${this.handleClick}">Click me!</button>
</div>`
  }
})
</script>

Alternatively, fork this Codepen to see it in action - https://codepen.io/ducksoupdev/pen/GRZPqJO

The hello world example creates a new custom element
using the createComponent function and registers it to the hello-world tag. It uses the lit-html renderer (multiple renderers are available) for creating HTML from tagged template literals.

Once registered, the tag can be used multiple times in HTML and instances can be programmatically obtained using document.querySelector
or element.querySelector

Less Javascript, more HTML and CSS

Matt Levy — Thu, 29 Oct 2020 17:26:55 +0000

I'm a big fan of modern Javascript frameworks. I use them every day and they make development fun again (even if you dislike Javascript!). However, more and more Javascript is something that is making me increasingly uncomfortable. For a number of years now, I've been worried about web obesity. I'm not alone https://idlewords.com/talks/website_obesity.htm

We use Javascript for everything! As cool as it is, it's not good for our front-end health.

Maybe I'm old school but I remember when Javascript was used to sprinkle web pages with interaction and other loveliness not available in HTML and CSS. This kept web pages lean, mean and Javascript to a minimum.

Less Javascript

As I said modern Javascript frameworks are amazing to work with but I've seen them used badly. This results in bloated web applications. It is common to see web apps that are over 2 MB in payload - even after tree-shaking!

This is in part due to the awesomeness of NPM. NPM seems to be a default for many developers looking to solve problems with a library and not considering the extra payload it will add to their applications. NPM packages are primarily for NodeJS and although many do provide browser bundles, often these are transpiled using polyfills and other unnecessary code to make them compatible with all browsers.

In a recent internal hackathon, an open clinic was set-up to allow developers to ask front-end questions at the start of their hacks. One question was asked more than any other "how can I use this NPM package I've found in my hack?". One of the limitations of the hack was that build tools were not allowed - no Webpack, no Rollup, no transpilation - just pure HTML, CSS and Javascript in the browser. Are developers lacking the understanding of how web applications run in the browser?

Progressive Web Apps (PWAs) are web applications that have been designed so they are capable, reliable, and installable. They are meant to be lightweight and fast - to feel like native applications in the browser. PWAs are an excellent set of principles for developing any web application. Performance is key in providing a great experience in your application. Too much Javascript can easily degrade the performance of your application.

More HTML

Whilst it is easy to fall into the trap of using Javascript for everything, it bloats unnecessarily.

Component based frameworks are amazing but they ultimately mean more and more javascript. Javascript is needed to generate HTML, Javascript is needed to provide user interaction, Javascript is needed to do all the things.

HTML has a rich set of elements for building modern web applications. Using more HTML and sprinkling Javascript where required will result in less Javascript. Less Javascript means more lightweight, fast web applications.

Use of more HTML elements for creating the application shell - navigation, menus, page structure means that Javascript is reserved for the areas where it is needed - a form, a data grid, a tree view.

Web components, whilst Javascript, provide a very lightweight way to extend HTML and provide baked-in solutions for common component problems. Web components can provide a way to implement common UI elements like tabs, dialogs and dropdown menus that work across all modern javascript and server-side frameworks.

More CSS

Styling web applications can be tricky and there are some great solutions for developers out there. Unfortunately, many of these rely on Javascript - all adding more and more Javascript bloat. Is this really necessary?

Being able to style components and enhance them in a progressive way can all be done natively with CSS. Using modern features like CSS variables and taking the time to split CSS into per page (or route) styles can lead to good web application performance.

In summary

The governing body for professional cycling in Great Britain, hired Dave Brailsford in 2003 as its new performance director. At the time, professional cyclists in Great Britain had endured nearly one hundred years of mediocrity. Since 1908, British riders had won just a single gold medal at the Olympic Games, and they had fared even worse in cycling’s biggest race, the Tour de France. In 110 years, no British cyclist had ever won the event.

Brailsford had been hired to put British Cycling on a new trajectory. What made him different from previous coaches was his relentless commitment to a strategy that he referred to as "the aggregation of marginal gains" which was the philosophy of searching for a tiny margin of improvement in everything you do.

This philosophy works well for web application development. In particular, addressing the issue of bloated web applications that have too much Javascript.

We need a new trajectory in front-end web apps; More HTML, CSS, Web components and a little Javascript.

Just imagine how better the user experience will be.

Introducing FicusJS

Matt Levy — Thu, 15 Oct 2020 15:52:17 +0000

FicusJS is a set of lightweight functions for developing applications using web components.

A function for creating fast, lightweight web components (1.88 KB gzipped)
A function for creating fast, lightweight stores for application state (1.21 KB gzipped)
A function for creating a fast, lightweight publish/subscribe event bus (271 B gzipped)

If you are looking for a fast, lightweight way to build web applications using native browser APIs, FicusJS might be what you are looking for!

Aligns with standards

FicusJS aligns with standard browser APIs which means it is not based on any proprietary code or libraries.

As it is based on standards, it has longevity and is a good choice for enterprise web applications.

Features

Functional programming patterns
Declarative component creator
Reactive components
Choose your own renderer
Extend components using functions
Application state management with stores
Application event bus
Small footprint
- All features - 3.54 KB gzipped
- Components - 1.88 KB gzipped
- Stores - 1.21 KB gzipped
- Event bus - 271 B gzipped
Features can be loaded independently or use the all features bundle
No dependencies
Works with all server-side and client-side frameworks

Documentation

The full documentation is available at https://docs.ficusjs.org

Getting started

To get started, you can use the FicusJS starter kit at WebComponents.dev

FicusJS router

Looking for a lightweight standalone client-side router that supports history and hash routing plus web components?

Try FicusJS router!

FicusJS script loader

Looking for a lightweight script loader for lazy loading ES modules and ES5 scripts or both based on dynamic paths?

Try FicusJS script loader!

DEV Community: Matt Levy

Model web component behaviour with XState

State machines vs statecharts

Benefits of using state machines

Designing state machines

An example

Creating a state machine

Creating side effects

Interpreted state machines

Component usage

The result

Summary

Breakpoint rendering in web components

Define the breakpoints

Component usage

Summary

JSX for web components

Without transpiling

With transpiling

What is the h pragma?

Summary

Keep your app smooth and responsive with web workers

Application state in a web worker

UI components

Conclusion

Delay font loading using Javascript

A simple solution

How to use

11ty and web components, an awesome combination

Getting started

Starter projects

Summary

Unit testing web components with ava and jsdom

Dependencies

Ava

Jsdom

Set-up

Create a web component

Writing a test

Run the test

Summary

Want to get started with web components?

What are web components?

Go build-less

Aligns with standards

Try it out

Less Javascript, more HTML and CSS

Less Javascript

More HTML

More CSS

In summary

Introducing FicusJS

Aligns with standards

Features

Documentation

Getting started

FicusJS router

FicusJS script loader

What is the `h` pragma?