Ask HN: Front-end “design patterns”?

[blawa]

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.

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.

[meesterdude]

Its not as rigid as software design patterns, and I think that's by design.

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.

* use html partials to reduce complexity

* think about cachability and rendering needs - sometimes a simple display feature can have huge ramifications on code required and complexity

* semantic markup is optional, but definetly helps break up a sea of divs, and is good for people who use screen readers

* 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)

* scss & co are really useful, but be careful to not go overboard.

* don't assume what fonts your users have - linux, mac, win all differ. if unsure, check all 3 platforms rendering

* load JS at the bottom of the page to prevent render blocking (vs. in the head)

* always test browser size reflow & zoom rendering

* always test css,html, js validations

* test design in grayscale/color blindness simulations

* be aware of browser compatibility and vendor prefixing needs - its not cookie cutter.

* 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)

* code comments, such as those that highlight return values, or why something is X, are hugely helpful

* 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.

* same for JS - make sure you still need / use it all

* html/css is rarely (for me) polished at first pass. Iteration is instrumental at arriving to clean, maintainable code.

[coldtea]

>semantic markup is optional, but definetly helps break up a sea of divs, and is good for people who use screen readers

Amen for the "optional" part.

Designers who don't really understand programming, reusability etc had this fad in the mid-2000s were they made "semanticness" some kind of holy grail, as if an html pages were meant to be data abstraction/interchange formats.

[blawa]

These are good tips, thanks!

[TheAceOfHearts]

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.

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 what 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.

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)

I've figured out some patterns and guidelines over time, but some of these tests tend to feel brittle or useless.

[jdlshore]

I have a screencast on developing a front-end JavaScript app that covers this topic. [1] The short answer is that you approach it in the same way you approach other TDD challenges: think about the code you want to write, then write a test that fails until that code has been written, then improve it, then repeat. A good test will talk more about the observable behavior of the unit rather than the way it's implemented.

So if your production JavaScript code sets a class based on some piece of business logic, your test checks that it sets that class in that situation. That may mean doing some DOM element creation in your test setup.

Testing HTML and CSS is a bit trickier. I'm developing a tool called Quixote [2] that enables TDD of this sort of code. It lets you do things like say "the login button needs to be 20px to the right of the nav bar." Same deal: you think about what you want your CSS to do, write the test, then write the CSS, then improve it.

