🚀 go-pugleaf

On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:

[...]

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

Czyli umiesz się wylegitymować przypadkami, w których framework
defakto spowodował niemożność pracy w zespole, w stosunku do wersji 
"bez"?

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

A gdzie tu była mowa o gwarancjach?

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

Z wszystkiego trzeba umieć korzystać, więc niespecjalnie
rozumiem taki argument.

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

Dzisiaj (2018) jest znacznie łatwiej napisać "to samo" co np. w 1998 r,
w dużo krótszym czasie. Tylko teraz wymagania są dużo większe, więc
i nie piszemy "tego samego".

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

Transpilacja to nie jest "wymysł frameworków".
Nie zgodzę się też z zarzutem narzutu w ilości "kilku MB".

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

I co z tego? Nie piszemy strony dla Atari.

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

ES6 ma mnóstwo przydanych usprawnień, które nie dość że poprawiają 
czytelność kodu, ale też powodują że łatwiej go utrzymać i łatwiej złapać 
błędy. Dodaj do tego możliwość np. typowania (flow lub typescript) i masz
o wiele wyższy stopień kontroli kodu. Pisałeś kiedyś aplikacje
w zespołach większych, np. 5-8-osobowych lub większych?

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com