$30 off During Our Annual Pro Sale. View Details »

Get rid of that front end

Get rid of that front end

For many back-end developers, the front-end is a pain. Dirty code within the application and even hard to test. So how can we use our experiences as Ruby developer to built a better front end?

Not every application developer (back-end or JavaScript) places importance on the details of front-end structure. Instead, they prefer simply to use APIs — mostly with a JSON interface. Instead of interference with the front-end developer’s work, this provides a structured API that only takes care of defined values.

CSS can’t live without HTML, and HTML almost can’t live without CSS. Let the front-end developer take care of both and consume the result as a well-tested API that takes nothing else than data as input.

Nico Hagenburger

September 12, 2015

More Decks by Nico Hagenburger

Other Decks in Programming


  1. Get rid of that 
 front end @hagenburger #rubyconftw

  2. nico@hagenburger.net email twitter blog first name last name

  3. (I’m from Germany. The country producing China Oil for Taiwan.)

  4. livingstyleguide.org @LSGorg

  5. Mentor https://instagram.com/langziehohr/ https://instagram.com/p/5198hBm7hS/

  6. Organizer/designer https://instagram.com/asaaki/ https://instagram.com/p/54xnvhp9Hy/

  7. (Ruby) back-end vs. front-end developers

  8. Back-end developer ★ Hard to hire ★ Used to work

    with: ★ Databases ★ Services ★ Ruby
  9. Front-end developer ★ Even harder to hire ★ Today mostly

    JavaScript based: ★ Grunt/Gulp/Broccoli/Webpack/etc. ★ Might not like use Ruby
  10. Working as a team ★ JavaScript/Node might be harder to

    install than expected ★ Ruby might be harder to install than expected ★ Note to self: Not everybody is using a MacBook
  11. Do you want to combine this?

  12. Might cost time.

  13. Better use the time to separate concerns.

  14. Split up your architecture

  15. A typical project

  16. Why Phone Apps?

  17. Why Phone Apps? APP APP HTML and CSS

  18. (The architecture might look like this:)

  19. (Step 1: Get the CSS out of the applications by

    creating a global front-end style guide)
  20. (This is what style guides contains)

  21. <div class="speaker-avatar"> <a href="#href"> <div class="speaker-avatar--photo"> <img class="speaker-avatar--photo-image" src=" </div>

    <h1 class="speaker-avatar--name">Akasha</h1> </a> </div> <div class="speaker-avatar"> <a href="<%= link_to user_path(@user) %>"> <div class="speaker-avatar--photo"> <img class="speaker-avatar--photo-image" src="<%= image </div> <h1 class="speaker-avatar--name"><%= @user.name %></h1> </a> </div> Style guide Application (The view in the app is almost the same as in the style guide. You have to copy and adjust over and over.)
  22. A style guide is a copy & paste API

  23. (3 × copy & paste) (actual Step 1: We created an

    additional version of the HTML templates and more complexity)
  24. (Step 2: Get the HTML out of the applications and

    providing the templates as API)
  25. HTML can’t live without CSS CSS can’t live without HTML

  26. (Example for a style guide describing an API partial. The

    style guide is just the API documentation.)
  27. Remote partials

  28. How to implement?

  29. Different approaches ★ Completely separate ★ Two applications combined ★

    As Ruby Gem ★ Monolith application
  30. Completely separate +Back end (Rails) +Front end (JS on developing

    machine) −Slow change processes ★ API: ★ Provide templates (e. g. as JSON) ★ Load all templates into back end at startup
  31. Two apps combined +Run the application (e. g. Rails) normally +Run

    the front-end app (e. g. Middleman) +Changes can be done more easily −Still does not solve different working environments #protip: Use Foreman
  32. GEM +Include it into every app +Helpers can be shared

    +Form builders are possible −Ruby back end only −Harder to develop (Git)
  33. One app +Nothing much to change +Share partials between app

    and style guide −Still does not solve different working environments
  34. Versioning

  35. Visual changes ★ CSS changes in the style guide ★

    HTML in the app must reflect this
  36. Example Old version: New version: (Applying this wrapper to all

    fields in the application might be a lot of work)
  37. Version numbers ★ Gem version ★ NPM version

  38. Git commit hash ★ Just refer to latest commit hash

    ★ Get the matching HTML for the CSS
  39. Testing

  40. Atomic design @brad_frost

  41. Split it up Front end templates (partials) Back end views

    (e. g. Rails) API
  42. Test it Unit tests (regression testing) Integration tests (e. g. Cucumber)

  43. Regression testing Old version: New version: (Button height fails: Pink

    parts show diff.)
  44. Default test Edge case test Test cases

  45. What’s an edge case? ★ Having the same HTML with

    different amount of text ★ Having the same HTML without image (user with no profile image) ★ Having the same HTML with too small image
  46. Front end Takes care that the ★ design won’t break

    ★ content won’t break ★ devices won’t break Back end Takes care that the ★ work flows won’t break ★ user input won’t break ★ security won’t break
  47. JavaScript

  48. Depends on the framework. (Backbone, React, and Ember might work

    well, Anguler could be tricky.)
  49. I18n

  50. Might be part of the front end.

  51. Why? ★ Translations need typography ★ Typography requires designers ★

    Designers work in the front-end team
  52. 100 % 50 % 0% (a designer knows which spacing is

  53. I18n is design and user experience.

  54. Conclusions

  55. Learnings ★ Keep it as simple as possible ★ Try

    using Mustache ★ Test the setup before releasing to your co- workers (Readme, Mac/Win/Linux, …)
  56. Takeaways ★ Your team must feel comfortable with your architecture

    ★ Front end and back end getting more and more different ★ Cherry-pick the parts you need ★ Some JS frameworks might be hard to use
  57. URLs ★ https://github.com/hagenburger/styleguide-api (WIP) ★ Also: https://github.com/webpack/webpack ★ http://atomicdesign.bradfrost.com ★

    Slides: https://twitter.com/hagenburger
  58. nico@hagenburger.net email twitter blog first name last name 謝謝 Thank