Adactio: Links—Tagged with build

Writing Javascript without a build system

For me, a complicated Javascript build system just doesn’t seem worth it for small 500-line projects – it means giving up being able to easily update the project in the future in exchange for some pretty marginal benefits.

This! Also, this:

I’m writing this because most of the writing I see about JS assumes that you’re using a build system, and it can be hard to navigate for folks like me who write very simple small Javascript projects that don’t require a build system.

Towards Growing Peaches Online - by Claire L. Evans

A beautiful meditation on Christopher Alexander by Claire L. Evans.

Balisage: Metaphors We Code By

My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:

Data is documents, processing data is clerking

Data is trees, processing data is forestry

Data is buildings, processing data is construction

Data is a place, processing data is a journey

Data is a fluid, processing data is plumbing

Data is a textile, processing data is weaving

Data is music, processing data is performing

Progressively Enhanced Builds - Jim Nielsen’s Blog

Rather than thinking, “how do I combine a bunch of disparate content, templates, and tooling into a functioning website?”, you might think “how do I start at a functioning website with content and then use templates and build tooling to enhance it?”

I think Jim is onto something here. The more dependencies you have in your build process, the likelier it is that over time one of them will become a single point of failure. A progressive enhancement approach to build tools means you’d still be able to launch your site (even if it’s not in its ideal state).

I want to be able to view, edit, and if need be ship a website, even if the build process fails. In essence, if the build does fail I can still take all the source files, put them on a server, and the website remains functional (however crude).

Blogging and the heat death of the universe • Robin Rendle

A cautionary tale on why you should keep your dependencies to a minimum and simplify your build process (if you even need one):

If it’s not link rot that gets you then it’s this heat death of the universe problem with entropy setting in slowly over time. And the only way to really defend against it is to build things progressively, to make sure that you’re not tied to one dependency or another. That complex build process? That’s a dependency. Your third party link to some third party font service that depends on their servers running forever? Another dependency.

Townscaper

Now you can play a demo of Townscaper right in your browser.

There goes your productivity.

Build a Better Mobile Input

This is such a handy tool for building forms! Choose different combinations of type, inputmode, and autocomplete attributes on input elements and see how that will be conveyed to users on iOS and Android devices.

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

use custom elements (for modular HTML without frameworks)

use the in-browser package manager (for JavaScript packages without build tools)

match pages with files (to avoid routing and simplify architecture)

stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

When we find remains of beavers, we assume they built beaver dams, even if we don’t immediately find remnants of such dams. The beaver dams are part of what biologists would call the animal’s extended phenotype, an unavoidable necessity of the ecological niche that the beaver occupies. When we find Homo sapiens skeletons, however, we instead imagine the people naked, feasting on berries, without shelter, and without social differentiation.

Robin Rendle ･ The web is too damn complex

The modern web wouldn’t be possible without big ol’ JavaScript frameworks, but—but—much of the web today is held back because of these frameworks. There’s a lot of folks out there that think that every website must use their framework of choice even when it’s not necessary. And although those frameworks solve a great number of problems, they introduce a substantial number of trade-offs; performance issues you have to deal with, complex build processes you have to learn, and endless dependency updates that can introduce bugs.

The web didn’t change; you did

The problem with developing front end projects isn’t that it’s harder or more complicated, it’s that you made it harder and more complicated.

Yes! THIS!

Web development did not change. Web development grew. There are more options now, not different options.

You choose complexity. You can also choose simplicity.

I don’t want to do front-end anymore

I can relate to the sentiment.

Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it.

How I Build JavaScript Apps In 2021

Sensible:

I avoid build processes.

I avoid transpiling.

I avoid the new and shiny.

I test EvErYtHiNg.

I optimize for performance and quality.

I use my own work.

I use open source to my advantage.

My stack will outlive yours

My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.

npm ruin dev | CSS-Tricks

Chris is gathering end-of-year thoughts from people in response to the question:

What is one thing you learned about building websites this year?

Here’s mine.

In 2020, I rediscovered the enjoyment of building a website with plain ol’ HTML, CSS, and JavaScript — no transpilin’, no compilin’, no build tools other than my hands on the keyboard.

Boring by default

Modern JS is amazing. Modern JS is trash. | Go Make Things

My name is Jeremy Keith and I endorse this message:

I love the modern JS platform (the stuff the browser does for you), and hate modern JS tooling.

Link tags: build

69