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.

28e1c6e895146e8217caf14eb56feb7b?s=128

Nico Hagenburger

September 12, 2015
Tweet

Transcript

  1. 8.

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

    with: ★ Databases ★ Services ★ Ruby
  2. 9.

    Front-end developer ★ Even harder to hire ★ Today mostly

    JavaScript based: ★ Grunt/Gulp/Broccoli/Webpack/etc. ★ Might not like use Ruby
  3. 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
  4. 19.

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

    creating a global front-end style guide)
  5. 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.)
  6. 23.

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

    additional version of the HTML templates and more complexity)
  7. 24.

    (Step 2: Get the HTML out of the applications and

    providing the templates as API)
  8. 26.

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

    style guide is just the API documentation.)
  9. 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
  10. 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
  11. 32.

    GEM +Include it into every app +Helpers can be shared

    +Form builders are possible −Ruby back end only −Harder to develop (Git)
  12. 33.

    One app +Nothing much to change +Share partials between app

    and style guide −Still does not solve different working environments
  13. 35.

    Visual changes ★ CSS changes in the style guide ★

    HTML in the app must reflect this
  14. 36.

    Example Old version: New version: (Applying this wrapper to all

    fields in the application might be a lot of work)
  15. 38.

    Git commit hash ★ Just refer to latest commit hash

    ★ Get the matching HTML for the CSS
  16. 39.
  17. 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
  18. 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
  19. 49.
  20. 55.

    Learnings ★ Keep it as simple as possible ★ Try

    using Mustache ★ Test the setup before releasing to your co- workers (Readme, Mac/Win/Linux, …)
  21. 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