🚀 go-pugleaf

W dniu 2017-03-15 o 06:20, Jivanmukta pisze:
> Mam na stronie:
 > ...
> Dlaczego undefined? Jak poprawić funkcję divLabelOf? Byłbym wdzięczny za
> podpowiedź.

Poradziłem sobie:

function divLabelOf(elem) {
	if (elem) {
		var p = elem;
		while (p.className != 'control') {
			p = p.parentNode;
		}
		p = p.parentNode;
		return p.childNodes[1];	// div
	}
	return null;
}

bo przed divem był pusty tekst co też się liczy jako childNodes.

---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

On 15/03/2017 14:31, Jivanmukta wrote:
> W dniu 2017-03-15 o 06:20, Jivanmukta pisze:
>> Mam na stronie:
>> ...
>> Dlaczego undefined? Jak poprawić funkcję divLabelOf? Byłbym wdzięczny za
>> podpowiedź.
>
> Poradziłem sobie:
>
> function divLabelOf(elem) {
>     if (elem) {
>         var p = elem;
>         while (p.className != 'control') {
>             p = p.parentNode;
>         }
>         p = p.parentNode;
>         return p.childNodes[1];    // div
>     }
>     return null;
> }
>
> bo przed divem był pusty tekst co też się liczy jako childNodes.

Zainteresuj się firstElementChild: 
https://developer.mozilla.org/en-US/docs/Web/API/ParentNode/firstElementChild

-- 
Cezary Tomczyk
https://www.aslint.org/ - walidacja Accessibility
Blokowanie automatycznego odtwarzania video na gazeta.pl w Google 
Chrome: https://goo.gl/0kCRLS

W dniu sobota, 18 marca 2017 16:05:05 UTC+1 użytkownik Wojciech Bancer napisał:
>ciach> 
> Ty mi raczej znajdź bank, który NIE korzysta z rozwiązań open-source.
> Od razu Ci podpowiem: nie ma takich. PKO, mBank, BZWBK, Sandander, Polbank,
> Citi Handlowy, cokolwiek nie znajdziesz, korzysta z open source garściami.
> 
> Przespałeś ostatnie 10-15 lat w IT? :)
> 
> -- 
> Wojciech Bańcer
> wojciech.bancer@gmail.com

Wiem że niektóre korzystają. Bo mają programistów którzy wsiąkli w te tematy i nie mogą z nich wyjść. A potem się męczą. Niedopuszczalne jest żeby część logiki aplikacji bankowej znajdował się na serwerach zewnętrznych, więc muszą ściągnąć wszystkie źródła. Za chwilę dochodzą do wniosku że zostają w tyle bo framework ma nową wersję, cokolwiek by to znaczyło.
I zaczyna się burza. Ostatnia np w Citi, gdzie kasa biegała po kontach w sposób niemalże losowy ;)

To jest złe programowanie.

Paweł 

zpksoft wrote:
>> A poza tym, zrezygnuj z onfocus i onblur inline i skorzystaj z delegacji
>> zdarzeń (event delegation):
>> 
>> https://bfkot.wordpress.com/2010/09/02/event-delegation-delegowane-nasluchy-czyli-wydarzenia-w-delegacji-czesc-1/
>> 
>> --
>> Cezary Tomczyk
>> https://www.aslint.org/ - walidacja Accessibility
>> Blokowanie automatycznego odtwarzania video na gazeta.pl w Google
>> Chrome: https://goo.gl/0kCRLS
> 
> Dodam jeszcze że niezbyt inteligentny jest ten kod. Po co tak motać prosty
> sznurek?
> 
> Przecież wystarczy napisać:
> 
>   document.onclick = function(e){
> 
>   e = e || window.event;
>   var t = e.target || e.srcElement;
>   n=t.id || t.className;
>   if (!n) return;
> //i teraz obsługa naszej aplikacji:
> 
> if (n=='id_diva1') {...}
> else if (n=='id_elementu_span1') {...}
> else ...

Zrobiłem tak:

function setFocusAndBlur() {
	var i, sel;
	sel = document.querySelectorAll("fieldset input");
	for (i = 0; i < sel.length; i++) sel[i].onfocus = onFocusElement;
	sel = document.querySelectorAll("fieldset input");
	for (i = 0; i < sel.length; i++) sel[i].onblur = onBlurElement;
	sel = document.querySelectorAll("fieldset select");
	for (i = 0; i < sel.length; i++) sel[i].onfocus = onFocusElement;
	sel = document.querySelectorAll("fieldset select");
	for (i = 0; i < sel.length; i++) sel[i].onblur = onBlurElement;
	sel = document.querySelectorAll("fieldset textarea");
	for (i = 0; i < sel.length; i++) sel[i].onfocus = onFocusElement;
	sel = document.querySelectorAll("fieldset textarea");
	for (i = 0; i < sel.length; i++) sel[i].onblur = onBlurElement;
	document.querySelector("#captcha").onfocus = onFocusElement;
	document.querySelector("#captcha").onblur = onBlurElement;
}

i mi działa. Problem zamknięty. Dzięki za pomoc.

On 2017-03-19, zpksoft <zpksoft@op.pl> wrote:
> W dniu sobota, 18 marca 2017 16:05:05 UTC+1 użytkownik Wojciech Bancer napisał:
>>ciach> 
>> Ty mi raczej znajdź bank, który NIE korzysta z rozwiązań open-source.
>> Od razu Ci podpowiem: nie ma takich. PKO, mBank, BZWBK, Sandander, Polbank,
>> Citi Handlowy, cokolwiek nie znajdziesz, korzysta z open source garściami.
>> 
>> Przespałeś ostatnie 10-15 lat w IT? :)
>
> Wiem że niektóre korzystają. 

Poproszę jeszcze raz. Znajdź bank który nie korzysta.

> Bo mają programistów którzy wsiąkli w te tematy i nie mogą z nich wyjść. A potem się męczą. 

Nie sądzę by ktokolwiek się tam męczył.

[...]

> To jest złe programowanie.

To co opowiadasz to jest brak wiedzy, a nie złe programowanie.
Możliwe, że z Twojej strony.

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

W dniu niedziela, 19 marca 2017 20:58:45 UTC+1 użytkownik Wojciech Bancer napisał:
> On 2017-03-19, zpksoft <zpksoft@op.pl> wrote:
> > W dniu sobota, 18 marca 2017 16:05:05 UTC+1 użytkownik Wojciech Bancer napisał:
> >>ciach> 
> >> Ty mi raczej znajdź bank, który NIE korzysta z rozwiązań open-source.
> >> Od razu Ci podpowiem: nie ma takich. PKO, mBank, BZWBK, Sandander, Polbank,
> >> Citi Handlowy, cokolwiek nie znajdziesz, korzysta z open source garściami.
> >> 
> >> Przespałeś ostatnie 10-15 lat w IT? :)
> >
> > Wiem że niektóre korzystają. 
> 
> Poproszę jeszcze raz. Znajdź bank który nie korzysta.
> 
> > Bo mają programistów którzy wsiąkli w te tematy i nie mogą z nich wyjść. A potem się męczą. 
> 
> Nie sądzę by ktokolwiek się tam męczył.
> 
> [...]
> 
> > To jest złe programowanie.
> 
> To co opowiadasz to jest brak wiedzy, a nie złe programowanie.
> Możliwe, że z Twojej strony.
> 
> -- 
> Wojciech Bańcer
> wojciech.bancer@gmail.com

Nie zaperzaj się. Mam konto we wspomnianym banku więc wiem co ostatnio się działo. Oczywiście z ciekawości zajrzałem w kod strony więc wiem co piszę.

Przekornie jeszcze nawiążę do tej grupy programistów o której pisałeś. Otóż rewolucyjnych rozwiązań nie tworzą grupy. 

Grupy tworzą takie np. Windows 10.

Paweł

Dnia Sat, 18 Mar 2017 07:34:00 -0700 (PDT), zpksoft napisał(a):

> Może się też okazać że stosując jakieś tam frameworki zrobisz zadanie
> znacznie wolniej niż ja bo będziesz musiał się najpierw tego nauczyć.

Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
i historie wszelkich niekompatybilności, a później próba zapamiętania tego.

> Kolejna sprawa to aplikacje o wysokim stopniu bezpieczeństwa. Oprzesz je
> na freewarowym frameworku? Np. aplikację dla banku?

Straszni amatorzy muszą pracować w tych bankach, bo w systemie
transakcyjnym mBanku widzę jQuery, jQuery UI i tonę wtyczek.

https://online.mbank.pl/combres.axd/LibsJs/301586628/

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

