2020-02-06 #javascript #vanilla-js #javascript-framework-diet

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


2020-01-30 #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


2019-10-08 #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.


2019-09-30 #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.


2019-09-26 #javascript #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


2019-09-23 #javascript

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


2019-09-22 #the-web #javascript

How much JavaScript do we really need?

How much should we invest in JavaScript as developers? I've asked myself that question over and over again. Around last year I came to a conclusion: I strongly believe JavaScript is a requirement for excellent user experiences. Not good experiences, excellent experiences.

Read more


2019-06-20 #react #javascript

Forget about component lifecycles and start thinking in effects

React components have always relied on lifecycle methods for side effects. While lifecycle methods get the job done, they're often overly verbose and have large margins for error.

It's easy to forget to "clean up" a side effect when a component unmounts, or update the side effect when props change. As Dan Abramov preaches: Don't stop the data flow.

React recently introduced a new way to deal with side effects: the useEffect hook. Translating lifecycle methods to useEffect calls can be confusing at first. It's confusing because we shouldn't be translating imperative lifecycle methods to declarative useEffect calls in the first place.

Read more


2019-05-20 #react #vue #javascript

React for Vue developers

For the past three years, I've been using both React and Vue in different projects, ranging from smaller websites to large scale apps.

Last month I wrote a post about why I prefer React over Vue. Shortly after I joined Adam Wathan on Full Stack Radio to talk about React from a Vue developer's perspective.

We covered a lot of ground on the podcast, but most things we talked about could benefit from some code snippets to illustrate their similaraties and differences.

This post is a succinct rundown of most Vue features, and how I would write them with React in 2019 with hooks.

Read more


2019-05-09 #react #vue #javascript / www.fullstackradio.com

Full Stack Radio 114: React for Vue developers

I had the honor to be a guest on Full Stack Radio with Adam Wathan.

We talked about why I prefer React over Vue — which I wrote about two weeks ago — and how to implement some patterns that Vue provides out of the box but aren't explicitly available in React. Examples include computed properties, events and slots.

Adam's quote:

In this episode, Adam talks to Sebastian De Deyne about learning React from the perspective of a Vue developer, and how to translate all of the Vue features you're already comfortable with to React code.

Tune in on fullstackradio.com or on your favorite podcatcher!


2019-05-05 #javascript #react / www.netlify.com

Understand React hooks internals with a 28-line React clone

Shawn Wang (@swyx) wrote about how React hooks work internally. The article is a deep dive into JavaScript closures, and builds up to a 28-line React clone with support for the useEffect and useState hooks.

In this article, we reintroduce closures by building a tiny clone of React Hooks. This will serve two purposes – to demonstrate the effective use of closures, and to show how you can build a Hooks clone in just 29 lines of readable JS. Finally, we arrive at how Custom Hooks naturally arise.

Understanding how React deals with hooks internally isn't a required to use them, but it's interesting material nonetheless!

You can read the full article on the Netlify blog.


2019-04-28 #web-components #javascript #the-web

Web components

Every now and then, web components hype seems to resurface. Judging by my Twitter feed, it's a bull market period now. Seems like a good time to share some thoughts.

Read more


2019-04-26 #javascript #react #vue

Why I prefer React over Vue

Vue is the default JavaScript framework for Laravel apps. Being part of the Laravel community, I often get the question why I prefer React, so I've decided to write down a few standout reasons.

Read more


2019-01-23 #the-web #javascript / css-tricks.com

The great divide

Chris Coyier consolidated an array of opinions about what it means to be a frontend developer today.

On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.

It's that other side that seems to really be feeling this divide. A quote from Mandy Michael:

What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

A lot of these excerpts really hit home. I'm looking forward to the conversation this might spark.

Read the full piece on css-tricks.com.


2018-12-28 #javascript #performance / kryogenix.org

Everyone has JavaScript, right?

I used to think disabled JavaScript went hand in hand with visitors explicitly blocking it. I came to the conclusion that I don't necessarily need to cater to that crowd, because the degraded user experience was by choice. After reading through this chart, I realized how wrong I was.

Sometimes your JavaScript just won’t work. Be prepared.

Read the flowchart on kryogenix.org.