🚀 go-pugleaf

Zrobiłem tak
'<input type=image src=png/if_back.png 
onclick=zaladuj_main_body(\'listakontrahentow.php?ID=1\');  title=Do 
tyłu   alt=Do tyłu> </td>'

działa w Chrome i IE tylko czy to jest prawidłowe
Najlepsze że w źródle strony widzę tekst ze znakami "

W dniu środa, 21 lutego 2018 08:19:50 UTC+1 użytkownik kons...@wp.pl napisał:
> Jest sobie funkcja
> var set_hist_back_html = function ( tekst ) {
>      document.getElementById("hist_back").innerHTML = tekst;
>    };
> 
> 
> następnie w jednym z div jest takie coś
> 
> <input type="image" src="png/if_edit-user_46799.png"
>    onclick=
>    "
>     set_hist_back_html('<input type="image" src="png/if_back.png" 
> onclick="zaladuj_main_body(\'listakontrahentow.php?ID=1\');"  title="Do 
> tyłu"   alt="Do tyłu"> </td>');
> 
> 
>    "       title="Edytuj dane kontrahenta." alt="lista">
> 
> 
> Pytanie jak prawidłowo wpisać tekst
> '<input type="image" src="png/if_back.png" 
> onclick="zaladuj_main_body(\'listakontrahentow.php?ID=1\');"  title="Do 
> tyłu"   alt="Do tyłu"> </td>'
> 
> Jako argument funkcji set_hist_back_html

//załaduj ciąg do zmiennej

var par='<input type="image" src="png/if_back.png" 
 onclick="zaladuj_main_body(\'listakontrahentow.php?ID=1\');"  title="Do 
 tyłu"   alt="Do tyłu"> </td>';

//a następnie: 

set_hist_back_html(par);

Paweł

W dniu środa, 21 lutego 2018 08:19:50 UTC+1 użytkownik kons...@wp.pl napisał:
> Jest sobie funkcja
> var set_hist_back_html = function ( tekst ) {
>      document.getElementById("hist_back").innerHTML = tekst;
>    };
> 
> 
> następnie w jednym z div jest takie coś
> 
> <input type="image" src="png/if_edit-user_46799.png"
>    onclick=
>    "
>     set_hist_back_html('<input type="image" src="png/if_back.png" 
> onclick="zaladuj_main_body(\'listakontrahentow.php?ID=1\');"  title="Do 
> tyłu"   alt="Do tyłu"> </td>');
> 
> 
>    "       title="Edytuj dane kontrahenta." alt="lista">
> 
> 
> Pytanie jak prawidłowo wpisać tekst
> '<input type="image" src="png/if_back.png" 
> onclick="zaladuj_main_body(\'listakontrahentow.php?ID=1\');"  title="Do 
> tyłu"   alt="Do tyłu"> </td>'
> 
> Jako argument funkcji set_hist_back_html

Napisałem na szybko, nie zapomnij wyłączyć znaki specjalne jak apostrofy wewnątrz łańcucha:

https://4programmers.net/JavaScript/Obiekty/String

Paweł

W dniu środa, 21 lutego 2018 09:28:50 UTC+1 użytkownik kons...@wp.pl napisał:
> Zrobiłem tak
> '<input type=image src=png/if_back.png 
> onclick=zaladuj_main_body(\'listakontrahentow.php?ID=1\');  title=Do 
> tyłu   alt=Do tyłu> </td>'
> 
> działa w Chrome i IE tylko czy to jest prawidłowe
> Najlepsze że w źródle strony widzę tekst ze znakami "

Jeśli miałbym Ci doradzić to generalnie kod jest zawikłany a przez to słaby. Ja to robię tak. Użyj skryptu w head html a w nim pętlę:

document.onclick = function(e){
  var t, n;
    e = e || window.event;
    var t = e.target || e.srcElement; //odporne na stare IE
    n=t.id; //n to id klikniętego elementu

  if (n=='if_edit'){
    //tu odpowiedni kod
}
  else if (n=='if_back') {
  //tu odpowiedni kod..
} else .. <- tu obsłużysz kolejne kliki

}

itd. W html nie będziesz miał żadnych onClicków, zwięzły i czytelny kod. Tylko musisz nadać id elementom których kliknięcia chcesz obsłużyć.
Zauważ że podobnie działa aplikacja desktopowa. W pętli komunikatów wywoływane są odpowiednie procedury ich obsługi, jeśli zostały zdefiniowane,

Paweł

Dnia Wed, 21 Feb 2018 09:22:53 -0800 (PST), zpksoft napisał(a):

> itd. W html nie będziesz miał żadnych onClicków, zwięzły i czytelny kod. 

Raczej antytezę zwięzłego i czytelnego kodu. 50 ifów jeden po drugim to
jest materiał na thedailywtf.com, a nie poradę w sieci.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu wtorek, 27 lutego 2018 22:19:15 UTC+1 użytkownik Borys Pogoreło napisał:
> Dnia Wed, 21 Feb 2018 09:22:53 -0800 (PST), zpksoft napisał(a):
> 
> > itd. W html nie będziesz miał żadnych onClicków, zwięzły i czytelny kod. 
> 
> Raczej antytezę zwięzłego i czytelnego kodu. 50 ifów jeden po drugim to
> jest materiał na thedailywtf.com, a nie poradę w sieci.
> 
> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

50 ifów? Dlaczego aż tyle? Piszesz aż tak złożone aplikacje na przeglądarkę? Wątpię.

Nawet gdyby, to podałem tylko schemat który łatwo podzielić na segmenty a nawet oddzielne pliki js. Uważam że to słuszna droga. Tak piszę swoje aplikacje przeglądarkowe. Bardzo łatwo utrzymać taki kod. Znacznie łatwiej niż gdyby rozsiać onkliki po obiektach a te na dokładkę tworzyć dynamicznie...
Nikt się w tym nie połapie, nawet twórca po jakimś czasie :)


Paweł

Dnia Wed, 28 Feb 2018 04:53:03 -0800 (PST), zpksoft napisał(a):

>> Raczej antytezę zwięzłego i czytelnego kodu. 50 ifów jeden po drugim to
>> jest materiał na thedailywtf.com, a nie poradę w sieci.
> 
> 50 ifów? Dlaczego aż tyle? Piszesz aż tak złożone aplikacje na przeglądarkę? Wątpię.

Wystarczy, że masz prostego datagrida z 50 wierszami. W tym rozwiązaniu
potrzebujesz każdemu nadać osobne ID i osobno obsłużyć. I jeszcze
przypadkiem nie dać możliwości zmiany liczby wierszy, bo się wszystko
posypie.

> Nawet gdyby, to podałem tylko schemat który łatwo podzielić na segmenty a
> nawet oddzielne pliki js. Uważam że to słuszna droga. 

To jest dramat, nie słuszna droga. Ścisłe powiązanie kodu JS ze strukturą
dokumentu całkowicie przekreśla jakąkolwiek elastyczność tego rozwiązania i
łatwość w utrzymaniu.

Ale myśmy juz kiedyś ustalili, że frameworki są zbędne, a wynajdywanie koła
na nowo jest świetnym ćwiczeniem dydaktycznym.

> Bardzo łatwo utrzymać taki kod. Znacznie łatwiej niż gdyby rozsiać
> onkliki po obiektach a te na dokładkę tworzyć dynamicznie...

Wiadomo, cały świat tak robi, by sobie utrudniać życie.

Do obsługi dynamicznie tworzonych obiektów wystaczy podpiąć event listener
do najbliższego sensownego obiektu nadrzędnego.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Wednesday, February 28, 2018 at 6:46:05 PM UTC-5, Borys Pogoreło wrote:
> Dnia Wed, 28 Feb 2018 04:53:03 -0800 (PST), zpksoft napisał(a):
> 
> >> Raczej antytezę zwięzłego i czytelnego kodu. 50 ifów jeden po drugim to
> >> jest materiał na thedailywtf.com, a nie poradę w sieci.
> > 
> > 50 ifów? Dlaczego aż tyle? Piszesz aż tak złożone aplikacje na przeglądarkę? Wątpię.
> 
> Wystarczy, że masz prostego datagrida z 50 wierszami. W tym rozwiązaniu
> potrzebujesz każdemu nadać osobne ID i osobno obsłużyć. I jeszcze
> przypadkiem nie dać możliwości zmiany liczby wierszy, bo się wszystko
> posypie.
> 
> > Nawet gdyby, to podałem tylko schemat który łatwo podzielić na segmenty a
> > nawet oddzielne pliki js. Uważam że to słuszna droga. 
> 
> To jest dramat, nie słuszna droga. Ścisłe powiązanie kodu JS ze strukturą
> dokumentu całkowicie przekreśla jakąkolwiek elastyczność tego rozwiązania i
> łatwość w utrzymaniu.
> 
> Ale myśmy juz kiedyś ustalili, że frameworki są zbędne, a wynajdywanie koła
> na nowo jest świetnym ćwiczeniem dydaktycznym.
> 
> > Bardzo łatwo utrzymać taki kod. Znacznie łatwiej niż gdyby rozsiać
> > onkliki po obiektach a te na dokładkę tworzyć dynamicznie...
> 
> Wiadomo, cały świat tak robi, by sobie utrudniać życie.
> 
> Do obsługi dynamicznie tworzonych obiektów wystaczy podpiąć event listener
> do najbliższego sensownego obiektu nadrzędnego.
> 
> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

Zgadzam sie w 100%. Pisanie czegos od zera w JavaScript to czysty masochizm i proszenie sie o klopoty w przyszlosci (no chyba ze caly kod w JavaSript ma 50-100 LOC). Lepiej zdecydowac sie naa jeden ugruntowany i dobrze wspierany framework lub jesli ktos calkowicie nie lubi JavaScript uzyc GWT lub TeaVM.

W dniu czwartek, 1 marca 2018 00:46:05 UTC+1 użytkownik Borys Pogoreło napisał:
> Dnia Wed, 28 Feb 2018 04:53:03 -0800 (PST), zpksoft napisał(a):
> 
> >> Raczej antytezę zwięzłego i czytelnego kodu. 50 ifów jeden po drugim to
> >> jest materiał na thedailywtf.com, a nie poradę w sieci.
> > 
> > 50 ifów? Dlaczego aż tyle? Piszesz aż tak złożone aplikacje na przeglądarkę? Wątpię.
> 
> Wystarczy, że masz prostego datagrida z 50 wierszami. W tym rozwiązaniu
> potrzebujesz każdemu nadać osobne ID i osobno obsłużyć. I jeszcze
> przypadkiem nie dać możliwości zmiany liczby wierszy, bo się wszystko
> posypie.

To proste. Wystarczy tu jeden if i id w stylu "db_idrek". W if wyłapujemy "db"

> 
> > Nawet gdyby, to podałem tylko schemat który łatwo podzielić na segmenty a
> > nawet oddzielne pliki js. Uważam że to słuszna droga. 
> 
> To jest dramat, nie słuszna droga. Ścisłe powiązanie kodu JS ze strukturą
> dokumentu całkowicie przekreśla jakąkolwiek elastyczność tego rozwiązania i
> łatwość w utrzymaniu.
> 
> Ale myśmy juz kiedyś ustalili, że frameworki są zbędne, a wynajdywanie koła
> na nowo jest świetnym ćwiczeniem dydaktycznym.

dyrdymały

> 
> > Bardzo łatwo utrzymać taki kod. Znacznie łatwiej niż gdyby rozsiać
> > onkliki po obiektach a te na dokładkę tworzyć dynamicznie...
> 
> Wiadomo, cały świat tak robi, by sobie utrudniać życie.
> 
> Do obsługi dynamicznie tworzonych obiektów wystaczy podpiąć event listener
> do najbliższego sensownego obiektu nadrzędnego.
> 

i co to ułatwia?

> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

Paweł

Dnia Thu, 1 Mar 2018 07:08:58 -0800 (PST), zpksoft napisał(a):

>> Wystarczy, że masz prostego datagrida z 50 wierszami. W tym rozwiązaniu
>> potrzebujesz każdemu nadać osobne ID i osobno obsłużyć. I jeszcze
>> przypadkiem nie dać możliwości zmiany liczby wierszy, bo się wszystko
>> posypie.
> 
> To proste. Wystarczy tu jeden if i id w stylu "db_idrek". W if wyłapujemy "db"

Coraz lepsze masz pomysły na łatanie chybionego z założenia pomysłu.

Nie prościej zrobić $datagrid.on('click', 'tr.row', function(e) { })
zamiast tworzyć rzeźbę z kodowaniem rodzaju danych w identyfikatorze?

>> Do obsługi dynamicznie tworzonych obiektów wystaczy podpiąć event listener
>> do najbliższego sensownego obiektu nadrzędnego.
> 
> i co to ułatwia?

Organizuje kontrolę zdarzeń w miejscach, których one logicznie dotyczą,
zamiast tworzenia gospodarki centralnie sterowanej. Kod JS nie musi mieć
żadnego związku z HTML-em poza znajomością struktury, a nie każdego
pojedynczego atrybutu. I taki przykładowy datagrid można bez problemu
oddzielić od reszty aplikacji, a nie żmudnie wyłuskiwać z wielkiego
galimatiasu skryptów.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu czwartek, 1 marca 2018 20:19:02 UTC+1 użytkownik Borys Pogoreło napisał:
> Dnia Thu, 1 Mar 2018 07:08:58 -0800 (PST), zpksoft napisał(a):
> 
> >> Wystarczy, że masz prostego datagrida z 50 wierszami. W tym rozwiązaniu
> >> potrzebujesz każdemu nadać osobne ID i osobno obsłużyć. I jeszcze
> >> przypadkiem nie dać możliwości zmiany liczby wierszy, bo się wszystko
> >> posypie.
> > 
> > To proste. Wystarczy tu jeden if i id w stylu "db_idrek". W if wyłapujemy "db"
> 
> Coraz lepsze masz pomysły na łatanie chybionego z założenia pomysłu.
> 
> Nie prościej zrobić $datagrid.on('click', 'tr.row', function(e) { })
> zamiast tworzyć rzeźbę z kodowaniem rodzaju danych w identyfikatorze?
> 

a co to jest 'tr.row'?

> >> Do obsługi dynamicznie tworzonych obiektów wystaczy podpiąć event listener
> >> do najbliższego sensownego obiektu nadrzędnego.
> > 
> > i co to ułatwia?
> 
> Organizuje kontrolę zdarzeń w miejscach, których one logicznie dotyczą,
> zamiast tworzenia gospodarki centralnie sterowanej. Kod JS nie musi mieć
> żadnego związku z HTML-em poza znajomością struktury, a nie każdego
> pojedynczego atrybutu. I taki przykładowy datagrid można bez problemu
> oddzielić od reszty aplikacji, a nie żmudnie wyłuskiwać z wielkiego
> galimatiasu skryptów.

Jeżeli aplikacja jest zmienna w sensie zmian zawartości interfejsu to trudno czymś takim zarządzać. Załóżmy, że wcześniej w miejscu tego datagrid był inny obiekt którego kliknięcie cośtam robiło. No i jak to przeanalizować gdy raptem znika w pewnym momencie zarówno obiekt jak i logika która go dotyczy?
 

> 
> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

Paweł

Dnia Thu, 1 Mar 2018 12:34:59 -0800 (PST), zpksoft napisał(a):

>> Coraz lepsze masz pomysły na łatanie chybionego z założenia pomysłu.
>> 
>> Nie prościej zrobić $datagrid.on('click', 'tr.row', function(e) { })
>> zamiast tworzyć rzeźbę z kodowaniem rodzaju danych w identyfikatorze?
> 
> a co to jest 'tr.row'?

Przykład. Tutaj wiersz datagrida.

> Jeżeli aplikacja jest zmienna w sensie zmian zawartości interfejsu to
> trudno czymś takim zarządzać. 

Przy kodowaniu identyfikatorów na twardo jak najbardziej. Reszta świata
odpina stary nadrzędny event listener i podpina nowy.

> Załóżmy, że wcześniej w miejscu tego datagrid był inny obiekt którego
> kliknięcie cośtam robiło. No i jak to przeanalizować gdy raptem znika w
> pewnym momencie zarówno obiekt jak i logika która go dotyczy?

Bardzo prosto. Datagrid sobie obsługiwał swoje eventy, które nie
bąbelkowały wyżej do Centralnego Biura Zarządzania Zdarzeniami.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu czwartek, 1 marca 2018 22:50:44 UTC+1 użytkownik Borys Pogoreło napisał:
> Dnia Thu, 1 Mar 2018 12:34:59 -0800 (PST), zpksoft napisał(a):
> 
> >> Coraz lepsze masz pomysły na łatanie chybionego z założenia pomysłu.
> >> 
> >> Nie prościej zrobić $datagrid.on('click', 'tr.row', function(e) { })
> >> zamiast tworzyć rzeźbę z kodowaniem rodzaju danych w identyfikatorze?
> > 
> > a co to jest 'tr.row'?
> 
> Przykład. Tutaj wiersz datagrida.

Jeżeli pewien wiersz jest identyfikowany przez ciąg 'tr.row' ta jak jest identyfikowany kolejny?

> 
> > Jeżeli aplikacja jest zmienna w sensie zmian zawartości interfejsu to
> > trudno czymś takim zarządzać. 
> 
> Przy kodowaniu identyfikatorów na twardo jak najbardziej. Reszta świata
> odpina stary nadrzędny event listener i podpina nowy.
> 

Po co podpinać nowy? Kupa roboty i kodu. I nie zasłaniaj się resztą świata. Pisz za siebie.

> > Załóżmy, że wcześniej w miejscu tego datagrid był inny obiekt którego
> > kliknięcie cośtam robiło. No i jak to przeanalizować gdy raptem znika w
> > pewnym momencie zarówno obiekt jak i logika która go dotyczy?
> 
> Bardzo prosto. Datagrid sobie obsługiwał swoje eventy, które nie
> bąbelkowały wyżej do Centralnego Biura Zarządzania Zdarzeniami.
> 

Nie zrozumiałeś pytania. 

> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

Paweł

On 2018-03-01, zpksoft <zpksoft@op.pl> wrote:

[...]

>> Przykład. Tutaj wiersz datagrida.
> Jeżeli pewien wiersz jest identyfikowany przez ciąg 'tr.row' ta jak jest identyfikowany kolejny?

<płaku> :D

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

Dnia Thu, 1 Mar 2018 14:03:13 -0800 (PST), zpksoft napisał(a):

>> Przykład. Tutaj wiersz datagrida.
> 
> Jeżeli pewien wiersz jest identyfikowany przez ciąg 'tr.row' ta jak jest identyfikowany kolejny?

Bierzesz sobie e.target i robisz z tym, co tylko chcesz. Np.
e.target.nextSibling, tudzież $(e.target).next() czy jak tam komu wygodnie.

>> Przy kodowaniu identyfikatorów na twardo jak najbardziej. Reszta świata
>> odpina stary nadrzędny event listener i podpina nowy.
> 
> Po co podpinać nowy? Kupa roboty i kodu. I nie zasłaniaj się resztą świata. Pisz za siebie.

datagrid.removeEventListener('click', staryhandler);
datagrid.addEventListener('click', nowyhandler);

No fakt, kupa roboty i kodu.

> Nie zrozumiałeś pytania. 

Widocznie źle je zadałeś. Co chcesz analizować i w czym przeszkadza, że
zniknęło?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

W dniu czwartek, 1 marca 2018 23:37:39 UTC+1 użytkownik Borys Pogoreło napisał:
> Dnia Thu, 1 Mar 2018 14:03:13 -0800 (PST), zpksoft napisał(a):
> 
> >> Przykład. Tutaj wiersz datagrida.
> > 
> > Jeżeli pewien wiersz jest identyfikowany przez ciąg 'tr.row' ta jak jest identyfikowany kolejny?
> 
> Bierzesz sobie e.target i robisz z tym, co tylko chcesz. Np.
> e.target.nextSibling, tudzież $(e.target).next() czy jak tam komu wygodnie.

Nadal nie odpowiedziałeś na moje pytanie: jak jest identyfikowany row. nextSibling() czy next() to są tylko funkcje. Co one odczytują?

> 
> -- 
> Borys Pogoreło
> borys(#)leszno,edu,pl

Paweł

W dniu piątek, 2 marca 2018 09:08:59 UTC+1 użytkownik zpksoft napisał:
> W dniu czwartek, 1 marca 2018 23:37:39 UTC+1 użytkownik Borys Pogoreło napisał:
> > Dnia Thu, 1 Mar 2018 14:03:13 -0800 (PST), zpksoft napisał(a):
> > 
> > >> Przykład. Tutaj wiersz datagrida.
> > > 
> > > Jeżeli pewien wiersz jest identyfikowany przez ciąg 'tr.row' ta jak jest identyfikowany kolejny?
> > 
> > Bierzesz sobie e.target i robisz z tym, co tylko chcesz. Np.
> > e.target.nextSibling, tudzież $(e.target).next() czy jak tam komu wygodnie.
> 
> Nadal nie odpowiedziałeś na moje pytanie: jak jest identyfikowany row. nextSibling() czy next() to są tylko funkcje. Co one odczytują?
> 
> > 
> > -- 
> > Borys Pogoreło
> > borys(#)leszno,edu,pl
> 
> Paweł

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? I żeby uprzedzić Twoją odpowiedź: nie chodzi mi o odpowiedź typu grid.currentClicked() czy coś w tym stylu. Tak jak napisałem: PO CZYM odczytywany jest id? Bo według ciebie nie jest przecież pamiętany dla każdego wiersza ...

Paweł

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

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ł

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. 

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ł

Dnia Fri, 2 Mar 2018 04:45:25 -0800 (PST), zpksoft napisał(a):

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

Jak już pisałem - polecam poznać model DOM. Serio. Niczego nie trzeba
oznaczać, by móc obsłużyć.

> Zarzuciłeś mi, że indeksowanie jest be a teraz piszesz o e.target.id.

Bo sam o to pytałeś. Weź ze dwa głębokie wdechy i przeczytaj raz jeszcze.

> Problem leży gdzie indziej. Głównie w twoim przeświadczeniu że bez obcego
> "frameworku" nie da się programować. 

Nie, problem leży w tym, że najwyraźniej nie znasz podstaw języka, na speca
od którego próbujesz się kreować. Poznałeś lub opracowałeś kiedyś jakąś
dziwną metodę z centralną obsługą zdarzeń i sie jej trzymasz, bo działa,
nie szukając innych rozwiązań.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Fri, 2 Mar 2018 21:10:31 +0100, Borys Pogoreło wrote:

> Nie, problem leży w tym, że najwyraźniej nie znasz podstaw języka, na speca
> od którego próbujesz się kreować. Poznałeś lub opracowałeś kiedyś jakąś
> dziwną metodę z centralną obsługą zdarzeń i sie jej trzymasz, bo działa,
> nie szukając innych rozwiązań.

Szkoda czasu na tego miszcza, on już na grupie delphi odstawiał swoje
filozofie i mądrości, łatwo wygooglować, choćby tu:

https://groups.google.com/forum/#!msg/pl.comp.lang.delphi/3YjX9S0hNS4/PEHncS31AQAJ

Co ciekawe to tutaj akurat na temat wielowątkowość JS, ale warto poczytać,
kupa zabawy ;-)

Blamażem zajmuje się też na swojej stronie, link:

http://zpksoft.republika.pl/jestem.htm

i rozwijamy "Programowaniem żyję, więc coś na ten temat musi być :)"

i od samego początku do końca bełkot i głupoty. 
Nie kuma Delphi, nie kuma JS, za to cwaniakuje na całego gdzie popadnie.

-- 
pozdrawiam
Roman Tyczka

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

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

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ł

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

W dniu sobota, 3 marca 2018 00:19:01 UTC+1 użytkownik Roman Tyczka napisał:
> On Fri, 2 Mar 2018 21:10:31 +0100, Borys Pogoreło wrote:
> 
> > Nie, problem leży w tym, że najwyraźniej nie znasz podstaw języka, na speca
> > od którego próbujesz się kreować. Poznałeś lub opracowałeś kiedyś jakąś
> > dziwną metodę z centralną obsługą zdarzeń i sie jej trzymasz, bo działa,
> > nie szukając innych rozwiązań.
> 
> Szkoda czasu na tego miszcza, on już na grupie delphi odstawiał swoje
> filozofie i mądrości, łatwo wygooglować, choćby tu:
> 
> https://groups.google.com/forum/#!msg/pl.comp.lang.delphi/3YjX9S0hNS4/PEHncS31AQAJ

Tam myślałem że dyżurny piesek się odezwie

> 
> Co ciekawe to tutaj akurat na temat wielowątkowość JS, ale warto poczytać,
> kupa zabawy ;-)
> 
> Blamażem zajmuje się też na swojej stronie, link:
> 
> http://zpksoft.republika.pl/jestem.htm
> 

Dobre... Nawet nie wiedziałem że to jeszcze wisi w sieci. 
Moja strona to http://zpksoft.pl Tamto to wpis kilkanaście lat temu na darmowym koncie onetu :D

> i rozwijamy "Programowaniem żyję, więc coś na ten temat musi być :)"
> 
> i od samego początku do końca bełkot i głupoty. 
> Nie kuma Delphi, nie kuma JS, za to cwaniakuje na całego gdzie popadnie.
> 

I po co się tak mędrkujesz? Jaki masz cel pijąc do mnie? Może sprawia ci to przyjemność? Zauważyłem, że wszędzie chcesz uchodzić za znawcę. Rób co chcesz, ale ode mnie się odwal, tyczka.

> -- 
> pozdrawiam
> Roman Tyczka

Paweł

W dniu sobota, 3 marca 2018 10:04:02 UTC+1 użytkownik zpksoft napisał:
> W dniu sobota, 3 marca 2018 00:19:01 UTC+1 użytkownik Roman Tyczka napisał:
> > On Fri, 2 Mar 2018 21:10:31 +0100, Borys Pogoreło wrote:
> > 
> > > Nie, problem leży w tym, że najwyraźniej nie znasz podstaw języka, na speca
> > > od którego próbujesz się kreować. Poznałeś lub opracowałeś kiedyś jakąś
> > > dziwną metodę z centralną obsługą zdarzeń i sie jej trzymasz, bo działa,
> > > nie szukając innych rozwiązań.
> > 
> > Szkoda czasu na tego miszcza, on już na grupie delphi odstawiał swoje
> > filozofie i mądrości, łatwo wygooglować, choćby tu:
> > 
> > https://groups.google.com/forum/#!msg/pl.comp.lang.delphi/3YjX9S0hNS4/PEHncS31AQAJ
> 
> Tam myślałem że dyżurny piesek się odezwie
> 
> > 
> > Co ciekawe to tutaj akurat na temat wielowątkowość JS, ale warto poczytać,
> > kupa zabawy ;-)
> > 
> > Blamażem zajmuje się też na swojej stronie, link:
> > 
> > http://zpksoft.republika.pl/jestem.htm
> > 
> 
> Dobre... Nawet nie wiedziałem że to jeszcze wisi w sieci. 
> Moja strona to http://zpksoft.pl Tamto to wpis kilkanaście lat temu na darmowym koncie onetu :D
> 
> > i rozwijamy "Programowaniem żyję, więc coś na ten temat musi być :)"
> > 
> > i od samego początku do końca bełkot i głupoty. 
> > Nie kuma Delphi, nie kuma JS, za to cwaniakuje na całego gdzie popadnie.
> > 
> 
> I po co się tak mędrkujesz? Jaki masz cel pijąc do mnie? Może sprawia ci to przyjemność? Zauważyłem, że wszędzie chcesz uchodzić za znawcę. Rób co chcesz, ale ode mnie się odwal, tyczka.
> 
> > -- 
> > pozdrawiam
> > Roman Tyczka
> 
> Paweł

i tak, wracając do samego początku niniejszego wątku, cóż się dziwić, że grupy zdychają jedna po drugiej?

On Sat, 3 Mar 2018 01:04:01 -0800 (PST), zpksoft wrote:

>> Co ciekawe to tutaj akurat na temat wielowątkowość JS, ale warto poczytać,
>> kupa zabawy ;-)
>> 
>> Blamażem zajmuje się też na swojej stronie, link:
>> 
>> http://zpksoft.republika.pl/jestem.htm
>> 
> 
> Dobre... Nawet nie wiedziałem że to jeszcze wisi w sieci. 
> Moja strona to http://zpksoft.pl Tamto to wpis kilkanaście lat temu na darmowym koncie onetu :D

Czy to znaczy, że zgadzasz się, że tam są bzdury popisane?
 
>> i rozwijamy "Programowaniem żyję, więc coś na ten temat musi być :)"
>> 
>> i od samego początku do końca bełkot i głupoty. 
>> Nie kuma Delphi, nie kuma JS, za to cwaniakuje na całego gdzie popadnie.
>> 
> 
> I po co się tak mędrkujesz? Jaki masz cel pijąc do mnie? 

Chcę ustrzec innych, zwłaszcza mniej doświadczonych, żeby nie traktowali
Cię zbyt poważnie i przypadkiem nie brali z Ciebie przykładu, bo pojadą w
maliny. 

> Może sprawia ci to przyjemność? 

Nie, to przykre, że trzeba czytać takie zbdety.

> Zauważyłem, że wszędzie chcesz uchodzić za znawcę. Rób co chcesz, ale ode mnie się odwal, tyczka.

<ziew>


-- 
pozdrawiam
Roman Tyczka

On Sat, 3 Mar 2018 01:14:27 -0800 (PST), ipluta62@gmail.com wrote:

> i tak, wracając do samego początku niniejszego wątku, cóż się dziwić, że grupy zdychają jedna po drugiej?

Grupy zdychają z zupełnie innych powodów, dziwne, że tego nie wiesz.

-- 
pozdrawiam
Roman Tyczka

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

....> 
> <ziew>
> 
> 
> -- 
> pozdrawiam
> Roman Tyczka

Już raz napisałem. Odwal się ode mnie.

Paweł

Dnia Sat, 3 Mar 2018 01:14:27 -0800 (PST), ipluta62@gmail.com napisał(a):

>> I po co się tak mędrkujesz? Jaki masz cel pijąc do mnie? Może sprawia ci to przyjemność? Zauważyłem, że wszędzie chcesz uchodzić za znawcę. Rób co chcesz, ale ode mnie się odwal, tyczka.
> 
> i tak, wracając do samego początku niniejszego wątku, cóż się dziwić, że
> grupy zdychają jedna po drugiej?

E tam, to powyższe to żaden powód. Kiedyś flejmów i kłótni było więcej i
były dużo bardziej soczyste, a nikogo to nie dziwiło. Ludzie odchodzą, a
nowi nie przychodzą, bo jest więcej miejsc z niskim progiem wejścia.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

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

On Sat, 3 Mar 2018 04:40:14 -0800 (PST), zpksoft wrote:

> Już raz napisałem. Odwal się ode mnie.
> 
> Paweł

Trochę pokory miszczu, pisanie do Borysa "Zobacz jak jest napisany to może
coś zrozumiesz" jest delikatnie mówiąc bezczelne, żeby nie dodać, że i
żenujące.

-- 
pozdrawiam
Roman Tyczka

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

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

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

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

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/

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

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

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/

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/

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

On 03/03/2018 22:32, Wojciech Bancer wrote:
> On 2018-03-03, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:
[...]
>> 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ć.

W takim razie doszliśmy do sytuacji, w której, że tak to ujmę, "we are 
on the same page" ;-)

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

Dnia Sat, 3 Mar 2018 22:32:38 +0100, Wojciech Bancer napisał(a):

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

To akurat zły przykład, bo tam siedzą tęgie głowy i kombinują, jak to
dobrze zrobić. Przy miliardzie użytkowników to musi być *naprawdę* dobrze
zoptymalizowane i mogą na to poświęcić odpowiednie środki.

Ciekawszym przykładem jest mBank, który pcha do przeglądarki 5.5MB(!) kodu
JS (1,67MB po kompresji). Jak dla mnie lekkie przegięcie. Ale o jakości tej
aplikacji napisano już wiele.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On 03/03/2018 22:55, Borys Pogoreło wrote:
> Dnia Sat, 3 Mar 2018 22:32:38 +0100, Wojciech Bancer napisał(a):
> 
>> 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.
> 
> To akurat zły przykład, bo tam siedzą tęgie głowy i kombinują, jak to
> dobrze zrobić. Przy miliardzie użytkowników to musi być *naprawdę* dobrze
> zoptymalizowane i mogą na to poświęcić odpowiednie środki.
> 
> Ciekawszym przykładem jest mBank, który pcha do przeglądarki 5.5MB(!) kodu
> JS (1,67MB po kompresji). Jak dla mnie lekkie przegięcie. Ale o jakości tej
> aplikacji napisano już wiele.

Podobnie zresztą robi ING Bank, ale tam się nikt tym nie przejmuje. :/

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

Borys Pogoreło pisze:
> Dnia Sat, 3 Mar 2018 22:32:38 +0100, Wojciech Bancer napisał(a):
> 
>> 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.
> 
> To akurat zły przykład, bo tam siedzą tęgie głowy i kombinują, jak to
> dobrze zrobić. Przy miliardzie użytkowników to musi być *naprawdę* dobrze
> zoptymalizowane i mogą na to poświęcić odpowiednie środki.
Coś nie za bardzo są to "tęgie głowy", skoro wspierają tylko
naj naj najnowszą wersję przeglądarki, a elementarna funkcjonalność
dostępną w przeglądarkach od lat nie działa.

> Ciekawszym przykładem jest mBank, który pcha do przeglądarki 5.5MB(!) kodu
> JS (1,67MB po kompresji). Jak dla mnie lekkie przegięcie. Ale o jakości tej
> aplikacji napisano już wiele.
true, true, true,

Jeszcze ciekawszym przykładem jest gowork, po otwarciu strony
przeglądarka przestała być responsywna, dopiero po wyłączeniu
obsługi JavaScript mogłem otworzyć stronę i coś zobaczyć.
Niestety Adblockiem nie bardzo jest co zablokować
(kod JavaScript jest w HTMLu).