On 20/03/2017 18:24, Borys Pogoreło wrote:
> Dnia Sat, 18 Mar 2017 07:34:00 -0700 (PDT), zpksoft napisał(a):
>
>> Może się też okazać że stosując jakieś tam frameworki zrobisz zadanie
>> znacznie wolniej niż ja bo będziesz musiał się najpierw tego nauczyć.
>
> Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
> i historie wszelkich niekompatybilności, a później próba zapamiętania tego.

Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień 
dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu 
na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle.

Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś 
jak CSS grid. ;-)

>> Kolejna sprawa to aplikacje o wysokim stopniu bezpieczeństwa. Oprzesz je
>> na freewarowym frameworku? Np. aplikację dla banku?
>
> Straszni amatorzy muszą pracować w tych bankach, bo w systemie
> transakcyjnym mBanku widzę jQuery, jQuery UI i tonę wtyczek.
>
> https://online.mbank.pl/combres.axd/LibsJs/301586628/

No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna 
do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z 
jQuery czy innego narzędzia, to odpowiedź jest jedna - z 
przyzwyczajenia. No a potem takie aplikacje puchną bez limitu.

Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że 
mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą 
aplikację. Sam tak robię. Korpo zasady to już inna bajka. Tam w 
większości przypadków nie mogłem zaobserwować postępu :-(

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

W dniu wtorek, 21 marca 2017 08:38:16 UTC+1 użytkownik Cezary Tomczyk napisał:
> On 20/03/2017 18:24, Borys Pogoreło wrote:
> > Dnia Sat, 18 Mar 2017 07:34:00 -0700 (PDT), zpksoft napisał(a):
> >
> >> Może się też okazać że stosując jakieś tam frameworki zrobisz zadanie
> >> znacznie wolniej niż ja bo będziesz musiał się najpierw tego nauczyć.
> >
> > Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
> > i historie wszelkich niekompatybilności, a później próba zapamiętania tego.
> 
> Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień 
> dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu 
> na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle.
> 
> Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś 
> jak CSS grid. ;-)
> 
> >> Kolejna sprawa to aplikacje o wysokim stopniu bezpieczeństwa. Oprzesz je
> >> na freewarowym frameworku? Np. aplikację dla banku?
> >
> > Straszni amatorzy muszą pracować w tych bankach, bo w systemie
> > transakcyjnym mBanku widzę jQuery, jQuery UI i tonę wtyczek.
> >
> > https://online.mbank.pl/combres.axd/LibsJs/301586628/
> 
> No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna 
> do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z 
> jQuery czy innego narzędzia, to odpowiedź jest jedna - z 
> przyzwyczajenia. No a potem takie aplikacje puchną bez limitu.
> 
> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że 
> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą 
> aplikację. Sam tak robię. 

Właśnie. Też to zauważyłem. I jest to budujące.

> Korpo zasady to już inna bajka. Tam w 
> większości przypadków nie mogłem zaobserwować postępu :-(
> 
> -- 
> Cezary Tomczyk
> http://www.ctomczyk.pl/

Paweł

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

[...]

>> Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
>> i historie wszelkich niekompatybilności, a później próba zapamiętania tego.
>
> Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień 
> dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu 
> na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle.

A to już zależy z jak bardzo zaawansowanego ES korzystasz i co masz do 
zrobienia. Dla przykładu generowanie plików binarnych po stronie frontendu
plus ich download potrafi sprawić problemy (np. z Safari).

> Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś 
> jak CSS grid. ;-)

IE ma całkiem sporo niedoróbek jeszcze:
https://kangax.github.io/compat-table/es6/
A z nowych rzeczy, to już w ogóle nie ma.

>> Straszni amatorzy muszą pracować w tych bankach, bo w systemie
>> transakcyjnym mBanku widzę jQuery, jQuery UI i tonę wtyczek.
>> https://online.mbank.pl/combres.axd/LibsJs/301586628/
>
> No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna 
> do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z 
> jQuery czy innego narzędzia, to odpowiedź jest jedna - z 
> przyzwyczajenia. No a potem takie aplikacje puchną bez limitu.

Ale to nie jest argument żeby nie używać tooli/frameworków. To jest argument
by dokonywać refaktoru kodu i używać go porządnie. Ja jestem zwolennikiem 
zasady, że w stabilnym projekcie do każdej dodanej zależności albo należy
dodać solidne uzasadnienie, albo należy jakąś inną zależność usunąć.

> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że 
> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą 
> aplikację.

I żeby jeszcze przeglądarki masowo wspierały owe "dzisiejsze implementacje" :P

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

On 2017-03-19, zpksoft <zpksoft@op.pl> wrote:

[...]

>> To co opowiadasz to jest brak wiedzy, a nie złe programowanie.
>> Możliwe, że z Twojej strony.
>> 
>> -- 
>> Wojciech Bańcer
>> wojciech.bancer@gmail.com
>
> Nie zaperzaj się. Mam konto we wspomnianym banku więc wiem co ostatnio się działo. 

Też mam. Problem z podwójnym księgowaniem kwot z kart (bo chyba o tym mówisz, taki
był ostatnio u nich problem) nie jest problemem interfejsu użytkownika systemu 
transakcyjnego.

> Oczywiście z ciekawości zajrzałem w kod strony więc wiem co piszę.

Wytworzyłeś związek przyczynowo-skutkowy bez żadnego uzasadnienia
i tylko na zasadzie "nie lubię jQuery" chyba.

Ja jeszcze mam konto w Raiffeisen-Polbank, mBanku, BZWBK, PKO BP, PeKaO S.A. i Aliorze.
Wszędzie używają min. jQuery. Zgodnie z Twoją wcześniejszą argumentacją to się zdarzyć
nie powinno, bo to instytucje finansowe.

> Przekornie jeszcze nawiążę do tej grupy programistów o której pisałeś. 
> Otóż rewolucyjnych rozwiązań nie tworzą grupy. 

W dziedzinie programowania dokonujemy rozwoju ewolucyjnego, nie rewolucyjnego.
Podobnie jak nie dokonumemy rewolucji w językach mówionych.

Rewolucji to możesz dokonywać na polu algorytmiki, a ta nie zależy od języka.

Problem w tym, że odrzucając wszystkie narzędzia wytworzone przez community
"bo Ty wiesz lepiej i szybciej", to trochę tak jakbyś próbował na nowo 
wymyślać koło, ignorując fakt że ktoś już wymyślił nie tylko koło, ale
i popierdala samochodem elektrycznym.

Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak 
Angular, czy React? Czy może uważasz że to zbędne narzędzia?

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

On 21/03/2017 15:17, Wojciech Bancer wrote:
[...]
> Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak
> Angular, czy React? Czy może uważasz że to zbędne narzędzia?

Wg mnie problem w tym, że ludzie nie zadają sobie pytania: jakiego 
rodzaju problem próbuję rozwiązać zanim skorzystam z rozwiązania [tu 
wstaw dowolną nazwę frameworku, narzędzi, itd.]?

Zamiast tego podąrzają za tłumem.

Przypomina mi się rozmowa z jednym z menadżerów projektu:

PM: Będziemy przechodzić na React teraz.
Ja: A jakiego rodzaju problemy tym rozwiążecie?
PM: No mamy problem z wydajnością.
Ja: A w którym konkretnie miejscu?
PM: No tak ogólnie.
Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej 
architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych 
zależności, a może proces zarządzania zadaniami kuleje?
PM: Hm, dobre pytanie. Muszę to sprawdzić.

Nie ma zbędnych narzędzi. Są za to złe zastosowania i przerost formy nad 
treścią.

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

On 21/03/2017 15:02, Wojciech Bancer wrote:
> On 2017-03-21, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:
>
> [...]
>
>>> Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
>>> i historie wszelkich niekompatybilności, a później próba zapamiętania tego.
>>
>> Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień
>> dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu
>> na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle.
>
> A to już zależy z jak bardzo zaawansowanego ES korzystasz i co masz do
> zrobienia. Dla przykładu generowanie plików binarnych po stronie frontendu
> plus ich download potrafi sprawić problemy (np. z Safari).

To, że Safari sprawia z tym problemy, to jest osobna sprawa i żadna 
biblioteka tego nie rozwiąże. ;-)

>> Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś
>> jak CSS grid. ;-)
>
> IE ma całkiem sporo niedoróbek jeszcze:
> https://kangax.github.io/compat-table/es6/
> A z nowych rzeczy, to już w ogóle nie ma.

Nic na siłę. Napisane porządnej aplikacji bez const/let i innych z ES6, 
jest jak najbardziej możliwe.

