I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.
In some cases, it’s entirely valid to explore new products and technologies, but in others, our striving for novelty becomes the driving factor for abandoning perfectly suitable solutions under the umbrella of technical debt.
Just because a technology is a few years old and possibly frustrating in some cases doesn’t mean you’re in technical debt. We need to stop projecting our annoyances as pitfalls of technological or design choices.
Oodles and oodles of data on cities, including gorgeous animations of urban growth over time.
This is a bit ranty but it resonates with what I’ve been noticing lately:
I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.
This is such a well-written piece! Jay Hoffman—author of the excellent History Of The Web newsletter—talks us through the JavaScript library battles of the late 2000’s …and the consequences that arose just last year.
The closing line is perfect.
Let’s take a meandering waltz through what other people have to say about simplicity.
Some lovely data visualisation by Brendan:
The work features three main components — the threats, represented by black obelisk style objects, the system which detects and deals with these threats, represented by an organic mesh like structure, and finally the creativity that is allowed to flow because the threats have been neutralised.
This is a nifty visualisation by Hui Jing. It’s really handy to have elements categorised like this:
Chris has made sonic sparklines on his site too, but they’re far more musical than mine. Here’s his explanation of how he did it.
Are many of the modern frontend tools and practices just technical debt in disguise?
Ooh, good question!
Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.
Words become walls.
I love this post from Ben on the value of plain language!
We’re not dumbing things down by using simple terms. We’re being smarter.
Read on for the story of the one exception that Ben makes—it’s a good one.
PPK looks at the different mental models behind CSS and JavaScript. One is declarative and one is imperative.
There’s a lot here that ties in with what I was talking about at New Adventures around the rule of least power in technology choice.
I’m not sure if I agree with describing CSS as being state-based. The example that illustrates this—a :hover style—feels like an exception rather than a typical example of CSS.
Programming lessons from Umberto Eco and Emily Wilson.
Converting the analog into the digital requires discretization, leaving things out. What we filter out—or what we focus on—depends on our biases. How do conventional translators handle issues of bias? What can programmers learn from them?
The Ballad Of Halo Jones is 35 years old this year.
Where did she go? Out.
What did she do? Everything.
The forbidden symmetry of Penrose tiles and quasicrystals.
Rob has turned his exhaustive spreadsheet of all the concerts he has attended into a beautiful website. Browse around—it’s really quite lovely!
Rob’s also writing about the making of the site over on his blog.
This orrery is really quite wonderful! Not only is it a great demonstration of what CSS can do, it’s a really accurate visualisation of the solar system.
It turns out that “it turns out” is a handy linguistic shortcut for making an unsubstaniated assertion.
I saw Daniel give a talk at Async where he compared linguistic rules with code style:
We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.
Thus began some thorough research into trying to uncover a universal grammar for readable code:
I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.
I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).
We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.
The Principle of Least Power looms large over this:
Some of the most important things in the world are intentionally designed “stupid”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.