Trochę mało tu wątków tego typu.

Chciałem zapytać szanowne grono, czy uprawiacie taką aktywność świadomie *bez* użycia
popularnych frameworków. Pod pojęciem "świadomie" rozumiem, że wiecie o ich istnieniu
a może nawet je znacie, ale pomimo tego podjęliście decyzję, żeby ich nie używać
(może właśnie dlatego, że je znacie).

Chciałbym to skonfrontować z ogólnym obrazem rynku, gdzie pojęcia "web development"
oraz "framework do JSa" wydają się być powszechnie tożsame.

Po stronie serwerowej też mógłbym zapytać, czy ktoś z Was praktykuje web development
wykorzystując języki natywnie kompilowane, czyli np. C++ - tzn. nie jako dalszy w
szeregu komponent back-endu, tylko jako wiodące (albo jedyne) rozwiązanie. Wiem o
kilku takich serwisach i sam kiedyś taki zrobiłem, ale chciałbym wiedzieć, czy te
koncepcje są jeszcze praktykowane.

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

do góry

2020-05-18 o 13:19 -0700, Maciej Sobczak napisał:
> Chciałem zapytać szanowne grono, czy uprawiacie taką aktywność
> świadomie *bez* użycia popularnych frameworków.

Do poważnych rzeczy? Nie. Ale jeśli chodzi o jakiś prosty serwis
informacyjny dla firemki lub samorządu, tj. coś, co można naskrobać w
kilkunastu linijkach php, to jak najbardziej. Tutaj dwa luźne przykłady
moich ostatnich prac:
https://abibio.fr/
http://soay.fr/

> Po stronie serwerowej też mógłbym zapytać, czy ktoś z Was praktykuje
> web development wykorzystując języki natywnie kompilowane, czyli np.
> C++ - tzn. nie jako dalszy w szeregu komponent back-endu, tylko jako
> wiodące (albo jedyne) rozwiązanie.

Raz mi się zdarzyło, niejako dla eksperymentu:
http://poludnitsa.sourceforge.net/

Gdybym miał znów coś takiego robić, to użyłbym gołego php.

Dodam, że ja absolutnie nie jestem żadnym "web developerem", zdarzy mi
się czasem coś popełnić, ale to raczej w ramach wieczornej rozrywki.

Mateusz

do góry

W dniu wtorek, 19 maja 2020 11:30:21 UTC+2 użytkownik Mateusz Viste napisał:

> Do poważnych rzeczy? Nie.

A dlaczego? Bo w ogóle nie robiłeś "poważnych rzeczy", czy te poważne koniecznie
robiłeś/robiłbyś z frameworkami?

To jest pytanie o granice stosowalności tego pomysłu - tzn. nie-frameworkowego
web-developmentu.
Oczywiście można sobie porozważać, że w odpowiednio dużym projekcie, praktykowanym
odpowiednio długo, przez sam fakt refaktoryzacji istniejącego kodu jakiś framework
mógłby się spontanicznie sam wyłonić a skoro tak, to czemu od razu nie zacząć z
istniejącym już frameworkiem. Ale wtedy kolejnym pytaniem byłoby, czy w takim
projekcie warto mieć własne rozwiązanie, naturalnie dopasowane do projektu, w ramach
którego powstało, czy też obce, do którego trzeba od poczatku naciągać projekt.

(teoretycznie można ten argument zastosować do każdego frameworku lub biblioteki, nie
tylko w tej dziedzinie)

Czyli: bierzemy HTML+CSS+JS (bo powiedzmy, że się uzupełniają i żadnego z tych trzech
nie może zabraknąć) i... tylko tyle, przynajmniej po stronie klienckiej. Czy jest
granica stosowalności tego podejścia i dlaczego jest właśnie tam?

> > Po stronie serwerowej też mógłbym zapytać, czy ktoś z Was praktykuje
> > web development wykorzystując języki natywnie kompilowane, czyli np.
> > C++ - tzn. nie jako dalszy w szeregu komponent back-endu, tylko jako
> > wiodące (albo jedyne) rozwiązanie.
>
> Raz mi się zdarzyło, niejako dla eksperymentu:
> http://poludnitsa.sourceforge.net/
>
> Gdybym miał znów coś takiego robić, to użyłbym gołego php.

Eksperyment się nie udał? Czy udał się, ale dostarczył argumentów przeciw?

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

do góry

2020-05-19 o 13:32 -0700, Maciej Sobczak napisał:
> > Do poważnych rzeczy? Nie.
>
> A dlaczego? Bo w ogóle nie robiłeś "poważnych rzeczy", czy te poważne
> koniecznie robiłeś/robiłbyś z frameworkami?

Nie jestem web deweloperem, ale zdarzało mi się zarządzać
takimi projektami - w praktyce zawsze kończyło się na jakimś Symfony,
CakePHP czy innym NodeJS.

