On Wed, 20 May 2020 11:46:05 -0700 (PDT), Maciej Sobczak wrote:

>> 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?

Owszem, jest tych braków coraz mniej, ale są, a po drugie nie w każdej
przeglądarce wszystko dsziała identycznie, dlatego stosuje się tzw.
polyfille i biblioteki ujednolicające interfejs, podam dwa przykłady:
https://underscorejs.org/
https://github.com/axios/axios

Podobnie np. z HTML i CSS, szybciej i wygodniej buduje się stronę na
Bootstrapie, niż w gołym kodzie - choć to ostatnio jest już prawie
niepotrzebne.
Niemniej, gdy znasz np. Bootstrapa to czytając HTMLa z użytymi klasami BS
od razu wiesz jak to się zachowa, a gdy masz zamknięte wynalazki to musisz
szukać źródeł i ryć.

>> 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%.

No... albo tak albo nie... a na końcu okazuje się, że pod presją czasu,
product managera lub czegokolwiek ten wasz framework to potworek o dwunastu
głowach i sześciu ogonach, którego tak naprawdę nikt już nie ogarnia. A
dokumentacja? ...eee... no nie pisaliśmy, bo każdy znał na 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.

Zależy o jakim poziomie mówisz, bo ten z samego dołu developer to klepacz
kodu, nie zna i nie musi znać dziedziny, on ma zadanka w tablicy agilowej i
koduje.

>> Dodatkowo musisz pisać dokumentację.
>
> Od kiedy pisanie dokumentacji jest złe? :-)

Kto twierdzi, że złe? Jest kosztowne.

>> 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.

Jeśli wybierzesz nieodpowiedni framework to tak.

>> 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.

To powiedz mi czym się różni znalezienie programisty do dobrego,
udokumentowanego i przetestowanego frameworka, który dziś już nie jest w
pierwszej piątce od znalezienia programisty do autorskiego, zamkniętego i
dużo mniej dopracowanego frameworka pisanego w firmie?

>> 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? :-)

To czy potrzebujesz to Twój wybór, osobisty. Ja mówię o tym, że są
narzędzia bardzo przyspieszające i organizujące pracę w danym frameworku,
bo ku temu zostały stworzone. Nie mam na myśli narzędzi, które utrudniają
pracę czy bez których nie da się frameworka używać.

> 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?

Wtedy nie masz takich narzędzi, czyli dokładnie tak jak z autorskim
frameworkiem.

>> Masz też często literaturę na ich tenat.
>
> Znowu - nie potrzebuję jej, jeśli tych frameworków nie używam.

Z kolei używając swojego nawet jeśli jej potrzebujesz to nie masz.

>> 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.

Nawet mocno pofragmentowana jest o kilka rzędów większa niż Twój zespół i
wszyscy znajomi programiści.

> To jak w końcu? Co jest tańsze?
>
> Czy ktoś ma podobne obserwacje?

No właśnie, ktoś coś?

--
pozdrawiam
Roman Tyczka