#javascript #vanilla-js

File structure

In the previous posts, we’ve gone through our first few utility functions. We now have enough in our toolbox to move on to our first component. However, where do all these functions belong?

Read more

#javascript #vanilla-js

Event delegation

After learning how to select elements in the DOM, it’s time to zoom into events. This is the third post in the JavaScript Framework Diet series.

Read more

#javascript #vanilla-js

Selecting elements (part 2)

In Selecting elements (part 1) we learned how to select elements from the DOM, and how to find elements inside other elements, both with our own $ and $$ helpers.

In part 2, we’re going to review two DOM element instance methods: closest and matches.

Read more

#javascript #vanilla-js

Selecting elements (part 1)

Lets get warmed up! Before we can get productive, we need two small helpers that we’ll be using in most components we’ll build from here on. I’m talking about $ and $$, which are wrappers around document.querySelector and document.querySelectorAll.

Read more

#javascript #vanilla-js

JavaScript Framework Diet

JavaScript frameworks are great, but overused. Adding small bits of interactivity to an interface shouldn’t mean installing kilobytes of dependencies or introducing complex build tools.

It’s time for a diet. I’m challenging you to build something without a framework, or follow along and learn something along the way.

Read more

#javascript #spatie

Mailcoach's (lack of) JavaScript stack

Yee-haw, we released Mailcoach! Mailcoach is a self-hosted newsletter solution. My contributions were on the JavaScript side of things: I helped decide which tech stack to use, and implemented it.

After building apps with almost exclusively Vue and React the past few years, we decided to go with vanilla JavaScript for Mailcoach. There’s no frontend framework involved, but we’re pulling in some npm packages where needed.

I’m not going to dive into implementation details. I’m going to talk about why we decided on this stack and go in-depth on the structure of the application code, bundle sizes, and choosing external dependencies.

Read more

#react #javascript #oss / reactjs.org

React's versioning policy

React follows semantic versioning, but with a twist. From their versioning policy:

When releasing critical bug fixes, we make a patch release by changing the z number (ex: 15.6.2 to 15.6.3).

When releasing new features or non-critical fixes, we make a minor release by changing the y number (ex: 15.6.2 to 15.7.0).

When releasing breaking changes, we make a major release by changing the x number (ex: 15.6.2 to 16.0.0).

The twist is subtle: non-critical bugfixes are released as minor releases.

I’ve often wondered whether three digits really is necessary for versioning. As a package maintainer, deciding between minor and patch is often a gray area.

Two digits would suffice: breaking changes and non-breaking changes. Feature or bugfix doesn’t really matter from a technical point of view: upgrading can either break things, or can’t.

React reserves the patch number for critical bugfixes, which I believe is a necessary escape hatch in a two digit system. But I like I how they default to simply bumping minor versions.

#livewire #javascript / calebporzio.com

Live updating Oh Dear! status pages: Livewire edition with Caleb Porzio

Last week I published a post about how I implemented live updates on an Oh Dear! status page.

Caleb Porzio rebuilt the page with Livewire. It’s pretty impressive to see how easy the process is by just adding a few built in Livewire directives.

Watch the short screencast on Caleb’s blog.

#javascript #inertia.js #livewire #laravel

Inertia.js and Livewire: a high level comparison

Both Inertia.js and Livewire have been in the spotlight the past few months. The two libraries often get put next to each other because of their (coincidentally) simultaneous releases.

I’ve seen many people compare the two, or ask if they can be used together. This post showcases their similarities and differences, and should help you understand which problems they each solve best.

Read more


Live updating Oh Dear! status pages

Last week Oh Dear! launched a new status pages feature. I designed them and implemented their frontend. Here’s a live example on status.flareapp.io.

We were originally going to use Vue for the pages, so we could make the entire view reactive so we could easily fetch and update data with AJAX or websockets. I started building the status page view, but quickly became hesitant about the decision to use Vue. It didn’t feel like the right tool for the job.

Read more