I came across this post by Jason Fried (from Basecamp) about giving ideas a few minutes before shooting them down.

I've caught myself blurting out unnecessary negative opinions when presented with an idea. More often than not, I have more empathy towards the idea a few minutes later, and feel bad about my initial reaction.

Next time you hear something, or someone, talk about an idea, pitch an idea, or suggest an idea, give it five minutes. Think about it a little bit before pushing back, before saying it’s too hard or it’s too much work. Those things may be true, but there may be another truth in there too: It may be worth it.

Read Give it five minutes on signalvnoise.com.

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

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

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

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 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

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

Dan Abramov shared a short post on some key principles the React team sticks to. Some solid general advice here, it's not explicitly related to React.

Absorb the Complexity

Making React internals simple is not a goal. We are willing to make React internals complex if that complexity lets product developers keep their code easier to understand and modify.

Hacks, Then Idioms

We need to allow hacks using escape hatches, and observe which hacks people put in practice. Our job is to eventually provide an idiomatic solution for hacks that exist in the name of better user experience. Sometimes, a solution might take years. We prefer a flexible hack to entrenching a poor idiom.

These two stood out because they're the opposite of how I generally need to think when building applications (although they make perfect sense in the context of something like a lower level framework). Either way, lots of food for thought in here.

Read all principles on overreacted.io.

Two weeks ago I shared my thoughts and doubts about the JAMstack. Today I came across an article by Mike Riethmuller, who seems to have a lot more JAMstack experience under his belt than me. Most of the article resonated with me:

Despite my enthusiasm, I'm often disheartened by the steep complexity curve I typically encounter about halfway through a JAMstack project. Normally the first few weeks are incredibly liberating. It's easy to get started, there is good visible progress, everything feels lean and fast. Over time, as more features are added, the build steps become more complex, multiple APIs are added, and suddenly everything feels slow. In other words, the development experience begins to suffer.

[…]

The end result is we've outsourced the database, fragmented the content management experience and stitched together a bundle of compromises. That’s a stark contrast from the initial ease of setting up and deploying a JAMstack site.

Mike continues with a thoughtful analysis of the current state of the JAMstack, and intrudoces the idea of a “JAMstack Plus”, essentially bringing the best parts of JAMstack and monoliths together.

I don’t think JAMstack should defined by pushing all the complexity into the front-end build process or by compromising on developer and user experience. Instead, I think JAMstack should focus on providing lean, configurable static front-ends.

That said, lean and configurable static front-ends are kind of a niche requirement in my world. While the JAMstack is a great tool in this space, I do believe it's in a hype phase.

Read the “The Rising Complexity of JAMstack Sites and How to Manage Them” on CSS-Tricks.

Have you ever made your own strawberry jelly? The recipe is straightforward: toss together 1 cup of strawberries (fresh or frozen), 1 cup of sugar, and 1 tablespoon of pectin (to thicken). Bring to a boil and let it cool.

Congratulations, you've made your own jelly! It also tastes 10x better than store-bought jars. You can tweak ratios and swap ingredients to your own delight, and it takes about 5 minutes to make.

Before we started making our own jelly at home, the thought never really occurred to me. I simply had the habit of buying jelly at the grocery store. Not knowing how to make jelly made me assume it was either diffucult or required a time consuming process. As it turns out, neither are true.

While I'd love to have a cooking blog at some point of my life, this one's still about programming. Where am I heading here?

External libraries are like strawberry jelly.

Before you npm install strawberry-jelly, consider making your own. Having an entire ecosystem of packages at your fingertips is amazing, but dependencies come at a cost. The cost of not fully understanding or owning the code. The cost of a package being a general solution: it might be incomplete or too complete, adding unnecessary weight.

Making jelly is a worthy tradeoff because it's fast and easy to make, and substantially better than the alternative.

I'm not asking anyone to stop installing dependencies altogether, but to think twice before adding an external helpers or toolboxes. Don't install dependencies when they're an easy solution, install them when they're a better solution.