>>> Straszni amatorzy muszą pracować w tych bankach, bo w systemie
>>> transakcyjnym mBanku widzę jQuery, jQuery UI i tonę wtyczek.
>>> https://online.mbank.pl/combres.axd/LibsJs/301586628/
>>
>> No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna
>> do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z
>> jQuery czy innego narzędzia, to odpowiedź jest jedna - z
>> przyzwyczajenia. No a potem takie aplikacje puchną bez limitu.
>
> Ale to nie jest argument żeby nie używać tooli/frameworków. To jest argument

Nie mówię nie używać, ale jeśli coś da się zrobić prościej, to dlaczego 
nie :-)

> by dokonywać refaktoru kodu i używać go porządnie. Ja jestem zwolennikiem
> zasady, że w stabilnym projekcie do każdej dodanej zależności albo należy
> dodać solidne uzasadnienie, albo należy jakąś inną zależność usunąć.

Ja bym jeszcze dodał: jeśli wszystkie unit i inne testy passed, to 
refactoring odbył się pomyślnie ;-)

>> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że
>> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą
>> aplikację.
>
> I żeby jeszcze przeglądarki masowo wspierały owe "dzisiejsze implementacje" :P

No cóż. Idealnie nigdy nie będzie, ale niektórzy już piszą w ES6 a 
potem... transpilują to do ES5 za pomocą popularnego Babel-a (Babla? :-)).

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

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

[...]

>> IE ma całkiem sporo niedoróbek jeszcze:
>> https://kangax.github.io/compat-table/es6/
>> A z nowych rzeczy, to już w ogóle nie ma.
>
> Nic na siłę. Napisane porządnej aplikacji bez const/let i innych z ES6, 
> jest jak najbardziej możliwe.

Ale gdzie ja twierdziłem, że to nie jest możliwe?
BA! Napisanie porządnej aplikacji w assemblerze jest możliwe!
Tylko _kosztuje_ więcej, jest mniej skalowalne, gorzej zarządzalne itp. itd.
Jak masz 2 programistów na krzyż i nielimitowany budżet, to możesz
sobie nawet dziergać w kodzie maszynowym.

>> Ale to nie jest argument żeby nie używać tooli/frameworków. To jest argument
>
> Nie mówię nie używać, ale jeśli coś da się zrobić prościej, to dlaczego 
> nie :-)

Toż cały czas kontruję, że _z wykorzystaniem_ frameworka jest prościej.
I łatwiej kodem zarządzać, bo całość (włącznie z organizacją tegoż) nie
siedzi w głowie 1 człowieka, są określone standardy pisania itp. itd.

>>> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że
>>> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą
>>> aplikację.
>>
>> I żeby jeszcze przeglądarki masowo wspierały owe "dzisiejsze implementacje" :P
>
> No cóż. Idealnie nigdy nie będzie, ale niektórzy już piszą w ES6 a 
> potem... transpilują to do ES5 za pomocą popularnego Babel-a (Babla? :-)).

Babel wszystkiego idealnie nie załatwi.

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

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

[...]

> PM: Będziemy przechodzić na React teraz.
> Ja: A jakiego rodzaju problemy tym rozwiążecie?
> PM: No mamy problem z wydajnością.
> Ja: A w którym konkretnie miejscu?
> PM: No tak ogólnie.
> Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej 
> architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych 
> zależności, a może proces zarządzania zadaniami kuleje?
> PM: Hm, dobre pytanie. Muszę to sprawdzić.

No i? Ja mam na tony przykładów projektów utrzymywanych z dużym
trudem, bo nie został podjęty wysiłek refaktoru po pierwszych 
programistach, którzy dziergali swoje cuda we własnych tylko sobie
znanych ścieżkach myślowych.

I potem śledź 10-letni kod i zastanawiaj się co autor (który już
dawno nie pracuje i ma to w pompie) miał na myśli :P

Frameworki przynajmniej potrafią standaryzować kod i ułatwiają
tego typu rzeczy.

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

On Tue, 21 Mar 2017 15:17:42 +0100, Wojciech Bancer wrote:

>> Przekornie jeszcze nawiążę do tej grupy programistów o której pisałeś. 
>> Otóż rewolucyjnych rozwiązań nie tworzą grupy. 
> 
> W dziedzinie programowania dokonujemy rozwoju ewolucyjnego, nie rewolucyjnego.
> Podobnie jak nie dokonumemy rewolucji w językach mówionych.
> 
> Rewolucji to możesz dokonywać na polu algorytmiki, a ta nie zależy od języka.
> 
> Problem w tym, że odrzucając wszystkie narzędzia wytworzone przez community
> "bo Ty wiesz lepiej i szybciej", to trochę tak jakbyś próbował na nowo 
> wymyślać koło, ignorując fakt że ktoś już wymyślił nie tylko koło, ale
> i popierdala samochodem elektrycznym.
> 
> Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak 
> Angular, czy React? Czy może uważasz że to zbędne narzędzia?

Po co Ty z nim rozmawiasz? To zwykły druciarz co dzierga jakieś krzywe
patenty w zespole jednoosobowym na zlecenie jednoosobowych firemek. Znam go
z innej grupy, tam też mędrkował i pouczał pisząc totalne bzdury, szkoda
czasu na dyskusje z amatorem, który nie ma bladego pojęcia o wzorcach,
metodykach i kodowaniu ogólnie.

-- 
pozdrawiam
Roman Tyczka

Dnia Tue, 21 Mar 2017 08:38:15 +0100, Cezary Tomczyk napisał(a):

>> Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
>> i historie wszelkich niekompatybilności, a później próba zapamiętania tego.
> 
> Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień 
> dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu 
> na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle.

Bo twórcy przeglądarek w końcu zaczęli czytać dokumentację, zamiast ją
wymyślać. Jednak to nie znaczy, że problemów nie ma, a zwłaszcza braków w
jakiejś konkretnej przeglądarce (najciekawiej jest, gdy coś nie działa w
Safari mobilnym, a w pełnym tak).

> Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś 
> jak CSS grid. ;-)

Albo choćby flexbox. Dostępny od lat, ale nie dość, że są trzy wersje, to
jeszcze implementacje mają masę błędów.

>> https://online.mbank.pl/combres.axd/LibsJs/301586628/
> 
> No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna 
> do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z 
> jQuery czy innego narzędzia, to odpowiedź jest jedna - z 
> przyzwyczajenia. No a potem takie aplikacje puchną bez limitu.

Ja bym odpowiedział, że z wygody. Inny problem to pluginy, które albo są
małe i nie robią tego, co chcesz albo mają setkę opcji i ważą 100KB sztuka.

> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że 
> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą 
> aplikację. Sam tak robię. Korpo zasady to już inna bajka. Tam w 
> większości przypadków nie mogłem zaobserwować postępu :-(

Programista jQuery jest tańszy ;)

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

Dnia Tue, 21 Mar 2017 17:43:51 +0100, Cezary Tomczyk napisał(a):

> PM: Będziemy przechodzić na React teraz.
> Ja: A jakiego rodzaju problemy tym rozwiążecie?
> PM: No mamy problem z wydajnością.
> Ja: A w którym konkretnie miejscu?
> PM: No tak ogólnie.
> Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej 
> architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych 
> zależności, a może proces zarządzania zadaniami kuleje?
> PM: Hm, dobre pytanie. Muszę to sprawdzić.

Urban legend, nie uwierzę w ostatnią linijkę ;)

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

On 21/03/2017 18:43, Wojciech Bancer wrote:
> On 2017-03-21, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:
>
> [...]
>
>> PM: Będziemy przechodzić na React teraz.
>> Ja: A jakiego rodzaju problemy tym rozwiążecie?
>> PM: No mamy problem z wydajnością.
>> Ja: A w którym konkretnie miejscu?
>> PM: No tak ogólnie.
>> Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej
>> architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych
>> zależności, a może proces zarządzania zadaniami kuleje?
>> PM: Hm, dobre pytanie. Muszę to sprawdzić.
>
> No i? Ja mam na tony przykładów projektów utrzymywanych z dużym
> trudem, bo nie został podjęty wysiłek refaktoru po pierwszych
> programistach, którzy dziergali swoje cuda we własnych tylko sobie
> znanych ścieżkach myślowych.
>
> I potem śledź 10-letni kod i zastanawiaj się co autor (który już
> dawno nie pracuje i ma to w pompie) miał na myśli :P
>
> Frameworki przynajmniej potrafią standaryzować kod i ułatwiają
> tego typu rzeczy.

Ale ja nie mówię, że nie. Przeciwnie. Frameworki standaryzują pracę i to 
jest fakt niezaprzeczalny. I odnośnie do Twojego "> No i?" - No i grunt 
to jest zawsze dobranie narzędzi do problemu, a nie odwrotnie.

