Realia komercyjne w aplikacjach webowych są takie, że projekty trwają wiele lat i zysk kilku dni na przestrzeni kilku lat jest pomijalny, a liczy się przede wszystkim elastyczność frameworków i komponowalność jego elementów. Nawet jeśli pisząc we frameworku X okaże się, że trzeba będzie trochę rozwleklej oprogramować te same komponenty niż we frameworku Y to i tak niekoniecznie będzie to miało duży wpływ na szybkość tworzenia aplikacji, bo zwykle i tak przy tworzeniu N-tego komponentu zauważa się kolejne duplikacje kodu i wyodrębnia kolejne abstrakcje. Sposób w jaki wyodrębni się te abstrakcje definiuje styl pisania kodu w projekcie, więc summa summarum różnice we frameworkach tego samego typu się zmniejszają.
Sztandarowym (dla mnie) przykładem marketingowego bubla jest Hibernate i wszelkie wynalazki do niego podobne (czyli np też wywodzący się od niego NHibernate). Hibernate w tutorialach wygląda na coś wspaniałego, bo załatwia od razu tworzenie tabel w bazie, mapowanie między nimi, a obiektami oraz automatycznie tworzy zapytania do bazy. W praktyce jednak jest kulą u nogi, bo:
- nie zawsze mapowanie 1:1 między bazą, a obiektami jest właściwe,
- skomplikowane i automatycznie obsługiwane hierarchie obiektów zniechęcają do przepakowywania modelu bazodanowego w niezależny model obliczeniowy/ widokowy, a to z kolei powoduje duże sprzężenie między wszystkimi warstwami aplikacji,
- jedna strategia wyciągania danych z bazy nie jest właściwa we wszystkich zastosowaniach, więc trzeba to omijać za pomocą Criteria API lub JPQL bezpośrednio,
- wzbogacanie bajtkodu przez Hibernate powoduje niespodzianki jeżeli nie przepakuje się w odpowiednim momencie modelu bazodanowego w inny,
Ogólnie nie rozmawiałem z nikim, kto byłby zadowolony z użycia Hibernate. Ludzie zwykle na to narzekają. Mimo wszystko marketingowo wygląda świetnie i ludzie się na to nabierają. Stąd należy zwracać uwagę na faktyczne wady i zalety, a nie to co marketingowcy chcą wcisnąć.
Jeżeli znowu patrzymy na szybkość tworzenia aplikacji w kontekście stworzenia projektu na kilka miesięcy to prawdopodobnie wygrają frameworki typu Ruby on Rails, gdzie pisania jest najmniej. Tam szybkość stawiania aplikacji jest największa. Ale jeśli patrzymy w kontekście projektu na wiele lat, to kilkudniowe początkowe zyski nie mają znaczenia, a ważna staje się łatwość stabilnego rozwijania i utrzymywania projektu. Do tego potrzebna jest przede wszystkim elastyczność, testowalność oraz sensowna architektura. To pasowałoby porównać.