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
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?
.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
.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
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.
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
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.