>> No i? Ja mam na tony przykładów projektów utrzymywanych z dużym
>> trudem, bo nie został podjęty wysiłek refaktoru po pierwszych
>> programistach, którzy dziergali swoje cuda we własnych tylko sobie
>> znanych ścieżkach myślowych.

Też pracowałem w takich projektach, ale fakt jest taki, że na początku 
drogi projektu wybrano takie, a nie inne rozwiązania. Być może słuszne 
na ten moment, kiedy projekt startował. A jak wiemy, w naszym świecie co 
roku zmieniają się technologie i podejścia, a my musimy z tym żyć. 
Refactoring jest częścią procesu produkcji oprogramowania.

>> I potem śledź 10-letni kod i zastanawiaj się co autor (który już
>> dawno nie pracuje i ma to w pompie) miał na myśli :P

A to swoją drogą. Ktoś po Tobie też będzie kiedyś poprawiał :P

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

On 21/03/2017 22:16, Borys Pogoreło wrote:
> Dnia Tue, 21 Mar 2017 17:43:51 +0100, Cezary Tomczyk napisał(a):
>
>> PM: Będziemy przechodzić na React teraz.
>> Ja: A jakiego rodzaju problemy tym rozwiążecie?
>> PM: No mamy problem z wydajnością.
>> Ja: A w którym konkretnie miejscu?
>> PM: No tak ogólnie.
>> Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej
>> architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych
>> zależności, a może proces zarządzania zadaniami kuleje?
>> PM: Hm, dobre pytanie. Muszę to sprawdzić.
>
> Urban legend, nie uwierzę w ostatnią linijkę ;)

No cóż, jak jest PM, który jest tzw. nietechniczny, to tak to wygląda ;-)

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

On 21/03/2017 18:39, Wojciech Bancer wrote:
> On 2017-03-21, Cezary Tomczyk <cezary.tomczyk@gmail.com> wrote:
>
> [...]
>
>>> IE ma całkiem sporo niedoróbek jeszcze:
>>> https://kangax.github.io/compat-table/es6/
>>> A z nowych rzeczy, to już w ogóle nie ma.
>>
>> Nic na siłę. Napisane porządnej aplikacji bez const/let i innych z ES6,
>> jest jak najbardziej możliwe.
>
> Ale gdzie ja twierdziłem, że to nie jest możliwe?
> BA! Napisanie porządnej aplikacji w assemblerze jest możliwe!
> Tylko _kosztuje_ więcej, jest mniej skalowalne, gorzej zarządzalne itp. itd.
> Jak masz 2 programistów na krzyż i nielimitowany budżet, to możesz
> sobie nawet dziergać w kodzie maszynowym.
>
>>> Ale to nie jest argument żeby nie używać tooli/frameworków. To jest argument
>>
>> Nie mówię nie używać, ale jeśli coś da się zrobić prościej, to dlaczego
>> nie :-)
>
> Toż cały czas kontruję, że _z wykorzystaniem_ frameworka jest prościej.
> I łatwiej kodem zarządzać, bo całość (włącznie z organizacją tegoż) nie
> siedzi w głowie 1 człowieka, są określone standardy pisania itp. itd.

Eh, myślę, że obaj mamy zbieżne poglądy, tylko inaczej nieco 
przedstawiane. :-)

>>>> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że
>>>> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą
>>>> aplikację.
>>>
>>> I żeby jeszcze przeglądarki masowo wspierały owe "dzisiejsze implementacje" :P
>>
>> No cóż. Idealnie nigdy nie będzie, ale niektórzy już piszą w ES6 a
>> potem... transpilują to do ES5 za pomocą popularnego Babel-a (Babla? :-)).
>
> Babel wszystkiego idealnie nie załatwi.

Naturalnie, że nie.

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

On 21/03/2017 22:12, Borys Pogoreło wrote:
> Dnia Tue, 21 Mar 2017 08:38:15 +0100, Cezary Tomczyk napisał(a):
>
>>> Tak, na pewno zajmie to dłużej, niż przekopywanie się przez specyfikacje JS
>>> i historie wszelkich niekompatybilności, a później próba zapamiętania tego.
>>
>> Oj, nie przesadzajmy z tą ogromną niekompatybilnością. Na dzień
>> dzisiejszy osoboście rzadko mi się zdarza, że muszę spędzić więcej czasu
>> na rozwiązaniu problemu z kompatybilnością. W 99% wszystko działa nieźle.
>
> Bo twórcy przeglądarek w końcu zaczęli czytać dokumentację, zamiast ją
> wymyślać. Jednak to nie znaczy, że problemów nie ma, a zwłaszcza braków w
> jakiejś konkretnej przeglądarce (najciekawiej jest, gdy coś nie działa w
> Safari mobilnym, a w pełnym tak).

Absolutnie podzielam Twoje zdanie.

>> Oczywiście, problem pojawia się na pewno, kiedy chce się zastosować coś
>> jak CSS grid. ;-)
>
> Albo choćby flexbox. Dostępny od lat, ale nie dość, że są trzy wersje, to
> jeszcze implementacje mają masę błędów.

Nie ma lekko :-) Ale dzięki temu mamy też pracę, bo jakby było idealnie, 
to nie bylibyśmy potrzebni :D

>>> https://online.mbank.pl/combres.axd/LibsJs/301586628/
>>
>> No ale ilość użytych narzędzi/libów/itp. nie jest wprost proporcjonalna
>> do jakości. Ilekroć pytam programistów o to, dlaczego korzystają z
>> jQuery czy innego narzędzia, to odpowiedź jest jedna - z
>> przyzwyczajenia. No a potem takie aplikacje puchną bez limitu.
>
> Ja bym odpowiedział, że z wygody. Inny problem to pluginy, które albo są
> małe i nie robią tego, co chcesz albo mają setkę opcji i ważą 100KB sztuka.

No i musimy z tym żyć. Czasem jednak szlag mnie już trafia i wychodzi na 
to, że szybciej sam napiszę coś (włączając w to unit testy), niż znajdę 
coś, co ma działać tak, jak ja chcę (lub określone w specyfikacji) :-)

Taki przykład z życia wzięty: do pewnego stopnia korzystałem z Grunt-a i 
Gulp-a, ale im bardziej miałem niestandardowy build process, tym większa 
frustracja była z korzystania z Grunt-a/Gulp-a (hackowanie, brak 
pluginów, brak aktualizacji pluginów, itd. Patrz: 
http://www.ctomczyk.pl/why-i-switched-to-only-nodejs-npm-and-stopped-using-grunt/767/).

No więc napisałem cały build process korzystając nawet z tych samym npm 
pakietów i wreszcie działa tak, jak trzeba. I nie, nie spędziłem nad tym 
wiele miesięcy. Ale, to są wyjątki ;-)

>> Moim zdaniem, dzisiejsze implementacje ECMAScript są na tyle dobre, że
>> mogę spokojnie uznać, że bez wielu ekstra rozwiązań da się napisać dobrą
>> aplikację. Sam tak robię. Korpo zasady to już inna bajka. Tam w
>> większości przypadków nie mogłem zaobserwować postępu :-(
>
> Programista jQuery jest tańszy ;)

Możliwe. Nie można tego wykluczyć :-)

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

W dniu wtorek, 21 marca 2017 15:17:44 UTC+1 użytkownik Wojciech Bancer napisał:
> On 2017-03-19, zpksoft <zpksoft@op.pl> wrote:
> 
> [...]
> 
> >> To co opowiadasz to jest brak wiedzy, a nie złe programowanie.
> >> Możliwe, że z Twojej strony.
> >> 
> >> -- 
> >> Wojciech Bańcer
> >> wojciech.bancer@gmail.com
> >
> > Nie zaperzaj się. Mam konto we wspomnianym banku więc wiem co ostatnio się działo. 
> 
> Też mam. Problem z podwójnym księgowaniem kwot z kart (bo chyba o tym mówisz, taki
> był ostatnio u nich problem) nie jest problemem interfejsu użytkownika systemu 
> transakcyjnego.
> 

Nie rozdzielał bym tego.

> > Oczywiście z ciekawości zajrzałem w kod strony więc wiem co piszę.
> 
> Wytworzyłeś związek przyczynowo-skutkowy bez żadnego uzasadnienia
> i tylko na zasadzie "nie lubię jQuery" chyba.

Trochę tak.

> 
> Ja jeszcze mam konto w Raiffeisen-Polbank, mBanku, BZWBK, PKO BP, PeKaO S.A. i Aliorze.

