Jak przyspieszyć proces tworzenia stron? Lista narzędzi, które powinieneś znać

Czas w webdevelopmencie płynie niesłychanie szybko, dlatego bardzo ważne jest, by być na czasie z najnowszymi narzędziami, które mogą znacznie wesprzeć proces tworzenia stron internetowych. W ciągu ostatnich dwóch lat pojawiło się ich sporo. Niejedne zrewolucjonizowały nasz fach. Co wypada znać?

Edytory tekstu

Jednym z najważniejszych edytorów tekstu ostatnich miesięcy jest Sublime Text. Posiada on niezwykle świetny system pluginów, świetną minimapę kodu, możliwość edycji kilku plików jednocześnie i wiele więcej. To po prostu szybki i niezwykle elastyczny edytor, który dziś wydaje się jednym z najpopularniejszych tego typu programów wśród twórców stron internetowych.

Innym, bardzo ważnym edytorem jest WebStorm. To już nie tylko zwykły procesor do tekstu, ale prawdziwy kombajn, jeśli chodzi o programowanie w JavaScript i nie tylko. Świetne podpowiadanie kodu, wsparcie na SVN/GIT, integracja z JS Hint/Lint i nie tylko. Jeśli programowaliście w Eclipse lub Netbeans, wiecie o czym mówię. Pełną listę opcji znajdziecie na stronie producenta. Warto pamiętać, że JetBrains, wydawca oprogramowania, oferuje często bardzo atrakcyjne promocje na swoje aplikacje.

Oprócz wymienionej dwójki, warto dodać, że rynek podbija Brackets, internetowy edytor autorstwa Adobe. Co ważne, jest on napisany wyłącznie w HTML, CSS i JS.

Emmet

Jeśli jesteśmy przy edytorach, a Ty myślisz o przyśpieszeniu swojej pracy, koniecznie zainteresuj się Emmetem, który jest podobny do Zen Coding (będąc jego rozwinięciem). Chcesz wygenerować kod dla kilku elementów listy (li) przy pomocy jednej linijki? Nie ma problemu. Sprawia Ci trudność wieczne sprawdzanie, jakie wymiary ma obrazek? Dzięki sprytnej komendzie Emmet zrobi to dla Ciebie i doda odpowiednie atrybuty width oraz height uzupełnione o rzeczywiste wymiary obrazka.

LESS, SASS, Stylus

Brakuje Ci zmiennych w CSS (np. do zdefiniowania powtarzających się kolorów)? Chciałbyś tworzyć komponenty, które można ponownie użyć, dzięki jednej linijce? Nie chcesz liczyć 1/4 wielkości elementu blokowego, tylko chcesz napisać $width / 4. Zainteresuj się LESSem bądź SASSem. Swoje CSSy napiszesz w ich języku, a następnie przetworzysz powstały kod na taki, który bez problemów przeczyta przeglądarka.

Konkurencją dla LESS i SASS jest z kolei Stylus.

Bootstrap

Bootstrap to głównie framework CSS (choć znajdziecie też kilkanaście widgetów napisanych w JavaScript), czyli zbiór plików CSS, gdzie autorzy zdefiniowali odpowiednie style dla najczęściej używanych na stronach internetowych komponentów, żebyś Ty mógł skupić się na implementowaniu designu strony. W Bootstrapie znajdziesz kod, dzięki któremu Twoje strony będą responsywne. Oprócz tego, nie będziesz musiał zawracać sobie głowy pisaniem kodu do ostylowania przycisków, breadcrumbów czy okienek modalnych. To już tam jest.

Grunt.js

Z reguły, podczas procesu web developmentu, a szczególnie aplikacji w JS, wykonujemy podobne, powtarzające się czynności. Sprawdzamy nasze pliki w JS Lint/Hint, pakujemy nasz kod, by zajmował mniej, czy uruchamiamy testy jednostkowe. Aby nie uruchamiać tych rzeczy pojedynczo, tylko zautomatyzować cały proces buildowania swojej aplikacji, powstał Grunt. Dzięki niemu łatwo zaprogramujesz, co ma się dziać po zakończeniu developmentu lub w jego trakcie – na przykład po każdej zmianie w którymś z plików. Potrzeba przetłumaczyć pliki LESS na CSS? Nie ma problemu, w Gruncie zaprogramujesz to bez żadnego trudu.

