Pylons analiza SWOT - Weaknesses
Pora trochę pojechać…
Trochę już pracuję z Pylonsem oraz śledzę jego rozwój. Oprócz wymienionych wcześniej zalet ma on trochę wad. Zresztą jak każdy soft.
A więc:
Wczesna faza rozwoju
Numer 0.9.x mówi sam za siebie. Jest to framework rodzący się, na szczęście w nie zawielkich bólach :-) Poszczególne składniki są wymieniane, dopasowywane. Jak zaczynałem z Pylonsem preferowanym ORM’em był SQLObject a teraz jest SQLAlchemy. Kładąc nacisk na nowy ORM stary popada w niełaskę. Powodem tego były problemy z uruchomieniem aplikacji opartych na SQLObject w Pylonsie 0.9.3. Niezbędne było paczowanie frameworku. Naszczęście w kolejnej wersji było to już poprawione.
Innym przykładem niskiego numerka jest obecnie promowany na domyślny system szablonów Mako (obecnie w wersji 0.1.1).
Na szczęscie autorzy Pylonsa poważnie podchodzą do sprawy i każda zmiana w api jest opisywana w release notes, dodawane warningi i legacy mode.
Jest też trochę motania się w różnych rozwiązaniach. Z wersji na wersję zmienia się sposób dostępu do konfiguracji, który i tak jest niejasny. W większym projekcie może to spowodować trochę problemów.
Ogólnie przyjęta zasada, że dopiero wersja 1.0 powoduje większe zamrożenie api projektu pozwala stwierdzić, że należy uzbroić się w cierpliwość i dać kredyt zaufania dla twórców.
Słaba dokumentacja
Dokumentacja jest dosyć słaba. Ma to również związek z charakterem Pylonsa. Łączy on wiele projektów w jedną całość, daje wiele alternatyw. Dlatego też ciężko opisywać w dokumentacji szczegółowe zastosowanie poszczególnych składników. Wysyła natomiast do dokumentacji źródłowej projektów. Niestety dokumentacji tej nie da się zastosować 1:1 w środowisku Pylonsowym, więc użytkownika czeka żmudne wyszukiwanie pożytecznych informacji.
Na szczęście dokumentacja się powoli poprawia. Poczkamy zobaczymy.
Słaby PR
W porównaniu do Django i Rails Pylons ma straszcze słaby PR. Nie ma wielu artykułów. Nie ma wielu prezentacji. Dobrą stroną tego stanu rzeczy jest fakt, że autorzy skupiają się na jakości kodu a nie na rozgłosie. Potrafią sporo dywagować IRC’u na temat dobrych praktyk, oraz elegancji kodu.
Po premierze Pylonsa 1.0 szykowane są artykuły opisujące framework.
Małe “Community”
Również tutaj w porównaniu z Railsem i Django Pylons wypada cieńko. Mało (ale coraz wiecej) osób na ircu w miarę spokojna grupa dyskusyjna powodują, że wsparcie jest trochę mniejsze. Na szczęście ta mała społeczność jest przyjazna i często pomaga w problemach.
Brak wsparcia komercyjnej firmy
Moim zdaniem wsparcie komercyjnej firmy daje większe bezpieczeństwo. Tak jest w Springu czy Django. Firma dba o rozwój frameworku, pracownicy etatowi rozwijają kod. Firma czerpie z tego korzyści. Dba aby projekt nie umarł. W przypadku Pylonsa developerami są raczej hobbyści, którzy piszą kod po etatowej pracy. Żadna większa firma nie stoi za projektem. Istnieje niebezpieczeństwo znudzenia się któregoś z głównych developerów i opuszczenia projektu.