Po co Ci tyle kont?


> Wszędzie używają min. jQuery. Zgodnie z Twoją wcześniejszą argumentacją to się zdarzyć
> nie powinno, bo to instytucje finansowe.
> 

Nie powinno. Nie zmienię zdania w tym temacie.


> > Przekornie jeszcze nawiążę do tej grupy programistów o której pisałeś. 
> > Otóż rewolucyjnych rozwiązań nie tworzą grupy. 
> 
> W dziedzinie programowania dokonujemy rozwoju ewolucyjnego, nie rewolucyjnego.
> Podobnie jak nie dokonumemy rewolucji w językach mówionych.
> 
> Rewolucji to możesz dokonywać na polu algorytmiki, a ta nie zależy od języka.
> 
> Problem w tym, że odrzucając wszystkie narzędzia wytworzone przez community
> "bo Ty wiesz lepiej i szybciej", to trochę tak jakbyś próbował na nowo 
> wymyślać koło, ignorując fakt że ktoś już wymyślił nie tylko koło, ale
> i popierdala samochodem elektrycznym.
> 
> Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak 
> Angular, czy React? Czy może uważasz że to zbędne narzędzia?
> 

Te biblioteki powstały ponieważ istnieje problem w zapanowaniu nad aplikacją bezstanową klient-serwer jaką jest aplikacja www.
Dla mnie to zbędne narzędzia bo dopracowałem się własnego, lepszego. Oczywiście to moje zdanie. Gdybym miał inne zdanie to stosował bym te (np) biblioteki.

Nawiązując do poprzedniego akapitu dot. ewolucji-rewolucji. Zobacz jak powstały te biblioteki. Nie przez ewolucję w grupach, tylko pomysły pojedynczych ludzi.


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

Paweł

W dniu wtorek, 21 marca 2017 20:27:52 UTC+1 użytkownik Roman Tyczka napisał:
> On Tue, 21 Mar 2017 15:17:42 +0100, Wojciech Bancer wrote:
> 
> >> Przekornie jeszcze nawiążę do tej grupy programistów o której pisałeś. 
> >> Otóż rewolucyjnych rozwiązań nie tworzą grupy. 
> > 
> > W dziedzinie programowania dokonujemy rozwoju ewolucyjnego, nie rewolucyjnego.
> > Podobnie jak nie dokonumemy rewolucji w językach mówionych.
> > 
> > Rewolucji to możesz dokonywać na polu algorytmiki, a ta nie zależy od języka.
> > 
> > Problem w tym, że odrzucając wszystkie narzędzia wytworzone przez community
> > "bo Ty wiesz lepiej i szybciej", to trochę tak jakbyś próbował na nowo 
> > wymyślać koło, ignorując fakt że ktoś już wymyślił nie tylko koło, ale
> > i popierdala samochodem elektrycznym.
> > 
> > Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak 
> > Angular, czy React? Czy może uważasz że to zbędne narzędzia?
> 
> Po co Ty z nim rozmawiasz? To zwykły druciarz co dzierga jakieś krzywe
> patenty w zespole jednoosobowym na zlecenie jednoosobowych firemek. Znam go
> z innej grupy, tam też mędrkował i pouczał pisząc totalne bzdury, szkoda
> czasu na dyskusje z amatorem, który nie ma bladego pojęcia o wzorcach,
> metodykach i kodowaniu ogólnie.
> 
> -- 
> pozdrawiam
> Roman Tyczka

Pijesz do mnie? Nie znając mojej pracy? 
Kiedy wspomniałeś o innej grupie przypomniała mi się dyskusja o indeksach w bazie, gdzie rzucono mi się do gardła kiedy skrytykowałem indeksy liczbowe. 
Nie chciało mi się tłumaczyć. Jeżeli ktoś w dyskusji wychodzi z założenia że są rozwiązanie jedynie słuszne..

Jeżeli masz coś do mnie to proszę merytorycznie.

Paweł

On 2017-03-22, zpksoft <zpksoft@op.pl> wrote:

[...]

>> Też mam. Problem z podwójnym księgowaniem kwot z kart (bo chyba o tym mówisz, taki
>> był ostatnio u nich problem) nie jest problemem interfejsu użytkownika systemu 
>> transakcyjnego.
> Nie rozdzielał bym tego.

Ale związku przyczynowo-skutkowego nie umiesz wskazać.

>> Ja jeszcze mam konto w Raiffeisen-Polbank, mBanku, BZWBK, PKO BP, PeKaO S.A. i Aliorze.
> Po co Ci tyle kont?

A czemu nie? Wolny kraj.

>> Wszędzie używają min. jQuery. Zgodnie z Twoją wcześniejszą argumentacją to się zdarzyć
>> nie powinno, bo to instytucje finansowe.
> Nie powinno. Nie zmienię zdania w tym temacie.

Ale masz jakieś wsparcie, czy to tylko Twoje Głębokie Przeświadczenie? :)

>> Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak 
>> Angular, czy React? Czy może uważasz że to zbędne narzędzia?
>
> Te biblioteki powstały ponieważ istnieje problem w zapanowaniu nad aplikacją bezstanową klient-serwer jaką jest aplikacja www.
> Dla mnie to zbędne narzędzia bo dopracowałem się własnego, lepszego. Oczywiście to moje zdanie. 

Aha. :D :D :D Własne i lepsze (TM).
Witamy w latach 90-tych.

> Gdybym miał inne zdanie to stosował bym te (np) biblioteki.

Po prostu i brutalnie: brak Ci umiejętności, nie znasz tych narzędzi
więc z gruntu je krytykujesz.

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

On Wed, 22 Mar 2017 07:28:01 -0700 (PDT), zpksoft wrote:

>> Po co Ty z nim rozmawiasz? To zwykły druciarz co dzierga jakieś krzywe
>> patenty w zespole jednoosobowym na zlecenie jednoosobowych firemek. Znam go
>> z innej grupy, tam też mędrkował i pouczał pisząc totalne bzdury, szkoda
>> czasu na dyskusje z amatorem, który nie ma bladego pojęcia o wzorcach,
>> metodykach i kodowaniu ogólnie.

> Pijesz do mnie? Nie znając mojej pracy? 

Czytam Twoje mierne wypociny.

> Kiedy wspomniałeś o innej grupie przypomniała mi się dyskusja o indeksach w bazie, gdzie rzucono mi się do gardła kiedy skrytykowałem indeksy liczbowe. 
> Nie chciało mi się tłumaczyć. Jeżeli ktoś w dyskusji wychodzi z założenia że są rozwiązanie jedynie słuszne..

Bredzisz i bredziłem nie w jednej tylko dyskusji.
Zasadniczo każda Twoja wypowiedź w skrócie wygląda tak:

- nie potrzebuje żadnych dokonać ludzi czy firm zewwnętrznych, każde koło
wynajdę sobie sam... a co? wolno mi!

I masz rację wolno Ci, Twoja piaskownica, baw się i lamerz do woli, tylko
nie staraj się innych przekonywać, że skoro sam nie potrafisz skorzystać z
dostępnych narzędzi i wszystko musisz tworzyć od zera to jest to lepsza i
tańsza metoda. NIE JEST.
 
> Jeżeli masz coś do mnie to proszę merytorycznie.

Wszystko co tu piszesz to bełkot amatora ubrany w stwierdzenia starego
wygi. Pieprzysz trzy po trzy na każdy temat, a już z Wordem i CMSami dałeś
popis nad popisami. Gratuluje profesjonalizmu!

-- 
pozdrawiam
Roman Tyczka

Dnia Wed, 22 Mar 2017 13:39:53 +0100, Cezary Tomczyk napisał(a):

>>> PM: Będziemy przechodzić na React teraz.
>>> Ja: A jakiego rodzaju problemy tym rozwiążecie?
>>> PM: No mamy problem z wydajnością.
>>> Ja: A w którym konkretnie miejscu?
>>> PM: No tak ogólnie.
>>> Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej
>>> architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych
>>> zależności, a może proces zarządzania zadaniami kuleje?
>>> PM: Hm, dobre pytanie. Muszę to sprawdzić.
>>
>> Urban legend, nie uwierzę w ostatnią linijkę ;)
> 
> No cóż, jak jest PM, który jest tzw. nietechniczny, to tak to wygląda ;-)

Nie wierzę, że zrobił krok wstecz od Hype Driven Developement :)

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

Dnia Wed, 22 Mar 2017 13:51:39 +0100, Cezary Tomczyk napisał(a):

