by

Some Guiding Principles For Front-End Development

I’ve recently had a bout of philosophy that I can’t quite shake. I like philosophy a lot, and I think we’re all philosophers. I think I picked up that idea in my Ayn Rand phase, where she said,

As a human being, you have no choice about the fact that you need a philosophy. Your only choice is whether you define a philosophy by a subconsious… thought

What I’ve realized is that I have had some subconscious thoughts about Front-end Development. And once I really bring them to the foreground, I realize that there are some core principles that guide why I do what I do, and how I choose to do it. So, I’d like to share some of my philosophies of front-end development.

The Browser isn’t Evil

Yes, this is a thing that I really do believe. The browser is not evil; it’s not there to make my life more difficult, or to ruin the experience of its user. The browser is there to browse the web. Real people made that browser, and they made it with thought and intent. Those were not perfect people, and they did not make a perfect browser — but their job was to make sure that the browser was true to its name.

!(Evil) !== good

I’m not saying that every browser is good, though. IE6, IE7… those weren’t good browsers — but they were better browsers. No, they aren’t feature-rich, and they don’t support HTML5, but they improve the browsing experience over their predecessors. Real human programmers had web browsing in mind when they created those browsers. Those programmers may not have followed W3C standards, but they may have been under deadlines, or incredibly tight technical restrictions — all which made the browser comparatively difficult to work with for front-end developers. The browser may not be good, but no one at Microsoft intentionally made an evil one. They didn’t want to ruin your, or my weekends.

Treat the browser as your ally

Recently I had someone ask me a question about how to deal with rendering a video that would be both responsive, and fullscreen capable. The individual was looking for pointers to CSS tricks or JavaScript libraries. Instead, my response was, “Just use the Fullscreen API“. Given the requirements, the Fullscreen API, which lives in most modern browsers natively, would have worked just fine.

His and my different attitudes about the browser are illustrated by how we tried to tackle the problem. He was starting by assuming the browser couldn’t help him, so all of his questions were centered around fighting it. My assumption was that the browser could help; so my reaction was to double-check caniuse.com and to review the API. Instead of assuming that you need to fight something that’s wrong in the browser, start by expecting the browser to have something that can help you.

The browser is here to help.

Don’t Start with a Library

jQuery with intent

jQuery is an amazing library that really has changed the way we write front-end. It makes it easy to select elements in the DOM, animate them, AJAX them, and interact with them. But that doesn’t mean you need it.

jQuery uses the selectivizr library for selecting elements— which was great when IE7 and 6 shared the same internet as Chrome and Firefox. But now, IE8 is what’s left over, and you know what it supports? document.querySelector(). You can select an element using a standard CSS selector with vanilla JavaScript using .querySelector() now. And it’s pretty consistent across all browsers (IE8, of course, will not support CSS3 selectors).

If you need a library to find a div, you’re not doing your reading

Don’t avoid a library, either

Sure, you’ll feel more sexy and powerful when you write JavaScript without a library. And yes, you’ll look more attractive. When I wrote McSandy, a fun little code & preview app in vanilla JS, my wife almost mistook me for Tom Selleck. But, I started McSandy with the intent of making sure it was not library-dependent. It needed to work without an internet connection, and you needed to be able to download the HTML page, and still be able to use it. I had good reason for not using a library.

But, event binding in vanilla JavaScript, especially for DOM manipulation, can get very time consuming very fast. Guaranteeing that events behave the same in all browsers is important, and so is making sure that the event binding is consistent throughout the experience, regardless of when or where the node got added to the DOM. All of a sudden jQuery’s .on() method seems pretty valuable.

Libraries exist to meet a developer’s needs; know when you’re in need and what you need

3. Bootstrapping Usually Isn’t

According to Wikipedia,

In general parlance, bootstrapping usually refers to the starting of a self-sustaining process that is supposed to proceed without external input.

A bootstrap that you fight isn’t a bootstrap

Bootstrap started off as an internal toolkit at Twitter to standardize development across departments. Now it’s a website kickstarter. Twitter Bootstrap is way more robust and feature rich than the name gives it credit for. It’s all the pieces you need to make a fully responsive website complete with navigations, menus, accordions, and carousels, including the jQuery-dependent JavaScript.

I don’t like Bootstrap. Admittedly, I’ve never used it —only fixed it. Every time I’ve seen Bootstrap it was because some non-front-end developer wanted to kickstart a website, and he got lost in the hacks. After his hacks made the project unsustainable, I’d get dragged in to fix it. Every Bootstrap implementation I’ve seen was the result of a non front-end developer who was fighting the bootstrap.

You shouldn’t expect fights with browsers, and you sure as hell shouldn’t pick them with bootstraps.

Boilerplate over Bootstrap

The HTML5 Boilerplate is a better bootstrap than Bootstrap. Because the Boilerplate is true to the meaning of a bootstrap: it’s self sustaining; you can download it and get started, and you can iteratively build it into more complex applications. Every website I’ve built in the last five years was bootstrapped off of the HTML5 Boilerplate.

I use the HTML5 boilerplate, a few stylus snippets, and a vanilla JavaScript snippet as my boilerplate. I have virtually zero code to change, and absolutely none to fight. I’m ready for building something more complex.

A framework that doesn’t require changes to be useful is, in fact, incredibly useful.

Don’t try to be cool

There’s lots of new and shiny out there on the interwebz. Every day new tools, tricks, plugins, libraries, and node packages pop up. That’s because every day, a developer has a new need and a newer, more innovative, way to meet it.

