A question of style

I’ve just a written a post over on the Clearleft blog about the way we’re currently nailing down some front-end design principles.

I’m a big fan of design principles for many reasons, not least of which is they way they can help to quickly resolve debates and arguments. They become a kind of higher authority to appeal to, taking opinion and ego out of the equation.

They can also lead to specific design patterns. This is something I’ve talked about in the past: the goals of a project inform its principles, which in turn inform the patterns that are used.

In the case of front-end design principles, they are informed by some higher-level goals. As I wrote on the Clearleft blog, some of those goals are user-centric, and some are developer-centric:

The user-centric goals include:

• performance,
• accessibility, and
• device-agnosticism.

While the developer-centric goals include:

• maintainability,
• readability, and
• modularity.

In turn, the final patterns produced—the actual markup and CSS and JavaScript—should be influenced by the resulting principles: the code should be maintainable, readable, and modular. So at the same time as we were figuring out high-level principles, we are also defining an in-house coding style.

Now here’s the thing about coding style: while it should ideally be informed by your design principles, there’s another factor that overrides everything else—what coding style is preferred by the developers who will be inheriting your code?

When it comes to things like tabs vs. spaces, or indentation, or naming variables, what matters is not which style you use, but that everyone is using the same style.

So, for example, I favour tabs over spaces. And I don’t tend to camelCase variable names in JavaScript. And I don’t like indenting my markup (I make judicious use of new lines instead). But I’m in the minority. I could try to force my style on everyone else at work but that wouldn’t be very productive. It’s far more important that everyone settles on the same style—any style—than it is for a coding style to be “correct.” The only “correct” coding style is the one that everyone is agreeing to use.

Mind you, people who write JavaScript functions with the opening curly brace on a new line are just plain wrong.

Moving on from React, a Year Later

Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.

There’s also this:

It’s really fast

One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.

HTML Is Actually a Programming Language. Fight Me | WIRED

When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).

Hell, yeah!

Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers.

Hell, yeeeeaaaaahhh!!!

What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.

Always bet on HTML | Go Make Things

I teach JS for a living. I’m obviously not saying “never use of JS” or “JavaScript has no place on the web.” Hell, their are even times where building a JS-first app makes sense.

But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.

I <3 the cascade! | Go Make Things

Chris makes the valid observation that JavaScript programmers who bemoan the “global scope” of CSS are handily forgetting that JavaScript also has global scope by default.

JS is also global by default. We use IIFEs and wrapper functions to add scope.

And for all this talk about CSS being global, you can actually scope styles when you need to. It’s more-or-less the same way you do it in JavaScript.

Modest JS Works | You were never sold on heavy-handed JavaScript approaches. Here’s a case for keeping your JS modest.

The fat JavaScript stacks-du-jour have a lot of appeal. They promise you to be able to do more with less. But what if I want to do less?

This is a terrific little (free!) online book all about modest JavaScript. The second part has practical code, but it’s the first part—all about the principles of staying lean—that really resonates with me.

Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.