Angular.js

Furorę robi ostatnio framework JavaScript Angular.js, dzięki któremu proces tworzenia aplikacji JavaScript jest jeszcze szybszy. Dzięki niemu można między innymi bardzo łatwo można powiązywać widoki pisane w HTMLu z modelami danych w JS, choć to dopiero początek listy zalet tej biblioteki. Dzięki Angular.js wiele procesów związanych z obsługą widoków i danych w JS staje się banalne proste (MVVM), a cały projekt mocno korzysta z Dependency Injection.

Bower

Brakowało Ci systemu, dzięki któremu łatwo zorganizujesz kod w większe pakiety oraz zdefiniujesz zależności między nimi? O co chodzi? Na przykład Twoja aplikacja jest oparta na jQuery, a Ty nie chcesz udostępniać pliku z tą biblioteką w swojej aplikacji (przecież w międzyczasie może wyjść nowa wersja jQ), a po prostu skonfigurować ją w ten sposób, że dzięki specjalnemu oprogramowaniu jQuery zostanie pobrane automatycznie po „zainstalowaniu” pakietu z Twoją aplikacją? Zrobisz to dzięki Bowerowi.

Yeoman

Yeoman to zbiór narzędzi (zawiera między innymi Bowera czy Grunta), który… automatyzuje pewne procesy, które wykonujemy, począwszy od stworzenia folderu naszej aplikacji. Potrzebujesz prostego, startowego szkieletu aplikacji napisanej w Backbone.js? Odpowiednio konfigurując Yeomana zrobisz to dzięki jednej komendzie. I nie tylko.

Systemy szablonów

Wyobrażasz sobie systemu szablonów, gdzie na przykład struktura HTML widoku newsa jest zapisana w pliku news.tpl, a w nim coś w stylu poniższego kodu?

<h1>{{title}}</h1>
<p>{{content}}</p>

Nie musisz wtedy programować każdego elementu widoku z osobna i przypisywać im wartość do innerHTML. Zrobi to dla Ciebie któryś z systemów szablonów, na przykład Mustache lub Handlebars.

Require.js

Załóżmy, że jeden z Twoich modułów, nazwijmy go X wymaga, aby dołączony do strony był inny moduł – powiedzmy Y, inaczej nic nie zadziała. Co więcej, chcesz załadować X tylko w konkretnym przypadku, na przykład kiedy user kliknie na konkretny przycisk. Zrobisz to z Require.js. Największą zaletą Require.js jest bardzo jasny podział kodu JS na moduły oraz definicja zależności między nimi.

Webmake

Webmake to podobny projekt do Require.js, natomiast wtórujący zupełnie innej filozofii. Otóż Twoja przeglądarka domyślnie nie zrozumie modułów napisanych w Webmake. Najpierw musisz je przetłumaczyć, przepuszczając kod przez specjalny parser. Plik wynikowy dołączasz do pliku HTML jako normalny skrypt JS i cieszysz się działającymi modułami. Największą różnicą między Webmake a Require.js jest to, że ten pierwszy, jeśli chodzi o API, jest napisany w stylu CommonJS, a drugi w AMD. Idą a tym pewne konsekwencje, na przykład to, że kod JavaScript napisany w Webmake zadziała w node.js, natomiast w przypadku Require.js potrzebny będzie dodatkowy moduł node’a.

Markdown

Dla wielu osób pisanie HTMLa jest dość czasochłonny, procesem (mimo narzędzi takich jak Emmet), a sam język wydaje się dość przekombinowany. Markdown wygląda na idealną alternatywę, proponując prostszą składnię, będąc przy tym przydatnym formatem m.in. do pisania dokumentacji kodu. Na przykład listę ul otrzymasz pisząc tak, jak poniżej:

*   Red
*   Green
*   Blue

Oczywiście, by otrzymać kod HTML na podstawie kodu Markdown, musimy użyć specjalnego parsera.

CoffeeScript

