Link tags: processing

19

sparkline

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.

The Economics of the Front-End - Jim Nielsen’s Weblog

I do think large tech companies employ JavaScript frameworks because, amongst other things, it saves them money at their scale. And what Big Tech does trickles down in the form of default choices for many others (“they’re doing it and are insanely successful, so mimicking them can’t be a bad idea”). However, the scale at which smaller projects operate doesn’t necessarily translate to the same kind of cost savings.

Move Fast & Don’t Break Things | Filament Group, Inc.

This is the transcript of a brilliant presentation by Scott—read the whole thing! It starts with a much-needed history lesson that gets to where we are now with the dismal state of performance on the web, and then gives a whole truckload of handy tips and tricks for improving performance when it comes to styles, scripts, images, fonts, and just about everything on the front end.

Essential!

194028 – Add limits to the amount of JavaScript that can be loaded by a website

Now this is a feature request I can get behind!

A user must provide permission to enable geolocation, or notifications, or camera access, so why not also require permission for megabytes of JavaScript that will block the main thread?

Without limits, there is no incentive for a JavaScript developer to keep their codebase small and dependencies minimal. It’s easy to add another framework, and that framework adds another framework, and the next thing you know you’re loading tens of megabytes of data just to display a couple hundred kilobytes of content.

I’m serious about this. It’s is an excellent proposal for WebKit, similar to the never-slow mode proposed by Alex for Chromium.

DasSur.ma – The 9am rush hour

Why JavaScript is a real performance bottleneck:

Rush hour. The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.

This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane all from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.

The Nature of Code

A web book with interactive code examples.

How can we capture the unpredictable evolutionary and emergent properties of nature in software? How can understanding the mathematical principles behind our physical world help us to create digital worlds? This book focuses on the programming strategies and techniques behind computer simulations of natural systems using Processing.

How Literature Became Word Perfect | New Republic

An engaging look at the history of word processing, word processed by Josephine Livingstone.

Are You Living in a Simulation?

Always worth bearing in mind when some perspective is needed.

If it is possible that our future species will go on to create simulations of our civilisation forerunners (us), then it is far more likely that we are currently in such a simulation than not.

An Hour of Code spawns hours of coding

Here’s a heartwarming tale. It starts out as a description of processing.js project for Code Club (which is already a great story) and then morphs into a description of how anyone can contribute to make a codebase better …resulting in a lovely pull request on Github.

IE-friendly mobile-first CSS with Sass 3.2

Jake demonstrates his technique for preprocessor-generated stylesheets for older versions of Internet Explorer (while other browsers get the same styles within media queries).

“Mobile first” CSS and getting Sass to help with legacy IE – Nicolas Gallagher

If you use Sass, this could be a really handy technique for handling IE<9 support with mobile-first responsive designs.

CreativeJS | The very best of creative JavaScript and HTML5

This is your one-stop shop for envelope-pushing in the browser:

The very best of creative JavaScript and HTML5.

BallDroppings

Brendan Dawes pointed me to this wonderfully playful creation. It's Flash-free, believe it or not.

Ex Nihilo

Dave has been experimenting with processing and documenting the results here.

HTML5 Canvas and Audio Experiment

A very pretty little Twitter canvas experiment accompanied by music delivered via the audio element. View this in a capable browser.

The Long Now Foundation - Essays

Richard Feynman and The Connection Machine.

John Resig - Processing.js

John gave us a sneak peak of this at @media Ajax last November: Processing ported to JavaScript using canvas. Check out the demos and be amazed.

What Is Google App Engine? - Google App Engine - Google Code

Infrastructure just got even cheaper. Between this and Amazon's EC2/S3, the barrier to entry to getting an app up and running is getting lower and lower.