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.

Read more

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.

Read more

It’s that time of the year, for the Advent of Code,
and this time around, I’m solving puzzles with Node.

My prior attempts included Elixir and TypeScript,
but after a few days of tinkering, most challenges got skipped.

I’m going back to basics, this time to sharpen my blades,
by solving all given puzzles without libraries to aid.

Feel free to join in, we’ve only just begun!
Follow along on GitHub, or enroll to be part of the fun.

Read more

I very much enjoy building sites with static site generators like Hugo or Next.js. Static site generators provide a great developer experience, perform great out of the box, and simplifying DevOps makes me a happy camper.

In my experience, the JAMstack (JavaScript, APIs, and Markup) is great until is isn’t. When the day comes that I need to add something dynamic–and that day always comes–I start scratching my head.

Read more

Back in the summer we were working on a new version of our package documentation site at Spatie.

Back then, all docs for all packages were stored as markdown files in a single docs.spatie.be repository. This made the website easy to maintain, but separating the docs from their code added unnecessary friction for contributors to also contribute to our docs when sending a PR.

We wanted to change things up and move the markdown files to their respective package repositories. This meant we had to come up with a way to aggregate files from multiple git repositories and serve them from a single website.

We ended up with an unsexy, procedural, 38 line node script to fetch all markdown files and copy them to a local folder. Then a simple static site generator does its thing and turn those markdown files into the website they were meant to become.

We could have built a custom web app, and the code would’ve been cleaner and have a pure architecture. Instead, we ended up with a script that fits on a 13" screen and a zero-config static site generator.

Don’t be afraid to choose a crude, simple, shop-built jig over a complex solution just for the sake of purity.

Read more

Long overdue, but I finished reading Shape Up. This quote stood out as I’ve experienced its effect first-hand.

It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles.

Really important ideas will come back to you. When’s the last time you forgot a really great, inspiring idea? And if it’s not that interesting—maybe a bug that customers are running into from time to time—it’ll come back to your attention when a customer complains again or a new customer hits it. If you hear it once and never again, maybe it wasn’t really a problem.

I used to keep lists for everything little thing that popped up. Both things that I had to do and things that I wanted to do. These lists slowly became mountains of work with paralyzing gazes, having the opposite effect of motivating me.

At some point I decided to delete all the baggage I’d been carrying around. It was exhilarating!

Now I only add things to a todo list that I’m not allowed to forget, not things that I have to or want to do. Something that’s on a list for more than a week is a smell; maybe it’s not as important as I thought.

Read more

During his lightning talk at Full Stack EU, Bram Van Damme mentioned the rule of least power.

The rule of least power was described in an essay by Tim Berners-Lee back in 2006.

When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. This finding explores tradeoffs relating the choice of language to reusability of information. The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.

This is a useful principle to follow for the web because less powerful languages fail better.

Forgot a closing tag in HTML? There’s a fair chance the browser will just fix it for you.

Did you write an invalid or unsupported CSS rule? The browser will ignore the statement and parse the rest as intended.

Got a syntax error in your JavaScript app? Prepare to watch the world burn.

Read the full essay on w3.org.

Read more

Read more

I last blogged about handling routes in a Laravel and Inertia app. The premise was that we don’t have access to Laravel’s URL generator functions with Inertia, so we need to pass our application’s routes down differently.

The same problem exists with authorization: we don’t have access to the can helper and other Gate methods. Here’s a short post about dealing with authorization on the frontend.

Read more

Back in 2003 when I was still in elementary school, Dave Akins wrote a list of laws to abide when building a spacecraft. I’m not planning to build one of those any time soon, but there seem to be many similarities with web development. A few examples:

• Engineering is done with numbers. Analysis without numbers is only an opinion
• Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate
• Don’t do nuthin’ dumb

Here’s a good one te keep next to your desk, and consider yourself lucky next time you ship a bug to production.

• Space is a completely unforgiving environment. If you screw up the engineering, somebody dies

Read all 44 laws at their home on spacecraft.ssl.umd.edu.

Read more

I work at an agency that started out building websites and small apps, but the past years have shifted towards larger web apps and products.

Small projects are easy to manage. GitHub issues or Basecamp todos are more than enough to keep things going. Adding a feature or refactoring a small project is also easy, because there aren’t too many moving parts to take consider.

Large and especially long-living projects are constant moving targets. It’s harder to estimate things and technical debt can become a real issue. A linear, chronological task list won’t do it anymore, we need to start prioritizing things.

I want to share four systems that have helped me, both on a personal and team level, prioritize work on large projects.

Read more

This was originally a lightning talk at Full Stack Europe 2019. You can watch the video on their YouTube channel.

In the 4.5 years I’ve been a developer at Spatie, over 200 packages have been built and released by our team. I’ve done quite some authoring and maintenance over the years, and I’d like to share 8 actionable tips on writing and maintaining open source software without going insane.

Read more

I was lucky enough to see Jeremy Keith speak at the inaugural edition of Full Stack Europe. He did a keynote on building on/for the web. I’m not going to distill the talk’s content to a few paragraphs as that wouldn’t do it justice, hopefully the talk will come online at some point.

One thing I’d like to mention he talked about is the difference between materials and tools for the web. Jeremy written about this in the past, and I believe his journal entry is an article worth sharing.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

And a bit further:

I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

Read the full article on adactio.com.

Read more

Read more

Want to view a single image on @imgur (literally its only job)? Good luck! You gotta successfully download (354KB) and run (1.21MB) of client-side React in order to get your image requested as resource 110 of 553. What should have been an IMG element became… this.

@csswizardry - and don’t forget to look at the visualization

This is ridiculous. Things like this don’t even make me any mad anymore, they disappoint.

To make things worse, a large portion of the replies try to justify everything with “but business decisions…”.

Nah.

We can do better. We should do better.

Read more