CoffeeScript to język programowania, który jest kompilowany do JavaScriptu. Można by rzec, że w CoffeeScript kilka firm Ruby on Rails zaczęło pisać aplikacje JS, by potem przetłumaczyć powstały kod na JavaScript i wydać swój produkt. To było dość dobre, tym bardziej, że nowa wersja ECMAScript zaczerpnęła z Coffee parę inspiracji. W pewnych kręgach CS stał się bardzo popularny, przyspieszając nieco proces developmentu. Złą stroną tego przedsięwzięcia jest jednak to, że kolejne kilkanaście osób zobaczyło, że możliwe jest pisanie JS bez jego znajomości, w tym wydawanie całych bibliotek napisanych w tym kawowym języku. Nie idź tą drogą.

A jak wygląda zbiór narzędzi u innych?

W tym celu spytałem Kamila Trebunię, Mariusza Nowaka oraz Tomasza Tunika, cenionych programistów HTML5/JS, jak przeważnie wygląda ich zbiór narzędzi i jaki sposób go używają.

Kamil Trebunia: Yeoman! Yeoman zmienił *dla mnie* wszystko. Jest dla mnie największą rewolucją od czasu gdy poznałem Git. Zajęło mi chwilę, żeby przywyknąć do korzystania komend generujących szablony, a po jakimś czasie i tak przepisuję Gruntfile.js na nowo, ale już nie wyobrażam sobie bez niego życia.

Każdy nowy projekt zaczynam od yo angular, po czym odpalam grunt server i jestem gotów do pracy. Mam samoczynnie odpaloną przeglądarkę w której działa przykładowa aplikacja, która odświeża się automatycznie gdy zapisuję zmiany w kodzie źródłowym.

Ale da się jeszcze lepiej… Odpowiednio skonfigurowany Gruntfile.js pozwala mi w tym momencie rozpoczynać pracę od odpalenia komendy grunt. To odpala mi proces, który obserwuje zmiany w plikach źródłowych i automatycznie je lintuje, unit testuje, kompiluje LESS do CSS i odświeża aplikację w przeglądarce (w miarę możliwości bez przeładowywania całej strony). O problemach jestem powiadamiany niemiłym “beep” wydobywającym się z głośników. Gdy chcę teraz stworzyć np. nową „podstronę” w mojej aplikacji, to korzystam z szablonów do Yeomana – wpisuję yo angular:route myRoute i to utworzy mi zalążki plików HTML z widokiem, JS z kontrolerem widoku oraz unit testów dla tegoż kontrolera. Yeoman spróbuje również załączyć powyższe pliki do index.html, a definicję podstrony wrzuci w konfigurację routera. Gdy mój kod jest gotowy wpisuję grunt deploy, po czym mój kod jest jeszcze raz testowany, budowany, a następnie wypchnięty na (testowy) serwer, który swoją drogą nie wymaga żadnej konfiguracji (Nodejitsu).

Ostatnim krokiem – gdy skończę pracę nad daną funkcjonalnością bądź poprawką – jest zwyczajny git push (oraz ewentualny pull request przed mergem z branchem “master”) – to wrzuci mój kod na GitHub, który powiadomi o tym fakcie nasze środowisko do Continous Integration (Circle CI), a ten z kolei przetestuje kod w osobnej chmurze (Sauce Labs), zbuduje go i na końcu uruchomi na produkcyjnym serwerze.

Wspomniałem na początku i jeszcze tylko przypomnę, że niezwykle ważną rzeczą jest dla mnie Git. Jestem wielkim fanem procesu opisanego w artykule Understanding the Git Workflow oraz zasad GitHub Flow.

W niedalekiej przyszłości zamierzam skonfigurować Protractor do testów end-to-end – lokalnie oraz w chmurze (Sauce Labs).

Mariusz Nowak: Jeśli chodzi o przeglądarkę, używam Google Chrome (niestety wciąż najlepsza do developmentu, choć ze względów ideowych mam nadzieję kiedyś przejść na Firefox’a). Na co dzień koduję w Emacs (moje ustawienia). Czemu Emacs? Parę lat temu byłem mocno sfrustrowany pracą z ciężkimi przywieszającymi się IDE, pierw dałem szansę VIM’owi, potem poświęciłem parę tygodni na dobre zapoznanie się z Emacs’em, który bardziej przypadł mi do gustu jako wielozadaniowy edytor.

