Hello HN, Are there any treatments of the topic of web front-end software design? I'm looking for something similar to "Design Patterns" (http://en.wikipedia.org/wiki/Design_Patterns) but for web front-end HTML/CSS.<p>I've read Duckett's book (Amazon bestseller) and its just syntax. Also, I've read the Atomic CSS design and BEM methodologies, and while those come close to what I want, I'm looking for a more detailed treatment.
To give an obvious example of what I'm looking for- I would say, use margins to separate multiple instances of same components (among other uses). I wonder if there are books that deal with similar, but non-obvious topics.
Its not as rigid as software design patterns, and I think that's by design.<p>I'll try to share some tips - hopefully this is the kinda thing you're after - i recognize some of it might not be on topic.<p>* use html partials to reduce complexity<p>* think about cachability and rendering needs - sometimes a simple display feature can have huge ramifications on code required and complexity<p>* semantic markup is optional, but definetly helps break up a sea of divs, and is good for people who use screen readers<p>* decouple your HTML from your CSS - if something is to be blue or big, it should be from the CSS, not because it has a "big" or 'blue" class. (see: csszengarden.com)<p>* scss & co are really useful, but be careful to not go overboard.<p>* don't assume what fonts your users have - linux, mac, win all differ. if unsure, check all 3 platforms rendering<p>* load JS at the bottom of the page to prevent render blocking (vs. in the head)<p>* always test browser size reflow & zoom rendering<p>* always test css,html, js validations<p>* test design in grayscale/color blindness simulations<p>* be aware of browser compatibility and vendor prefixing needs - its not cookie cutter.<p>* flexbox is new on the block, but it's dreamy to work with and is great for layout (shoutout to flexboxin5.com for helping me)<p>* code comments, such as those that highlight return values, or why something is X, are hugely helpful<p>* check for unused CSS - there are a number of scripts/browser extensions/sites that can tell you what CSS is never used, and help you remove it.<p>* same for JS - make sure you still need / use it all<p>* html/css is rarely (for me) polished at first pass. Iteration is instrumental at arriving to clean, maintainable code.
Along the same line... Any good resources on building maintainable applications with user interfaces? It doesn't have to be web applications, it can be a book focused on building desktop or mobile applications. I'm more interested in the patterns the follow, as well as what and how they focus on testing.<p>I've found TDD pretty much impossible when you're building a user interface. Even when I test my components (recently using react, prior to that using angular), it's hard to know <i>what</i> I should be testing for. Testing the component's logic is a given, and usually very straightforward. But how in depth should my DOM structure validation be? Should I check that certain classes and IDs are set correctly and leave it at that? Should I verify the DOM structure of the component? I've found this extremely difficult because you'll often find yourself adding or removing classes to restyle components, or you'll find yourself rewriting the HTML to fit better with a redesign of some sort.<p>Along this same line, what about e2e tests? I test core user interactions (e.g. user can create foo) with e2e tests, and edge-cases with unit tests. These tests will be clicking around and sending keys to inputs and eventually reach some state that confirms that the action was successful. Among all the states that were traversed, how many things will you validate (e.g. check that the link the user clicks is in a list, check that in the final state he can view all of foo's information)? And how in depth? (e.g. checking that #foo contains all of foo's information, or checking that #foo contains .bar, .baz, .qux, and that each contains part of foo's information)<p>I've figured out some patterns and guidelines over time, but some of these tests tend to feel brittle or useless.
The most important idea is testing the user experience according to the following five "laws" of human-computer interaction:<p>1. Fitt's Law (of movement to a target area): <a href="https://en.wikipedia.org/wiki/Fitts%27s_law" rel="nofollow">https://en.wikipedia.org/wiki/Fitts%27s_law</a><p>2. Steering Law (of movement through a tunnel): <a href="https://en.wikipedia.org/wiki/Steering_law" rel="nofollow">https://en.wikipedia.org/wiki/Steering_law</a><p>3. Hick's Law (of choices and decision time): <a href="https://en.wikipedia.org/wiki/Hick%27s_law" rel="nofollow">https://en.wikipedia.org/wiki/Hick%27s_law</a><p>4. Miller's Law (of working memory): <a href="https://en.wikipedia.org/wiki/Miller%27s_law" rel="nofollow">https://en.wikipedia.org/wiki/Miller%27s_law</a><p>5. Power Law (of practice and reaction time): <a href="https://en.wikipedia.org/wiki/Power_law_of_practice" rel="nofollow">https://en.wikipedia.org/wiki/Power_law_of_practice</a>
This topic interests me as well, and I've written about many of these ideas in the past. They're not necessarily analogous to the GoF design patterns, but I think they're similar in spirit. I hope you find them helpful.<p>CSS Architecture
<a href="http://philipwalton.com/articles/css-architecture/" rel="nofollow">http://philipwalton.com/articles/css-architecture/</a><p>Side Effects in CSS
<a href="http://philipwalton.com/articles/side-effects-in-css/" rel="nofollow">http://philipwalton.com/articles/side-effects-in-css/</a><p>Decoupling Your HTML, CSS, and JavaScript
<a href="http://philipwalton.com/articles/decoupling-html-css-and-javascript/" rel="nofollow">http://philipwalton.com/articles/decoupling-html-css-and-jav...</a>
I strongly believe that in order to do good interaction work you really just need to understand typography well. That might not be a popular viewpoint around here, but I encourage you to consider some of these references.<p>I recommend Josef Muller-Brockmann's Grid Systems in Graphic Design: <a href="http://www.amazon.com/Grid-Systems-Graphic-Design-Communication/dp/3721201450" rel="nofollow">http://www.amazon.com/Grid-Systems-Graphic-Design-Communicat...</a> or Emil Ruder's Typographie: <a href="http://www.amazon.com/Typographie-Manual-Design-Emil-Ruder/dp/3721200438" rel="nofollow">http://www.amazon.com/Typographie-Manual-Design-Emil-Ruder/d...</a>.<p>There are many, many other good resources but those are important primary sources. So is The Elements of Typographic Style, by Robert Bringhurst: <a href="http://www.amazon.com/gp/product/0881792128/ref=pd_lpo_sbs_dp_ss_3?pf_rd_p=1944687762&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=3721200438&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=038MRVMFF37KXY94ER2F" rel="nofollow">http://www.amazon.com/gp/product/0881792128/ref=pd_lpo_sbs_d...</a>.
It looks like I'm first here. Check out Addy Osmani's book first
<a href="http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/" rel="nofollow">http://www.addyosmani.com/resources/essentialjsdesignpattern...</a>
You can always rely on Martin Fowler: <a href="http://martinfowler.com/eaaDev/uiArchs.html" rel="nofollow">http://martinfowler.com/eaaDev/uiArchs.html</a>
Not quite what you're after, but I went a short talk[1] on constraint's based GUI programming, with some examples from Adobe -- as best I can tell the examples were related to Adobe's "Adam and Eve": <a href="http://stlab.adobe.com/group__asl__overview.html" rel="nofollow">http://stlab.adobe.com/group__asl__overview.html</a><p>The talk focused on things like a (sane) way to model widget interactions in complex UIs, in a way that reduced the complexity by ignoring invalid combinations (stuff like height in pixels being updated, when height in percent is adjusted, without having a rats nests of event listeners across all widgets).<p>Other than that, I'm afraid I can't really think of anything other than the original MVC-stuff by Reenskaug, and his new DCI-stuff (search [1] for Reenskaug). Things have certainly evolved/changed, but generally it seems to be about splitting out layout, and handling events in a sane way.<p>[1] Jaakko Järvi, Texas A&M;: "Avoiding faulty user interfaces" <a href="http://bldl.ii.uib.no/2014/seminars-2014.html" rel="nofollow">http://bldl.ii.uib.no/2014/seminars-2014.html</a><p>Also (linked): <a href="http://bldl.ii.uib.no/2014/14v-bldl_hiday-JaakkoJarvi-avoiding_faulty_user_interfaces.pdf" rel="nofollow">http://bldl.ii.uib.no/2014/14v-bldl_hiday-JaakkoJarvi-avoidi...</a>
For CSS architecture I thought SMACSS [<a href="https://smacss.com/" rel="nofollow">https://smacss.com/</a>] by Jonathan Snook has really good design patterns that have been proven to be good throughout his many projects.
O'Reilly has a book called "Designing Interfaces: Patterns for Effective Interaction Design" by Jennifer Tidwell. It's a little out of date, but has a lot of the big ideas and useful bibliographies to dig in deeper.
There are definitely design patterns for frontend. There are just no books being published on this topic yet.<p>Most knowledge in this area is scattered is varies blog post, tech talks, and maybe some framework guides. There are a few published as GitHub gists and readme. Occasionally, you'll find some comments in framework source code that reference some reading material<p>But yes, it would be nice for someone to put together a book.<p>Some example of frontend pattern:
- promise
- data binding
- FRP event stream<p>None of these are exclusively frontend, but you'll see them more often in UI development.
I feel that most of the answers in this thread are wrong.<p>Design patterns, as the wikipedia says, is "a formal way of documenting a solution to a design problem in a particular field of expertise".<p>So, it's a solution for a specific problem.<p>The main issue with HTML/CSS is that people tend to think that there's a best approach than can work with every website. But different websites require different HTML/CSS architectures, because they offer different design problems! It's not the same to create a corporate website than an application website (just to name two different problems).<p>I'll use the layout as an example:<p>There are different ways to define the layout of a website (call it grid if you want). If I want to create a secondary column, there's the "explicit" way, where I specify that my div will take 1/3rds of the main layout with a ".col-md-4" class (like <a href="http://getbootstrap.com/css/#grid" rel="nofollow">http://getbootstrap.com/css/#grid</a> does). And there's the "semantic" way, where I create a div with the "sidebar" class, and my CSS will make the div to take 1/3rds (like <a href="http://neat.bourbon.io/" rel="nofollow">http://neat.bourbon.io/</a> does)<p>None of this two approaches is the best. Each one is a design pattern. And each one will be a better solution for a different problem.
Oh yes, there are definitely books that deal with this: I highly recommend "Don't Make Me Think" by Steve Krug. Quite an engaging, useful read, and it is well-reviewed on Amazon.<p><a href="http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758" rel="nofollow">http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/032134...</a>
a lot of the comments here seem misguided. he is asking about software design patterns, not graphic design patterns. the wikipedia article and BEM reference should have cleared that up.
I watched this old talk from the YUI Library recently. It's framework-agnostic and not heavy on code, just a lot of common sense that might not be obvious for some.<p>Nicholas Zakas: Scalable JavaScript Application Architecture
<a href="https://www.youtube.com/watch?v=vXjVFPosQHw" rel="nofollow">https://www.youtube.com/watch?v=vXjVFPosQHw</a>
There's "The Design of Sites", but it's not really about CSS.
<a href="http://www.amazon.com/The-Design-Sites-Principles-Customer-Centered/dp/020172149X" rel="nofollow">http://www.amazon.com/The-Design-Sites-Principles-Customer-C...</a>
I think it's worth mentioning Material design from Google: <a href="http://www.google.com/design/spec/material-design/introduction.html" rel="nofollow">http://www.google.com/design/spec/material-design/introducti...</a>
(I'm new to HN so not sure how to edit)
Thanks for some excellent answers.<p>So as to keep the discussion to the question's point for posterity, I think I wasn't very clear. As some people have poined out- I'm not looking for graphic design patterns, or design from the user experience perspective.
I'm looking for how to design my components. and what should classify as a component, or what should be an individual template. What should go as a parent and as a child in the component. Thanks again!