So You’ve Learned HTML, CSS, and JavaScript; Now What? (Part 1)
As a former program manager and product designer for a popular front-end developer bootcamp in the heart of downtown San Francisco, I’m all too familiar with the sheer blinding peril bootcamp grads can feel after being dropped into the job market without an actionable plan for continued personal growth. Sometimes, this is an onus which falls on the bootcamp program, but most often, it’s one which falls squarely on the shoulders of the developer-to-be.
EDIT: The content of this series will be updated and fleshed out over time, so I’d encourage you to check back to a given piece which did not dive deeply enough into its topic on your first read.
The core competencies of becoming a web developer, building web apps, or designing and implementing beautiful and compelling websites, are being able to write and read HTML, CSS, and JavaScript. Of this, there is no question. But ticking off those boxes will leave you ill-equipped to find the rewarding job you’re looking for, and will leave you woefully in the dark in terms of the professional conversation and general discourse about the field and its developments.
In order to bridge the gap between knowing and being confident in the foundational languages of web development, and being a confident web developer, some very critical low-hanging fruit — some very actionable steps — need to be identified.
Learn how to evaluate web performance
As a web engineer, client-side performance is strictly your responsibility. If “client-side” is an unfamiliar term to you, then go ahead and look it up now. I’ll wait. That — what you just did there — is something you need to be prepared to do constantly from now on. Anytime you read anything and come across an unfamiliar term, you need to fill yourself in right then and there.
Client-side performance is critical, as a metric of your development skills after everything is said and done. After the beautiful new web app is built and error- and bug-free, the most important question is, “How does it perform?”
There is no shortage of quality tools for measuring web performance, but by far the easiest and most out-of-the-box ready is Google’s Lighthouse. Lighthouse tests are actually built into Google Chrome, and if you’re a front-end developer worth your salt, you’re developing with Google Chrome (if you’re not doing so, take the hint now and make the switch!).
To use Lighthouse, simply open your developer tools on the website or web app you wish to test, and click on the “Audits” tab, where you’ll be presented with a number of options for configuring an audit of your site, such as testing for desktop or mobile usage. I won’t go into what all of these parameters are for, you’re entirely capable of doing so yourself now that you’ve found them, but I’d suggest running a few audits on projects you’ve built to familiarize yourself with the info Lighthouse gives you. Your most important are going to be “Performance,” “Accessibility,” “Best Practices,” and “SEO.”
You’re going to see a lot of terminology you may have never come across before: “First Meaningul Paint”, “Time to Interactive”, “Estimated Input Latency”, etc. Some of these will make intuitive sense, some of them won’t, but all of theme are touchstones with which you should become very familiar in order to immediately advance your understanding and value-adding capability as a front-end dev.
Perhaps even more usefully, Lighthouse also presents you with “Opportunities,” suggested opportunities in your site or site architecture where there is room for improvement; even going so far as to isolate problematic image files, scripts, markup, plugins, or other bottlenecks as a result of your code. Dive deep into these opportunities, see how many you can effectively resolve or fix so they’re eliminated on the next audit of your site!
EDIT: For the Love of All That is Good, Optimize Your Images
The number one culprit affecting web performance among junior web developers and designers is the size of images and other assets. There are a few tools and rules of thumb out there to help, but all the helpful hints in the world won’t do any good unless you’re conscious of your image sizes and how this is impacting your site performance!
First, some terminology and rules to live by:
If you need an image that includes transparency, such as a transparent background, use a PNG file.
Images which incorporate a high degree of vibrant colors should be JPGs. PNGs in general tend to be more economical than JPGs; so, wherever possible, use PNGs instead of JPGs.
Small animations require GIF files. GIFs can easily bloat to enormous file sizes, so process with caution.
Do not use auto-playing videos unless absolutely necessary; make a GIF instead.
Avoid using image files for simple icons and logos; use SVGs, instead.
Try to resize image files down to the size at which they will be displayed.
When in doubt, use easy online tools like TinyPNG, JPEG-Optimizer, iLoveIMG (for GIFs), or SVGOMG to automagically optimize your asset files and reduce file size!
Finally, if you’re ready to deploy your sites, minify EVERYTHING. Even if you don’t get a lot of size-reduction out of it, it’s a good habit to have and to showcase to potential employers. Later on, we’ll talk about how to minify your code files automatically during build/deployment; but for now, there’s nothing stopping you from doing so yourself with this HTML minifier, this CSS minifier, and this JS minifier.
And stay tuned for more.
Evan is an illustrator, developer, designer, and animator who tells stories in any which way he can. When he’s not branding businesses or building front-end apps; he’s illustrating children’s books, painting for tabletop games, animating commercials, or developing passion projects of his own.