Co do narzędzi… Przede wszystkim programuję w JS (HTML/CSS w bezpośredniej formie dotykam sporadycznie), więc większość moich narzędzi to po prostu moduły JS. Jak organizuję kod? Ponad dwa lata temu miałem możliwość zacząć pracę przy projekcie stricte na nowe silniki, wówczas przestawiłem organizację kodu na styl Node.js, który wraz z NPM jest wg mnie najlepiej zaprojektowanym system zależności jaki obecnie posiada JavaScript. Wszystko pakuję pod przeglądarkę za pomocą Webmake. Swój kod sprawdzam w JS Lincie. Mam nawet zmodyfikowaną wersję JSLint’a (mam to też podpięte bezpośrednio pod edytor). Co do xlint’a to muszę opublikować nową wersję na NPM’ie, obecnie opublikowana jest już mocno nieaktualna…

Obecnie swój kod testuję tylko w konsoli node’em (czyli tylko silnik V8 oraz jsdom, jeśli potrzebuję implementacji HTML+DOM). Może to się wydawać dość ograniczone, nie mniej w dzisiejszych czasach, kiedy znamy i trzymamy się standardów, to zdaje egzamin. Przeglądarki są dość zgodne i błędy związane z różnicami między nimi nie są tak częste, jak kiedyś.

Testy konfiguruję i odpalam za pomocą TADa. TAD podaje standardowy toolkit assert’ów, automatycznie na podstawie struktury katalogów wiąże testowane moduły z ich testami i sekwencyjnie odpala wypuszczając czytelny log.

Tomasz Tunik: Mój „toolchain” i środowisko robocze to ostatnimi czasy wielkie dzieło redukcji i upraszczania. Javascript ma chyba najbrutalniej rozwijające się środowisko ze wszystkich języków. Rewolucja goni rewolucję, a bezludnych szańców porzuconych rozwiązań ostatecznych jest więcej niż developerów, którzy mogliby je obsadzić. Rozwiązania, które definiowały developerskie „wczoraj” w świetle „dzisiaj” zdają się być odległą przeszłością, pod którą wstyd się podpisać, a „jutro” w tym wszystkim to trochę taki obraz strachu i gadżeciarskiej fascynacji, rzucania na nowe rozwiązania i walki w obronie jednej racji przed drugą. O ile kiedyś sam z chęcią pchałem się na te szańce i wybiegałem czasem przed nie, jakoś z wiekiem mi to przeszło i pozostawiam rewolucję młodszym developerom – niech zaburzają status quo i pchają do przodu ten wóz, na którym ja sobie pozwoliłem wygodnie się rozsiąść.

W tej wygodnej pozycji staram się ograniczyć ilość szumu związanego z wyborem i ewolucją i otaczam się paroma dobrymi przyjaciółmi, którzy codziennie towarzyszą mi w realizowaniu tego co muszę zrobić. Sublime Text z pluginem sublimelint na żywo sprawdzającym kod za pomocą JSHint i skrypt bashowy dodający autouzupełnianie komand i branchy do Githuba to tak naprawdę wszystko czego używam. Jeżeli chodzi o środowisko niezmiennie od dwóch lat AMD + Backbone, pakowanie tego i optymalizacja już zależą od projektu. QUnit albo Jasmine + PhantomJS żeby wpiąć to w CI… jeżeli jest czas – chociaż mam wrażenie, że skazany jestem już na budowanie samolotów w locie, gdzie ważniejsze jest dodać skrzydło niż opisać procedurę sprawdzającą czy skrzydło jest na miejscu. Do tego pełna znajomość każdej zakładki i opcji dostępnych w Chrome Dev Toolsach i to by było tyle tak naprawdę. Jeżeli muszę stworzyć nową architekturę, sporo czerpię z tego zestawu traktując Backbone’a jako silną bazę ideologiczną do tworzenia czegokolwiek i AMD jako mechanizm bezpieczeństwa przed nadmiernym rozrostem struktur (300+ linii per plik i zapala się lampka bezpieczeństwa). Dzięki temu, że wszystkiego jest tak mało, mogę bez problemu zmieścić się na swoich 13”, nie tracąc komfortu pracując w ruchu. Nie tęsknię za dwoma zewnętrznymi monitorami, które zostawiłem daleko za sobą.

