Blog, page 15

Brad Frost:

JavaScript is eating the world and the rest of the frontend stack with it. Those server-side languages people used to write in? Node. HTML? JSX. Styling? We do that in JS now too. HTML, CSS, and JavaScript are three sturdy, capable languages that each have their own histories, nuances, and best practices. I do worry that as we author more and more in JS we risk losing those hard-won HTML/CSS best practices. Of course, it’s totally possible to preserve those HTML/CSS best practices even as we write everything in JS, which is why I want to make sure libraries like React are accessible to frontend people like me who don’t come from a JavaScript/programming background.

Kevin Ball:

“Real programmers” were antisocial, geeky, and only cared about computing. If you didn’t fit the profile you didn’t belong.

With the growth of the importance of front-end development, we’re seeing the story play out again.

The systematic devaluation of CSS, and more, the people who use CSS.

At the top of Jeremy’s list, other people’s Javascript:

At number one with a bullet, it’s all the crap that someone else tells us to put on our websites. Analytics. Ads. Trackers. Beacons. “It’s just one little script”, they say. And then that one little script calls in another, and another, and another.

It’s so disheartening when you’ve devoted your time and energy into your web font loading strategy, and optimising your images, and unbundling your JavaScript …only to have someone else’s JavaScript just shit all over your nice performance budget.

Steven Garrity:

The inability to deal with long strings of text is the most basic and maybe most common way components can fail when coming in contact with real data. You thought the tab would be labelled “Settings”? Well, now it’s called “Application Preferences.” Oh, and the product launches tomorrow.

Lily Hay Newman, for Wired:

Google's Chrome browser turns 10 today, and in its short life it has introduced a lot of radical changes to the web. From popularizing auto-updates to aggressively promoting HTTPS web encryption, the Chrome security team likes to grapple with big, conceptual problems. That reach and influence can be divisive, though, and as Chrome looks ahead to its next 10 years, the team is mulling its most controversial initiative yet: fundamentally rethinking URLs across the web.

Evan Puschak:

Otomo has said that he wanted Tokyo itself to be a major character in Akira, and one of the ways he fleshes this out is with light. Particularly, neon.

Neon has a special significance for both Tokyo and the cyberpunk genre. It is the bitter, but beautiful light that signifies both the colorful radiance and the gaudy consumerism of modernity.

Man, this movie is just so cool. I rewatched it recently; it has lost none of its power to mesmerize me.

Ethan Marcotte:

Lately, I’ve been reflecting on some of the language I use to talk about accessibility—or, more specifically, to talk about the people I’m designing for. Like, I’ve spoken in the past about “screen reader users” or “users who navigate primarily by keyboard.” (Heck, maybe you have too.) And I’ve been wondering if that language is problematic, since it implicitly treats those groups as monoliths: as though every single person using a given piece of assistive technology would browse, behave, and think exactly the same. In other words, if two different people visit your site with the same speaking browser, each of those people will have their own expectations of how a website should work, and how information will be arranged.

Cole Henley makes some very astute observations on the value and purpose of web development tools:

At the risk of sounding like a Luddite, I do worry that the adoption of tools for producing websites often lacks focus and a clear reason for “why.” As a largely self-taught profession, we have often lent on our peers for guidance and direction. But how often is the context of this guidance comparable to our own? As I said earlier, can the efforts to produce code for enterprise website applications across large, distributed teams share some equivalence with the work many of us produce in creating small, brochure sites for small to medium-sized businesses and not-for-profits? Does one shoe fit all? And are we in danger of focusing too much on the “Pencils rather than the drawing”? The Process over the Product?

I found this question particularly hard to grapple with:

But one of the ways CSS Zen Garden was used to persuade people about the merits of a web standards approach was to suggest that we can retain the markup and replace the CSS. However in reality how many projects has this ever happened on? What is the realistic lifespan of a thing we produce? And do we tend to underestimate how disposable our code truly is?

Jennifer Ouellette, for Ars Technica:

Manmade clocks may precisely measure time, but, from a human perspective, the passage of time is remarkably fluid. It drags when you’re doing your taxes but really does fly when you’re having fun. Isolate yourself from any markers of time (night and day, watches or clocks) and you will feel less time has passed than actually has, because under those circumstances, the brain condenses time.

Mark Brown’s “Designing for Disability” series seems to be very comprehensive and well researched. I’m moderately colorblind and feel very well represented by this video.

It reminded me of the game I most wanted to love but just couldn’t play: Puzzle Bobble. If a level had both blue and purple bubbles, I was toast. Even though each bubble color had a different shape inside, the differentiation wasn’t enough for split second decisions.

Heydon Pickering:

Designing is deliberating; reasoning; justifying. It is joining up the dots.

Sara Soueidan:

Using the color wheel to pick colors has many benefits. One of the main advantages of HSL is that creating color harmonies becomes a piece of cake.

Sam Greer, for Eurogamer:

Some games are so big, and yet we engage with such a small percentage of their space in a meaningful way. When time isn’t an obstacle, why not have miles and miles of samey fields? “More is better” is such a common characteristic of big budget titles and the result is big spaces, filled with repetitive content and scarcely anything memorable. Our interactions with so many gaming worlds is passive. Even when they’re pretty enough to make us stop and snap a screenshot we’re still not learning them or unravelling them. They just want to get us to the next item on a checklist.

Eric Meyer experiences internet access in rural Uganda:

For geosynchronous-satellite internet access, the speed of light become a factor in ping times: just having the signals propagate through a mixture of vacuum and atmosphere chews up approximately half a second of travel time over roughly 89,000 miles (~152,000km).

But that’s not the real connection killer in most cases: packet loss is. After all, these packets are going to orbit and back. Lots of things along those long and lonely signal paths can cause the packets to get dropped. 50% packet loss is not uncommon; 80% is not unexpected.

A local caching server, meant to speed up commonly-requested sites and reduce bandwidth usage, is a “man in the middle”. HTTPS, which by design prevents man-in-the-middle attacks, utterly breaks local caching servers. So I kept waiting and waiting for remote resources, eating into that month’s data cap with every request.

Ken Kocienda recounts the process of designing the iPhone keyboard:

I started to think about improvements, and to help me keep my keyboard goal literally in sight as I sat in my office, I measured and cut out a small piece of paper, about 2 inches wide by 1.3 inches tall, a little smaller than half the size of a credit card turned on end. I pinned up this little slip of paper on the bulletin board next to my desk. I looked at it often. This was all the screen real estate I had available for my keyboard.