> Jest wiele powodów by nie robić tego w ten sposób.

A jednak pobawię się w adwokata diabła i spróbuję znaleźć kontr-argumenty.

> Goły HTML, JS i CSS
> oznacza, że trzeba narąbać tony (istniejącego już) kodu, który załata wiele
> braków i niedoróbek tej golizny.

Np. jakich braków i niedoróbek? Myślałem, że kolejne standardy tychże były
opracowywane właśnie z myślą o usprawnieniach. Rozumiem, że 20 lat temu czegoś mogło
tam nie być, ale czego tam nie ma w 2020 roku?

> Wymyślając te swoje ficzery tworzysz de
> facto kolejnego frameworka,

Tak. Prawdę mówiąc każdy projekt, jeśli jest właściwie i na bieżąco refaktoryzowany,
wyłania coś, co ma szensę istnieć odrębnie. To może być jedna funkcja pomocnicza, a
może być framework. Albo cokolwiek pomiędzy.

> z tym, że nikt poza Tobą i Twoim zespołem go
> nie zna.

Ale za to ja i mój zespół znamy go w 100%.

> Zatrudnij teraz do zespołu nowego developera i każ mu to
> zrozumieć, rzeźnia.

Z moich doświadczeń wynika, że nowy developer najwięcej problemów ma ze zrozumieniem
dziedziny problemu, czyli przedmiotu realizowanego projektu. Ogarnięcie się w samym
kodzie i rozwiązywanie kolejnych wyzwań przez analogię z istniejącym kodem jest
najmniejszym problemem.

> Dodatkowo musisz pisać dokumentację.

Od kiedy pisanie dokumentacji jest złe? :-)

> Używając
> frameworka open source masz produkt rozwijany za darmolca przez
> setki/tysiące developerów,

Z pierdylionem rzeczy, których nie potrzebuję, ale które muszę zintegrować, i
zapłacić za nie pamięcią, pasmem, itp.

> Dodatkowo, gdy potrzebujesz zmienić kogoś w zespole lub nawet cały
> zespół to szukasz developerów znających X, Y lub Z i masz niemal od strzału
> gotowego programistę,

I tu mam przeciwne spotrzeżenie. Ilość dostępnych frameworków oznacza, że ten
ekosystem jest niesamowicie sfragmentowany, więc pula "talentów" jest mniejsza, niż
mogłaby być, gdybyśmy celowani w bardziej podstawowe rozwiązania. Konkretnie: jak byś
nie liczył, ilość developerów znających jakiś wybrany framework do JSa jest mniejsza,
niż ilość developerów znających JSa.
A to oznacza, że developer znający framework X sam siebie uzna za bardziej
wyjątkowego (i słusznie), przez co będzie droższy. Czyli developer od frameworka X
będzie droższy, niż developer od JSa.
I teraz mam zatrudnić cały zespół takich jednorożców?

To samo dotyczy wymiany zawodnika na innego.

Jeszcze gorzej, jak się nam projekt zestarzeje, po tym jak wszystkich zaskoczył i
niestety odniósł sukces. Wtedy okaże się, że poszukiwanie developera znającego jakiś
niemodny już framework będzie podobne do szukania programisty np. COBOLa.

Jeśli mówimy o kosztach, to właśnie teraz o nich mówimy.

> Ponadto popularne frameworki mają masę dodatkowych narzędzi wspomagających
> typu pluginy do edytorów,

Których nie potrzebuję jeśli nie używam frameworków? Czyli frameworki rozwiązują
problemy, których nie mam, jeśli ich nie używam? :-)
Albo i nie rozwiązują. Co jeśli mój ulubiony edytor nie jest ulubionym edytorem
młodzieży pasjonującej się jakimś "nowoczesnym" frameworkiem?

> Masz też często literaturę na ich tenat.

Znowu - nie potrzebuję jej, jeśli tych frameworków nie używam.

> Oraz olbrzymią bazę społecznościową,

Ale sfragmentowaną bardziej (a przez to mniej dostępną), niż bazę społecznościową
bardziej podstawowego stosu.
I przy bardziej podstawowym stosie mogę tej bazy społecznościowej potrzebować mniej.

To jak w końcu? Co jest tańsze?

Czy ktoś ma podobne obserwacje?

--
Maciej Sobczak * http://www.inspirel.com