> To jest pytanie o granice stosowalności tego pomysłu - tzn.
> nie-frameworkowego web-developmentu.

Granica - w moim skromnym mniemaniu - jest tylko jedna: koszt.

> Ale wtedy kolejnym pytaniem byłoby, czy w takim projekcie warto mieć
> własne rozwiązanie, naturalnie dopasowane do projektu, w ramach
> którego powstało, czy też obce, do którego trzeba od poczatku naciągać
> projekt.

Z (mojej) praktyki raczej wynika, że jest wręcz odwrotnie - przy jakimś
in-house potworku szybko okazuje się, że ten potworek nie umie tego
albo tamtego (bo w początkowych specyfikacjach tego nie było), i trzeba
strugać go na bieżąco, dodawać wyjątki, itd. Natomiast gotowiec ma ten
etap z reguły już za sobą. Korzystają z niego rzesze programistów w
bardzo wielu projektach i dzięki inkrementalnym ulepszeniom daje radę,
jednocześnie zapewniając spójne API, przemyślane nazwy
klas/funkcji/zmiennych, itp.

> Czyli: bierzemy HTML+CSS+JS (bo powiedzmy, że się uzupełniają i
> żadnego z tych trzech nie może zabraknąć) i... tylko tyle,
> przynajmniej po stronie klienckiej. Czy jest granica stosowalności
> tego podejścia i dlaczego jest właśnie tam?

Koszt. Dlaczego? Bo wymyślanie koła na nowo kosztuje. Jeśli robisz to w
ramach hobby to spoko - ale w biznesowym świecie mało który klient
(z tych których znam przynajmniej) zgodzi się opłacać takie
przedsięwzięcie. Bo frontend ma działać, być gotowy na wczoraj, i ma
być tanio (tj. taniej niż konkurencja, przy tych samych wymaganiach).

> Eksperyment się nie udał? Czy udał się, ale dostarczył argumentów
> przeciw?

Udał się w sensie, że zapewnił mi rozrywkę na kilka wieczorów.

Argument przeciw jest taki, że kompilowanie dziada za każdym razem
kiedy chcę go wgrać na nową platformę (+instalacja gcc +ew. walki z
linkerem) jest po drugim razie... nużące. Plik PHP natomiast wystarczy
wrzucić i po prostu działa. Do tego C nie proponuje wielu
"oczywistych" (w świecie web) usprawnień, które w PHP są niejako od
zawsze - i wraca leitmotiv odkrywania koła na nowo (tak głupie rzeczy
jak np. "odczytaj wartość pola z formularza"). No i PHP jednak dużo
potrafi wybaczyć, a w C jedna literówka potrafi zakończyć się core
dumpem. W trakcie pracy dużo łatwiej zlokalizować problem z logów php
aniżeli analizować wypis z gdb. W końcu po coś te technologie "webowe"
ktoś wymyślił. :)

Mateusz

do góry

On Tue, 19 May 2020 13:32:30 -0700 (PDT), Maciej Sobczak wrote:

>> Do poważnych rzeczy? Nie.
>
> A dlaczego? Bo w ogóle nie robiłeś "poważnych rzeczy", czy te poważne koniecznie
robiłeś/robiłbyś z frameworkami?
>
> To jest pytanie o granice stosowalności tego pomysłu - tzn. nie-frameworkowego
web-developmentu.
> Oczywiście można sobie porozważać, że w odpowiednio dużym projekcie, praktykowanym
odpowiednio długo, przez sam fakt refaktoryzacji istniejącego kodu jakiś framework
mógłby się spontanicznie sam wyłonić a skoro tak, to czemu od razu nie zacząć z
istniejącym już frameworkiem. Ale wtedy kolejnym pytaniem byłoby, czy w takim
projekcie warto mieć własne rozwiązanie, naturalnie dopasowane do projektu, w ramach
którego powstało, czy też obce, do którego trzeba od poczatku naciągać projekt.
>
> (teoretycznie można ten argument zastosować do każdego frameworku lub biblioteki,
nie tylko w tej dziedzinie)
>
> Czyli: bierzemy HTML+CSS+JS (bo powiedzmy, że się uzupełniają i żadnego z tych
trzech nie może zabraknąć) i... tylko tyle, przynajmniej po stronie klienckiej. Czy
jest granica stosowalności tego podejścia i dlaczego jest właśnie tam?

