Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail Newsgroups: pl.comp.lang.javascript From: Wojciech Bancer Subject: Re: Argument funkcji References: <5a8d1d93$0$674$65785112@news.neostrada.pl> <148vihvftubia.1e9gxiae9fy4p.dlg@40tude.net> <1qn3p672u6yl5.1585lwp0arhbr.dlg@40tude.net> <1b368637-7199-4b74-85d2-5a359e6666e0@googlegroups.com> <15dvc5ead1h2c.cg8ko59kdlzt$.dlg@40tude.net> <246a73c9-8dc7-4ee0-946e-885933c13103@googlegroups.com> <27t8tt1m96wu.11hqw4vglcdjq.dlg@40tude.net> <11hsdnx36lvz3.sjxote5c1628.dlg@40tude.net> <2762d7f6-99fd-4697-b267-dc1ce7a9fe24@googlegroups.com> <18glwbnoogv4i$.ob1q7xeh9yly$.dlg@40tude.net> <3c1ede4e-1fb8-4574-9e6a-429e512643db@googlegroups.com> <99f5fc14-8443-4e78-b5ca-9bcdd1c9af59@googlegroups.com> Organization: None Date: Sat, 3 Mar 2018 20:12:03 +0100 User-Agent: slrn/1.0.3 (Darwin) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Message-ID: Lines: 75 NNTP-Posting-Host: 37.47.160.93 X-Trace: 1520104325 unt-rea-a-02.news.neostrada.pl 997 37.47.160.93:8312 X-Complaints-To: abuse@news.neostrada.pl X-Received-Bytes: 4758 X-Received-Body-CRC: 2434975479 Xref: csiph.com pl.comp.lang.javascript:3453 On 2018-03-03, Cezary Tomczyk 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