> Taki przykład z życia wzięty: do pewnego stopnia korzystałem z Grunt-a i 
> Gulp-a, ale im bardziej miałem niestandardowy build process, tym większa 
> frustracja była z korzystania z Grunt-a/Gulp-a (hackowanie, brak 
> pluginów, brak aktualizacji pluginów, itd. 

A jaki miałeś problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z
uwagi na deklaratywne podejście, ale w Gulpie możesz napisać prawie
wszystko, to w końcu zwykły JS + strumienie. 

> Patrz: 
> http://www.ctomczyk.pl/why-i-switched-to-only-nodejs-npm-and-stopped-using-grunt/767/).

Aleś wykombinował, ten wynalazek w Gulpie miałby kilka linii. Choć czytałem
już o takim, co uniksowe Makefile używa w roli build procesu dla www. Niby
"co kto lubi", ale spróbuj takie rozwiązanie przejąć po kimś...

Widzę, że w komentarzach Ci napisali w sumie to samo ;)

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

W dniu środa, 22 marca 2017 22:42:12 UTC+1 użytkownik Roman Tyczka napisał:
> On Wed, 22 Mar 2017 07:28:01 -0700 (PDT), zpksoft wrote:
> 
> >> Po co Ty z nim rozmawiasz? To zwykły druciarz co dzierga jakieś krzywe
> >> patenty w zespole jednoosobowym na zlecenie jednoosobowych firemek. Znam go
> >> z innej grupy, tam też mędrkował i pouczał pisząc totalne bzdury, szkoda
> >> czasu na dyskusje z amatorem, który nie ma bladego pojęcia o wzorcach,
> >> metodykach i kodowaniu ogólnie.
> 
> > Pijesz do mnie? Nie znając mojej pracy? 
> 
> Czytam Twoje mierne wypociny.
> 
> > Kiedy wspomniałeś o innej grupie przypomniała mi się dyskusja o indeksach w bazie, gdzie rzucono mi się do gardła kiedy skrytykowałem indeksy liczbowe. 
> > Nie chciało mi się tłumaczyć. Jeżeli ktoś w dyskusji wychodzi z założenia że są rozwiązanie jedynie słuszne..
> 
> Bredzisz i bredziłem nie w jednej tylko dyskusji.
> Zasadniczo każda Twoja wypowiedź w skrócie wygląda tak:
> 
> - nie potrzebuje żadnych dokonać ludzi czy firm zewwnętrznych, każde koło
> wynajdę sobie sam... a co? wolno mi!
> 
> I masz rację wolno Ci, Twoja piaskownica, baw się i lamerz do woli, tylko
> nie staraj się innych przekonywać, że skoro sam nie potrafisz skorzystać z
> dostępnych narzędzi i wszystko musisz tworzyć od zera to jest to lepsza i
> tańsza metoda. NIE JEST.
>  
> > Jeżeli masz coś do mnie to proszę merytorycznie.
> 
> Wszystko co tu piszesz to bełkot amatora ubrany w stwierdzenia starego
> wygi. Pieprzysz trzy po trzy na każdy temat, a już z Wordem i CMSami dałeś
> popis nad popisami. Gratuluje profesjonalizmu!
> 
> -- 
> pozdrawiam
> Roman Tyczka

Aż ziejesz nienawiścią.

Daj link to jakiejkolwiek strony której jesteś autorem, chciałbym zobaczyć czy warto z tobą rozmawiać.

Czekam.

Paweł

On 23/03/2017 01:27, Borys Pogoreło wrote:
> Dnia Wed, 22 Mar 2017 13:51:39 +0100, Cezary Tomczyk napisał(a):
>
>> Taki przykład z życia wzięty: do pewnego stopnia korzystałem z Grunt-a i
>> Gulp-a, ale im bardziej miałem niestandardowy build process, tym większa
>> frustracja była z korzystania z Grunt-a/Gulp-a (hackowanie, brak
>> pluginów, brak aktualizacji pluginów, itd.
>
> A jaki miałeś problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z
> uwagi na deklaratywne podejście, ale w Gulpie możesz napisać prawie
> wszystko, to w końcu zwykły JS + strumienie.

No właśnie dlatego, że mam dostępny Promise, to Gulp nie jest mi potrzebny.

>> Patrz:
>> http://www.ctomczyk.pl/why-i-switched-to-only-nodejs-npm-and-stopped-using-grunt/767/).
>
> Aleś wykombinował, ten wynalazek w Gulpie miałby kilka linii. Choć czytałem
> już o takim, co uniksowe Makefile używa w roli build procesu dla www. Niby
> "co kto lubi", ale spróbuj takie rozwiązanie przejąć po kimś...

To żadna kombinacja. Przypatrz się temu dokładnie. Bierzesz pakiet npm i 
używasz go całkiem normalnie: wejście -> wyjście. Nie ma tam żadnej 
magii i przejęcie tego przez kogoś innego jest naprawdę proste. Ba! Już 
kilka build-ów napisałem, zostały przejęte i nie było z tym żadnego 
problemu. Co więcej, raz napisany build działa przez bardzo długi czas i 
nie trzeba do niego zaglądać co rusz ;-) No, poza aktualizacjami 
pakietów npm, jeśli ktoś chce.

A jeśli ktoś ma problem ze zrozumieniem kodu, który jest w buildzie, to 
nie wiem, co mogę o tym sądzić.

Osobiście, po jakimś czasie doszedłem do wniosku, że Grunt/Gulp za 
bardzo ograniczają mnie i w zasadzie zdefiniowanie i napisanie kroków do 
build-a jest banalnie proste:

1. Definiujesz co chcesz osiągnąć.
2. Dobierasz sobie pakiet npm.
3. Piszesz kilka linijek kodu, by przekazać parametry do pakietu npm i tyle.

Każde zadanie jest niezależne i kolejkę ustawiam sobię zwykłym Promisem. 
Rzecz jasna - są plusy i minusy. Do plusów zaliczam:

* Usuwam niepotrzebną zależność od Grunt-a/Gulp-a
* Nie muszę czekać, aż autor pakietu dla Grunt-a/Gulp-a uaktualni mi go
* Nie muszę nic hackować, bo albo korzystam z gotowych pakietów npm 
(jeśli są wystarczające), albo piszę sam.
* Do konkretnego zadania mogę wybrać jakikolwiek pakiet npm, spełniający 
moje wymagania. Mając Grunt-a/Gulp-a muszę brać pod uwagę to, że pakiet 
był specjalnie dla G/G.

Do minusów:

* Trzeba przeczytać i zrozumieć kod :D
* Więcej nie pamiętam, ale możesz dopisać kolejne punkty tutaj ;-)

> Widzę, że w komentarzach Ci napisali w sumie to samo ;)

Zdania są podzielone i to jest normalne. Nie oczekuję tego, iż G/G 
zostanie porzucony czy nagle wszyscy przestaną z tego korzystać. 
Zaprezentowałem swój punkt widzenia.

Akceptuję odmienne zdanie ;-)

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

On 23/03/2017 01:11, Borys Pogoreło wrote:
> Dnia Wed, 22 Mar 2017 13:39:53 +0100, Cezary Tomczyk napisał(a):
>
>>>> PM: Będziemy przechodzić na React teraz.
>>>> Ja: A jakiego rodzaju problemy tym rozwiążecie?
>>>> PM: No mamy problem z wydajnością.
>>>> Ja: A w którym konkretnie miejscu?
>>>> PM: No tak ogólnie.
>>>> Ja: To może nie jest problem frameworka, który macie obecnie, a bardziej
>>>> architektura, nadmierna ilość użytych narzędzi, zbyt wiele zewnętrznych
>>>> zależności, a może proces zarządzania zadaniami kuleje?
>>>> PM: Hm, dobre pytanie. Muszę to sprawdzić.
>>>
>>> Urban legend, nie uwierzę w ostatnią linijkę ;)
>>
>> No cóż, jak jest PM, który jest tzw. nietechniczny, to tak to wygląda ;-)
>
> Nie wierzę, że zrobił krok wstecz od Hype Driven Developement :)

Na szczęście już nie muszę się martwić o skutki podjętych decyzji -)

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

W dniu środa, 22 marca 2017 17:22:04 UTC+1 użytkownik Wojciech Bancer napisał:
> On 2017-03-22, zpksoft <zpksoft@op.pl> wrote:
> 
> [...]
> 
> >> Też mam. Problem z podwójnym księgowaniem kwot z kart (bo chyba o tym mówisz, taki
> >> był ostatnio u nich problem) nie jest problemem interfejsu użytkownika systemu 
> >> transakcyjnego.
> > Nie rozdzielał bym tego.
> 
> Ale związku przyczynowo-skutkowego nie umiesz wskazać.
> 

