Better Practices (7 Part Series)
Consistently indent, nest, include braces, quotes, and new lines so that code is clear and can be read easily. New code added should never deviate from existing formatting conventions or change the indent levels.
Use of whitespace, comments, and descriptive variable names as appropriate for writing easy-to-read code.
There is no need to write code in an obfuscated or compressed way for the purpose of filesize savings.
Use automated server-side or other build processes to optimize files.
This includes concatenating files, code minification, and gzipping.
The ability for other developers to read the code is paramount above other concerns, especially if optimization can be handled another way.
Use the right tool for the right job.
Un-minified libraries and third-party scripts should be leveraged in local development environments for easier debugging if available. The code should be committed to source control in an unmodified state, or simply referenced in dependency management components that resolve the files in a build. The final products will be compressed with the rest of the source for delivery.
Likewise, third-party code and libraries should never be modified and their original source and the license must be documented and be appropriate for a project. Any changes to third party code must be agreed upon and must be for specific reasons. If changes are mandated by bug fixes then the appropriate upstream project should have the changes submitted (assuming the code is part of an open source repository).
Library code should be treated as an external dependency and should be considered something that may need to be wholesale updated or replaced at a later time.
Inclusion of any third-party code should be carefully considered and verified as the appropriate solution to a given problem. Adding another plug-in is not always the best solution.
HyperText Markup Language, commonly referred to as HTML, is the standard markup language used to create web pages. Web browsers can read HTML files and render them into visible or audible web pages. HTML describes the structure of a website semantically along with cues for presentation, making it a markup language, rather than a programming language. — Wikipedia
Semantic elements are elements with tags that clearly define the content included for both the developer and the web browser. Basic HTML includes tags such as <b> to represent bold and <i> to represent italics. In HTML 4.01, <strong> represents strong (generally bold) and <em> emphasis (representing italics) were introduced. HTML5, the most current version of HTML, introduced support for semantic elements; an example of which are <header> and <nav> for which the meaning becomes immediately clear.
Thanks to Natalie de Weerd for correcting the history above.
These elements are more commonly used by developers today and improve the automated processing of documents; All mainstream browsers such as Google Chrome, Mozilla Firefox, and Apple Safari support HTML5 and semantic elements.
Using both ID and Class names are practical and relevant HTML practices to define an element. In HTML, the class attribute is used to define the specific styling of an element. Class attributes can be reused between multiple elements, allowing for elements to carry identical modifiers.
An ID tag is used to define a specific variable and can be used alongside a class attribute. IDs are assigned to only one specific element and should never be reused. This allows for specific customization to the element using the ID tag without affecting others inside the same class.
Cascading Style Sheet (CSS), is behind almost everything seen when a website is visited. While HTML is responsible for the content a website possesses, CSS is what visually stylizes the content and website.
All web browsers add their own styling by default, and each web browser applies these styles in their own unique way. For example, many browsers make links blue and visited links purple by default. Others may give tables a certain amount of border and padding. Utilizing a CSS Reset is a great practice to reset all styles to begin styling from the ground up.
A CSS Reset, or Reset CSS, is a short and often compressed (minified) set of CSS rules that resets the styling of all HTML elements to a consistent baseline. Using a CSS Reset will allow every browser to have all its styles reset to null. This helps avoid cross-browser variation.
The structure of the CSS file should remain consistent with the structure of an HTML file. This can benefit both the developer and those who may have to make adjustments to the code in the future. If the CSS code is all over the place and does not follow the same pattern and flow as the HTML document, it will likely take a lot of time and effort to make sense of the two before changes can be made.
Typically, CSS is written in a separate CSS file with the .css file extension. Inline styles are CSS sheets included within the HTML document itself. This practice should almost always be avoided when writing HTML and CSS code.
While most web developers refrain from using inline styles, there are some exceptions to when they should be used. Some examples of that would be:
- HTML Email
- Generating a Performance Baseline
- Content Management System Content (WordPress, Drupal, etc.)
- Older Websites
The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents. The nodes of every document are organized in a tree structure, called the DOM tree. Objects in the DOM tree may be addressed and manipulated by using methods on the objects. The public interface of a DOM is specified in its application programming interface (API). — Wikipedia
A front-end developer crafts HTML, CSS, and JS that typically runs on a web platform delivered from one of the following operating systems (OS):
- OS X
- Ubuntu (or some flavor of Linux)
- Windows Phone
These operating systems typically run on one or more of the following devices:
- Desktop computer
- Laptop / netbook computer
- Mobile phone
- Things (i.e., anything you can imagine, car, refrigerator, lights, thermostat, etc.)
Generally speaking, front-end technologies can run on the aforementioned operating systems and devices using the following run time web platform scenarios:
- A web browser (examples: Chrome, IE, Safari, Firefox).
- A headless browser.
- A WebView/browser tab (think iframe) embedded within a native application as a runtime with bridge to native APIs. WebView applications typically contain a UI constructed from web technologies. (i.e., HTML, CSS, and JS). (examples: Apache Cordova, NW.js, Electron)
- A native application built from web tech that is interpreted at runtime with a bridge to native APIs. The UI will make use of native UI parts (e.g., iOS native controls) not web technologies. (examples: NativeScript, React Native)
The days of designing for strictly desktop screens have passed. Mobile web browsing has surpassed browsing on a traditional computer. The most efficient way to deal with this change is to design a site that can adapt to the size of the viewport. This is where responsive web design comes in.
The best responsive websites utilize fluid grids, flexible images and specific CSS styling techniques to alter design of the website and render it according to the width of the browser. The developer must be sure to test the website on all browsers, not just a favorite or the most commonly used ones. Some browsers interpret CSS in different ways and require their own CSS properties to achieve a specific style.
There is nothing wrong with becoming a master of a specific library or framework. It is important to not exclusively rely on them. All libraries and frameworks are built on the native languages themselves and get updated and phased out constantly. With a solid understanding of the native languages, a developer can keep learning, which will ensure the work will stay up to date.
The time it takes for a website to load matters. While page speed is usually not an issue with smaller websites, more robust and dense sites can and will take longer to load. It is true that in some cases, there will be factors that will unavoidably impacting page speed. However, there are a few better practices that should always be taken into account to ensure a website is as size efficient as possible.
The image sizes actually needed are certainly something to be aware of. A large image is going to take a long time to load and will use a significant amount of bandwidth. If there are a lot of large images on a site, extra time is added for every image.
The file format is important, as well. Browsers can load JPG, PNG, and GIF images nice and quickly. But, heavy formats such as TIFF or BMP are going to increase load time.
Avoid using images to display text, whenever possible. Again, images take up more room than text, even if the text needs a heavy amount of styling.
A front-end developer is typically only a single player on a team that designs and develops web sites, web applications, or native applications running from web technologies.
A bare bones development team for building professional web sites or software application for the web platform will typically, minimally, contain the following roles.
- UX / UI Designer (User Experience / User Interface)
- Front-End Developer (Client Side)
- Back-End Developer (Server Side)
It is assumed that the team mentioned above is being directed by a project lead and/or some kind of product owner (i.e., stakeholder, project manager, project lead, etc.)
A larger web team might include the following roles not shown above:
- DevOps Engineers
- Database Administrators
- QA Engineers / Testers