The title says it all, really. This is another great piece of writing from Paul Ford.
I’ve noticed that when software lets nonprogrammers do programmer things, it makes the programmers nervous. Suddenly they stop smiling indulgently and start talking about what “real programming” is. This has been the history of the World Wide Web, for example. Go ahead and tweet “HTML is real programming,” and watch programmers show up in your mentions to go, “As if.” Except when you write a web page in HTML, you are creating a data model that will be interpreted by the browser. This is what programming is.
I probably need to upgrade the Huffduffer server but Maciej nails why that’s an intimidating prospect:
Doing this on a live system is like performing kidney transplants on a playing mariachi band. The best case is that no one notices a change in the music; you chloroform the players one at a time and try to keep a steady hand while the band plays on. The worst case scenario is that the music stops and there is no way to unfix what you broke, just an angry mob. It is very scary.
I decided to implement almost all of the UI by just adding & removing CSS classes, and using CSS transitions if I want to animate a transition.
Yup. It’s remarkable how much can be accomplished with that one DOM scripting pattern.
I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do.
But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.
Nice and straightforward. Locally:
git branch -m master main
git push -u origin main
Then on the server:
git branch -m master main
git branch -u origin/main
On github.com, go into the repo’s settings and update the default branch.
Thanks for this, Scott!
P.S. Don’t read the comments.
This is clever—using custom properties to enable if/else logic in CSS.
Note that John is a computer scientist that knows a fair bit about the Web: He had Node & npm installed, he knew what MIME types are, he could start a localhost when needed. What hope do actual novices have?
I think it’s even worse than that. Not only are potential new devs being put off ever getting started, I know plenty of devs with experience who have pushed out by the overwhelming and needless complexity of the modern web’s toolchain. It’s like a constant gaslighting where any expression of unease is summarily dismissed as being the whinings of “the old guard” who just won’t get with the programme.
John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole.
(Just watch as Lea’s post gets written off as an edge case.)
This is a very clear description of the differences between libraries and frameworks, along with the strengths and weaknesses of both.
A library is a set of building blocks that may share a common theme or work well together, but are largely independent.
A framework is a context in which someone writes their own code.
I very much agree with the conclusion:
If your framework can be a library without losing much, it probably should be.
Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.
This is all just mwah—chef’s kiss!—perfect:
Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.
A 2015 paper by Long Tien Nguyen and Alan Kay with a proposal for digital preservation.
We discuss the problem of running today’s software decades,centuries, or even millennia into the future.
80 geocoding service plans to choose from.
I’m going to squirrel this one away for later—I’ve had to switch geocoding providers in the past, so I have a feeling that this could come in handy.
Tom’s videos are so good! Did you see his excellent in-depth piece on copyright?
This one is all about APIs and the golden age of Web 2.0 when we were free to create mashups.
It pairs nicely with a piece by another Tom from a couple of years back on the joy of Twitterbots.
This is a great way to organise code snippets—listed by use case, and searchable too!
Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.
I’m constantly forgetting the difference between the
async attribute and the
defer attribute on
script elements—this is a handy explanation.
I am the programming equivalent of a home cook.
The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.
But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way.
We should think of our code, even our designs, as running for decades, and alter our work to match.