Bez przesady. Szkoda na to czasu. Niemnie fakt, masz rację.

> >> Ja jeszcze mam konto w Raiffeisen-Polbank, mBanku, BZWBK, PKO BP, PeKaO S.A. i Aliorze.
> > Po co Ci tyle kont?
> 
> A czemu nie? Wolny kraj.
> 

Tak tylko spytałem :P

> >> Wszędzie używają min. jQuery. Zgodnie z Twoją wcześniejszą argumentacją to się zdarzyć
> >> nie powinno, bo to instytucje finansowe.
> > Nie powinno. Nie zmienię zdania w tym temacie.
> 
> Ale masz jakieś wsparcie, czy to tylko Twoje Głębokie Przeświadczenie? :)

Wsparcie? Co masz konkretnie na myśli?


> 
> >> Ile wysiłku trzeba włożyć wg Ciebie żeby zbudować narzędzie takie jak 
> >> Angular, czy React? Czy może uważasz że to zbędne narzędzia?
> >
> > Te biblioteki powstały ponieważ istnieje problem w zapanowaniu nad aplikacją bezstanową klient-serwer jaką jest aplikacja www.
> > Dla mnie to zbędne narzędzia bo dopracowałem się własnego, lepszego. Oczywiście to moje zdanie. 
> 
> Aha. :D :D :D Własne i lepsze (TM).
> Witamy w latach 90-tych.
> 
> > Gdybym miał inne zdanie to stosował bym te (np) biblioteki.
> 
> Po prostu i brutalnie: brak Ci umiejętności, nie znasz tych narzędzi
> więc z gruntu je krytykujesz.

Nie krytykuję tych narzędzi. Źle to odebrałeś. 
A co do umiejętności to stwierdzę tyko tyle, że gdybym ich nie miał to właśnie wtedy sięgnął bym pewnie do wspomnianych narzędzi zamiast targnąć się na utworzenie własnego rozwiązania.

Dam tylko ogólny przykład z mojej logiki, choć już dawno jesteśmy OT w tym wątku.

Komunikacja z serwerem wygląda z poziomu aplikacji tak:

wywołuję funkcję:

fillBuf(sender, [tablica_parametrow], 'id_elementu_docelowego', function(buf){
  //czynności "pozaautomatycne"
})


Działa to mniej więcej tak:

sender- to id kontrolki generującej interakcję z serwerem (ale niekoniecznie)
[tablica_parametrow] - ogólnie to określiłem, są tu dwie tablice: tablica id elementów z których silnik (czyli moja biblioteka) wyciąga wartości parametrów, to co jest akurat charakterystyczne z danej kontrolki (text, innerHTML, checked itp)- czyli wystarczy, że podam samą listę id a dane z kontrolek zostaną wyciągnięte i przesłane na serwer; oraz tablica parametrów "z palca"

 'id_elementu_docelowego' - jeżeli zostanie podany to jego innerHTML zostanie wypełniony danym zwróconymi przez serwer.

function(buf) - funkcja startuje po otrzymaniu zwrotki z serwera w postaci stringu tu nazwanego "buf". Może to być zawartość jakiegoś diva, lub dowolne dane. Funkcji może oczywiście w tym wywołaniu fillBuf() nie być wcale. Zależy od logiki aplikacji.

Podstawowa obsługa błędów, również tych z serwera,  leży po stronie silnika.

Mam nadzieję, że napisałem czytelnie. Ten kod w połączeniu z cytowanym przezemnie wcześniej (if() elseif() ...) daje schemat aplikacji.
Prosty i naprawdę szybki do implementacji.

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

Paweł

Dnia Thu, 23 Mar 2017 10:41:11 +0100, Cezary Tomczyk napisał(a):

>> A jaki miałeś problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z
>> uwagi na deklaratywne podejście, ale w Gulpie możesz napisać prawie
>> wszystko, to w końcu zwykły JS + strumienie.
> 
> No właśnie dlatego, że mam dostępny Promise, to Gulp nie jest mi potrzebny.

A nie widzę, byś go używał. Do tego to by jeszcze bardzo zaciemniło Twoje
rozwiązanie, zwłaszcza jakbyś musiał zsynchronizować kilka promises. Nie
wspominając już o zabawie z łapaniem wyjątków, itd. Ze strumieniami jest
znacznie łatwiej, do ich scalania i synchronizowania masz gotowe narzędzia,
a ich użycie to 1-2 linijki.

> To żadna kombinacja. Przypatrz się temu dokładnie. Bierzesz pakiet npm i 
> używasz go całkiem normalnie: wejście -> wyjście. 

A po drodze odpalasz binarkę CLI eslint, musisz ją skonfigurować,
samodzielnie obsłużyć błędy i do tego zupełnie nie widać, co jest wynikiem
działania tej funkcji. Coś tam sobie leci w pętli i nie bardzo wiadomo, co
się dzieje i gdzie szukać efektów (co to jest "report" i jak go czytać? co
to jest "formatter" i czemu pojawia się dopiero na końcu, choć nazwa
wskazuje na coś potrzebnego w trakcie procesu?). A całość jest długa na dwa
ekrany. To nie jest proste rozwiązanie. Idealizujesz je, bo jesteś autorem.
Proste rozwiązanie to jest wziąć garść plików, złączyć je w jeden strumień,
wrzucić w eslint z konfiguracją i coś zrobić ze strumieniem wyjściowym. I
nie przejmować się zanadto obsługą błędów, bo robi to za nas narzędzie.

> Osobiście, po jakimś czasie doszedłem do wniosku, że Grunt/Gulp za 
> bardzo ograniczają mnie i w zasadzie zdefiniowanie i napisanie kroków do 
> build-a jest banalnie proste:

Ja mam nieodparte wrażenie, że gulpa nawet nie spróbowałeś na dobre, bo
wcześniej stworzyłeś to swoje rozwiązanie.

> 1. Definiujesz co chcesz osiągnąć.
> 2. Dobierasz sobie pakiet npm.
> 3. Piszesz kilka linijek kodu, by przekazać parametry do pakietu npm i tyle.

No popatrz, opisałeś gulpa ;)

Hint: nikt Ci nie broni używać pakietów npm w procesie gulpa. Prościej
jednak jest trzymać się konwencji.

> * Usuwam niepotrzebną zależność od Grunt-a/Gulp-a

To nie jest argument.

> * Nie muszę czekać, aż autor pakietu dla Grunt-a/Gulp-a uaktualni mi go

Pakiety npm też nie zawsze są aktualne.

> * Nie muszę nic hackować, bo albo korzystam z gotowych pakietów npm 
> (jeśli są wystarczające), albo piszę sam.

A czym jest hackowanie, jak nie tym ostatnim? ;)

Nawiasem mówiąc pakiety gulp nie są jakieś przesadnie skomplikowane. 

gulp-babel to prosty wrapper na moduł npm i wygląda tak:
https://github.com/babel/gulp-babel/blob/master/index.js

> * Do konkretnego zadania mogę wybrać jakikolwiek pakiet npm, spełniający 
> moje wymagania. Mając Grunt-a/Gulp-a muszę brać pod uwagę to, że pakiet 
> był specjalnie dla G/G.

Nie musisz, ale tak jest wygodniej.

> Do minusów:
> * Trzeba przeczytać i zrozumieć kod :D
> * Więcej nie pamiętam, ale możesz dopisać kolejne punkty tutaj ;-)

* Tworzysz rozwiązanie in-house, z którym musisz sobie radzić sam
* Musisz w wielu miejscach wynajdować koło na nowo
* Uzyskujesz strasznie rozwlekły kod, bo patrz wyżej

>> Widzę, że w komentarzach Ci napisali w sumie to samo ;)
> 
> Zdania są podzielone i to jest normalne. Nie oczekuję tego, iż G/G 
> zostanie porzucony czy nagle wszyscy przestaną z tego korzystać. 
> Zaprezentowałem swój punkt widzenia.

Na blogaskach generalnie wypada chwalić w komentarzach, nawet takie
wynaturzenia jak JSS ;)

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

On 23/03/2017 21:46, Borys Pogoreło wrote:
> Dnia Thu, 23 Mar 2017 10:41:11 +0100, Cezary Tomczyk napisał(a):
>
>>> A jaki miałeś problem z Gulpem? Grunt faktycznie nie jest zbyt elastyczny z
>>> uwagi na deklaratywne podejście, ale w Gulpie możesz napisać prawie
>>> wszystko, to w końcu zwykły JS + strumienie.
>>
>> No właśnie dlatego, że mam dostępny Promise, to Gulp nie jest mi potrzebny.
>
> A nie widzę, byś go używał.

