HTML5 Best Practices for Designers
HTML5 is sure to be a big hit this year as far as web design trends go, and rightfully so. It’s new, exciting, easy to understand and better than anything that has come before it. Up until recently, we have had to navigate a grey area in terms of compatibility and definition, and as a result, many of the early adoptions of HTML5 have been partial or complete disasters.
The first thing to understand is where HTML5 ends and CSS3 begins. HTML5 is just the markup – a set of standards that define how a document should be structured and how browsers should interpret it. Rather than shouldering all the responsibility for presentation and functionality, HTML5 gets back to basics, allowing us to tap into APIs and native browser functionality, while looking to CSS to create the visual look and feel. In the end we are left with a straight-forward and simplified language for creating websites and applications.
Learning as much as you can about HTML5 and following these basic practices will help you produce websites with high quality markup and improve your overall design and development process without running into the common pitfalls that have plagued the web for over a decade.
1. Use a Framework
As someone that designs visually and doesn’t have a huge arsenal of coding know-how, frameworks and "boilerplates" give you the opportunity to build a project using a consistently formatted code base that has been tested, validated and in most cases, developed by an industry leader. These pre-packaged starter templates do not prescribe a specific design philosophy or force you into one layout or another, they simply give you a valid HTML5 document and associated CSS3 stylesheet with all required JavaScript libraries already included.
Another option is to use an HTML5 design application to build valid websites without worrying about coding it yourself. Unfortunately there are only a few tools available such as Adobe’s Muse and Edge previews (which won’t be fully released for some time yet) and single-purpose web generators. To answer the call of front-end designers everywhere, Wix had launched the very first, full-featured HTML5 website building application on March 26th that allows you to create complete websites online. This tool can significantly change how you design, giving you a visual editor for creating and styling elements, using drag and drop for arranging layouts and adding widgets. You will also get access to a library of interactive canvas elements and animations, CSS3 effects and add-ins such as HTML5 audio, video, slideshows, forms and more. Visit the Wix website to learn more and sign up to be the first to explore this new technology.
The benefit of using a framework or HTML5 application is a more efficient workflow and consistent results. It is still important to understand the semantics, limitations and possibilities of HTML5, but as a front-end designer there is no shame in keeping your focus on what you do best.
Resources:
2. Understand the Doctype
If you choose to code your own document, or convert an existing site to HTML 5, it is extremely important to understand the dependencies and requirements of the HTML5 doctype. Simply changing the <!DOCTYPE> tag from <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> to <!DOCTYPE html>will not magically transform your markup, it will only allow the browser to detect the document as HTML5 and expect HTML5 markup. It also should not be confused with the opening <html> tag. Other element commonly found in the document head have changed as well, including character encoding,<script> and <link> elements. The core of a basic HTML5 document head should look like this:
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>...</title> <link rel="stylesheet" href="style.css"> </head>
Resources:
3. Use Elements Responsibly
Before diving into building a site with HTML5, ensure you understand what each new element is intended for and where it belongs in your layout. These are the primary elements introduced in HTML5 that should be used, almost exclusively, when building a layout:
<header>
Not to be confused with <head>, this element designates the header, or top part, of an element or layout and can be used independently or within other elements.
<hgroup>
Used inside the <header>, the <hgroup> designates a grouping of header tags to help preserve typographical hierarchy and allow the browser to prioritize them as a group rather than individually. For example, you may have an H2 element as a page heading, then use another H2 for post titles, followed by an H3 for the author. The second H2 and H3 should be wrapped in an <hgroup> within a <header>.
<nav>
This element indicates a navigation menu, and should encapsulate an unordered list in most cases. The <nav> element can be used independently or within other elements, such as <aside>. A group of links grouped together in your content isn’t enough reason to use the nav element. Site-wide navigation, or sub-navigation does belong in a nav element.
<section>
Used for grouping together thematically-related content. Sounds like a div element, but its not. The div has no semantic meaning. Before replacing all your div’s with section elements, always ask yourself, “Is all of the content related?”
<article>
This tag represents an independent piece of content , such as a blog post or news article. It is almost always placed inside a <section>, but it isn’t required..
<aside>
The <aside> is most easily compared to a sidebar or any area containing content that is not directly related to the <article> or primary content displayed on the page. How your site is structured will depend on how you use the <aside>, but common practice either uses it to contain an unordered list of secondary elements, or places it inside a <section>, using the <aside> to contain each "block" of content. However,just because some content appears to the left or right of the main content isn’t enough reason to use the <aside> element. Ask yourself if the content within the aside can be removed without reducing the meaning of the main content.
<footer>
Like the header, the <footer> is used to designate the foot or bottom part of an element or layout. It can be used independently, as seen in most web layouts for copyright information, or within other elements to designate "footer" content such as author, date, category and so on.
<figure> & <figcaption>
Not well understood and under-used, <figure> essentially replaces the need for a <div class="caption"> element used to wrap a video or image in a padded, styled box containing a description. Example:
<figure> <img src="pic.jpeg"> <figcaption> <p>This is a caption.</p> </figcaption> </figure>
All of these elements are styled in CSS as base classes, and only require an additional ID or class if used repeatedly within a document, or specific styles need to be applied to one element.
When used properly, HTML5 elements greatly reduce the need for DIVs and other unnecessary elements. To build the most efficient markup possible, avoid using the <div>as much as possible, and only fall back to it when no other element is appropriate. Remember that spans and tables are completely valid structural elements in HTML5 and that using them in favor of floating elements is preferred for mobile compatibility.
Here is an example of a basic HTML5 document structure:
<header> <h1>My Site</h1> <nav id="menu"> <ul> <li><a href="#" title="link1">Link1</a></li> <li><a href="#" title="link2">Link2</a></li> <li><a href="#" title="link3">Link3</a></li> </ul> </nav> </header> <div id="main"> <section id="content"> <article> <header class="post"> <hgroup> <h2>Title</h2> <h3>by Author</h3> </hgroup> </header> <p>Article content...</p> </article> </section> <aside> <ul> <li>...</li> <li>...</li> <li>...</li </ul> </aside> </div> <nav id="paged">...</nav> <footer>...</footer>
The CSS would look something like this:
header {...}
h1{...}
h2{...}
h3{...}
nav {...}
#menu {...}
#menu ul {...}
#menu ul li{...}
…and you get the idea. Not all CSS features are supported in all browsers with HTML5 yet, so it is important to get familiar with common issues and verify anything you’re not sure of before implementing it into your design.
Best practices from HTML4 can still be carried over into the HTML5 world when writing your markup. Even though HTML5 is more forgiving of case, quotes and tag closing, continue to:
- Use lower-case markup
- Close all tags
- Enclose attributes in quotes
- Use the "alt" attribute in the
<image>tag - Use the "title" attribute in
<a>links
Resources
- HTML5 Working Draft
- HTML5 Semantics by Bruce Lawson
- HTML5 for Web Designers by Jeremy Keith
- Figure and Figcaption
- HTML5 <article> and <section> explained
4. Plan for Backwards Compatibility
All current webkit browsers (such as Firefox, Chrome and Opera), mobile browsers and Internet Explorer 9 support most HTML5 features in the existing spec. HTML5 itself is designed to be as backwards compatible as possible, building upon existing features and allowing for graceful degradation. It is still a good idea to provide a measure of fallback support in the form of an HTML5 Shiv, which is a small JavaScript that helps older browsers interpret some of the newer rules and elements properly. The shiv is added to the document head, just after your stylesheet declaration.
In addition to the script, providing conditional statements for Internet Explorer is smart, as plenty of web users are still confined to these older browser versions. By separating special styles and fixes for IE versions, you can easily remove them later as the versions become obsolete.
Example:
<!--[if IE 7]> <link rel="stylesheet" href="css/ie-7.css" media="all"> <![endif]--> <!--[if lt IE 9]><script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
Unless you use a CSS reset, ensure you include a line in your stylesheet that applies a display:blockstyle to your HTML5 elements, like so:
header, hgroup,nav,section,article,aside,footer {display:block;}
Resources:
- DD_belated PNG script
- Modernizr
- Remy Sharp’s HTML5 Shiv
- CSS reset
- HTML5 Please helps you out with recommendations for polyfills and implementation so you can decide if and how to put each of these features to use.
- When Can I Use provides extensive browser compatibility and support information for CSS3, HTML5 and more.
5. Separate Content from Presentation
Whether you decide to use a framework or not, keep 99% of the design in your stylesheets. Essentially, without your stylesheet, the page should collapse into a completely unformatted mess when viewed in a browser. It sounds dire, but this separation is important to maintain ongoing development and ensure your code has the best chance of validating. It is significantly easier to maintain a site with markup written to be style-independent. For example, changing the color of a site that uses <font color=""> in the markup requires multiple tedious changes. By using CSS exclusively, these changes are reduced to one file with few instances.
HTML5 has none of the presentational attributes that were in HTML4 such as <frame> or <font> and has changed the way several tags are interpreted. Additionally, a number of tags have been removed completely from HTML5, so it is important to keep a reference of the differences. Here are a few things to avoid:
- Never use inline styles. Example
<div style="border: 1px"> - Use paragraphs
<p>instead of</br>to arrange content on new lines. - Avoid using
<em>and<strong>when styling text elements in the design and use a heading tag or class. Never use<i>and<b>which have been depreciated from HTML5. For theme developers, this can be applied to content created in editing tools by using Post Formats instead of relying on the legacy editing actions like B and I. - Use a paragraph class that contains ample padding to indent text and reserve the
<blockquote>tag for actual quotes.
Here is a full list of removed HTML4 elements:
| Tag | What it did |
| <acronym> | Defines an acronym. Removed because it creates confusion. Use abbr instead. |
| <applet> | Defined an applet. Use object instead. |
| <basefont> | Use CSS to define main body font. Use CSS to define font size. |
| <big> | Use CSS to set font size. |
| <center> | Use CSS to align text or elements. |
| <dir> | Defined a directory list. Use ul. |
| <font> | Use CSS classes |
| <frame> | Defined a frame. Damages usability and accessibility. |
| <frameset> | Defines a set of frames. Damages usability and accessibility. |
| <isindex> | Defines a single-line input field. Use HTML5 form controls instead. |
| <noframes> | Damages usability and accessibility. |
| <s> | Defines strikethrough text. Use CSS. |
| <strike> | Defines strikethrough text. Use CSS. |
| <tt> | Defines teletype text. Use CSS. |
| <u> | Defines underlined text. Use CSS. |
HTML5 has also removed, changed or depreciated over 50 attributes. The following attributes are allowed but it is best to use an alternative solution:
- border attribute on <img> is required to have the value "0" when present. This is another form of inline styling, so use CSS instead.
- language attribute on <script> is required to have the value "javascript" if used, and cannot conflict with the type attribute. It is best to just remove these attributes.
- name attribute on <a> should be changed to an id attribute instead.
- summary attribute on <table> is depreciated. The HTML5 draft defines several alternative solutions.
- width and height attributes on <img> and other elements are no longer allowed to contain percentages. It is best to use CSS here also.
These attributes have been removed and should not be used:
- rev and charset attributes on <link> and <a>.
- shape and coords attributes on <a>.
- longdesc attribute on <img> and <iframe>.
- target attribute on <link>.
- nohref attribute on <area>.
- profile attribute on <head>.
- version attribute on <html>.
- scheme attribute on <meta>.
- archive, classid, codebase, codetype, declare and standby attributes on <object>.
- valuetype and type attributes on <param>.
- axis and abbr attributes on <td> and <th>.
- scope attribute on <td>.
- summary attribute on <table>.
Here is as full list of depreciated HTML4 attributes. Replace them with CSS in HTML5:
| Attribute | Used with Tag |
| align | caption, iframe, img, input, object, legend, table, hr, div, h1, h2, h3, h4, h5, h6, p, col, colgroup, tbody, td, tfoot, th, thead and tr. |
| alink | body |
| link | body |
| vlink | body |
| text | body |
| background | body |
| bgcolor | table, tr, td, th and body. |
| border | table and object. |
| cellpadding | table |
| cellspacing | table |
| char | col, colgroup, tbody, td, tfoot, th, thead and tr. |
| charoff | col, colgroup, tbody, td, tfoot, th, thead and tr. |
| clear | br |
| compact | dl, menu, ol and ul. |
| frame | table |
| compact | dl, menu, ol and ul. |
| frame | table |
| frameborder | iframe |
| hspace | img and object. |
| vspace | img and object. |
| marginheight | iframe |
| marginwidth | iframe |
| noshade | hr |
| nowrap | td and th |
| rules | table |
| scrolling | iframe |
| size | hr |
| type | li, ol and ul. |
| valign | col, colgroup, tbody, td, tfoot, th, thead and tr |
| width | hr, table, td, th, col, colgroup and pre. |
Resources:
To learn more about why changes were made, and which strategies work best for getting the same effect with HTML5, visit the official HTML5 draft on Non-Conforming Features.
6. Design for Accessibility
While it is possible to use presentational markup in a way that provides users of assistive technologies (ATs) with a good user experience, doing so is significantly more difficult than simply using semantic markup.
The WAI ARIA specification defines a set of specialised “landmark” roles that can be combined with HTML elements to help assistive technologies provide users with features they can use to identify and navigate between sections of page content more easily. To implement roles, you simply add the role attribute and the element’s appropriate value.
Here is a list of common elements used with HTML5 web design and the corresponding roles:
| Language feature | Recommended role value | Restrictions |
a | link | Role must be either link, button, checkbox, menuitem, menuitemcheckbox, menuitemradio, tab, or treeitem |
address | No role | If specified, role must be contentinfo |
article | article | Role must be either article, document, application, or main |
aside | note | Role must be either note, complementary, or search |
audio | No role | If specified, role must be application |
button | button | Role must be either button, link, menuitem, menuitemcheckbox, menuitemradio, radio |
details | group | Role must be a role that supports aria-expanded |
embed | No role | If specified, role must be either application, document, or img |
footer | No role | If specified, role must be contentinfo |
h1-h6 element that isn’t inside hgroup | heading role, with the aria-level property set to the element’s outline depth | Role must be either heading or tab |
header element | No role | If specified, role must be banner |
iframe element | No role | If specified, role must be either application, document, or img |
img element whose alt attribute’s value is present and not empty | img role | No restrictions |
li element whose parent is an ol or ul element | listitem role | Role must be either listitem, menuitemcheckbox, menuitemradio, option, tab, or treeitem |
object element | No role | If specified, role must be either application, document, or img |
ol element | list role | Role must be either directory, list, listbox, menu, menubar, tablist, toolbar, tree |
output element | status role | No restrictions |
section element | region role | Role must be either alert, alertdialog, application, contentinfo, dialog, document, log, main, marquee, region, search, or status |
ul element | list role | Role must be either directory, list, listbox, menu, menubar, tablist, toolbar, tree |
video element | No role | If specified, role must be application |
| body element | document role | Role must be either document or application |
Resources:
7. Use CSS in Place of JavaScript and Sprites
One of the primary aims of HTML5 is to provide native browser support for components, effects and techniques that have been achieved through JavaScript. With the introduction of CSS3, much of the day-to-day tricks in standard web design can now be created without JavaScript at all. This tip from HTML5 expert Paul Irish explains how to blend CSS3 transitions with HTML5: "CSS Transitions give you an attractive visual transition between two states. Most style properties can be transitioned, like manipulating the text-shadow, position, background or color. You can use transitions into pseudo-selector states like :hover or from HTML5 forms, :invalid and :valid (example with form validation states). But they’re much more powerful and can be triggered when you add any class to an element."
Here is how transitions look in CSS3:
div.box {
left: 40px;
-webkit-transition: all 0.3s ease-out;
-moz-transition: all 0.3s ease-out;
-o-transition: all 0.3s ease-out;
transition: all 0.3s ease-out;
}
div.box.totheleft { left: 0px; }
div.box.totheright { left: 80px; }
By adding the toggling the classes of totheleft and totheright, you can move the box around. Compare this amount of code with that of a JavaScript animation library. There is also an added performance increase in terms of how the animation rendering in the browser affects your hardware’s graphic processing capabilities.
HTML5 also gives us extended power over the draggable attribute.
This attribute can be added to any element, and when combined with CSS, allows us to create native drag and drop functionality without depending on JavaScript plugins or APIs.
CSS3 brings a new way of creating visual information for the web that can replace a large percentage of elements used in design including buttons, sprites, vectors and virtually any interface element. Here are a few of the things you can do with CSS3 in HTML5 that you needed JavaScript or plugins for in the past:
- Linear and radial gradients
- Border-radius for rounded corners
- Box-shadow for drop shadows and glow
- RGBA for alpha opacity
- Transforms for rotation
- CSS masks
Resources:
- Drag and Drop overview
- CSS3 Transitions
- CSS3 for Better Performance
- A Look at Some of the New Selectors Introduced in CSS3
- Sliding Navigation without JavaScript
- Futurebox, Lightbox Without the JavaScript
- Create a Fancy Image Gallery with CSS3
8. Provide Fallbacks for Multimedia
The <audio>,<video> and <canvas> tags were some of the first HTML5 elements to become wildly popular, mainly due to the increasing need for mobile-friendly media to replace Flash and other content. Even though these elements simplfy the process of embedding media, they depend on the browser’s native ability to playback the content since there is no plugin such as Flash or Java being invoked. Each browser (currently) has it’s own limitations on what kind of media it can handle and how. Thankfully, HTML5 allows for fallbacks with these elements through the <source> tag.
Opera’s Bruce Lawson explains,"In this example, Opera, Firefox and Chrome will download the Ogg version of Master Bieber’s latest toe-tappin’ masterpiece, while Safari and IE will grab the MP3 version. Chrome can play both Ogg and MP3, but browsers will download the first source file that they understand.
The fallback content between the opening and closing tags is a link to download the content to the desktop and play it via a separate media player, and it is only shown in browsers that can’t play native multimedia:"
<audio controls> <source src=bieber.ogg type=audio/ogg> <source src=bieber.mp3 type=audio/mp3> <!-- fallback content: --> <a href=bieber.ogg>Ogg</a> <a href=bieber.mp3>MP3</a> </audio>
The same concept should be applied to the <video> element as well so that users of older browsers such as IE7 will see a YouTube video, while those using the newest Opera, Firefox or Chrome will get the native player and content streamed directly from the website:
<video controls> <source src=video.webm type=video/webm> <source src=video.mp4 type=video/mp4> <!-- fallback content: --> <iframe width="480" height="360" src="http://www.youtube.com/embed/xzMUyqmaqcw?rel=0" frameborder="0" allowfullscreen> </iframe> </video>
Resources
9. Simplfy Your Forms
Extensive and wll-written resources already exist which document the elements and attributes new to forms in HTML5, so there is no reason to repeat them here. The essential part of HTML5 forms is, again, their ability to use native browser functionality for processing and validation, rather than depending on scripts or plugins. HTML5 also streamlines the way forms can be coded, removing the need for a closing slash on input fields, and adding semantic attributes to help form fields make more sense to the browser. At a minimum, an HTML5 form should follow these rules:
- Enclose all label names with the <label> tag.
- Use the new
emailandurlinput types to define these common fields. - Use the
placeholderattribute to provide input hints. - Use the
requiredattribute to request validation. - Drop the
nameattribute in favor of anidwhere needed.
<form method="post" action="index.php"> <form method="post" action="index.php"> <label>Name:</label> <input id="name" autofocus placeholder="Your name here"> <label>Email:</label> <input id="emailaddy" type="email" placeholder="Your email here" required> <label>Message:</label> <textarea id="message" placeholder="Your comments here"></textarea> <input id="submit" type="submit" value="Submit"> </form>
Here is a quick overview of what is new to forms in HTML5:
New form attributes:
- autocomplete
- novalidate
New input attributes:
- autocomplete
- autofocus
- form
- form overrides (formaction, formenctype, formmethod, formnovalidate, formtarget)
- height and width
- list
- min, max and step
- multiple
- pattern (regexp)
- placeholder
- required
Resources
- HTML5Rocks on HTML5 Forms
- W3C Spec HTML5 Forms
- nettuts+ HTML Forms Best Practices provides a general overview of form elements and proper use in design. This article is not specific to HTML5 so keep the changes in mind.
10. Design for Performance
87% of Planet Earth has a mobile phone, and more than 60% use it to browse the web. If you’re not creating a mobile website, you need to consider the load time and compatibility of your site with the rendering and processing capabilities of a mobile device.
The first step to better performance is to minimize and combine your code into as few files as you can. Since this process makes it absolutely maddening to do updates later on, always keep an "unminizmied" copy of your site and combine things down as the last step before publication. Minimizing includes the combining of all stylesheets and Javascripts into one file, or the removal of unneeded characters and spaces.
In the case of JavaScript in particular, optimizing the files and load order will gain the best results, since browsers can’t do anything while JavaScript is being downloaded. All scripts should be loaded from the footer of the document rather than the traditional place in the head under your stylesheets, with the exception of the HTML5 Shiv. You should also avoid linking to external scripts, even though it has become common practice to do this with Google libraries, for example.
This strategy isn’t always possible with all scripts, depending on their compatibility with one another, but the more you can get loading last and fast, the better.
Resources:
- Procssor – Combine, prettify or minify your stylesheets
- JSCompress – minify JavaScripts
- Smashing Magazine on Website Performance
- Web Performance Best Practices from Google
Validation
While I’ve mentioned valid code once or twice, it is the least important of all these practices. A lot of designers misinterpret validation as a judgement of good work versus bad. On the contrary, code that validates doesn’t mean it is good, and code that doesn’t might be amazing in terms of cutting-edge structure and use of HTML5 semantics. The fact is, most perfectly coded HTML5 websites won’t validate because 100% of the spec is not implemnted across the board yet.
Validation is still a good practice simply because it can point out errors or possible problems you need to correct or accommodate. Validate frequently to save yourself from support disasters or poor feedback in the future.
Conclusion
Hopefully you’ve learned a thing or two and feel more comfortable with using HTML5. Still feel like going back to the comfort of Fireworks? Don’t forget to check out the new Wix application to see what it can do to jump-start your next website project.
Nice tutorial, I think Backwards Compatibility is one of the most important things to think about when using HTML5. You have to remember to use the HTML5shiv script or IE8 and lower won’t see any styles on your new HTML5 tags. It’s also to remember when using new form features, such as new input types, validation some browsers still don’t support this.
I found this website really useful to use on backward compatibility http://caniuse.com/.
What exactly does the javascript file does for IE? I keep seeing it pop up in HTML5 tutorials, but I’m confused about what it would solve as far as canvas, web workers, sockets, etc.
Hi Nitesh!
Mainly the shiv allows older browsers to interpret styling of HTML5 elements. Each browser has a set of intepreters and algorithms for rendering different elements. For example, IE deals with the CSS box model differently than webkit browsers, which is why it is such a pain in the ass for a lot of people. The shiv adds new HTML5 elements (which is simple code), but also supports printing HTML5 elements and includes the default styles for HTML5 elements, like block on article and section. Basically it adds the support for HTML5 and some CSS3 styling that these browsers are missing inherently, and that has since been added to IE10, for example. Hope that helps!
Thank you for this article!
this is a good start.. thanks tut!
Really awesome…
Very useful information. Appreciate it
In “9. Simplify your forms”, I believe you have an extra tag, unclosed. Nice article.
A bit old article to be commenting on maybe, but I just wanted to get up to date with HTML5 (which I did). Unfortunatley, I followed your advice of “dropping the name attribute” on input tags thinking that the ID attribute would replace it. Well, maybe when referencing it in javascript, but certainly not when posting the form for server-side processing.
Is this really a part of the HTML5 spec (I know it’s not done yet), and if so, am I missing something. Reading on W3C, it states “For each form control you want submitted, you then have to give a name that will be used to refer to the data in the submission.”.
I can see that omitting the name attribute is not a problem when only using ajax calls and fetching all the values by referencing an ID, but I would not recommend skipping it anywhere. Or do you have a good reason for doing this? I doesn’t work in chrome when posting to a php-script at least. The $_POST is just empty.
A very smart approach to explain the things, I like your step by step tutorial,
I’m not trying to be too negative here. Best practices are frameworks and JS libraries ?
Designers/front-end designers/developers should use tools like “instant-drag/drop”, “themes”, and “templates” ? These are best practices because they’re easy ? More maintainable ?
I’m sure knowing your own markup, style, and scripts and what they are all doing, and why, is much more valuable a lesson, a practice, and professional than “oh, yeah I design using wix” ?
I think this tutorial is great, except for the first section (1. Use a Framework) .
Learn to write CSS and HTML. Understand how to use them, and incorporate design and functionality. Don’t lose sight of user experience, and simplicity. Then you may have a project that calls for a framework or code library, or at least be able to know if you need or want to use one. As opposed to diving into frameworks immediately for any project. That’s total crap, and not a best practice! The rest of the article is rock solid!