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
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 CSS 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) API
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 right)
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 you!