Unic - frontend development-in-complex-projects

Frontend development in complex projects
Frontend Conference Zurich 2012

9th September 2012 Rosmarie Wysseier & Thomas Jaggi

Rosmarie Wysseier

• Gymnasium (Psychology and Economy)
• Creative Media Diploma, SAE Zürich, 2004
• Bachelor of Computer Science
University of Applied Sciences Bern, 2009

© Unic - Seite 2

Thomas Jaggi

• MSc Food Science (Major in Human
Nutrition) from ETH Zurich
• Fiddling around with frontend
technologies since before it was cool

© Unic - Seite 3

Unic at a glance

• Founded in 1996 in Switzerland
• We design, develop and maintain premium e-business solutions
for e-commerce, digital communication and collaboration
• We are an independent, owner-operated group with 270 employees
• Sales of 38 million CHF i.e. 33 million Euro (2011)
• 7 offices: Amsterdam, Bern, Brussels, Karlsruhe, Munich, Vienna and Zurich

© Unic - Seite 4

What we are going to talk about

• Writing maintainable and scalable
HTML / CSS
• Data mocking
• Unit testing
• Continuous integration

© Unic - Seite 5

Starting point

• Lots of people involved
• Multiple devs / teams are working on the same project
• Sometimes in parallel, sometimes one after another

• High degree of uncertainty
• Detail specifications and/or design might still be in the works
• Interface frontend – backend not yet defined

© Unic - Seite 6

Agenda

HTML / CSS
• Data mocking
• Unit testing

© Unic - Seite 7

Exemplary issues

• Issue #1: HTML code is highly redundant
• Issue #2: CSS is location-dependent
• Issue #3: CSS assumes too much about the markup
• Issue #4: JS is not adequately separated from HTML / CSS
• Issue #5: No consistent coding style

© Unic - Seite 8

probably copyright-protected screenshot of “The Office”

Issue #1
HTML code is highly redundant

«The customer just told me he wants
Click to editform in the header, after
this search Master title style
all.»

– Project manager

© Unic - Seite 10

Problem: Redundant HTML code is difficult to maintain

• Design templates for every existing page type
• Usually: 1 design template = 1 HTML file

• Changing the structure means changing dozens of HTML files
• Find & replace has its limits

© Unic - Seite 11

Solution

• Modularization of the HTML
• Our tool of choice: Middleman (http://middlemanapp.com)

© Unic - Seite 12

Using partials in middleman

• Layout file: <html>
<head>
<title>My Site</title>
</head>
<body>
<%= partial "header" %>
<%= yield %>
</body>
</html>

• Partial: <header>
<a href="#" class="logo“>Home</a>
</header>

© Unic - Seite 13

Disadvantages

• Build process necessary
• HTML for one page type spread over many files

© Unic - Seite 14


Issue #2
CSS is location-dependent

«The customer just told me he wants to
Click to edit Master the main content
to use this teaser in title style
area, too.»

– Project manager

© Unic - Seite 16

Problem: Location-dependent CSS is not flexible

#sidebar a {
color: #c30;
text-decoration: none;
}

#sidebar .teaser {
background-image: linear-gradient(to bottom, #ddd, #fff);
padding: 1em;
}
#sidebar .teaser h3 {
font-size: 1.2em;
font-weight: normal;
margin-bottom: 1em;
}

© Unic - Seite 17

Solution

• Modularization
• Approach: OOCSS

© Unic - Seite 18

