Może trochę źle wyraziłem swoje zdanie. Oczywiste, że wszystkiego nie będziemy stawiać zawsze od samego początku (budowanie prawie tej samej aplikacji na nowo). Chodzi mi o aktualne podejście programistów w stylu
"OO wyszedł framework (cms, orm itp), zobaczymy co potrafi i jedziem z biznesem"
Prawda jest taka że bierzecie do ręki kupe. Dobrze jej nie znacie, machnęliście na nim parę serwisów a jak przyjdzie po jakimś czasie klient i powie, że to wszystko wolno działa to jesteście ... nigdzie. Połowę tyle czasu jaki poświęciliście na tworzeniu tegoż serwisu spędzicie na jego optymalizacji i szukania wąskich gardłe, których nie znacie w FW. I do czego dojdziecie? Kupa śmieci jaką daje FW jest wam kompletnie nie potrzebna. I co wtedy? Sami odpowiedzcie na to pytanie.
ad 1) Sęk w tym, żeby coś używać to powinno się w to NAJPIERW zgłębić dość dokładnie. Kit z dokumentacją. Dokumentacja nie powie ci, że cały obekt acl dla 100 ról jest jednym obiektem ważącym 50 MEGA i ładowanym (zserializowany, to nie ma znaczenia, i tak tracisz 50 mega na bezsens) za każdym uruchomieniem strony. Istnieją pewne klasy narzędzia napisane bardzo lekko, sprawnie, dość uniwersalnie z możliwością rozszerzania. Lecz ich ilość jest tak mała, że zniechęca do przeglądania kolejnych tego typu rozwiązań.
Przykład z życia. Zend_Form, prawie super poza dekoratorami. Super, dodajesz dynamicznie atrybuty do każdego taga, bajka. Problem w tym, że DUŻO PROŚĆIEJ byłoby gdyby np taki input był plikiem szablonu, który sobie odpowiednio można zmodyfikować dla specyficznych pól. Dlaczego? lekkość, łatwość użycia, łatwość nauczenia, brak komplikacji przy większych formularzach (to zależy od programisty). Większość z was nie zwróci na to uwagę bo "działa, jest ok".
ad 2) W dużej mierze tak. Serwis jest dobry (pomysł,content), dobrze napisany, wydajny, mniejsze koszty jego utrzymania.
ad 3) To była ironia. Mówię, że porządnych i dobrych serwisów nie piszę się na FW. A jak już napiszą to przynoszą problemy w utrzymaniu. Z doświadczenia wiem, że spore.
Oczywiście, że pod aplikacje na lanie dla takiej ilości użytkowników nie musisz przykładać na to tak wielkiej wagi, (tak samo jak dla aplikacji na pulpit) ale w serwisach www jest taka konieczność. Czasem nawet w małych, ponieważ owych niuansów nie zauważysz na początku życia strony (mało danych, mało użytkowników, więcej "stronek" na jednym serwerze) a po roku ZONK.
Przykład z klientem jest trafnym, lecz chodzi mi o inne rozwiązanie. Usiąść, stworzyć coś własnego (mówię o FW, cms-ie itp), przetestować przez co:
1) Sami będziemy wiedzieli gdzie co jest w aplikacji i w mgnieniu oka będziemy w stanie dostosować ją do potrzeb klienta (wywalić rzeczy, których nie są potrzebne a zawadzają) itp itd
2) Łatwość zarządzania
3) + sporo nabytych umiejętności
4) cena w okolicach rozwiązania opartego na fw, lecz znacznie mniejsze koszty utrzymania
5) istnieje bardzo duże prawdopodobieństwo, iż pewne rozwiązania będą unikalne a czasem nawet lepsze od komercyjnych.
Przykład. Potrzebowałem swego czasu parsera bbcode, którego łatwo użyję, da mi dużo kontroli nad zawartością wpisywaną przez użytkownika, rozszerzalność itp. Nie znalazłem gotowego rozwiązania i byłem zmuszony do napisania swojego. Co by zrobiła reszta?
a) wzięła byle jaki

szukałaby, przerobiła i może by to jakoś działało
c) powiedziała, że bbcode niepotrzebny
Coraz częściej jak jakiegoś gotowca nie ma to odchodzicie od tworzenia owego rozwiązania bądź robicie po łebkach (oby wasze dzieci nie były tak zrobione

Jeżeli chodzi o lukę to łatwo ją zapełnić. INNYM PODEJŚCIEM PROGRAMISTYCZNYM. Nadal większość będzie robiła coś za kasę z czegoś za darmo i jest super więc rynek wyrównany.
Poza tym takie podejście automatycznie odsiewa lamusów i script kiddies od biznesu.
Na koniec taka ciekawostka. Popytajcie swoich znajomych programistów (nie tylko ich) "Co stworzyłeś własnego z czego jesteś dumny?". Ci którzy odpowiedzą "nic" są mniej warci w oczach pracodawców. Ale nie wierzcie mi na słowo. Sprawdźcie sami.