Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Modern Front-End Developer

89c7dd7559f9155af5114377436f9454?s=47 Jonas Jonny
December 10, 2012

Modern Front-End Developer

My opinions what a modern front-end developer should know.
BarCamp 2012 (Ostrava)


Jonas Jonny

December 10, 2012


  1. Modern Front-End Developer

  2. ABOUT • Jonáš Krutil • Web developer / designer •

    PhD. student • @JonasKrutil • http://linkedin.com/in/jonaskrutil
  3. I WEB ♥

  4. BUT

  5. • Meaningful • Clean DRY code • Semantic code •

    User friendly • Visually attractive • Minimalistic MUST BE

  7. HTML 5 Boilerplate The web’s most popular front-end template.[1] [1]

    http://html5boilerplate.com/ „HTML5 Boilerplate helps you build fast, robust, and adaptable web apps or sites. Kick-start your project with the combined knowledge and effort of 100s of developers, all in one little package.“ [1]
  8. HTML 5 Boilerplate & Initializr „Initializr is an HTML5 templates

    generator to help you getting started with a new project based on HTML5 Boilerplate. It generates for you a clean customizable template with just what you need to start!“ [2] [2] http://initializr.com/ • Mobile-first responsive • Responsive Twitter Bootstrap • Modernizr with Respond.js • Jquery • Normalize.css • Base styles, Helpers, Media queries, Print styles
  9. HTML CODE [5] http://www.w3.org/TR/wai-aria/ • One language – English prefered

    • Semantic class & ID names • Lowercase vs. Uppercase • Be careful with new HTML5 elements (Structure) [3][4] • Get to know with WAI-ARIA (Accessibility) [5] • MicroData (Schema.org) „My best practise with naming convention is use camelCase for IDs and hyphenate for classes. In my opinion IDs look more unique and stronger that way and classes more common.“ [4] http://www.netmagazine.com/features/truth-about-structuring-html5-page/ [3] http://html5doctor.com/avoiding-common-html5-mistakes/
  10. CSS CODE [6] [6] http://engineering.appfolio.com/2012/11/16/css-architecture/ • CSS rules should be

    abstract → REUSABLE • Should be easily managed by a single person or a large engineering team → SCALABLE • Your CSS rules behave as you’d expect → PREDICTABLE • When adding new component X to the page shouldn’t break component Y by its mere presence → MAINTAINABLE „Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.“ „The less the CSS needs to know about the HTML structure the better.“
  11. JAVASCRIPT CODE [9] http://metaflood.com/work-life/use-jquery-and-modernizr-to-load-javascript-conditionally-based-on-existence-of-dom-element/ • Simply knowing a JavaScript library

    isn’t sufficient any more [8] • Jquery only when needed • Launch scripts only when needed [9] • Scalability and robustness are two things you should keep in mind when beginning development [7] „Don’t be ashamed to use a Javascript library. They are there to help you. It’s estimated that 3,000 of the top 10,00 sites on the web use jQuery alone and again.“ [7] [8] http://rmurphey.com/blog/2012/04/12/a-baseline-for-front-end-developers/ [7] http://darcyclarke.me/development/javascript-applications-101/ (via @r4ms3scz, @tomasmatis)
  12. OTHER GOOD THINGS TO KNOW • CSS preprocessors (SASS /

    LESS) • CSS Grids • CoffeeScript compiler for JavaScript • Git, GitHub • Time Tracking

  14. CSS BEST PRACTICES #10 [11] http://smacss.com/ • Principles of writing

    consistent, idiomatic CSS [10] • SMACSS - Scalable and Modular Architecture for CSS [11] ~ Organize Your CSS ~ [10] https://github.com/necolas/idiomatic-css/ & https://github.com/necolas/idiomatic-css/tree/master/translations/cs-CZ by @machal
  15. CSS BEST PRACTICES #9 ~ Declarations, Properties, Values Order ~

    .selector { /* Element */ display: inline-block; position: absolute; top: 0; right: 0; bottom: 0; left: 0; width: 100px; height: 100px; padding: 10px; margin: 10px; /* Font style */ color: #f1bd0c; font-size: 3em; line-height: 1.523; text-align: center; text-indent: 100%; /* Other */ border: 1px #000 solid; background-color: #fff; z-index: 10; overflow: hidden; /* CSS3 animations, prefixes */ -webkit-border-radius: 1px; -moz-border-radius: 1px; border-radius: 1px; „This is my best practise with „categories“. You should also add empty space per categories if more than two properties.“
  16. CSS BEST PRACTICES #8 [12] [12] http://engineering.appfolio.com/2012/11/16/css-architecture/ • When classes

    are used by too many parts of the application, it becomes very scary to remove them from your HTML. Especialy on a large projects. • However, with an established convention, this problem can be completely avoided. • When you see a class in the HTML, you should be able to tell instantly what its purpose is. • Recommendation by Philip Walton is to give all non-styled classes a prefix. He use .js- for JavaScript and .supports- for Modernizr classes. • My recommendation (+SMACSS) is use .is- for state rules. ~ Use Classes For Styling And Styling Only ~
  17. CSS BEST PRACTICES #7 [12] [12] http://engineering.appfolio.com/2012/11/16/css-architecture/ • When an

    existing component needs to look slightly different in a certain context, create a modifier class to extend it. ~ Extend components with modifier classes ~ /* Bad */ .widget { } #sidebar .widget { } /* Good */ .widget { } .widget-sidebar { }
  18. CSS BEST PRACTICES #6 [12] [12] http://engineering.appfolio.com/2012/11/16/css-architecture/ • Namespacing your

    classes keeps your components self- contained and modular. • It minimizes the likelihood that an existing class will conflict, and it lowers the specificity required to style child elements. ~ Namespace your classes ~ /* High risk of style cross-contamination */ .widget { } .widget .title { } /* Low risk of style cross-contamination */ .widget { } .widget-title { }
  19. CSS BEST PRACTICES #5 [13] [13] http://www.onextrapixel.com/2012/06/05/15-best-css-practices-to-make-your-life-easier/ • One of

    the main reasons is that inline styles to not separate the content from the design. This can prove to make development and designing difficult. • Another reason to avoid inline CSS is because it is much harder to maintain. ~ Avoid Inline CSS ~
  20. CSS BEST PRACTICES #4 [14] [14] http://css-tricks.com/why-ems/ • The same

    size body type that looks good on a phone sized screen does not look good on a widened desktop layout. • Text should be a bit bigger on large screens. • You're going to need to change font sizes for different screen sizes. Let's say you look through your stylesheet and find 50 different font-size declarations in px. That's 50 places you need to change that font size through a media query when the screen size changes. That's 50 suck points. ~ Migrate from PX EM / Percentages → ~
  21. CSS BEST PRACTICES #3 [15] [15] http://csswizardry.com/2012/11/code-smells-in-css/ • IDs, as

    well as being non-reusable can never be used more than once in a page. • Use IDs in HTML for fragment identifiers and JS hooks, but never in CSS. • Don’t stop using IDs, just be aware of where they can cause you headaches and know where to sensibly circumvent them. Anyone telling you not to use them at all is not wrong, but they’re definitely not right…[16] ~ Use IDs in CSS only there is no other way ~ [16] http://csswizardry.com/2011/09/when-using-ids-can-be-a-pain-in-the-class/
  22. CSS BEST PRACTICES #2 [12] [12] http://engineering.appfolio.com/2012/11/16/css-architecture/ • Relying on

    HTML tags and combinators keeps your HTML squeaky clean, but it makes your CSS gross and dirty. ~ Stay away from complex selectors ~ /* Grenade → Clean HTML */ #main-nav ul li ul { } /* Sniper Rifle → Predictable CSS */ .subnav { }
  23. CSS BEST PRACTICES #1 [12] [12] http://engineering.appfolio.com/2012/11/16/css-architecture/ • They totally

    inhibit reusability on another element • They increase specificity • They increase browser workload (decreasing performance) ~ Stay away from qualified selectors ~ ul.nav li.active a{} div.header a.logo img{} .content ul.features a.button .nav .active a{} .logo > img {} .features-button{}

  25. RESPONSIVE WEB DESIGN BASICS „The web is responsive by default.

    Keep it simple. Strip al the JS. Don't worry about pixels. Focus on content. You're half way done! #rwd“ ~ Tom Aertssens ~ WHAT – WHY - HOW
  26. WHAT „RWD is an approach to web design in which

    a site is crafted to provide an optimal viewing experience — easy reading and navigation with a minimum of resizing, panning, and scrolling—across a wide range of devices (from desktop computer monitors to mobile phones).“ [17] [17] http://en.wikipedia.org/wiki/Responsive_web_design [Seminal Responsive Web Design Example] http://mediaqueri.es/45/
  27. WHY • User experience • Unlimited amount of mobile /

    web devices • Performance „Poor performance has been tied to a decrease in revenue, traffic, conversions, and overall user satisfaction.“ User satisfaction should be our main goal.
  28. MOBILE FIRST „The constraints of the mobile medium force designers

    to focus on what’s truly important to a product or service. [18] Mobile provides a great opportunity to reevaluate what content/functionality is necessary and gives us an opportunity to strip away the cruft across the board (and not just for mobile users either).“ [18] ~ Luke Wroblewski ~ [19] [19] http://www.lukew.com/presos/preso.asp?26 [18] http://bradfrostweb.com/blog/mobile/the-many-faces-of-mobile-first/
  29. MOBILE FIRST & MEDIA QUERIES „Mobile-first styles mean establishing shared

    CSS styles first and only introducing larger-screen-specific styles only when appropriate.“ [18] http://bradfrostweb.com/blog/mobile/the-many-faces-of-mobile-first/ .product-img { width: 100%; float: left; } @media screen and (min-width: 768px) { .product-img { width: 50%; } }
  30. PERFORMANCE „Guy Podjarny, who has done a lot of research

    around responsive performance, discovered that 86% of the responsive sites he tested were either the same size or larger on the small screen as they were on the desktop.“ [20] „71% of people say they expect on mobile sites to load as quickly or faster on their phone when compared to the desktop.“ [20] [20] http://24ways.org/2012/responsive-responsive-design/
  31. CSS PERFORMANCE • Display: none; → It’s completely useless? [21]

    • Responsive images [22] • CSS3 • Sprites (hi-res retina) [23] • Custom fonts with icons [24] • Base64 Encode • Minify CSS [24] http://icomoon.io/app/ & http://fontello.com/ [23] http://weedygarden.net/2012/04/hi-res-retina-display-css-sprites/ [22] http://24ways.org/2012/responsive-responsive-design/ [21] http://timkadlec.com/2012/04/media-query-asset-downloading-results/
  32. JS PERFORMANCE [50 Performance Tricks (Video) http://media.ch9.ms/ch9/807f/19ad02f7-9954-41e9-805e-5d9eb030807f/3-132.webm • Conditional loading

    → Don’t load any more than you absolutely need to. • Minify JS • Initialize JS on demand • Minimize DOM interactions → var elm = $(‘.sub-nav’); [22] http://24ways.org/2012/responsive-responsive-design/ „Peter-Paul Koch recently exclaimed that current JavaScript libraries are just “too heavy for mobile”.“ [22] „Research from Stoyan Stefanov on parse times supports this. On some Android and iOS devices, it can take as long as 200-300ms just to parse jQuery.“ [22]
  33. Thank you @JonasKrutil http://speakerdeck.com/jonas