«Basically, a CSS “object” is a repeating
visual pattern, which can be abstracted
into an independent snippet of HTML,
Click and possibly JavaScript. Once
CSS, to edit Master title style
created, an object can then be reused
throughout a site.»
– OOCSS (https://github.com/stubbornella/oocss/wiki)

© Unic - Seite 19

Multiple approaches

• Some famous methodologies:
• OOCSS by Nicole Sullivan (https://github.com/stubbornella/oocss/)
• SMACSS by Jonathan Snook (http://smacss.com/)
• BEM by Yandex (http://bem.github.com/)

© Unic - Seite 20

Examples (based on how I understand their docs)

• OOCSS: <div class="teaser featured">
<h3 class="title">Title</h3>
<div class="bd">Blabla</div>
</div>

• SMACSS: <div class="teaser is-featured">
<h3>Title</h3>
<div class="body">Blabla</div>
</div>

• BEM <div class="teaser teaser_type_featured">
<h3 class="teaser__title">Title</h3>
<div class="teaser__body">Blabla</div>
</div>
© Unic - Seite 21


Issue #3
CSS assumes too much about the markup

«We can’t strictly implement your
Click tostructure, our CMS renders
HTML edit Master title style
additional tags.»

– Backend developer

© Unic - Seite 23

Example

• Before: <div class="block-teaser">
<h3>Title</h3>

<div class="content“>Blabla</div>
</div>

• After:
<div class="block-teaser">
<span id="hfk42342kj:ksa89080hajlk">
<h3>Title</h3>
</span>

<div class="content“>Blabla</div>
</div>

© Unic - Seite 24

Problem: CSS assumes too much about the markup
Slide updated to reduce confusion
• Avoid
• Immediate child selector: .block-teaser > h3 {}

• Adjacent sibling selector: .block-teaser .xy + h3 {}

• And similar ones

.block-teaser .title {}
• Use additional classes instead:
// or faster regarding
// selector matching:
.block-teaser-title {}
© Unic - Seite 25

Disadvantages

• Missing out on generally useful selectors
• Extra markup

© Unic - Seite 26


Issue #4
JS is not adequately separated from HTML / CSS

«Your JavaScript does not work. How
Click to edit Master title style
about testing before shipping?»

– Backend developer

© Unic - Seite 28

Styling hooks used as JS hooks

• JavaScript functionality is coupled too tightly to CSS selectors used for styling
• E.g.: Changing a class breaks the JS

© Unic - Seite 29

Example

• HTML: <div class=“carousel">
<ul>
<li>Hi there</li>
<li>Hi there 2</li>
</ul>
</div>

• JS: $(function() {
var $target = $('.carousel‘),
carousel = new Carousel($target);

carousel.init();
});

© Unic - Seite 30

Solution

• Use namespaced classes as your JS “hooks” (i.e. “js-carousel”)
• Use data attributes instead of classes

© Unic - Seite 31

Example

<div class="carousel" data-init="carousel“ data-options='{}'>
<ul data-role="items">
<li data-role="item">Hi there</li>
<li data-role="item">Hi there 2</li>
</ul>
</div>

© Unic - Seite 32

Disadvantages

• Performance of attribute selectors
• Extra markup

© Unic - Seite 33


Issue #5
No consistent coding style

«I just refactored your multi-line
declarations into single-line ones
because I like them better.»

– Other frontend developer

© Unic - Seite 35

Problem: Every developer follows his own private styleguide

• Indentation, spaces: CSS/JS is difficult to read
• Structure: Specific parts are hard to find
• Versioning: Refactoring messes up history

© Unic - Seite 36

Example: Github (https://github.com/styleguide/css)

• Use soft-tabs with a two space indent.
• Put spaces after : in property declarations.
• Put spaces before { in rule declarations.
• Use hex color codes #000 unless using rgba.
• Use // for comment blocks (instead of /* */).
• Document styles with KSS

© Unic - Seite 37

Other examples

• Curated by Chris Coyier, http://css-tricks.com/css-style-guides/:
• Google HTML/CSS Style Guide
(http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml)
• WordPress CSS Coding Standards
(http://make.wordpress.org/core/handbook/coding-standards/css/)
• «Idiomatic CSS» by Nicolas Gallagher (https://github.com/necolas/idiomatic-css)
• …

© Unic - Seite 39

probably copyright protected screenshot of “The Office”

Strive to make everyone’s life easier.

Data mocking

• Mock a GET-Request

$.get('/js/data/data.json', function(data) {
alert('This was easy');
});

• Mock REST (i.e. with Backbone)

POST /collection
GET /collection[/id]
PUT /collection/id
DELETE /collection/id

© Unic - Seite 42

Mock of REST requests

var oldBackboneSync = Backbone.sync;

Backbone.sync = function(method, model, options) {
…
if (method == "delete" || method == "update")
// handle id in URL
…
// is URL mocked?
if (urls[baseUrl])
…
// is method mocked?
…
return response[method];
else
oldBackboneSync(method, model, options);
}

© Unic - Seite 44

Mock of REST requests

BackboneMock = {
"/request_mocks/collection/": {
"read": function () {
return [{
"id": "1",
"title": "This was hard work!"
}]
},
"create": function () {
return {
"id": Math.floor(Math.random()*10000)
}
},
"delete": function () {
return {};
}
}
};
© Unic - Seite 45

Unit testing

• Tests should cover the most important pieces of code
• You should test the interface with the backend carefully
• You should not test styling or plugins

© Unic - Seite 48

Continuous Integration

layout, partials

HAML HTML

@import "partials/base";
SCSS CSS

//= require 'plugins'
JS JS

Middleman

© Unic - Seite 51

Continuous Integration

Check updates

Jenkins
SVN Source
Ruby server

Deploy
HTML
JS
CSS

Apache server
© Unic - Seite 52

Unic AG Rosmarie Wysseier

Belpstrasse 48 Senior Frontend Engineer
3007 Bern
Tel +41 31 560 12 12 Thomas Jaggi
Fax +41 31 560 12 13
Senior Frontend Engineer
bern@unic.com
www.unic.com

© Unic - Seite 55

Unic - frontend development-in-complex-projects

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Unic - frontend development-in-complex-projects

Similar to Unic - frontend development-in-complex-projects (20)

More from Unic

More from Unic (20)

Recently uploaded

Recently uploaded (20)

Unic - frontend development-in-complex-projects