Jest wiele powodów by nie robić tego w ten sposób. 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. Wymyślając te swoje ficzery tworzysz de
facto kolejnego frameworka, z tym, że nikt poza Tobą i Twoim zespołem go
nie zna. Zatrudnij teraz do zespołu nowego developera i każ mu to
zrozumieć, rzeźnia. Dodatkowo musisz pisać dokumentację. Używając
frameworka open source masz produkt rozwijany za darmolca przez
setki/tysiące developerów, udokumentowany, wytestowany na olbrzymiej
liczbie platform i środowisk, autonaprawiający się (bugi naprawia core
team). 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ę, który widzi kod i rozumie co się w nim dzieje.
Ponadto popularne frameworki mają masę dodatkowych narzędzi wspomagających
typu pluginy do edytorów, powiązane biblioteki rozwiązujące problemy nie
ujęte w samym frameworku, itd. Masz też często literaturę na ich tenat.
Oraz olbrzymią bazę społecznościową, gdzie możesz zadawać pytania i niemal
od ręki dostawać pomoc.

--
pozdrawiam
Roman Tyczka

do góry

> 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

do góry

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

do góry

> 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

Pojedyncze biblioteki są bezpieczniejszym rozwiązaniem, niż framework, który z natury
narzuca więcej. Ja nie mam problemu z bibliotekami.

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

Ale ja nie chcę mieć zamkniętych wynalazków, skoro ustaliliśmy, że ostatnio (i z
biegiem czasu) wszystko co potrzeba, jest w standardzie.

> 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% ;-)

Jest takie ryzyko. Ale ja widzę, że to samo dzieje się z zewnętrznymi frameworkami.
Gdy autorzy już ich nie ogarniają, to powstaje nowy framework. Jeszcze fajniejszy. I
pozbawiony wad poprzedniego frameworka!

To nie jest tak, że zewnętrzne rozwiązania się nigdy nie degradują. Degradują się a
nawet z tego powodu wychodzą z użycia. ActiveX? Applety? Flash? To są oczywiste
archaizmy, ale świat frameworków niebezpiecznie przyśpieszył i do tej grupy dołączają
frameworki, które jeszcze niedawno były cool.

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

Ja pracowałem w miejscach, gdzie jednak "ten z samego dołu" musiał wiedzieć, co
koduje. Bo by bez tej wiedzy po prostu nie zakodował. I ta wiedza jest zwykle
trudniejsza, niż znajomość frameworka.

> > Od kiedy pisanie dokumentacji jest złe? :-)
>
> Kto twierdzi, że złe? Jest kosztowne.

Policzmy. Nie za bardzo mam na czym liczyć poza moim projektem YAMI4, ale skoro go
mam, to policzmy. Lubię pisać "prozę" i nigdy nie słyszałem zarzutu, że moja
dokumentacja ma jakieś braki, więc uważam, że to właściwy przykład. Otóż w tym
projekcie dokumentację robi Doxygen z odpowiednich komentarzy w kodzie, których
jest... 5%, jeśli liczyć ilość linii. To jest wartość obiektywna, którą potrafię
zmierzyć - ale jest jeszcze odczucie subiektywne, że ta część dokumentacyjna się
zmienia najrzadziej (np. tam się nie robi optymalizacji, nie poprawia algorytmów, nie
debuguje, itd.), więc wysiłek w relacji do całości jest pewnie rząd, jeśli nie dwa,
wielkości mniejszy.

I to jest ten "koszt". Czyli żaden koszt.
Prawdziwym kosztem jest ten właściwy kod a nie dokumentacja. I tylko ten właściwy kod
może być motywacją do tego, żeby go nie pisać i postawić na istniejący framework.

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

Słusznie. A skąd mam wiedzieć, czy jest odpowiedni?
Zwykle wygląda to tak, że tworząc zespół do kodu, którego jeszcze nie ma, zatrudniam
pierwszego jednorożca, który wybiera framework. Potem on odchodzi z zespołu (albo
awansuje - na jedno wychodzi) a reszta się męczy z konsekwencjami jego wyborów z
wczesnego etapu projektu.

Więc skąd mam wiedzieć, że mój pierwszy zatrudniony jednorożec wybierze odpowiedni
framework?

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

Tym, że w drugim przypadku zatrudniam programistę do standardowego stacku, bo z jego
punktu widzenia właśnie to zobaczy w firmie. A to, że część kodu w projekcie zostanie
wydzielona przez refaktoryzację do osobnego bytu (i czy w ogóle to nastąpi), to jest
szczegół, który w ogóle nie musi przeszkadzać w rekrutacji.

Natomiast w pierwszym przypadku muszę napisać w ofercie pracy, że szukam programisty
do frameworka X. I tym ogłoszeniem od razu zniechęcam tych, którzy tego frameworka
nie znają. Czyli ograniczam target, a przez to zwiększam koszt.

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

Nie, bo moja docelowa społeczność to standardowy stack. Ta społeczność jest zawsze
największa. Ja nigdy nie zapytam na grupie dyskusyjnej, czy ktoś wie, jak się coś
robi w moim własnym frameworku. Natomiast w przypadku cudzego frameworku już bym może
musiał pytać.

Czyli dalej nie wiemy, co się bardziej opłaca.

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

do góry