Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.lang.javascript > #3396 > unrolled thread
| Started by | "konsul41@wp.pl" <konsul41@wp.pl> |
|---|---|
| First post | 2018-02-21 08:19 +0100 |
| Last post | 2018-02-21 05:13 -0800 |
| Articles | 20 on this page of 65 — 10 participants |
Back to article view | Back to pl.comp.lang.javascript
Argument funkcji "konsul41@wp.pl" <konsul41@wp.pl> - 2018-02-21 08:19 +0100
Re: Argument funkcji "konsul41@wp.pl" <konsul41@wp.pl> - 2018-02-21 09:28 +0100
Re: Argument funkcji Roman Tyczka <noemail@because.no> - 2018-02-21 10:52 +0100
Re: Argument funkcji "konsul41@wp.pl" <konsul41@wp.pl> - 2018-02-21 11:00 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-02-26 22:10 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-02-27 05:10 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-02-21 09:22 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-02-27 22:18 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-02-28 04:53 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-01 00:45 +0100
Re: Argument funkcji Adam M <amorawski@magna-power.com> - 2018-03-01 07:01 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-01 07:08 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-01 20:22 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-01 12:34 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-01 22:53 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-01 14:03 -0800
Re: Argument funkcji Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-03-01 23:13 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-01 23:40 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-02 00:08 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-02 00:14 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-02 12:39 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-02 04:45 -0800
Re: Argument funkcji irq <ipluta62@gmail.com> - 2018-03-02 05:22 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-02 07:10 -0800
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 03:25 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 00:45 -0800
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 03:19 +0100
Re: Argument funkcji Roman Tyczka <noemail@because.no> - 2018-03-03 09:52 +0100
Re: Argument funkcji Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-03-03 12:17 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 14:17 +0100
Re: Argument funkcji Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-03-03 16:49 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 17:34 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 17:22 +0100
Re: Argument funkcji Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-03-03 17:49 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 19:01 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 19:14 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 21:24 +0100
Re: Argument funkcji Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-03-03 20:12 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 21:19 +0100
Re: Argument funkcji Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-03-03 22:32 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 22:36 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 22:55 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-04 10:24 +0100
Re: Argument funkcji "PawelS pawel(at)wbcd(dot)pl" <fake@email.org> - 2018-03-09 16:51 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-02 21:10 +0100
Re: Argument funkcji Roman Tyczka <noemail@because.no> - 2018-03-03 00:19 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 01:04 -0800
Re: Argument funkcji ipluta62@gmail.com - 2018-03-03 01:14 -0800
Re: Argument funkcji Roman Tyczka <noemail@because.no> - 2018-03-03 12:05 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 13:44 +0100
Re: Argument funkcji Roman Tyczka <noemail@because.no> - 2018-03-03 12:04 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 04:40 -0800
Re: Argument funkcji Roman Tyczka <noemail@because.no> - 2018-03-03 14:47 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 06:13 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 00:58 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 14:10 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 06:25 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 16:34 +0100
Re: Argument funkcji Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2018-03-03 17:30 +0100
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 18:30 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 08:39 -0800
Re: Argument funkcji Borys Pogoreło <borys@pl.edu.leszno> - 2018-03-03 19:10 +0100
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-03-03 10:34 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-02-21 05:06 -0800
Re: Argument funkcji zpksoft <zpksoft@op.pl> - 2018-02-21 05:13 -0800
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-03-02 12:39 +0100 |
| Message-ID | <18glwbnoogv4i$.ob1q7xeh9yly$.dlg@40tude.net> |
| In reply to | #3417 |
Dnia Fri, 2 Mar 2018 00:14:59 -0800 (PST), zpksoft napisał(a): > Właściwie to był zły przykład. Bo obiekt może pamiętać id aktywnego > rekordu i na tej podstawie łatwo mu podać kolejny-poprzedni. Weźmy coś > innego: user klika dowolny wiersz. Jak odczytujesz jego id? Po czym? Ale PO CO mi jego ID? To Ty się uparłeś, by wszystko miało swoje ID, bo najwyraźniej nie potrafisz inaczej się odwołać do obiektu. A można to zrobić na wiele sposobów, z których ID jest akurat najmniej praktyczny i z reguły zupełnie zbędny. Lecz jeśli koniecznie go potrzebujesz, to wystarczy sięgnąć do e.target.id / e.target.nextSibling.id. Polecam zapoznanie się z modelem DOM i hierarchią obiektów. Oraz z obsługą zdarzeń. I generalnie z dokumentacją JavaScriptu, bo chyba tu leży problem. -- Borys Pogoreło borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | zpksoft <zpksoft@op.pl> |
|---|---|
| Date | 2018-03-02 04:45 -0800 |
| Message-ID | <3c1ede4e-1fb8-4574-9e6a-429e512643db@googlegroups.com> |
| In reply to | #3418 |
W dniu piątek, 2 marca 2018 12:42:57 UTC+1 użytkownik Borys Pogoreło napisał: > Dnia Fri, 2 Mar 2018 00:14:59 -0800 (PST), zpksoft napisał(a): > > > Właściwie to był zły przykład. Bo obiekt może pamiętać id aktywnego > > rekordu i na tej podstawie łatwo mu podać kolejny-poprzedni. Weźmy coś > > innego: user klika dowolny wiersz. Jak odczytujesz jego id? Po czym? > > Ale PO CO mi jego ID? To Ty się uparłeś, by wszystko miało swoje ID, bo > najwyraźniej nie potrafisz inaczej się odwołać do obiektu. A można to > zrobić na wiele sposobów, z których ID jest akurat najmniej praktyczny i z > reguły zupełnie zbędny. Lecz jeśli koniecznie go potrzebujesz, to wystarczy > sięgnąć do e.target.id / e.target.nextSibling.id. Wykręcasz się jak możesz. oczywiście że można na kilka sposobów identyfikować obiekt. Ale... jeśli go nie oznaczysz to również nie obsłużysz. Zarzuciłeś mi, że indeksowanie jest be a teraz piszesz o e.target.id. Generalnie miotasz się w swoich przeświadczeniach i widzimisiach które wytworzyłeś sobie pewnie przed laty i używasz po to żeby zarzucać innym niepoprawność myślową bo niezgodną z twoją. > > Polecam zapoznanie się z modelem DOM i hierarchią obiektów. Oraz z obsługą > zdarzeń. I generalnie z dokumentacją JavaScriptu, bo chyba tu leży problem. No, no. Problem leży gdzie indziej. Głównie w twoim przeświadczeniu że bez obcego "frameworku" nie da się programować. > > -- > Borys Pogoreło > borys(#)leszno,edu,pl Paweł
[toc] | [prev] | [next] | [standalone]
| From | irq <ipluta62@gmail.com> |
|---|---|
| Date | 2018-03-02 05:22 -0800 |
| Message-ID | <99f5fc14-8443-4e78-b5ca-9bcdd1c9af59@googlegroups.com> |
| In reply to | #3419 |
W dniu piątek, 2 marca 2018 13:45:26 UTC+1 użytkownik zpksoft napisał: > W dniu piątek, 2 marca 2018 12:42:57 UTC+1 użytkownik Borys Pogoreło napisał: > > Lecz jeśli koniecznie go potrzebujesz, to wystarczy > > sięgnąć do e.target.id / e.target.nextSibling.id. > > Wykręcasz się jak możesz. oczywiście że można na kilka sposobów identyfikować obiekt. Ale... jeśli go nie oznaczysz to również nie obsłużysz. obiekt jest dostępny jako e.target (https://www.w3schools.com/jsref/event_target.asp). Cóż więcej trzeba żeby go obsłużyć? Czyżby wykonać getElementById(e.target.id) ? > Zarzuciłeś mi, że indeksowanie jest be a teraz piszesz o e.target.id. kolega wyraźnie zastrzegł powyżej, że skoro Ty koniecznie chcesz mieć id to możesz je uzyskać w ten sposób. Odpowiedział jedynie na Twoją potrzebę, nie wnikając w jej istotę. > > No, no. > Problem leży gdzie indziej. Głównie w twoim przeświadczeniu że bez obcego "frameworku" nie da się programować. > da się programować, tylko ile się trzeba namęczyć! Siebie i innych. I wynajdywać koło i proch na nowo z każdym nowym projektem. Dostrzegli to programiści zmuszeni niegdyś do programowania w ten sposób i stworzyli ... frameworki. A co więcej - opublikowali i udokumentowali.
[toc] | [prev] | [next] | [standalone]
| From | zpksoft <zpksoft@op.pl> |
|---|---|
| Date | 2018-03-02 07:10 -0800 |
| Message-ID | <d7a0f098-368b-407b-93ab-dc2d21790fd7@googlegroups.com> |
| In reply to | #3420 |
W dniu piątek, 2 marca 2018 14:22:05 UTC+1 użytkownik irq napisał: > W dniu piątek, 2 marca 2018 13:45:26 UTC+1 użytkownik zpksoft napisał: > > W dniu piątek, 2 marca 2018 12:42:57 UTC+1 użytkownik Borys Pogoreło napisał: > > > Lecz jeśli koniecznie go potrzebujesz, to wystarczy > > > sięgnąć do e.target.id / e.target.nextSibling.id. > > > > Wykręcasz się jak możesz. oczywiście że można na kilka sposobów identyfikować obiekt. Ale... jeśli go nie oznaczysz to również nie obsłużysz. > > obiekt jest dostępny jako e.target (https://www.w3schools.com/jsref/event_target.asp). Cóż więcej trzeba żeby go obsłużyć? Czyżby wykonać getElementById(e.target.id) ? > > > Zarzuciłeś mi, że indeksowanie jest be a teraz piszesz o e.target.id. > > kolega wyraźnie zastrzegł powyżej, że skoro Ty koniecznie chcesz mieć id to możesz je uzyskać w ten sposób. Odpowiedział jedynie na Twoją potrzebę, nie wnikając w jej istotę. > Hm, śledzisz ten wątek? Chyba nie. Ja nie wyraziłem tu żadnej potrzeby. To mi zarzucono nadawanie id obiektom. Na moje pytanie jak sobie radzisz bez oznaczania obiektów nie uzyskałem odpowiedzi. > > > > No, no. > > Problem leży gdzie indziej. Głównie w twoim przeświadczeniu że bez obcego "frameworku" nie da się programować. > > > > da się programować, tylko ile się trzeba namęczyć! Siebie i innych. I wynajdywać koło i proch na nowo z każdym nowym projektem. Dostrzegli to programiści zmuszeni niegdyś do programowania w ten sposób i stworzyli ... frameworki. A co więcej - opublikowali i udokumentowali. OK. Lata temu było tak: JS kreował pewien standard, przeglądarki w części go respektowały, w części tworzyły swoje rozwiązania (celował w tym IE). Żeby móc pisać jednoznacznie na wszystkie przeglądarki należało bawić się w obejścia typu if (IE) .. else .. Powstały więc biblioteki w których te obejścia były już gotowe. Teraz jest już inna rzeczywistość. Znakomita większość języka jest prawidłowo interpretowana przez wszystkie współczesne przeglądarki więc już nie ma takiej potrzeby stosowania owych bibliotek, zwłaszcza, że z czasem obrosły w tony nadmiarowego kodu. Programiści którzy wdepnęli zdrowo w ten sposób programowania nie są w stanie się z niego wydostać. Mało tego- są święcie przekonani że to jedyna słuszna droga. Klienci pracujący na moich aplikacjach przeglądarkowych często mnie pytają co ja takiego zrobiłem że działają tak szybko. Otóż u mnie nie ma nadmiarowego kodu. I żeby nie było że stale wyważam otwarte drzwi. Mam można by powiedzieć własny framework :) Osobiście szanuję tych którzy programują inaczej niż ja i tego samego oczekuję od innych. Paweł
[toc] | [prev] | [next] | [standalone]
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Date | 2018-03-03 03:25 +0100 |
| Message-ID | <p7d12h$2cb3$1@csiph.com> |
| In reply to | #3421 |
On 02/03/2018 16:10, zpksoft wrote: [...] > OK. Lata temu było tak: JS kreował pewien standard, przeglądarki w części go respektowały, w części tworzyły swoje rozwiązania (celował w tym IE). Żeby móc pisać jednoznacznie na wszystkie przeglądarki należało bawić się w obejścia typu if (IE) .. else .. Powstały więc biblioteki w których te obejścia były już gotowe.[...] Dla ścisłości: nie ma czegoś takiego, jak JS. Jest standard ECMAScript (https://www.ecma-international.org/publications/standards/Ecma-262.htm) i jego poszczególne implementacje. JavaScript to znak towarowy, którego właścielem jest obecnie Oracle: http://tsdr.uspto.gov/#caseNumber=75026640&caseType=SERIAL_NO&searchType=statusSearch -- Cezary Tomczyk http://www.ctomczyk.pl/ Blokowanie automatycznego odtwarzania video na gazeta.pl w Google Chrome: https://goo.gl/0kCRLS https://www.aslint.org/ - Accessibility validator tool
[toc] | [prev] | [next] | [standalone]
| From | zpksoft <zpksoft@op.pl> |
|---|---|
| Date | 2018-03-03 00:45 -0800 |
| Message-ID | <10c87091-9d0f-4857-88b1-2a09fb566c8f@googlegroups.com> |
| In reply to | #3425 |
W dniu sobota, 3 marca 2018 03:25:22 UTC+1 użytkownik Cezary Tomczyk napisał: > On 02/03/2018 16:10, zpksoft wrote: > [...] > > OK. Lata temu było tak: JS kreował pewien standard, przeglądarki w części go respektowały, w części tworzyły swoje rozwiązania (celował w tym IE). Żeby móc pisać jednoznacznie na wszystkie przeglądarki należało bawić się w obejścia typu if (IE) .. else .. Powstały więc biblioteki w których te obejścia były już gotowe.[...] > > Dla ścisłości: nie ma czegoś takiego, jak JS. Jest standard ECMAScript > (https://www.ecma-international.org/publications/standards/Ecma-262.htm) > i jego poszczególne implementacje. > > JavaScript to znak towarowy, którego właścielem jest obecnie Oracle: > http://tsdr.uspto.gov/#caseNumber=75026640&caseType=SERIAL_NO&searchType=statusSearch > > -- > Cezary Tomczyk > http://www.ctomczyk.pl/ > Blokowanie automatycznego odtwarzania video na gazeta.pl w Google > Chrome: https://goo.gl/0kCRLS > https://www.aslint.org/ - Accessibility validator tool Dzięki za uściślenie Paweł
[toc] | [prev] | [next] | [standalone]
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Date | 2018-03-03 03:19 +0100 |
| Message-ID | <p7d0nd$2c5t$1@csiph.com> |
| In reply to | #3420 |
On 02/03/2018 14:22, irq wrote: [...] > da się programować, tylko ile się trzeba namęczyć! Siebie i innych. I wynajdywać koło i proch na nowo z każdym nowym projektem. Dostrzegli to programiści zmuszeni niegdyś do programowania w ten sposób i stworzyli ... frameworki. A co więcej - opublikowali i udokumentowali. Od tych wszystkich wspaniałych frameworków aplikacje puchną do wielu megabajtów, a i ogarnianie ich zajmuje też sporo czasu i zasobów. Aplikacje wcale nie stają jakoś radykalnie łatwiej zarządzane, szczególnie biorąc pod uwagę wiedzę, jaką mają dzisiejsi programiści :-( -- Cezary Tomczyk http://www.ctomczyk.pl/ Blokowanie automatycznego odtwarzania video na gazeta.pl w Google Chrome: https://goo.gl/0kCRLS https://www.aslint.org/ - Accessibility validator tool
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-03-03 09:52 +0100 |
| Message-ID | <19l6sjnte10rh$.dlg@tyczka.com> |
| In reply to | #3424 |
On Sat, 3 Mar 2018 03:19:24 +0100, Cezary Tomczyk wrote: >> da się programować, tylko ile się trzeba namęczyć! Siebie i innych. I wynajdywać koło i proch na nowo z każdym nowym projektem. Dostrzegli to programiści zmuszeni niegdyś do programowania w ten sposób i stworzyli ... frameworki. A co więcej - opublikowali i udokumentowali. > > Od tych wszystkich wspaniałych frameworków aplikacje puchną do wielu > megabajtów, a i ogarnianie ich zajmuje też sporo czasu i zasobów. > Aplikacje wcale nie stają jakoś radykalnie łatwiej zarządzane, > szczególnie biorąc pod uwagę wiedzę, jaką mają dzisiejsi programiści :-( Trochę przesadzasz. nie jest aż tak źle, choć są frameworki i Frameworki. https://gist.github.com/Restuta/cda69e50a853aa64912d -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-03-03 12:17 +0100 |
| Message-ID | <slrnp9l11l.311p.wojciech.bancer@pl-test.org> |
| In reply to | #3424 |
On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote: > On 02/03/2018 14:22, irq wrote: > [...] >> da się programować, tylko ile się trzeba namęczyć! Siebie i innych. I wynajdywać koło i proch na nowo z każdym nowym projektem. Dostrzegli to programiści zmuszeni niegdyś do programowania w ten sposób i stworzyli ... frameworki. A co więcej - opublikowali i udokumentowali. > > Od tych wszystkich wspaniałych frameworków aplikacje puchną do wielu > megabajtów, a i ogarnianie ich zajmuje też sporo czasu i zasobów. > Aplikacje wcale nie stają jakoś radykalnie łatwiej zarządzane, > szczególnie biorąc pod uwagę wiedzę, jaką mają dzisiejsi programiści :-( Dzięki tym wszystkim frameworkom możesz: a) wykonać dużo więcej pracy w porównywalnym lub krótszym odcinku czasu b) efektywnie rozdzielać pracę w zespole (sensowna struktura obiektowa, która jest spójna i znana bo wynika z założeń / dokumentacji) c) ten sam efekt uzyskać w dużo krótszym czasie Co z tego że zajmują megabajty? Nie pracujemy na i386, czy nawet na Pentium. Pracujemy na kolejnych generacjach Core iCoś, _coraz tańszych i coraz mocniejszych maszynach_, czy nawet smarfonach które obecnie mają moc zdolną przetwarzać filmy 4k. Wykorzystywanie coraz bardziej wysokopoziomowych języków i narzędzi ma na celu optymalizację kosztów, bo ogarnianie wszystkiego niskopoziomowo tylko dlatego że ktoś chce oszczędzić 5 cykli procesora jest po prostu bezcelowe i powoli poza zasięgiem przeciętnego człowieka. 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. -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-03-03 14:17 +0100 |
| Message-ID | <74bwydc9ddln.wru6ss101vi6.dlg@40tude.net> |
| In reply to | #3433 |
Dnia Sat, 3 Mar 2018 12:17:09 +0100, Wojciech Bancer napisał(a): > Co z tego że zajmują megabajty? Nie pracujemy na i386, czy nawet na Pentium. > Pracujemy na kolejnych generacjach Core iCoś, _coraz tańszych i coraz mocniejszych > maszynach_, czy nawet smarfonach które obecnie mają moc zdolną przetwarzać filmy 4k. Erm, veto. Właśnie te nieszczęsne smartfony stają się sporym problemem, bo większość z nich nie grzeszy nadmiarem mocy obliczeniowej. Jakość połączenia (w tym opóźnienia i czas nawiązania połączenia) też z reguły nie jest najlepsza. Fajnie o tym opowiada gość z Google: https://www.youtube.com/watch?v=4bZvq3nodf4 -- Borys Pogoreło borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-03-03 16:49 +0100 |
| Message-ID | <slrnp9lgve.e9e.wojciech.bancer@pl-test.org> |
| In reply to | #3437 |
On 2018-03-03, Borys Pogoreło <borys@pl.edu.leszno> wrote: [...] >> Co z tego że zajmują megabajty? Nie pracujemy na i386, czy nawet na Pentium. >> Pracujemy na kolejnych generacjach Core iCoś, _coraz tańszych i coraz mocniejszych >> maszynach_, czy nawet smarfonach które obecnie mają moc zdolną przetwarzać filmy 4k. > > Erm, veto. Właśnie te nieszczęsne smartfony stają się sporym problemem, bo > większość z nich nie grzeszy nadmiarem mocy obliczeniowej. Jakość > połączenia (w tym opóźnienia i czas nawiązania połączenia) też z reguły nie > jest najlepsza. Ale to jest niezależne od zastosowanego frameworka. Te nowe myślę że daje się dopasować do wymagań. Zresztą sam autor tak naprawdę nie skupia się na tym by ich nie używać, a by odpowiedni optymalizować dostarczanie contentu, stosować cache, workery itp. I już to widzę jak mielibyśmy to robić sposobem zpksoftu, czyli wszystko pisać ręcznie i obsługiwać w centralnym miejscu. :) -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-03-03 17:34 +0100 |
| Message-ID | <1r54fefeog4ow.s97jpuavchhp$.dlg@40tude.net> |
| In reply to | #3442 |
Dnia Sat, 3 Mar 2018 16:49:01 +0100, Wojciech Bancer napisał(a): > Ale to jest niezależne od zastosowanego frameworka. Te nowe myślę że > daje się dopasować do wymagań. Do pewnego stopnia zależne, bo przeglądarka musi sparsować te kilobajty kodu, z których z reguły i tak wykorzystujemy zaledwie jakąś część. Inna sprawa, że najczęściej do tego jest dorzucane 10 razy tyle dodatkowych bibliotek i leci paczka 400KB, która blokuje telefon na sekundę albo i dłużej... > Zresztą sam autor tak naprawdę nie skupia się na tym by ich nie używać, > a by odpowiedni optymalizować dostarczanie contentu, stosować cache, > workery itp. Tak, ale też pokazuje z czym tak naprawdę trzeba się liczyć pisząc kod. I że optymalizacja nadal jest wymagana. i7 pod biurkiem i Snapdragon 835 w kieszeni trochę psują punkt widzenia. > I już to widzę jak mielibyśmy to robić sposobem zpksoftu, czyli > wszystko pisać ręcznie i obsługiwać w centralnym miejscu. :) Ja jestem ciekaw z jak wielkim hukiem by wyleciał z pierwszego code review. -- Borys Pogoreło borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Date | 2018-03-03 17:22 +0100 |
| Message-ID | <p7ei4m$eji$1@csiph.com> |
| In reply to | #3433 |
On 03/03/2018 12:17, Wojciech Bancer wrote: > On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote: >> On 02/03/2018 14:22, irq wrote: >> [...] >>> da się programować, tylko ile się trzeba namęczyć! Siebie i innych. I wynajdywać koło i proch na nowo z każdym nowym projektem. Dostrzegli to programiści zmuszeni niegdyś do programowania w ten sposób i stworzyli ... frameworki. A co więcej - opublikowali i udokumentowali. >> >> Od tych wszystkich wspaniałych frameworków aplikacje puchną do wielu >> megabajtów, a i ogarnianie ich zajmuje też sporo czasu i zasobów. >> Aplikacje wcale nie stają jakoś radykalnie łatwiej zarządzane, >> szczególnie biorąc pod uwagę wiedzę, jaką mają dzisiejsi programiści :-( > > Dzięki tym wszystkim frameworkom możesz: > > a) wykonać dużo więcej pracy w porównywalnym lub krótszym odcinku czasu Niektóre rzeczy, ale nie wszystko. > 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. Trafiłem na projekt napisany w Angularze 1.x. W pewnym momencie doszli do ściany, bo aplikacja stała się niezarządzalna. Wniosek jest taki, że żaden framework nie zabezpieczy przed napisaniem śmieciowego kodu. > c) ten sam efekt uzyskać w dużo krótszym czasie To pojęcie względne. > Co z tego że zajmują megabajty? Nie pracujemy na i386, czy nawet na Pentium. > Pracujemy na kolejnych generacjach Core iCoś, _coraz tańszych i coraz mocniejszych > maszynach_, czy nawet smarfonach które obecnie mają moc zdolną przetwarzać filmy 4k. > Wykorzystywanie coraz bardziej wysokopoziomowych języków i narzędzi ma na celu > optymalizację kosztów, bo ogarnianie wszystkiego niskopoziomowo tylko dlatego > że ktoś chce oszczędzić 5 cykli procesora jest po prostu bezcelowe i powoli > poza zasięgiem przeciętnego człowieka. > > 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. 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. -- Cezary Tomczyk http://www.ctomczyk.pl/ Blokowanie automatycznego odtwarzania video na gazeta.pl w Google Chrome: https://goo.gl/0kCRLS https://www.aslint.org/ - Accessibility validator tool
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-03-03 17:49 +0100 |
| Message-ID | <slrnp9lkg8.h15.wojciech.bancer@pl-test.org> |
| In reply to | #3443 |
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'. >> 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. > 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. > 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. >> 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ś. >> 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? > 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. -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Date | 2018-03-03 19:01 +0100 |
| Message-ID | <p7enu8$iil$1@csiph.com> |
| In reply to | #3447 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Borys Pogoreło <borys@pl.edu.leszno> |
|---|---|
| Date | 2018-03-03 19:14 +0100 |
| Message-ID | <snaukkcgrs3f.1iq53i4dbct71$.dlg@40tude.net> |
| In reply to | #3449 |
Dnia Sat, 3 Mar 2018 19:01:43 +0100, Cezary Tomczyk napisał(a): > 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. Akurat to żadna różnica dla ostatecznej wersji kodu, bo i tak przeglądarka dostanie ES5. A programista zamiast ręcznie rzeźbić w starszym standardzie, może od razu pisać krócej / wygodniej / szybciej. -- Borys Pogoreło borys(#)leszno,edu,pl
[toc] | [prev] | [next] | [standalone]
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Date | 2018-03-03 21:24 +0100 |
| Message-ID | <p7f09l$nur$1@csiph.com> |
| In reply to | #3451 |
On 03/03/2018 19:14, Borys Pogoreło wrote: > Dnia Sat, 3 Mar 2018 19:01:43 +0100, Cezary Tomczyk napisał(a): > >> 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. > > Akurat to żadna różnica dla ostatecznej wersji kodu, bo i tak przeglądarka > dostanie ES5. A programista zamiast ręcznie rzeźbić w starszym standardzie, > może od razu pisać krócej / wygodniej / szybciej. Żeby nie było, to sam używam ES6/ES7. Aczkolwiek to, co mnie po prostu irytuje, to ilość narzuconego kodu po transiplacji. No ale trudno. Widocznie takie mamy czasy. Któregoś dnia pewnie to się zmieni, jak większość przeglądarek będzie wspierać ES6/ES7. Wówczas będzie można pozbyć się transpilerów. :-) -- Cezary Tomczyk http://www.ctomczyk.pl/
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-03-03 20:12 +0100 |
| Message-ID | <slrnp9lss4.kfh.wojciech.bancer@pl-test.org> |
| In reply to | #3449 |
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
[toc] | [prev] | [next] | [standalone]
| From | Cezary Tomczyk <cezary.tomczyk@gmail.com> |
|---|---|
| Date | 2018-03-03 21:19 +0100 |
| Message-ID | <p7f00k$nqe$1@csiph.com> |
| In reply to | #3453 |
On 03/03/2018 20:12, Wojciech Bancer wrote: > 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"? Piszesz, że framework pomaga "efektywnie rozdzielać pracę w zespole". To tylko częściowo prawda. Framework nie zaplanuje architektury aplikacji czy też modeli, przykładowo. >>>> 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? Ja twierdziłem, że frameworki nie gwarantują. Są tylko narzędziem, które ułatwiają. >>> 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. ">>> I że możemy efektywniej rozdzielać pracę bo ktoś już nad tym >>> pomyślał i nie trzeba odkrywać koła na nowo." Ta? To weź do zespołu 10-ciu juniorów programistów. Zobaczymy, jak gładko będzie szło. >>> 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". Ja nie napisałem, że pisze się to samo tylko, że pisanie oprogramowania jest (i będzie) nadal skomplikowane. Po prostu ciężar tego skomplikowania przeniósł się gdzie indziej. Teraz już nie myślisz o pewnych rzeczach, które robiłeś 10 lat temu, ale za to musisz robić rzeczy, których nie było 10 lat temu. >>> 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". Autorów tych frameworków. > Nie zgodzę się też z zarzutem narzutu w ilości "kilku MB". No to sprawdź webpack bundle analyzer co siedzi w finalnych paczkach. >>> 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. A co to ma do rzeczy? >> 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 Samo typowanie to za mało. Od łapania błędów to masz tslint (TypeScript), eslint, porządnie napisane unit testy, integration testy, generalnie cały process walidacji. > o wiele wyższy stopień kontroli kodu. Pisałeś kiedyś aplikacje > w zespołach większych, np. 5-8-osobowych lub większych? Tak. Uściślając, by nie kontynuować akademickiej dyskusji dalej: uważam, że frameworki to dobre narzędzia, które do pewnego stopnia pozwalają na organizację pracy. Niemniej jednak do tego dochodzi jeszcze m.in. znajomość procesów jakości, bezpieczeństwa, mechanizmy cache i cache policy, patternów, continuous deployment, continuous integration, itd. -- Cezary Tomczyk http://www.ctomczyk.pl/
[toc] | [prev] | [next] | [standalone]
| From | Wojciech Bancer <wojciech.bancer@gmail.com> |
|---|---|
| Date | 2018-03-03 22:32 +0100 |
| Message-ID | <slrnp9m53m.upt.wojciech.bancer@pl-test.org> |
| In reply to | #3454 |
On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote: [...] >> Czyli umiesz się wylegitymować przypadkami, w których framework >> defakto spowodował niemożność pracy w zespole, w stosunku do wersji >> "bez"? > > Piszesz, że framework pomaga "efektywnie rozdzielać pracę w zespole". To > tylko częściowo prawda. Framework nie zaplanuje architektury aplikacji > czy też modeli, przykładowo. Framework _pomaga_, a nie _odwala robotę za_. >>>>> 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? > Ja twierdziłem, że frameworki nie gwarantują. Są tylko narzędziem, które > ułatwiają. Czyli potwierdzasz moją tezę. Ułatwiają. >>> 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. > > ">>> I że możemy efektywniej rozdzielać pracę bo ktoś już nad tym > >>> pomyślał i nie trzeba odkrywać koła na nowo." > > Ta? Ta. > To weź do zespołu 10-ciu juniorów programistów. Zobaczymy, jak > gładko będzie szło. Wezmę 10 juniorów, dam im dokumentację i wzorce (które ktoś opracował, w przypadku takiego Angulara np. John Papa), dam im zadania, dam im stack overlow, zaprzęgnę porządny code review i wymóg pisania testów i tych 10 juniorów da radę. A bez frameworka co im dasz? "Sami wymyśclie sobie strukturę, sami wymyślcie sobie Centralne Biuro Zarządzania Obiektami"? >> 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". > > Ja nie napisałem, że pisze się to samo tylko, że pisanie oprogramowania > jest (i będzie) nadal skomplikowane. Po prostu ciężar tego > skomplikowania przeniósł się gdzie indziej. Czyli dzięki większej warstwie abstrakcji jesteśmy w stanie albo dostarczyć więcej, albo w krótszym czasie. W 2000 napisanie prostego CMSa zajmowało kilka miesięcy. Teraz jest to kilka godzin. > Teraz już nie myślisz o pewnych rzeczach, które robiłeś 10 lat temu, ale > za to musisz robić rzeczy, których nie było 10 lat temu. Innymi słowy możesz się skupić na dostarczaniu coraz bardziej wyszukanych narzędzi, czyli wzrasta złożoność tworzonego kodu. Między innymi dlatego używamy JS, a nie np. Asemblera. >> Transpilacja to nie jest "wymysł frameworków". > Autorów tych frameworków. Absolutnie nie. >> Nie zgodzę się też z zarzutem narzutu w ilości "kilku MB". > No to sprawdź webpack bundle analyzer co siedzi w finalnych paczkach. Kod ES5, a co ma siedzieć? Święty Mikołaj? Nadal, nie ma "narzutu kilka MB". I ciągle nie rozumiem tego zarzutu o kilku MB. Rozumiem, że filmów nie oglądasz, bo to kilkaset, kilka tysięcy MB i Ci się komputer przegrzeje? >>> 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. > A co to ma do rzeczy? Prosta optymalizacja. Dzień pracy programisty kosztuje często więcej niż rok utrzymania przeciętnej strony/aplikacji, więc o ile nie piszesz softu "ratującego życie", to nie ma potrzeby biznesowej by się ściskać poniżej 1MB. Facebook zajmuje "megabajty", a nikt nie powie że działa wolno lub niewydajnie. Takie kryterium jakości jest po prostu nic nie warte. Więcej optymalizacji da Ci w tym momencie admin który włączy kompresję gzip i cache niż stado programistów, którzy będą się głowić jak zejść o 10-100kb kodu. Martwić się o megabajty trzeba jak to jest wąskie gardło, a nie "bo tak". >> 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 > > Samo typowanie to za mało. Od łapania błędów to masz tslint > (TypeScript), eslint, porządnie napisane unit testy, integration testy, > generalnie cały process walidacji. Który nota bene jest świetnie udokumentowany i wdrożony gdzie? Ano w tych frameworkach. :) > Uściślając, by nie kontynuować akademickiej dyskusji dalej: uważam, że > frameworki to dobre narzędzia, które do pewnego stopnia pozwalają na > organizację pracy. Czyli jak widzisz się zgadzamy, bo takie były moje tezy początkowe. :) > Niemniej jednak do tego dochodzi jeszcze m.in. > znajomość procesów jakości, bezpieczeństwa, mechanizmy cache i cache > policy, patternów, continuous deployment, continuous integration, itd. Tak, nie przeczę że do tego by programować trzeba umieć programować i korzystać z narzędzi. Tym niemniej lepiej że te narzędzia są, niż jakby ich miało nie być. -- Wojciech Bańcer wojciech.bancer@gmail.com
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | pl.comp.lang.javascript
csiph-web