Nie. Aktualnie nie używam. A nawet przyznam się, że używałem Gulpa 
bardzo króciótko i przy jednym projekcie. Grunt-a używałem przez kilka lat.

> Do tego to by jeszcze bardzo zaciemniło Twoje
> rozwiązanie, zwłaszcza jakbyś musiał zsynchronizować kilka promises.

Promise.all - to wszystko, co jest potrzebne i jest dostępne. Chyba, że 
myślisz o czymś innym.

> Nie wspominając już o zabawie z łapaniem wyjątków, itd. Ze strumieniami jest
> znacznie łatwiej, do ich scalania i synchronizowania masz gotowe narzędzia,
> a ich użycie to 1-2 linijki.

"catch" z Promise-a powinien pomóc. Niektóre npm moduły zwracają Error 
object.

>> To żadna kombinacja. Przypatrz się temu dokładnie. Bierzesz pakiet npm i
>> używasz go całkiem normalnie: wejście -> wyjście.
>
> A po drodze odpalasz binarkę CLI eslint, musisz ją skonfigurować,
> samodzielnie obsłużyć błędy i do tego zupełnie nie widać, co jest wynikiem
> działania tej funkcji. Coś tam sobie leci w pętli i nie bardzo wiadomo, co

A wrapper do G/G to jak działa?

> się dzieje i gdzie szukać efektów (co to jest "report" i jak go czytać? co
> to jest "formatter" i czemu pojawia się dopiero na końcu, choć nazwa
> wskazuje na coś potrzebnego w trakcie procesu?). A całość jest długa na dwa

Wszystko jest opisane w dokumentacji: 
http://eslint.org/docs/user-guide/command-line-interface

> ekrany. To nie jest proste rozwiązanie. Idealizujesz je, bo jesteś autorem.

Absolutnie nie idealizuję. Z resztą, nie wymyśliłem niczego nowego. 
Przykładowo eslint 
https://github.com/eslint/eslint/blob/master/Makefile.js korzysta z tego 
samego podejścia do build-a.

Ba! Nawet z samego NPM-a możesz korzystać:

https://medium.com/@dabit3/introduction-to-using-npm-as-a-build-tool-b41076f488b0

> Proste rozwiązanie to jest wziąć garść plików, złączyć je w jeden strumień,
> wrzucić w eslint z konfiguracją i coś zrobić ze strumieniem wyjściowym. I
> nie przejmować się zanadto obsługą błędów, bo robi to za nas narzędzie.

Jak masz proste kroki w buildzie, to wszystko się zgadza. Jeszcze raz 
podkreślę - każdy używa to, co jest dla niego najlepsze albo musi, bo 
jest już to w projekcie od jakiegoś czasu. Jeżeli ląduję w projekcie z 
G/G, to nie marudzę tylko tego używam ;-)

A poza tym, zapominasz o innych argumentach. Przykład:

https://gist.github.com/elijahmanor/179e47828bf760c218bb3820d929836d

>> Osobiście, po jakimś czasie doszedłem do wniosku, że Grunt/Gulp za
>> bardzo ograniczają mnie i w zasadzie zdefiniowanie i napisanie kroków do
>> build-a jest banalnie proste:
>
> Ja mam nieodparte wrażenie, że gulpa nawet nie spróbowałeś na dobre, bo
> wcześniej stworzyłeś to swoje rozwiązanie.

Próbowałem, ale bardzo krótko i przy jednym projekcie. Z resztą, 
przeszedłem na inne podejście, które według mnie, jest bardziej 
elastyczne. Może odrobinę więcej czasu zajmuje napisane zadania, ale nie 
jest to też aż tak skomplikowane. Sądzę, że trochę przesadzasz w drugą 
stronę ;-)

>> 1. Definiujesz co chcesz osiągnąć.
>> 2. Dobierasz sobie pakiet npm.
>> 3. Piszesz kilka linijek kodu, by przekazać parametry do pakietu npm i tyle.
>
> No popatrz, opisałeś gulpa ;)

:D

> Hint: nikt Ci nie broni używać pakietów npm w procesie gulpa. Prościej
> jednak jest trzymać się konwencji.

Trzymanie się konwencji jest pewnym ułatwieniem w organizacji pracy, ale 
jednocześnie, osobiście, nie wykluczam indywidualnego podejścia. 
Wszystko zależy od sytuacji i potrzeb.

>> * Usuwam niepotrzebną zależność od Grunt-a/Gulp-a
>
> To nie jest argument.

W w/w linku są podane argumenty, a ja także podałem je w swoim artykule.

>> * Nie muszę czekać, aż autor pakietu dla Grunt-a/Gulp-a uaktualni mi go
>
> Pakiety npm też nie zawsze są aktualne.

Pewnie, ale pakiety dla G/G jeszcze bardziej ;-)

>> * Nie muszę nic hackować, bo albo korzystam z gotowych pakietów npm
>> (jeśli są wystarczające), albo piszę sam.
>
> A czym jest hackowanie, jak nie tym ostatnim? ;)

Hack to obejście. Ja niczego nie obchodzę :-) Ot, korzystam z pakietów 
npm i tyle.

> Nawiasem mówiąc pakiety gulp nie są jakieś przesadnie skomplikowane.
>
> gulp-babel to prosty wrapper na moduł npm i wygląda tak:
> https://github.com/babel/gulp-babel/blob/master/index.js

No i teraz pytanie po co mi wrapper skoro mogę skorzystać bezpośrednio z 
pakietu npm ;-)

>> * Do konkretnego zadania mogę wybrać jakikolwiek pakiet npm, spełniający
>> moje wymagania. Mając Grunt-a/Gulp-a muszę brać pod uwagę to, że pakiet
>> był specjalnie dla G/G.
>
> Nie musisz, ale tak jest wygodniej.

No więc najpierw muszę znaleźć coś, co zadziała z G/G, a jeśli nie ma, 
to pozostaje mi własne rozwiązanie, które potem muszę podpiąć pod G/G.

>> Do minusów:
>> * Trzeba przeczytać i zrozumieć kod :D
>> * Więcej nie pamiętam, ale możesz dopisać kolejne punkty tutaj ;-)
>
> * Tworzysz rozwiązanie in-house, z którym musisz sobie radzić sam

I tak, i nie. Po mojej "in-house" stronie jest tylko to, co ja 
napisałem. Reszta to pakiety npm. Tak, czy inaczej, wsparcie community jest.

> * Musisz w wielu miejscach wynajdować koło na nowo

Nie bardzo wiem, co takiego muszę wynajdować na nowo.

> * Uzyskujesz strasznie rozwlekły kod, bo patrz wyżej

Nie powiedziałbym, że rozwklekły, ale ok. Za to mam pełną kontrolę i 
swobodę nad tym, co określone zadanie ma robić. Poza tym, build piszesz 
raz i działa latami. Nie trzeba do tego codziennie zaglądać, jak do 
źródeł aplikacji ;-)

>>> Widzę, że w komentarzach Ci napisali w sumie to samo ;)
>>
>> Zdania są podzielone i to jest normalne. Nie oczekuję tego, iż G/G
>> zostanie porzucony czy nagle wszyscy przestaną z tego korzystać.
>> Zaprezentowałem swój punkt widzenia.
>
> Na blogaskach generalnie wypada chwalić w komentarzach, nawet takie
> wynaturzenia jak JSS ;)

:-)

Jednym z plusów takiego rozwiązania, o którym napisałem, jest brak 
zależności od konkretnego rozwiązania do builda.

Przy okazji, przypomina mi się sytuacja historycznie:

* Grunt - tego teraz używamy.
* Gulp - Grunt już je be, teraz Gulp jest super.
* Browserify - nie znasz? Teraz to jest na topie :-)
* Webpack - nie, już Browserify nie jest dobre.
* Rollup (http://rollupjs.org/) - teraz Rollup musi być najlepszy.

Ja wiem, że są rożnice w tym, co one potrafią, ale to już inna bajka.

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

Jivanmukta wrote:
> Problem zamknięty. Dzięki za pomoc.

Jeszcze coś mi nie działa. Nie rozumiem dlaczego kod:

<input type="text" name="client_mobile1" value=""  id="client_mobile1" 
maxlength="16" size="16" style="width: 16ex" class="mobile" >

p = document.getElementById("client_mobile1");
if (!p.hasOwnProperty("className")) alert(p.tagName + "#" + p.id + " has no 
className");

wyświetla mi alerta: INPUT#client_mobile1 has no className. Używam FireFoxa, 
ale chciałbym żeby mi działało pod wszystkimi popularnymi przeglądarkami.