Śledź mój Fanpage!

Budowanie front-end – nie wymyślaj koła na nowo!

10 stycznia, 2014 16:51, komentarze 2

front-end

Zawsze kiedy startujemy z nowym projektem webowym, dobrze sprawdzam kto będzie odpowiedzialny za front-end. Chodzi i warstwę wizualną projektu, czyli HTML, CSS i podstawy JavaScript. Czego chcę uniknąć?

Chcę uniknąć tego, żeby ktoś pisał szablony html od zera. Po co? Po jakiego grzyba? Koduje front-end od 1999 roku i nikt mnie nie przekona, że dziubanie szabloników od początku ma jakikolwiek sens. Nie, nie ma.

Użyj front-end framework… bo ważne są konwencje

Wyjdę od tego jakie strony lubią docelowi użytkownicy w kontekście front-end? Oryginalne? Nie sądzę. Piękne i przeładowane? Na pewno nie. Sekret brzmi: lubią taki webdesign, przy którego używaniu nie muszą myśleć… Kropka. Oni nie przychodzą podziwiać wyglądu Twojej strony, ale wykonać interesującą ich akcję (zakup, dodanie komentarza, itd.).

A co pomaga kierowcom nie myśleć jak prowadzić ich nowy samochód? Konwencja użycia. Kierownica po lewej, wajcha po prawej, gaz po prawej. Tak samo warto stosować konwencje dla stron internetowych. One mogą się różnić brandingiem, tak samo jak samochody różnią się np. linią nadwozia. Ale logo ma być po lewej u góry, a przyciski głównych akcji najczęściej wyglądają tak i tak.

Więc Ty jako front-end developer powinieneś się zainteresować tym, czy ktoś już spisał gdzieś te konwencje i zbudował jakiś front-end framework (środowisko z gotowcami). Dzięki niemu możesz użyć gotowych komponentów i przyspieszyć swoją pracę.

Jaki css framework ja wybrałem? Oczywiście Twitter Bootstrap.

Twitter Boostrap dla niektórych jest bee

Wszystko ma wady i zalety. Ja widzę wiele zalet tego framework? Społeczność. Na każde głupie zapytanie co jak tam zrobić jest 100 odpowiedzi na Stackoverflow. Jest to bezcenne zarówno w kontekście rozwiązywania aktualnych problemów z kodowaniem jak i obietnica stałego rozwoju.

Niektórzy uważają, że Twitter Bootstrap narzuca za dużo kwestii wyglądowych. Jednak dla dobrego developera zmiana kilku paddingów, kolorów, czcionek, nie powinna stanowić problemu. Jeśli ktoś chce robić jednak bardziej odjechany front-end, to bardzo prawdopodobne jest, że wyjeżdża poza wspomniane konwencje. Dlatego nie zauważam u mnie takich problemów.

Do tego liczba zewnętrznych komponentów i web templates, powinna uleczyć ten ból. Niektórzy podnoszą też problem szybkości działania witryn z takimi dodatkami. Jednak przy coraz lepszych łączach, dodatkowe 10KB nie wiem czy są aż takim problemem.

Włącz dopalacze

Kilka technik, których używam aby przyspieszyć tworzenie front-end:

  1. Spisz zasady – w moich projektach tworzymy zawsze dokument techniczny. Opisujemy co i jak będzie robione w back-end, ale także we front-end. Nazewnictwo klas w css, podział plików css, dziedziczenia, komentowanie, dobre praktyki. Część o front-end to ~2 strony A4. Niewiele, a pozwala uniknąć burdelu w przyszłości.
  2. Podepnij dopalacze – czyli biblioteki Twitter Boostrap, Jquery, Fontawesome i kilka hacków dla „wspaniałego” Internet Explorer.
  3. Zrób najpierw jeden szablon – o co chodzi? O to, że zaczynając budować szablon wrzucam do jednego pliku wszystkie strony i planowane widgety na jeden widok. Co to mi daje? Przy modyfikacjach CSS mam ogląd czy coś nie zepsuło, bez potrzeby skakania między szablonami. Potem dzielę jak mam wykonane 99% pracy.
  4. Użyj kreatorów online – takie zabawki jak Divshot czasem się przydają, oczywiście w pierwszej fazie projektu. Edytor w chmurze pozwala mi pracować nad szablonami w różnych miejscach i łatwo udostępniać wyniki.
  5. Minimalizuj ilość CSS – jak widzę 2000 linii w CSS przy prostym layout z użyciem Twitter Boostrap to wiem, że coś jest nie tak. Warto sprawdzać czy TW nie ma już tego niż pisać nowe style od zera. Przydatne są też biblioteki SASS i LESS.

Jaki efekt?

Ano taki, że czasem tworzenie front-end trwa o 90% czasu krócej niż dawniej. Czyli uchroniłem się przed traceniem kasy na wymyślanie koła na nowo.

Do tego stale dostosowujemy biblioteki Boostrap do swoich potrzeb, aby jednak nie były za ciężkie. Nawet jeśli nie chcesz zewnętrznych bibliotek tak czy siak warto zacząć budować wtedy własny framework, który będzie udoskonalany i używany ponownie z projektu na projekt? 🙂 Polecam.