Link tags: functions

10

sparkline

The Demise of the Mildly Dynamic Website

It me:

Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.

This rings sadly true to me:

Suppose a company makes a webpage for looking up products by their model number. If this page were made in 2005, it would probably be a single PHP page. It doesn’t need a framework — it’s one SELECT query, that’s it. If this page were made in 2022, a conundrum will be faced: the company probably chose to use a statically generated website. The total number of products isn’t too large, so instead their developers stuff a gigantic JSON file of model numbers for every product made by the company on the website and add some client-side JavaScript to download and query it. This increases download sizes and makes things slower, but at least you didn’t have to spin up and maintain a new application server. This example is fictitious but I believe it to be representative.

Also, I never thought about “serverless” like this:

Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.

Functions and the future of design systems || Matthew Ström, designer-leader

Despite their name, most design systems aren’t all that much like systems. Granted, they are designed according to a system, and there’s a logical consistency to how their components and tokens are defined, but really, most design systems work like a dictionary: look up a component, get the instructions for using that component.

Mathew goes on to advocate moving towards a more function-centred approach to systematic design. It makes a lot of sense.

By the way, this isn’t directly related—other than metaphor being used—but I wrote about web standards, dictionaries, and design systems a while back.

Making QR codes with cloud functions • tommorris.org

Tom makes an endpoint for generating QR codes so you don’t have to rely on the Google Charts API.

He also provides a good definition of “serverless”:

Now, serverless is a very silly buzzword dreamed up by someone from the consultant class who love coming up with terrible names, so I promise I won’t use it any further. Your code obviously run on a server. It just means it runs on a server someone else manages.

Amazon call it a ‘Lambda Function’. Google call it a ‘Cloud Function’. Microsoft Azure call it simply a ‘Function’. But none of those are very descriptive, because, well, anyone who writes any kind of programming language generally writes functions pretty much all the time in much the same way as anyone who writes English writes paragraphs, and we don’t call our blogging software “Cloud Paragraphs”. (Someone will now, I’m guessing.)

Coding with Clarity · An A List Apart Article

Good advice on writing code that is understandable to your fellow humans (and your future self).

plainJS - The Vanilla JavaScript Repository

Some more useful snippets of JavaScript. The functions and helpers are particularly handy if you’re weaning yourself off jQuery.

Essential Vanilla JavaScript Functions

The title is overkill, but these functions ported from PHP to JavaScript could be useful (especially for dealing with arrays).

Code clarity - Anthony Ricaud

Breaking down programming tasks into smaller chunks …and naming things.

I’ll take a piece of paper and write the function names I’m going to implement. Or I’ll do it directly in my code editor, with real functions or comments.

It allows you to focus on one problem at a time. When you’re writing those function names, you are thinking about what the code should be doing. When you’re implementing the functions, you are thinking about how the code should do it.

Callback Hell

At first when I was reading this JavaScript coding guide, I thought “Isn’t this exactly what promises address?” but that is then addressed further down:

Before looking at more advanced solutions, remember that callbacks are a fundamental part of JavaScript (since they are just functions) and you should learn how to read and write them before moving on to more advanced language features, since they all depend on an understanding of callbacks.

Fair enough. In any case, what you’ll find here is mainly good advice for writing modular code.

Making your JavaScript Pure · An A List Apart Article

I really like this piece by Jack. All the things he’s talking about—pure functions and referential transparency—are terms I was previously unfamiliar with …but the concepts smell familiar. It’s good to have terminology (and reasoning) to apply to the way I structure my JavaScript.