Alex Sexton gave a name to that big part of our life that we Front-End folks didn’t previously have a name for–Front-End Ops–the knowledge, techniques and practices we use to make faster Web sites and applications, monitor errors, and build and deploy our work.
But nearly two years on, and with developments like HTTP/2, what’s the state of Front-End Ops? Who better to tell us than the guy who came up with the name in the first place?
Quick recap: Alex’ article appears in Smashing Mag in 2013; FeOps conference in 2014; then people starting hiring roles called frontend ops… naturally naming front-end ops was the hardest part.
So what is front-end ops? Serving web pages is really hard. Front-End Ops is the collection of things you can do to make serving web pages easier.
It frees other devs from having to think about deployment stuff all the time. Developers split time between writing their app, and working on a great deal of other stuff which is not the app but still has to be done to get the app live.
FeOps also addresses the problem where it’s considered normal for frontend developers NOT to be monitoring their application in production. For backend devs that would be insane, so why is it normal for frontend? Particularly now that app logic is being pushed to the client via client-side MVVM/MVC/etc.
Backend programmers habitually automate stuff like error logging, lifecycle logging, application measurement over time (eg. is the app getting faster or slower?)
Performance is the basis of UX; speed is how we measure that. Everything can be measured and tracked, but it’s important to read that information correctly.
Tools not rules.
Make computers do the hard work. Use tools to evaluate things you are concerned about. There are testing tools for pretty much everything.
Step 1: forget everything you know because it’s wrong. All the stuff yslow taught you is wrong.
Step 2: it’s probably the network
Step 3: read Browser Networking by Ilya to fix that…
(missed the others)
Then http2 will come along so we’ll have to forget it all over again!
Use Chrome dev tools to simulate slow networks. “If you throttle everything to 3G all the time, you’ll do a pretty good job of fixing speed problems…”
Theoretical graphs (timelines):
Measure twice, optimise once!
Make a dashboard. Get this stuff visible and easy to read:
Speed of development = developer happiness.
Use component libraries.
How to make one:
Spare no expense in your tooling! Automate everything, cache everything!
Future considerations: http2 support, async loading, non-js dependencies, web components…
The ultimate idea here is to have machines take the load off the humans, so they can focus their energy on the people using the application rather than the application itself.
(refer to slides for the huge list of tools)
Q: are there any really good resources to learn the deep depths of Chrome Dev Tools.
A: follow talks from Addy Osmani and Paul Irish, they do a good job showing off the shiny stuff.