Posts tagged “code”, page 3

Chris Coyier tries to make sense of what “front-end web developer” means now, and gets to the core of why I avoid calling myself one:

When companies post job openings for “Front-End Developer,” what are they really asking for? Assuming they actually know (lolz), the title front-end developer alone isn’t doing enough. It’s likely more helpful to know which side of the divide they need the most.

Two “front-end web developers” can be standing right next to each other and have little, if any, skill sets in common. That’s downright bizarre to me for a job title so specific and ubiquitous. I’m sure that’s already the case with a job title like designer, but front-end web developer is a niche within a niche already.

Florian goes over a set of confusingly named properties and values from the css-text-3 specification that control what happens to white spaces when laying out text, and how line breaking works. He explains the logic of the system, different ways the properties can be used to achieve various results, and looks into some of the complication caused by incomplete implementations.

I care about this topic a lot, but it really tests my patience. If only browser support for these properties were consistent, I could start to build a mental model that takes them all into consideration. As it stands, it’s such a mess that I routinely have to spend time reading about it, and still not be super confident with the results.

A really clever (if somewhat opaque) use of flexbox to achieve some semblance of container-based layout breakpoints. Intrinsic Web Design for the win!

Jonathan Snook tried to make it more understandable, and Heydon published a follow-up post with some optimizations.

Andy Bell:

It’s getting exhausting spending so much of my time defending one of the three pillars of the web: CSS. It should sit equal with HTML and JavaScript to produce accessible, progressively enhanced websites and web apps that help everyone achieve what they need to achieve.

Painful. But at least human-readable?

Dave Rupert:

As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code.

Will these lists ever get shorter?

Jeremy Keith:

Now when we look at new things added to HMTL, new features, new browser APIs, what we tend to ask, of course, is: how well does it work?

How well does this thing do what it claims it’s going to do? That’s an excellent question to ask whenever you’re evaluating a new technology or tool. But I don’t think it’s the most important question. I think it’s just as important to ask: how well does it fail?

Nothing like a full hour of Jeremy Keith to get the year’s work started.

Jeremy Keith:

It’s not that CSS in inherently incapable of executing complex conditions. Quite the opposite. It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.

Christine Dodrill:

What? The code for that? It’s obvious, figure it out.

See? Five times as fast. Who cares that you have to throw out basically all your existing stuff, and if you mix rilkef and non-rilkef you’re gonna run into problems.

I’ve been taking a lot of interest in this topic ever since I started working on my own reset/boilerplate — Cobalt.

Peter Welch, back in April 2014:

Websites that are glorified shopping carts with maybe three dynamic pages are maintained by teams of people around the clock, because the truth is everything is breaking all the time, everywhere, for everyone.

Every once in a while I feel a need to reread this 2014 gem. Thanks to Jeremy Keith for reminding me.

Ben Frain gives some very useful and pragmatic advice on how to build web front-end prototypes.

Producing something of high fidelity, perfectly matching any flat designs, runs counter to the notion of creating something quickly. The challenge for the prototyper is therefore how to cut corners that don’t impact the fidelity of the prototype.

Jeremy Keith adds:

In my experience, it’s vital that the prototype does not morph into the final product …no matter how tempting it sometimes seems.

Prototypes are made to be discarded (having validated or invalidated an idea). Making a prototype and making something for production require very different mindsets: with prototyping it’s all about speed of creation; with production work, it’s all about quality of execution.

Jeremy Keith:

I really like this design pattern. Cover 80% of the use cases with a declarative solution in HTML, but also provide an imperative alternative in JavaScript that gives more power. HTML5 has plenty of examples of this pattern. But I feel like the history of web standards has a few missed opportunities too.

In recent years there’s been a push to expose low-level browser features to developers. They’re inevitably exposed as JavaScript APIs. In most cases, that makes total sense. I can’t really imagine a declarative way of accessing the fetch or cache APIs, for example. But I think we should be careful that it doesn’t become the only way of exposing new browser features. I think that, wherever possible, the design pattern of exposing new features declaratively and imperatively offers the best of the both worlds—ease of use for the simple use cases, and power for the more complex use cases.

Heydon Pickering:

Most of you will be familiar with JavaScript’s fat arrow functions, also known as “chonky darts”.

In ES2019, fat arrow functions are not the only kinds of arrow functions available to you. Let’s take a look at some of the others and what they have to offer.

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.