Watch your task runners

Just when I’d gotten good with Grunt, Gulp galloped into view. So now I have two node.js-based task runners built with two entirely different philosophies. I experimented with gulp a few times on personal projects before I decided to use it for work. And, you know what?

Gulp makes sense for certain use cases.

You know what else? Gulp is also configured in a completely different way than Grunt. A project with a hard deadline isn’t the time to bust out a new and unfamiliar toy.

And really, if you have a four-page prototype, do you even need gulp or grunt? Is it that hard to save and build?

Not everything needs to be preprocessed, templated, or frameworked

There are currently six CSS preprocessors, three of which get major attention (Less, SASS, Stylus). For HTML, I worked with Markdown, Handlebars, Jade, Mustache, and Angular this week alone. For JavaScript, there’s CoffeeScript, Caffeine, Typecast, Dart, TypeScript, and many more.

HTML, CSS, AND JavaScript aren’t these incredibly hard languages with poorly-written documentation. So it seems odd that each language has at least three other languages that can be used to build it.

Is it really so complex to write in the language that you need to make writing it more complicated? After you set up your build system, configured it, learned/trained a new syntax, imported your library and debugged your build errors, did you really save any time?

Some things could use a helping hand

I’m a big fan of a CSS preprocessor called Stylus. Huge fan, in fact. It’s got a flexible syntax that let’s me decide if I want to write more like SASS, or more like plain ol’ CSS. The Stylus syntax is very forgiving and easy to learn. Getting a handle on Stylus is more about discovering the features, rather than debugging my mistakes. And in the mean time, I can create variables, mixins, and import libraries that can keep me DRY and SRP.

Markdown is also nice. A small amount of time is needed to learn reserved symbols and syntax (I always forget how to do links), but it lets me mix and match Markdown and HTML. It’s pretty easy to do be content-focused with Markdown, because that’s why it was written; it’s there to make non-programmer types feel more comfortable writing content for the web. This makes sense because, after all, HTML exists for content — not the other way around.

A tool in your project should be like a microwave in your kitchen;it lets you boil a cup faster than you can boil a pot — without needing to turn off the stove.

Creative > Cool

Just because you can use a spiffy new framework in a project, does that mean you should? Is the shiny new framework solving a problem that you couldn’t solve before? No? Then reconsider using it.

Gulp is a great example of discovering the difference between creative and cool. I’ve had several projects where, I needed a task runner that performed several manipulations of a file. Gulp, in all its streaming awesomeness, was a perfect solution. I didn’t need it because it was the new cool thing, I needed it because using Grunt to minify, rename, and move a file is kind of a pain.

The flexbox CSS module is an amazing new way to deliver layouts. It also is a pretty in-depth module, with lots of new keywords and concepts to learn. McSandy uses Flexbox… mostly for the cool points. Because Flexbox properties don’t work on form elements, I made sacrifices in markup so that I could keep my cool points. I also had to create a very large block of CSS because Flexbox is still vendor prefixed in some browsers. Though cool to use Flexbox for the entire layout, it wasn’t a creative solution to an existing problem.

Being creative with your code solves problems; being cool with your code creates them.

It’s about Content

It isn’t a flat design, a responsive layout, or a new and shiny node package that brings people to a site. It’s the content. The end user doesn’t care if you used Flexbox or jQuery to get those boxes vertically centered. The end user doesn’t care if you’re using Ajax or PHP. The end user wants content.

Everything you do in your code either makes it easier, or harder, for the end user to get content. All of the philosophies, theories, frameworks, methods, tricks, tips and hacks don’t really matter in the end. All that matters is whether you delivered content to the user.

Nothing that you did will ever matter as much as the content.

</existential-crisis>

4 Comments


  1. //

    I never heard of HTML5 Boilerplate so I did some digging. It seems that that is what I would want to use if I had more of a vision about what I wanted to do on a site creatively at least. From what I remember Bootstrap gave developers a way to quickly throw up a competent site to get their information out there with as little pain as possible.

    What’s interesting is that a lot of sites use Bootstrap which makes me sad from a creative perspective. They all look and feel the same! Not that I’m asking for mystery-meat navigation but it just feels like they took the easy road. It is unsettling for some reason.


    1. //

      Richard,

      The first thing that I’ve noticed is that not many front-end developers use Bootstrap, for the reason you’ve stated; it’s a loss of creative control. Bootstrap certainly provides some helpful starting points, but if you want to make a unique and client-specific website from scratch, you’ll often spend more time gutting Bootstrap than using it.


  2. //

    We share the notion that it’s sometimes good to code directly in your target language. But then as a WCMS guy, the big risk is too much code generation. Nice piece.


    1. //

      I’m still conflicted about the use of preprocessors and ‘compilers’ for HTML, CSS, and JavaScript.

      I’ve had several cases where there was a definite benefit to using a preprocessor for my CSS. I had an instance not too long ago where I needed to change the number of columns in a grid. Because I was using a preprocessor, it took less than five minutes. No IDE could’ve helped me change column widths and the number of columns that fast.

      At the same time, I’m struggling to see the value in an HTML preprocessor when I’m writing front-end that needs to be put in the hands of a WCMS developer. I suspect he wants to see rendered HTML, not pre-compiled Jade.

      There is a risk of too much code generation, and I think that you have to go back to, “am I using this because I need to, or because I want to?”

Comments are closed.