A Front End Engineer’s Manifesto

September 02, 2012 🇺🇸 USA

Early last year at Nebraska Code Camp 2011, I gave a talk to a bunch of .NET developers about my own personal perspective on the world of Front End Engineering.

True to form, I developed the slide deck for the web using BigText, sausage.js, and a few other self-developed but yet-to-be released plugins. I uploaded it world wide for my presentation but never published the URL publicly. Unexpectedly, last week a developer from France found it and shared it on Twitter. Well, the cat is out of the bag.

I’ve been reluctant to share the slides because I certainly don’t want developers to take them as dogmatic truth. Rather, I’d love for people to see a forest using trees they’ve planted themselves. Try to take a step back and see the big picture when you’re problem solving on the front end and figure out what’s important to you.

So with a bit of trepidation but without further adieu:

f2em.com, A Front End Engineer’s Manifesto

If you’d like to see this talk live, let me know in the comments.

The site is also available on GitHub.

Talk Description

In the fast paced world of Front End Engineering, change reigns supreme. Dormant for years, the Browser Wars are back and have broken web development wide open. Led by competing vendors championing their own implementations of HTML5, CSS3, and other Web Standards, they’re unchaining us from the desktop computing environment. We’re seeing web browsers in our favorite Mobile Phones, E-Book Readers, and Tablet devices. Does your web site work with the Android Browser? On the iPad? How about the Kindle browser? IE9? Do you even know what version Google Chrome is on?

As web programmers, how do we keep up with this blistering, nauseating pace while still taking time to improve our skills? I’ll go through a set of principles and guidelines I use to simplify the world of Front End Engineering. These criteria will help you write better future-compatible flux-resistant code. They will help you evaluate new toolsets, APIs, frameworks, and even file formats and codecs. They will improve the quality of your web sites and applications.

Many thanks to Nate Koechley, who influenced some of this manifesto with his talk on Professional Front End Engineering, and to the countless other developers and designers who have made equally important community contributions.

Originally posted at:

Screenshot image for https://v1.screenshot.11ty.dev/http%3A%2F%2Ff2em.com/opengraph//

Tags: Project Speaking 9,169 Views

< Newer
Older >

Zach Leatherman is a builder for the web at Font Awesome and the creator/maintainer of Eleventy (11ty), an award-winning open source site generator. At one point he became entirely too fixated on web fonts. He has given 84 talks in nine different countries at events like Beyond Tellerrand, Smashing Conference, Jamstack Conf, CSSConf, and The White House. Formerly part of CloudCannon, Netlify, Filament Group, NEJS CONF, and NebraskaJS. Learn more about Zach »

12 Comments

Matt Steele Disqus
03 Sep 2012

Might be a good talk to give at Barcamp?
ciembor Disqus
03 Sep 2012

Without JavaScript or CSS, or without mobile Webkit, my site may not look pretty but will still be functional. Not every web application can be functional without JavaScript. My sites will be functional without JavaScript only if it's possible and profitable.I acknowledge that Performance is CriticalIt depends on scale of enterprise. Again, it's not always profitable and should be considered.I will learn at the root, not the abstraction: JavaScript before jQueryI hope you know lambda calculus already.I am front end engineer too.
ciembor Disqus
03 Sep 2012

Well... I think you might add CSS to allowed HTML tags.
Wojtek Disqus
03 Sep 2012

@ciemborPerformance optimization is always critical and profitable. Everyone notices the boost in speed. Smaller latency is better conversion. Should be a priority even for the smallest projects.
Shirsendu Disqus
03 Sep 2012

Please upload a version on SlideShare. This needs to spread!
ciembor Disqus
04 Sep 2012

@WojtekSometimes, good architecture is much more important than efficiency. This is why people use Ruby on Rails over CGI in C or Backbone over pure functional JS. Sometimes it's more profitable to use libraries with needless code instead of writing code from zero.
ciembor Disqus
04 Sep 2012

I just noticed it can be even more rationalized!Assume that your time is as valuable as the time of users.delta_t - difference of the time of code usage before and after optimizationx - prognosed number of code usagesy - time spent on optimizing the codez - prognosed waste of time in future development processprofit = y + z / x * delta_dhttp://i.imgur.com/UmpOi.gif:)
ciembor Disqus
04 Sep 2012

Oh, should be:profit = x * delta_d / y + zof course
Kent Brewster Disqus
04 Sep 2012

I love this, and I think I understand where it's coming from. Question: how do you feel about supporting IE6?
Zach Leatherman Disqus
12 Sep 2012

@Matt: It sure would have. Your talk was, of course, brilliant.@Kent: Of course, I fall in the camp of Yahoo's graded browser support and have relegated it to C-grade.
Ruma Bhat Disqus
25 Oct 2012

I have got to say I really enjoy your site, the way you write is wonderful!
Black Hat SEO Disqus
20 Apr 2013

In practice, Google identify 'bad neighbourhoods' by devaluing back-links from the same IP subnet. In order to offset the fact that this text generally reads horribly it will often be placed at the bottom of a page and in a very small font size. In this age of computers, people are looking for information on the internet and they visit various websites where the particular piece of information they want is found.