Przekleństwo frameworków Javowych

Dla Javy napisano już setki, jeśli nie tysiące szkieletów do pisania aplikacji webowych. Jeśli ktoś wnikliwie czyta newsy na theserverside to wie, że nowe frameworki powstają jak grzyby po deszczu.

Pytanie jednak brzmi... skoro każdy szkielet jest taki dobry, to czemu powstają nowe? Odpowiedź jest jedna - nie da się napisac szkieletu dla każdego. Ponadto wiele nowych frameworków bardziej utrudnia niż ułatwia życie programistów, starając się rozwiązać każdy problem. Świadczy może o tym na przykład fakt, iż wciąż najczęsciej używany jest Struts, pomimo swego sędziwego wieku.

Jakie więc powinny być cechy idealnego frameworka? W mojej opinii szkielet to narzędzie, które pozwoli programiście przede wszystkich na łatwiejsze i szybsze pisanie aplikacji. Dlatego też szkielet powinien być jak najprostszy, mieć przejrzyste API, zadbany i przemyślany kod źródłowy, aby programista mógł bez problemu go zrozumieć (często lepiej jest po prostu zobaczyć jako kod działa, aniżeli czytać często niekompletną dokumentację). Jeśli zaś mówimy o szybkości pisania aplikacji to developer powinien implementować ją w sposób niezwykle zwinny (ang. agile). Chodzi o to, żeby programista (na przykład na życzenie klienta) mógł bardzo szybko nanieść poprawki bez konieczności wprowadzania zmian w kilku miejscach, długim testowaniu aplikacji od strony GUI (na przykład w przypadku brak możliwości pisania testów jednostkowych dla komponentów GUI) czy wreszcie ciągłych restartów serwera. Jeszcze jedna kwestia - szkielet nie powinien w żaden sposób ograniczać programisty! Jeśli coś można w prosty sposób zrobić w HTMLu i JavaScriptcie, to i w tym szkielecie musi to być czynność prosta i przede wszystkim możliwa(!).

Oburzony brakiem "idealnego" frameworka, stworzyłem własny prototyp takiego szkieletu - zaprojektowany tak, aby mógłbyć podstawą większości aplikacji tworzonych w standardowym modelu klient-serwer (bez udziwnień AJAXowych, z wiszącymi połączeniami włącznie). Szkielet ten zawiera jedynie podstawową funkcjonalność (brakuje w nim chociażby walidatorów), jednak w mojej opinii jest ona w zupełności wystarczająca. Uznaję zasadę, że programista musi znać szkielet, którego używa w 100 procentach. Jeśli udostępniłbym programiście zaawansowane komponenty, to mógłby on w ogóle nie rozumieć zasady ich działania (co w końcu doprowadziłoby do poważnych przestojów w projekcie, związanyc z poprawianiem uprzednio napisanego kodu).

Ów prototyp okazał się na tyle ciekawy, że postanowiłem zacząć pisać projekt z prawdziwego zdarzenia. Projekt nosi nazwę Egg i jak sama nazwa wskazuje jest zalążkiem tworzonej przez Ciebie aplikacji. Używając go będziesz mógł stworzyć zarówno prostą, jak i szalenie skomplikowaną aplikację. Do niektórych jego cech należą: automatyczne reloadowanie klas bez restartów serwera, pełna obiektowość (możliwość tworzenia własnych komponentów w śmiesznie prosty sposób), DRY (zasada nie powtarzania kodu w różnych miejscach), CoC (konwencja zamiast konfiguracji) oraz możliwość łatwego testowania tworzenego GUI (na zasadach TDD). Wersja alpha projektu będzie dostępna w ciągu kilku dni na serwerach Google Code.