Regardless, these are unit tests (or unit-like tests; I don't want to argue semantics), not end-to-end tests. Each one is focused on testing a specific thing, stay inside the browser process, and you use them to drive development. The key is to use good tools; I like Karma [3] because it allows me to run my tests against multiple browsers simultaneously, including mobile devices.

And, with apologies to @Anchor, you should absolutely test using real browsers. There are meaningful differences between browsers and you want your tests to catch those differences. Speed is not a problem if you use good test design and tooling; my Quixote tests use Karma, run against ten browsers, and execute 200 tests / sec.

[1] http://www.letscodejavascript.com

[2] https://github.com/jamesshore/quixote

[3] http://karma-runner.github.io/0.12/index.html

[zachrose]

Forgive me for being vague and brief, but I've been trying to test my UIs for the last year or so and this is what I've come up with.

I've found the ideas in Gary Bernhardt's talk, Boundaries (1), to be very helpful in figuring out how to test interactive web UIs. The basic idea is that DOM manipulation can be an "imperative shell" with as little logic and as few conditionals as possible. Derive the state of your UI component with separate functions and methods that return plain values (a "functional core"), and write tests for those because testing for values is easy.

So no, don't test for the presence of classes and IDs. Test your imperative shell once, maybe even manually or with an integration test, and that's probably enough.

Angular and React both encourage something like this approach, but you don't need those technologies to do it this way. In Backbone, for instance, just try to avoid conditionals and logic in your templates and render methods. If you think your UI piece needs to render with conditionals because it can be in different states, ask yourself if those states are just appearances that can be programmed declaratively with classes and CSS.

Also, testing is so much easier when you limit API surface areas. So if you're using a library like Backbone, where models and views both have many methods with many ways they can be called and used, don't give them direct references to each other. I've had some success in having models and views communicate only with a global event bus, which means my objects don't even know about each other. This makes them easier to specify, which makes them easier to test, which usually results in more focused interfaces and responsibilities.

(1) https://www.youtube.com/watch?v=yTkzNHF6rMs

[Anchor]

Here is a good introduction to structuring applications https://www.youtube.com/watch?v=HhNIttd87xs The talk is given by Robert C. Martin (Uncle Bob) and, quite naturally, also touches the issue of testing.

Much of this comes down to decoupling different aspects of the system: persistence (DB), domain logic (business rules), delivery mechanism (web, REST), presentation format, UI layout, etc. This aggressive decoupling enables one to isolate and test these different facets of the system individually. Of course, building this decoupling requires some effort, and one has to be careful not to over-engineer. As with many things, it is a balancing act.

And yes, you can do TDD with the UI; separate the UI logic (user actions, UI state, input validation, etc.) from the layout system (and don't try to test the latter automatically). The fun thing is that when the system is decoupled, you can test the user interface of a JavaScript web application without ever starting a real* browser, running a web server or spinning up a database. It is an interesting system design challenge to be able to run even your UI tests at a rate of 100 tests/second.

*A headless browser is not a real browser in this sense

[daniel_puterman]

Full disclosure - I'm part of Applitools' core team. Since the service we provide is visual testing, we work with a lot of web development teams and automation teams. I've encountered different levels of unit tests and e2e tests and I can't say there's a single methodology to "rule them all". Some test only specific pages, some browse the entire website, some load specific components to a separate page for unit testing, and some don't. Some have their R&D team provide "id" to each element (which is set "forever") so the automation team has a very easy time locating elements, and some have to "make do". So on that matter, I think you should go with whatever gives you the best ROI.

The questions "which elements to check?" and "how many things to validate?" are exactly the questions for which there's a really good and simple answer: use visual testing and validate everything with a single call. Got a signup page with multiple options and inputs? awesome. use visual testing on the page and voila, all the elements and data in the page are validated, no element-specific validation code required. In fact, you can flow through your application, use visual test on every page (or major event), and boom! You got dozens if not hundreds or more elements validated in a single swoop.

Applitools ( https://www.applitools.com ) does an extremely good work in making visual testing trivial, so you can have full blown E2E validation on your website/webapp with almost no validation code actually written. It's worth trying us out. We allow for a free account, and our SDKs are open source.

[theyouker]

Sort of a side note but: this is one of the cool things about react. Testing dom structure and things like ids and classes becomes (practically) testing react itself and redundant. If you keep components simple and driven entirely by props and state (perferably as little state as possible), you only need to verify these things are what you'd expect them to be for the given state in the state machine that is your component. Its beautifully simple. You can even get a long way with tools like react-vdom where you don't actually render anything and just test the validity of your props. https://github.com/gcanti/react-vdom (I believe the author did tcomb...definitely also use jest though)

[applecore]

The most important idea is testing the user experience according to the following five "laws" of human-computer interaction:

1. Fitt's Law (of movement to a target area): https://en.wikipedia.org/wiki/Fitts%27s_law

2. Steering Law (of movement through a tunnel): https://en.wikipedia.org/wiki/Steering_law

3. Hick's Law (of choices and decision time): https://en.wikipedia.org/wiki/Hick%27s_law

4. Miller's Law (of working memory): https://en.wikipedia.org/wiki/Miller%27s_law

5. Power Law (of practice and reaction time): https://en.wikipedia.org/wiki/Power_law_of_practice

[applecore]

Source: https://speakerdeck.com/roundedbygravity/5-interface-laws-ev...

[grandalf]

This is awesome. I'm imagining a fluffy UX/design conversation being replaced by a proof.

[pritambarhate]

Does anybody know of a book on human computer interaction where these are explained in detail?

[philipwalton]

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.

CSS Architecture http://philipwalton.com/articles/css-architecture/

Side Effects in CSS http://philipwalton.com/articles/side-effects-in-css/

Decoupling Your HTML, CSS, and JavaScript http://philipwalton.com/articles/decoupling-html-css-and-jav...

[alanfalcon]

These are so good. Thank you! Any advice on how I can immerse myself in resources like this short of stumbling across them on HN?

[airblade]

Terrific stuff. Thanks!

[blawa]

Thank you. I read them and they are exactly what I'm looking for. May I ask how you learnt this so that I can too?

[state]

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.

I recommend Josef Muller-Brockmann's Grid Systems in Graphic Design: http://www.amazon.com/Grid-Systems-Graphic-Design-Communicat... or Emil Ruder's Typographie: http://www.amazon.com/Typographie-Manual-Design-Emil-Ruder/d....

There are many, many other good resources but those are important primary sources. So is The Elements of Typographic Style, by Robert Bringhurst: http://www.amazon.com/gp/product/0881792128/ref=pd_lpo_sbs_d....

[mattmanser]

It doesn't sound like you know what software design patterns are. This has absolutely nothing at all to do with design patterns, which is about software design and how to manage complexity and nothing else. UX is not code.

[blawa]

Thank you. While not exactly what I was asking for, this is great to know.

[naugtur]

It looks like I'm first here. Check out Addy Osmani's book first http://www.addyosmani.com/resources/essentialjsdesignpattern...

[BerislavLopac]

You can always rely on Martin Fowler: http://martinfowler.com/eaaDev/uiArchs.html

[e12e]

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": http://stlab.adobe.com/group__asl__overview.html

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).

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.

[1] Jaakko Järvi, Texas A&M;: "Avoiding faulty user interfaces" http://bldl.ii.uib.no/2014/seminars-2014.html

Also (linked): http://bldl.ii.uib.no/2014/14v-bldl_hiday-JaakkoJarvi-avoidi...

[akvlad]

For CSS architecture I thought SMACSS [https://smacss.com/] by Jonathan Snook has really good design patterns that have been proven to be good throughout his many projects.

[karlshea]

I was also going to mention this. Drupal 8 implemented this for all of the default CSS: https://www.drupal.org/node/1887922

[vonnik]

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.

[yojo]

I've read this, and appreciate that it is a useful thing. However, (as the title suggests), it's about the user level interaction design of components, not code level patterns that promote reuse and maintainability.

Like the OP, I'd love to find more resources on good programming patterns.

[nateweiss]

I agree with this recommendation. It's a good book.

[lightblade]

There are definitely design patterns for frontend. There are just no books being published on this topic yet.

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

But yes, it would be nice for someone to put together a book.

Some example of frontend pattern: - promise - data binding - FRP event stream

None of these are exclusively frontend, but you'll see them more often in UI development.

[rimantas]

http://vault.simplebits.com/publications/bulletproof/ comes close, alas it is quite old. OTOH it may be still worth taking a look, because the same way of thinking still applies. Also, it was written in the golden age of the web. I'd say in those years the cleaniest code was written. Later we got one-page-web-sites, javascript-everything, moronic war for the mobile, and crap like OOCSS and BEM, i. e. went back into the mess. We also got gazillion of frameworks and node powered tools to produce mess even faster and in larger quantities. I wonder, will we ever get another 'clean the web' revolition like one in 200x

[3oheme]

I feel that most of the answers in this thread are wrong.

Design patterns, as the wikipedia says, is "a formal way of documenting a solution to a design problem in a particular field of expertise".

So, it's a solution for a specific problem.

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).

I'll use the layout as an example:

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 http://getbootstrap.com/css/#grid 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 http://neat.bourbon.io/ does)

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.

[nailer]

In the visual classes example, your appearance logic in now in two places: your HTML with the visual classes, and your CSS. Using only CSS or SASS or whatever else for appearance allows you to have a single place to modify the appearance of .sidebar items, which is objectively better.

[larrymcp]

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.

http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/032134...

[blawa]

While not exactly what I was looking for, this is very useful, thanks!

[catshirt]

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.

[BrandonM]

You might be mistaken:

> To give an obvious example of what I'm looking for- I would say, use margins to separate multiple instances of same components

I was surprised, too, because I was expecting to see lots of MVC talk.

[blawa]

I hope this is not considered a spam, but I had another related question today: https://news.ycombinator.com/edit?id=9178012

[blawa]

You're right :-)

[obeid]

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.

Nicholas Zakas: Scalable JavaScript Application Architecture https://www.youtube.com/watch?v=vXjVFPosQHw

[jongalloway2]

Here's a nice pattern catalog http://ui-patterns.com/

[toomim]

There's "The Design of Sites", but it's not really about CSS. http://www.amazon.com/The-Design-Sites-Principles-Customer-C...

[chocopoche]

I think it's worth mentioning Material design from Google: http://www.google.com/design/spec/material-design/introducti...

[grandalf]

I think the choice of pattern depends a lot on what you are building and how much and how often you will need to change it.

[jkinz86]

I think what you're looking for is Harry Roberts' ITCSS?

www.youtube.com/watch?v=1OKZOV-iLj4