The following is a walkthrough of everything I learned about front-end development while making the Perfecting Product website from scratch.
I am not a developer by trade, so while I've learned a number of things about software development from working with SaaS companies on marketing and product and have even directly managed software developers as a product manager, this is my first experience building a website completely from scratch.
Everything you read from here on out is what I learned and experienced in the order it actually happened.
Software development is hard because software's hidden complexities constantly tempt you to change scope
One of the key challenges in building software is staying organized while you build something complex. That requires abstract thinking. You need to follow a clear process and structure or else you'll get bogged down by details.
Sometimes I would find the answers to what I was searching for online and other times I wouldn't. I can't say my comfort level with writing website code really improved until I got annoyed enough by failing to force me to replace it.
Building the website from scratch was more than cumbersome; it was exhausting.
I realized I was using all my mental energy on organizing what I was doing and using very little of it to actually perform the tasks I was trying to accomplish.
Once I had admitted this realization to myself, the answer was clear: I needed to improve my development process.
First, I started my development process by writing my website's code in Atom.
This was a good first step.
Not using a code editor wastes energy on writing correct code syntax instead of correct code logic
While it'd technically be possible to develop code for websites using a plain text editor or using other writing tools not specifically designed towards writing code, using a code editor is incredibly useful.
Just like when you're learning a new spoken language, one of the biggest difficulties learning a new coding language is learning how and when to use the correct grammar and syntax.
Code editors directly help you write better code by highlighting mistakes and subtle changes in syntax and perform this task for many coding languages.
Notice in the image above how the colors of text in the editor represent different types of code.
In HMTL, red text represents different types of HMTL content, orange text represents property names, green text represents property values, and grey text represents plain text content.
Good development tools save developers from exerting excess mental effort, not necessarily time
At the beginning of development, I had no specific process to speak of.
I knew the syntax required to get words onto a page. I could define basic attributes using CSS and write the basic building blocks of code using HTML. But at the moment, I had no way of previewing my code except for opening it as an external file in my browser.
I quickly learned that worrying about bracket syntax and needing to use a browser to check my code on every change sucks.
I was focusing on writing the correct HTML and CSS syntax instead of creating the elements I wanted on a page or deciding how they should look.
My initial website development process was severely lacking and was obviously improved upon by installing and using the infamous Emmet package.
Installing Emmet let me do two things that immediately made me more productive:
- I could now instantly create HTML files without having to write, copy, or paste basic HTML code required to define the page. [insert image of gif]
- I could now stop worrying about basic bracket syntax because Emmet would auto close brackets for me. [insert gif]
This was a great improvement to my workflow, but I still had a problem. Now I could write code a lot faster, but I still couldn't see results quickly.
So I installed an Atom package simply named Atom HTML Preview that let me do exactly that.
Thanks to this package I could now instantly see changes I made to my website's code by simply pressing Control + Shift + H while inside any HTML file.
The difficulty involved in solving software's abstract problems demands you give yourself fast feedback loops to keep making progress
Having a live preview of my code was an instant game-changer because I no longer needed to switch to viewing code in the browser or fatigue myself using unnecessary steps. Now I could just write code. WYSIWYG FTW.
Some caveats to using Emmet I still haven't figured out:
How to Save HTML Page Defaults
Right now I can initiate new HTML pages through Emmet by pressing tab after typing "!".
This initiates the HTML file with a default set of code that allows me to begin coding right away.
But ideally, I'd want to create a default HTML page template for every website project that includes my website's default stylesheet connections, google analytics tracking code, nav bar and footer, connections to image resources such as favicons, and maybe additional resources I'd like every page to load such as jQuery for running simple scripts.
This leads me to a question I have yet to fully answer:
How interconnected do I want my website's resources to be?
I know many developers say you need to strike a balance with using global variables. Use too few and you do too much duplicative work. Use too many and you break your dependencies on change.
This is one of the major challenges of developing software. Information architecture and how data connects from one source to another is a big deal.
My first annoyance with information architecture while building this website happened super early. I had built only two webpages with almost zero text, but I was getting annoyed copying and pasting custom CSS properties from one HTML file to another. I needed to build and link a universal style guide so I could write content and make it look exactly as I like and then have that look apply everywhere else I wanted to see it.
With my newly installed Emmet, live previews, and auto-closing brackets, I could actually write code and see its effect site-wide.
HTML first implements a website's style, then its content, then its functionality. You can do mostly the same in your development process
I quickly realized that I wanted some content to have a standard look, but I wanted other content to have a distinct look.
This was the case for my tagline:
"What would business look like if people loved your product?"
I wanted this text to be written in what's normally my header font size and weight, but I didn't want it to have the normal spacing around it.
I wanted the text to appear precisely in the middle of the screen, like the text that appears in a slideshow.
This required creating an id element and defining its properties in my style guide:
Next, I wanted to place a particular emphasis on the word "love" within the tagline. So I used a bright yellow highlight color as a background element behind the text itself and then manually positioned the image so that it would be in the right place: strategically asymmetrical to the text, bringing just the right focus and attention, while not seeming cheap or heavy-handed.
To place even more emphasis on my key tagline, I wanted the website to not show the site’s navigation menu until users got a chance to read it. So I found some jQuery code that allowed me to delay object visibility until after a preset amount of time after the page had fully loaded.
Next, I ran into an issue with nesting. Sometimes doing something seems so simple, yet a small misconception can cause serious challenges. One thing I was set on doing was making the website open-source and its codebase easy to see.
My solution for this was simple: host the website using GitHub Pages and place a footer at the bottom of every page with the link to my site's repository on Github where users could copy the site's template or even potentially contribute to it.
Easy enough, right?
Well, for whatever reason, I struggled with the simple task of centering my footer link on the page. Sometimes the footer would be centered at a different width than the rest of the page; sometimes it wouldn't be centered at all.
I soon discovered the cause of my problem easily enough. I had two simple issues I overlooked.
- Understanding the prioritization of nesting and combining class and element ids with CSS.
- Making sure GitHub pages is using the updated files by committing your code
While I saved my CSS code locally on my computer, I hadn't committed that code to the master branch, so my live website wasn't using the updated CSS.
That concludes what I learned from developing Perfecting Product’s website from scratch.
If there's something you think I’ve missed or remaining questions you have about front-end web development, reach out and I’ll consider writing about it.