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.

Transcript

1. Get rid of that 

   front end
   @hagenburger #rubyconftw
   

   View Slide

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

   View Slide

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

   View Slide

4. livingstyleguide.org
   @LSGorg
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. Back-end developer
   ★ Hard to hire
   ★ Used to work with:
   ★ Databases
   ★ Services
   ★ Ruby
   

   View Slide

9. Front-end developer
   ★ Even harder to hire
   ★ Today mostly JavaScript based:
   ★ Grunt/Gulp/Broccoli/Webpack/etc.
   ★ Might not like use Ruby
   

   View Slide

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
    

    View Slide

11. Do you want to
    combine this?
    

    View Slide

12. Might cost time.
    

    View Slide

13. Better use the time
    to separate concerns.
    

    View Slide

14. Split up your
    architecture
    

    View Slide

15. A typical project
    

    View Slide

16. Why
    Phone
    Apps?
    

    View Slide

17. Why
    Phone
    Apps?
    APP
    APP
    HTML
    and
    CSS
    

    View Slide

18. (The architecture might look like this:)
    

    View Slide

19. (Step 1: Get the CSS out of the applications by creating a global front-end style guide)
    

    View Slide

20. (This is what style guides contains)
    

    View Slide

21. 
    
    
    Akasha
    
    
    
    
    
    <%= @user.name %>
    
    
    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.)
    

    View Slide

22. A style guide is a
    copy & paste API
    

    View Slide

23. (3 × copy & paste)
    (actual Step 1: We created an additional version of the HTML templates and more complexity)
    

    View Slide

24. (Step 2: Get the HTML out of the applications and providing the templates as API)
    

    View Slide

25. HTML can’t live without CSS
    CSS can’t live without HTML
    CSS
    HTML
    

    View Slide

26. (Example for a style guide describing an API partial. The style guide is just the API
    documentation.)
    

    View Slide

27. Remote partials
    

    View Slide

28. How to implement?
    

    View Slide

29. Different approaches
    ★ Completely separate
    ★ Two applications combined
    ★ As Ruby Gem
    ★ Monolith application
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. GEM
    +Include it into every app
    +Helpers can be shared
    +Form builders are possible
    −Ruby back end only
    −Harder to develop (Git)
    

    View Slide

33. One app
    +Nothing much to change
    +Share partials between app and style guide
    −Still does not solve different working
    environments
    

    View Slide

34. Versioning
    

    View Slide

35. Visual changes
    ★ CSS changes in the style guide
    ★ HTML in the app must reflect this
    

    View Slide

36. Example
    Old version: New version:
    (Applying this wrapper to all fields in the application might be a lot of work)
    

    View Slide

37. Version numbers
    ★ Gem version
    ★ NPM version
    

    View Slide

38. Git commit hash
    ★ Just refer to latest commit hash
    ★ Get the matching HTML for the CSS
    

    View Slide

39. Testing
    

    View Slide

40. Atomic design
    @brad_frost
    

    View Slide

41. Split it up
    Front end templates
    (partials)
    Back end views
    (e. g. Rails)
    API
    

    View Slide

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

    View Slide

43. Regression testing
    Old version: New version:
    (Button height fails: Pink parts show diff.)
    

    View Slide

44. Default test Edge case test
    Test cases
    

    View Slide

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
    

    View Slide

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
    

    View Slide

47. JavaScript
    

    View Slide

48. Depends on the
    framework.
    (Backbone, React, and Ember might work well, Anguler could be tricky.)
    

    View Slide

49. I18n
    

    View Slide

50. Might be part of the
    front end.
    

    View Slide

51. Why?
    ★ Translations need typography
    ★ Typography requires designers
    ★ Designers work in the front-end team
    

    View Slide

52. 100 % 50 % 0%
    (a designer knows which spacing is right)
    

    View Slide

53. I18n is design
    and user experience.
    

    View Slide

54. Conclusions
    

    View Slide

55. Learnings
    ★ Keep it as simple as possible
    ★ Try using Mustache
    ★ Test the setup before releasing to your co-
    workers (Readme, Mac/Win/Linux, …)
    

    View Slide

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
    

    View Slide

57. URLs
    ★ https://github.com/hagenburger/styleguide-api
    (WIP)
    ★ Also: https://github.com/webpack/webpack
    ★ http://atomicdesign.bradfrost.com
    ★ Slides: https://twitter.com/hagenburger
    

    View Slide

58. nico@hagenburger.net
    email
    twitter
    blog
    first name
    last name
    謝謝
    Thank you!
    

    View Slide