Pozwolę sobie wrócić do oryginalnego pytania. Zacznij od uwolnienia się trochę od myślenia, że musisz dokonać idealnego wyboru. Idealny wybór byłby wtedy, kiedy znałbyś dane narzędzie na wylot i dokładnie znał wszystkie (obecne i przyszłe) wymagania. Jedno i drugie jest niemożliwe do osiągnięcia, co oznacza, że w którymś momencie zawsze się przejedziesz. Wystarczy w zupełności sprawić, że rozwiążesz problem w takiej formie, w jakiej jest to satysfakcjonujące i dla Ciebie, i dla Twojego klienta :).
Jak to zrobić? Przykładowo, możesz sobie narzędzia przeanalizować pod kątem jakichś kryteriów:
- jakie masz z nimi doświadczenie,
- czy projekt dopiero wystartował czy jest już w miarę dojrzały,
- jak duża jest społeczność stojąca za danym projektem,
- jak duża jest bariera wejścia dla nowej osoby,
- czy projekt ma jasno opisane założenia.
I potem przyglądasz się im w kontekście tego, co chcesz zrobić:
A. masz zadanie stworzenia niewielkiego projektu, który ma jasno określony czas trwania. Po jego zakończeniu będzie on używany, ale raczej nie będzie już rozwijany zbyt aktywnie.
To jest projekt, w którym osobiście pozwoliłbym sobie na eksperymenty. Jest to miejsce, gdzie można śmiało przetestować jakieś mniej popularne bądź "wschodzące" narzędzia.
B. tworzysz projekt, który będzie rozwijany przez dłuższy czas i będą pojawiały się nowe funkcjonalności. Kod jest dla Ciebie i Twojego zespołu i nikogo innego.
Kluczowe narzędzia takie, jak framework - warto wybrać coś, co choć trochę sprawdziło się w boju, ma dokumentację i jest jakaś społeczność, która danego projektu używa. Projekt będzie istniał przez dłuższy czas, być może przyjdą nowi ludzie. Fajnie byłoby zwiększyć swoje szanse na to, że będą dane narzędzie znać, albo chociaż kojarzyć, aby nie przyuczać ich od zera. Nie przejmowałbym się aż tak mocno barierą wejścia. Jeśli chodzi o Twoje doświadczenie, to sprawa wygląda tak: jak je masz, to super. Jak go nie masz, na bank popełnisz na starcie jakieś błędy projektowe, które później wypadałoby jakoś odkręcić. Możesz zainwestować wcześniej w prototyp, jak masz czas, aby trochę tego doświadczenia zdobyć.
C. tworzysz jakiś framework czy bibliotekę dla innych zespołów. Będziesz miał duże grono technicznych użytkowników.
Tutaj wybór narzędzi musi być przemyślany, gdyż Twoje decyzje mogą wpływać na wiele produktów i kwestie takie, jak społeczność, wsparcie techniczne czy bariera wyjścia odgrywają duże znaczenie. Jeśli ludzie będą mieli problemy i nie będą potrafili ich rozwiązać, przyjdą do Ciebie prosić o pomoc. Jeśli ich będzie dużo, umrzesz pod nawałem pytań. Jeśli robisz framework, lepiej brać też mniejsze biblioteki i komponować z nich gotowe rozwiązanie. Budowanie frameworka na frameworku może się skończyć tym, że bazowy framework zacznie Cię mocno ograniczać. Warto też przyjrzeć się tutaj, z jakich narzędzi korzystają przyszli użytkownicy Twojego projektu i odpowiedzieć sobie na pytanie, jak może wyglądać integracja z nimi.
Niezależnie od Twojego zadania, zawsze trzeba przyjrzeć się założeniom narzędzia. Jeśli stoją one w sprzeczności z tym, co masz zrobić, to automatycznie one odpadają. Cóż, reszta to - jak koledzy wspomnieli - doświadczenie i uczenie się na błędach :).