Raz na jakiś czas zaburzam ten spokój i sięgam po inne rozwiązania żeby trzymać rękę na pulsie, ale póki co od dwóch lat zostaję wierny temu zestawowi – chociaż uważam, że jest masa równie dobrych narzędzi (zwłaszcza jeżeli chodzi o MVC i pochodne), za pomocą których można by osiągnąć to samo.

Z rzeczy, które ostatnimi czasy wywarły na mnie spore wrażenie, na pewno muszę wymienić Compass’a, którego poznałem przy okazji pracy pierwszy raz od dłuższego czasu nad typowo webowym projektem i jego zdolność do tworzenia spritesheetów w locie i upraszczania całego procesu tworzenia i optymalizacji CSSów i reszty.

A Wy? Jakich narzędzi używacie?

Komentarze

1

Mimo wszystko jako IDE polecam NetBeansa – zwłaszcza gdy front-endowiec musi się czasem babrać backendem ;)
Konsola wbudowana w Firefoxa (nie Firebug) jest również ciekawa – często dowiemy się z niej więcej niż z panelu Developer przeglądarki Chrome

2

@procek „więcej” czyli…?

Lukas
3

Moje narzędzia nie są tak dopracowane ani zaawansowane, ponieważ nie pracuję zazwyczaj z „hardkorowym” JavaScriptem.

Używam Sublime Text* z dodatkiem Emmet oraz od niedawna Emmet LiveStyle do CSS – http://livestyle.emmet.io Gdy raz na jakiś czas LiveStyle odmówi posłuszeństwa bez powodu, zastępuję go LiveReload.

Do obsługi Gita polecam GitBox. Zmiejsza on ryzyko „zamotania” się z terminalem. Na początku używania Gita używałem jednak tylko linii poleceń – pozwoliło mi dobrze zrozumieć to narzędzie.

Niedawno odkryłem też Localtunnel – http://progrium.com/localtunnel/ – dzięki niemu mogę szybko pokazać coś z lokalnego serwera znajomemu/klientowi.

Z rzeczy prawdopodobnie totalnie nie dla front-endowców i totalnie passe w dzisiejszych czasach: polecam darmowy Sequel Pro do zarządzania bazą MySQL: http://www.sequelpro.com To tak dobrze zrobiona, _darmowa_ aplikacja, że musiałem się nią podzielić ;)

Terminal.app zamieniłem na iTerm 2 oraz https://github.com/robbyrussell/oh-my-zsh – polecam każdemu.

(Szkoda, że nie można edytować komentarzy, bo pewnie coś jeszcze mi się przypomni.)

Dzięki za ciekawy artykuł oraz przepytanie kilku deweloperów. Jedyne czego mi tutaj brakuje, to opis Twojego workflow ;>

* – w tym miejscu pragnę uprzedzić fakty i zaprotestować nazywaniem tego edytora „darmowym”, co widziałem już w paru miejscach w internecie. To, że aplikacja nie domaga się mocno kupna licencji, nie oznacza że powinniśmy to robić.

pim
4

Ja mam 2 zestawy: jeden do frontu (Sublime + pluginy), a drugi do backendu (ciągle PHP i Python ciągle mi się pisze lepiej w NetBeans).
Ponadto, Bootstrap, Backbone, GIT i Yeoman.

5

@Lukas – zerknij na konsolę podczas wczytywania strony. W Chrome masz np. GETy w Network – tutaj leci to wszystko w konsoli i dzięki temu szybciej można znaleźć błędy związane z błędną komunikacją.
Co komu wygodniejsze :)
Inna sprawa, że nie wyobrażam sobie testowania rozwiązań webowych w tylko jednej przeglądarce… Z Chrome korzystam równo często jak z Firefoxa.

6

Pytanie może głupie, ale cóż, przyznaję, że z JS nie jestem do końca na czasie, bo siedzę głównie w świecie PHP. Czy te wszystkie zabawki jak npm, yeoman, bower, itp działają i instalują się normalnie pod Windowsem? Widzę, że jest tu sporo terminala, a terminal nie do końca kojarzy mi się z tym systemem. Pamiętam, jak walczyłem kiedyś z instalacją pod Windows Pythona i Django (chciałem móc używać różnych wersji Django dla różnych projektów). Straciłem dzień przez to, bo non stop były jakieś problemy z instalacją różnych bibliotek. Ta sama czynność pod Debianem zajęła mi 5 minut.
Czy z narzędziami do JavaScriptu jest podobnie?

