Using npm as a Build Tool

The main purpose being: you're using npm anyway, so using it directly to run scripts removes a dependency (i.e. gulp/grunt/whatever) and brings you a bit closer to the tools you are using directly. I could see this example `package.json` file from Graham Smith being highly referenced as people try this out for themselves.

Remember Damon Bauer covered this here on CSS-Tricks last year, with a whole bunch of examples of what is possible.

TypeScript at Slack

An excellent subhead by Felix Rieseberg: How I Learned to Stop Worrying & Trust the Compiler.

I'd wager that some of the popularity of SCSS was due to that fact that any valid CSS was valid SCSS, so you could baby step into SCSS on an existing codebase fairly easily. The same is true with TypeScript:

Modern JavaScript is valid TypeScript, meaning that one can use TypeScript without changing a single line of code. This allowed us to use "gradual typing" by enabling the compiler and the static analysis early, without suspending work on critical bug fixes or new features.

And, also like SCSS, you get immediate benefit from the baby stepping. You'll find bugs right away:

... the more lines of code a human writes, the more inevitable it becomes to misspell a property, assume the parent of a nested object to always exist, or to use a non-standard error object.

What appeals to me the most though, is what TypeScript does to your IDE:

TypeScript understands which properties and methods are available on certain objects, enabling your editor to do the same. An autocomplete system that only uses words in the current document feels barbaric afterward.

Poly Fluid Sizing

Fluid typography is pretty amazing. We have a writeup of how it all works. But as fancy as that is, it's still scaling the type linearly. What if we wanted the type size to fall along a curve? The math gets a bunch more complicated, but it's possible.

Jake Wilson digs in, and while he finds that calc() isn't quite up for the job (e.g. font-size: calc(3vw * 3vw); /* This doesn't work in CSS */), he does land on a technique he's calling Poly Fluid Sizing, which takes a map of breakpoints and font sizes and linear interpolates them just about as good (*it depends*).

The Different Logical Ways to Group CSS Properties

Over on the MediaTemple Blog, I talk about some logical possibilities for how you might arrange the declarations within a ruleset. Personally:

I'll admit, I traditionally haven't had much of an opinion about the ordering of CSS properties. I just add what I need. I think they end up largely "grouped" by related things because that's just how my brain spits them out.

While writing this, I looked into CSS Comb again, and I'm starting to be convinced this is a good idea. I don't know if it's worth the tedious work of manually organizing properties, but I can see the advantages of code that is meticulously organized, so having a computer do it seems like a good idea.

Which Projects Need React? All Of Them!

When does a project need React? That's the question Chris Coyier addressed in a recent blog post. I'm a big fan of Chris' writing, so I was curious to see what he had to say.

In a nutshell, Chris puts forward a series of good and bad reasons why one might want to use React (or other similar modern JavaScript libraries) on a project. Yet while I don't disagree with his arguments, I still find myself coming to a different conclusion.

So today, I'm here to argue that the answer to "When does a project need React?" is not "it depends". It's "every time".



The "normal" workflow I'm sure we've all lived is that design happens, then coding happens. A healthy workflow has back-and-forth between everyone involved in a project, including designers and developers, but still: The code is the final product. You design your way to code, you don't code your way to designs.

It was only a little over a month ago when it was news that Sketch 43 was moving to a .JSON file format. The final release notes drop the news quite blasé:

Revised file format

But Jasim A Basheer rightly made a big deal of it:

... it will fundamentally change how the design tools game will be played out in the coming years.

"enables more powerful integrations for third-party developers" is stating it lightly. This is what the fine folks at Bohemian Coding has done — they opened up Sketch's file format into a neat JSON making it possible for anyone to create and modify Sketch compatible files.


The Many Tools for Shape Morphing

To no one's surprise, I'm sure, there are lots of different ways to do the same thing on the web. Shape morphing, being a thing on the web, is no different. There are some native technologies, some libraries that leverage those, and some libraries that do things all on their own. Let's look at some of the options (with demos) and weigh the advantages and disadvantages.


Think you know the top web browsers?

If I had to blindly guess about global marketshare, I would have gotten it wrong. I probably would have forgotten about UC browser (kind of the point of Peter O'Shaughnessy's article) that's so huge in Asia. I would have guessed Firefox has a slight edge on Safari (turns out Firefox is half the share of Safari), and that Edge would be outpacing IE by now (also only half).

This is good dinner party conversation fodder, but I wouldn't base any major decision making on it. The only stats that matter at your websites stats.


Legally Binding Electronic Signatures with eversign

There are few things more obnoxiously tedious than being asked to sign a document over email, where they tell you to print it, sign it, scan it, and email it back. One time I Photoshopped my signature onto a document, and they were able to tell somehow and made me go through the whole rigamarole instead.

We're working with highly sophisticated computers here, can't I sign this thing with the web somehow? Yes, you can! As long as the company asking is using eversign, that is.


The Power of Custom Directives in Vue

When you're initially learning a JavaScript framework, it feels a little like being a kid in a candy store. You take in everything available to you, and right off the bat, there are things that will make your life as a developer easier. Inevitably though, we all reach a point working with a framework where we have a use-case that the framework doesn't cover very well.

The beautiful thing about Vue is that it's incredibly feature-rich. But even if you have an edge case not covered by the framework, it's got your back there as well, because you can quite easily create a custom directive.


When Does a Project Need React?

You know when a project needs HTML and CSS, because it's all of them. When you reach for JavaScript is fairly clear: when you need interactivity or some functionality that only JavaScript can provide. It used to be fairly clear when we reached for libraries. We reached for jQuery to help us simplify working with the DOM, Ajax, and handle cross-browser issues with JavaScript. We reached for underscore to give us helper functions that the JavaScript alone didn't have.

As the need for these libraries fades, and we see a massive rise in new frameworks, I'd argue it's not as clear when to reach for them. At what point do we need React?