🚀 go-pugleaf

On 03/03/2018 17:49, Wojciech Bancer wrote:
> On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:
> 
> [...]
> 
>>> a) wykonać dużo więcej pracy w porównywalnym lub krótszym odcinku czasu
>>
>> Niektóre rzeczy, ale nie wszystko.
> 
> Zły akcent. Raczej "prawie wszystko za wyjątkiem jakiś zupełnie
> najprostszych podstaw typu 'hello world'.

Prawie robi wielką różnicę, ale zostawmy już to.

>>> b) efektywnie rozdzielać pracę w zespole (sensowna struktura obiektowa, która
>>>      jest spójna i znana bo wynika z założeń / dokumentacji)
>>
>> W teorii tak, a w praktyce wygląda to zupełnie inaczej.
> 
> W praktyce wygląda dokładnie tak.

No to mamy różne doświadczenia.

>> Trafiłem na projekt napisany w Angularze 1.x. W pewnym momencie
>> doszli do ściany, bo aplikacja stała się niezarządzalna.
> 
> No i? Niczemu z tego co napisałem to nie przeczy.

No i to, że żaden framework nie gwarantuje niczego.

>> Wniosek jest taki, że żaden framework nie zabezpieczy przed
>> napisaniem śmieciowego kodu.
> 
> Ale nie taka była moja teza.
> Moją tezą było, że z wykorzystaniem frameworka możemy zrobić
> więcej, a nie że nagle zrobi magicznie z idioty programistę.
> 
> I że możemy efektywniej rozdzielać pracę bo ktoś już nad tym
> pomyślał i nie trzeba odkrywać koła na nowo.

Owszem, przecież nie pisałem, że tak nie jest. Jeno to, że jeszcze 
trzeba umieć z nich korzystać. Ale to już osobny temat.

>>> c) ten sam efekt uzyskać w dużo krótszym czasie
>>
>> To pojęcie względne.
> 
> Nie. Całkowicie mierzalne.
> Chociażby w ilości i skomplikowaniu aplikacji typu SPA jakie
> powstają dzisiaj, a jakie powstawały kiedyś.

Stopień skomplikowania jest taki sam, tylko jego ciężar przeniósł się 
gdzie indziej. Wcale dzisiaj (2018) nie jest łatwiej.

>>> Nadal w procesie wytwarzania oprogramowania człowiek jest tym najdroszym
>>> elementem,zwłaszcza taki który nie rozumie jak szkodliwa i kosztowna jest
>>> przedwczesna i niepotrzebna optymalizacja.
>>
>> Nie mam nic przeciwko frameworkom. Niemniej jednak większość z nich jest
>> strasznie "spuchnięta", a jak dodać jeszcze to, co programiści
>> "wyrzeźbią", to robi się z tego kilka MB.
> 
> I co z tego?

I to z tego, że na siłę robimy w ES6 a i tak wszystko potem 
transpilujemy do kilku MB ES5. Bo tak sobie frameworki wymyśliły. To 
tylko przykład bezsenownego podejścia.

>> Według mnie ma to znaczenie, bo co z tego, że mamy kilka GB RAM-u jak
>> trzeba tony kodu bez sensu przetwarzać by osiągnąć proste rezultaty.
> 
> Sens jest taki, że te "mikrooptymalizacje" kosztują czas.
> Dużo więcej czasu, za który musisz zapłacić / rbh.
> A korzyści realnej z tego nie masz żadnej, bo kilka MB
> to jest nic dla współczesnych systemów.

Ja nie pisałem o mikrooptymalizacjach, a o tym, że frameworki same z 
siebie dodają jeszcze masę syfu. Plus ludzie dodają np. całe Underscore 
by skorzystać z jednej metody, itp. I aplikacje mają po kilka(naście) MB.

Np. moim zdaniem 75% kodu wygenerowanego przez webpack dla Angulara to 
masa śmieci. W ogóle pomysł na używanie na siłę ES6 w środowisku web, 
który i tak jest transpilowany do ES5, jest średnio użyteczny. Pomijam 
tutaj NodeJS, bo tu ma to sens. To oczywiście nieco dygresja.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/