Michal L
7

Michał, tak wszystko gra pod Windowsem bez większego problemu.
node+npm już od wersji 0.6 działa naturalnie na windzie a yeoman i bower stoją na node.

8

Dziwi mnie, że nikt nie wspomniał o TestCafe – http://testcafe.devexpress.com/.

9

Emmet nie jest podobny do Zen Coding, to jest po prostu jego nowa nazwa. Nawet w dokumentacji stoi jak byk „Emmet (previously known as Zen Coding)” :)

mck
10

Co nie znaczy, ze nie jest podobny. Znalem ten fakt, dodalem go.

11

Osobiście korzystam z SublimeText2 i nie zamieniłbym go na nic innego. Sporadycznie VIM, głównie do git’a ;)

michal
12

Ja tam wolę kombajny typu netbeans ;) Ale co kto lubi.

hyh
13

Ten Yeoman kojarzy mi się z hipsterstwem. Ja preferuję Adobe Brackets z podglądem na żywo i Emmet. Ale do NetBeansa też mam sentyment. Do tworzenia produkcyjnego kodu JS używam Closure Compiler, jest do ściągnięcia z Google Code.

Józek
14

Popieram sublime’a – jednakże ostatnio (jakieś 2-3 miesiące) Cloud9 załatwia wszystko :), świetny edytor, pluginy (zen, formatowanie kodu, podpowiedzi idp), połączenie z githubem, niedawno doszła opcja odpalenia własnego msql-a

Tak więc – kodować nie umierać ;)

pch
15

@michal: ja ostatnio zamieniłem Sublime Text 2 na coś innego – na jego kolejną wersję. ;)

Jest parę przyjemnych różnic, wszystkie interesujące mnie wtyczki działają bez problemu, a póki co napotkałem tylko na jeden błąd (bez wyraźnego powodu wywaliło mi pakiet kolorowania składni dla LESS, ale reinstalacja załatwiła sprawę). A konsola w nim z wyszukiwaniem heurystycznym działa przegenialnie. :3

16

CoffeeScript jak dla mnie jest nieczytelny.
Klamry to dla mnie podstawa. Łatwiej mi ogarnąć dłuższy blok kodu niż jedno liniowy zapis w stylu:

bla blablabla for blablabla in blabla when blablabla isnt blabss

W JS nawet każdego ifa z klamrami zapisuje, bo wielokrotnie naciąłem się na czyjeś pułapki w stylu:
if(true)
lorem.ipsum();

Natomiast SASS to coś fajnego, klamer tam nie brakuje :)

17

głównie dla siebie programuję ale później chce zarabiać i puki co phpDesigner się fajnie pisze co wystarczy że klepnę chociaż 1 literkę i już włączy się automatyzacja kodu z podglądem do czego służy, co akurat mi pasuje i na bieżąco 1 przyciskiem mogę sprawdzić czy dany kod zadziała jak chce, głównie w php piszę ale js też trzeba czasem użyć :)

erochan
18

Witam
Dopiero zaczynam. Używam Netbeans i mam pytanie co trzeba zrobić by się przeglądarka odświerzała automatyczie po edycji kodu. Za każdym razem otwiera mi nową zakładkę w przeglądarce.
Pozdrawiam Jakub

19

[…] Jak przyspieszyć proces tworzenia stron? Lista narzędzi, które powinieneś znać […]

20

Zabrakło mi tu NetBeans. Używam go ponad dziesięć lat i próbowałem przejść na inne edytory ale jakoś w moim odczuciu nic NB nie jest w stanie przebić. Pracowałem nawet na wcale nie tanim Zend Studio i też wróciłem do NB. Również jest do niego wiele wtyczek, obsługuje wiele formatów kodu, ma wbudowanego klienta ftp, świetnie współpracuje z różnymi systemami kontroli wersji. Naprawdę zachęcam do bliższego zapoznania się tym narzędziem.

Dodaj komentarz

Dozwolone tagi: <blockquote>, <code>, <strong>