znaczacy > comp.lang.* > comp.lang.javascript

Cezary Tomczyk (19.03.2017, 22:37)
On 19/03/2017 20:56, Wojciech Bancer wrote:
> On 2017-03-19, zpksoft <zpksoft> wrote:
> [...]
> Nie. Do tego są właśnie frameworki.
> W Javie masz Spring. W PHP masz Symfony/Zend/Laravel. Ruby + Rails itp. .NET Framework (C#)
> itd. itp. W javascripcie masz tego już naprawdę na tony (Express.JS, jQuery, Angular,
> React, Vue itp. itd.).


jQuery to nie framework, a zwykły tool :-)
zpksoft (19.03.2017, 22:53)
W dniu niedziela, 19 marca 2017 20:58:45 UTC+1 uzytkownik Wojciech Bancer napisal:
> On 2017-03-19, zpksoft <zpksoft> wrote:
> Poprosze jeszcze raz. Znajdz bank który nie korzysta.
> Nie sadze by ktokolwiek sie tam meczyl.
> [...]
> To co opowiadasz to jest brak wiedzy, a nie zle programowanie.
> Mozliwe, ze z Twojej strony.
> --
> Wojciech Bancer
> wojciech.bancer


Nie zaperzaj sie. Mam konto we wspomnianym banku wiec wiem co ostatnio sie dzialo. Oczywiscie z ciekawosci zajrzalem w kod strony wiec wiem co pisze.

Przekornie jeszcze nawiaze do tej grupy programistów o której pisales. Otóz rewolucyjnych rozwiazan nie tworza grupy.

Grupy tworza takie np. Windows 10.

Pawel
zpksoft (19.03.2017, 23:04)
W dniu niedziela, 19 marca 2017 21:00:53 UTC+1 uzytkownik Wojciech Bancer napisal:
> On 2017-03-19, zpksoft wrote:
> [...]
> > Nie przespalem :) Tylko ewoluuje a nie dryfuje. To jest zasadnicza róznica.
> > Upierasz sie przy pogladzie ze stosowanie frameworków to koniecznosc i nowoczesnosc.

> Bo jest. Tak jak kiedys nowoczesnym bylo programowanie w C, a nie na kartach perforowanych.


A na kartach perforowanych to nie programowalo sie w C?

> > Ja uwazam natomiast, ze wiekszosc tego co oprogramowujemy to proscizna.
> > Podstawowy JS daje wszystko co potrzeba.

> Zalezy od skali projektu.


Zdecydowana wiekszosc "projektów" to proste stronki gdzie oczywiscie w naglówku musi byc zmieniajacy sie baner a w srodku jquery :)
No i oczywiscie wszystko pisane w joomli czy innym cms-ie.

Pawel
Borys Pogorelo (20.03.2017, 19:12)
Dnia Sat, 18 Mar 2017 07:37:33 -0700 (PDT), zpksoft napisal(a):

> Pokretne rozumowanie. Ale ok, Twoim zdaniem "zespól ludzi" + Ty zrobi
> mniej bledów niz ja?


Tak, bo poswiecili czas na rozpracowanie wszystkich trudnych przypadków, w
tym przypadków brzegowych i niezgodnosci przegladarek. Masz na to czas? W
tym co nam wkleiles bylo juz jedno obejscie dla starszego IE, a to zaledwie
kilka liniijek.
Borys Pogorelo (20.03.2017, 19:16)
Dnia Sat, 18 Mar 2017 15:52:32 +0100, Wojciech Bancer napisal(a):

> Jeszcze pamietam czasy kiedy kazda agencja interaktywna, kazdy podmiot
> na polskim rynku musial miec wlasne rozwiazanie, wlasny framework
> i wlasne rozwiazania. :) I to nie byly dobre czasy :)


Teraz za to spolecznosc troche przegina, az sie z nich zartuje.

Borys Pogorelo (20.03.2017, 19:24)
Dnia Sat, 18 Mar 2017 07:34:00 -0700 (PDT), zpksoft napisal(a):

> Moze sie tez okazac ze stosujac jakies tam frameworki zrobisz zadanie
> znacznie wolniej niz ja bo bedziesz musial sie najpierw tego nauczyc.


Tak, na pewno zajmie to dluzej, niz przekopywanie sie przez specyfikacje JS
i historie wszelkich niekompatybilnosci, a pózniej próba zapamietania tego.

> Kolejna sprawa to aplikacje o wysokim stopniu bezpieczenstwa. Oprzesz je
> na freewarowym frameworku? Np. aplikacje dla banku?


Straszni amatorzy musza pracowac w tych bankach, bo w systemie
transakcyjnym mBanku widze jQuery, jQuery UI i tone wtyczek.

Cezary Tomczyk (21.03.2017, 09:38)
On 20/03/2017 18:24, Borys Pogorelo wrote:
> Dnia Sat, 18 Mar 2017 07:34:00 -0700 (PDT), zpksoft napisal(a):
>> Moze sie tez okazac ze stosujac jakies tam frameworki zrobisz zadanie
>> znacznie wolniej niz ja bo bedziesz musial sie najpierw tego nauczyc.

> Tak, na pewno zajmie to dluzej, niz przekopywanie sie przez specyfikacje JS
> i historie wszelkich niekompatybilnosci, a pózniej próba zapamietania tego.


Oj, nie przesadzajmy z ta ogromna niekompatybilnoscia. Na dzien
dzisiejszy osoboscie rzadko mi sie zdarza, ze musze spedzic wiecej czasu
na rozwiazaniu problemu z kompatybilnoscia. W 99% wszystko dziala niezle.

Oczywiscie, problem pojawia sie na pewno, kiedy chce sie zastosowac cos
jak CSS grid. ;-)

>> Kolejna sprawa to aplikacje o wysokim stopniu bezpieczenstwa. Oprzesz je
>> na freewarowym frameworku? Np. aplikacje dla banku?

> Straszni amatorzy musza pracowac w tych bankach, bo w systemie
> transakcyjnym mBanku widze jQuery, jQuery UI i tone wtyczek.
>


No ale ilosc uzytych narzedzi/libów/itp. nie jest wprost proporcjonalna
do jakosci. Ilekroc pytam programistów o to, dlaczego korzystaja z
jQuery czy innego narzedzia, to odpowiedz jest jedna - z
przyzwyczajenia. No a potem takie aplikacje puchna bez limitu.

Moim zdaniem, dzisiejsze implementacje ECMAScript sa na tyle dobre, ze
moge spokojnie uznac, ze bez wielu ekstra rozwiazan da sie napisac dobra
aplikacje. Sam tak robie. Korpo zasady to juz inna bajka. Tam w
wiekszosci przypadków nie moglem zaobserwowac postepu :-(
zpksoft (21.03.2017, 12:52)
W dniu poniedzialek, 20 marca 2017 18:12:24 UTC+1 uzytkownik Borys Pogorelo napisal:
> Dnia Sat, 18 Mar 2017 07:37:33 -0700 (PDT), zpksoft napisal(a):
> Tak, bo poswiecili czas na rozpracowanie wszystkich trudnych przypadków, w
> tym przypadków brzegowych i niezgodnosci przegladarek. Masz na to czas? W
> tym co nam wkleiles bylo juz jedno obejscie dla starszego IE, a to zaledwie
> kilka liniijek.
> --
> Borys Pogorelo
> borys(#)leszno,edu,pl


Sa dwie drogi:

- starac sie zaspokoic wszystkich, lub
- olac niespelniajacych standardy

Ja preferuje to drugie. Jak zauwazyles w moim kodzie- nie do konca jest to prawda. Ale z reguly trzymam sie tego.
Niedawno czytalem jakis kod w necie z kilkoma "obejsciami". Usunalem je i co sie okazalo? Na wszystkich przegladarkach (mówie oczywiscie o najnowszych wersjach)zagralo.

Pawel
zpksoft (21.03.2017, 12:56)
W dniu wtorek, 21 marca 2017 08:38:16 UTC+1 uzytkownik Cezary Tomczyk napisal:
[..]
> Moim zdaniem, dzisiejsze implementacje ECMAScript sa na tyle dobre, ze
> moge spokojnie uznac, ze bez wielu ekstra rozwiazan da sie napisac dobra
> aplikacje. Sam tak robie.


Wlasnie. Tez to zauwazylem. I jest to budujace.

> Korpo zasady to juz inna bajka. Tam w
> wiekszosci przypadków nie moglem zaobserwowac postepu :-(
> --
> Cezary Tomczyk
>


Pawel
Wojciech Bancer (21.03.2017, 16:02)
On 2017-03-21, Cezary Tomczyk <cezary.tomczyk> 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:

A z nowych rzeczy, to już w ogóle nie ma.

> 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 Bancer (21.03.2017, 16:08)
On 2017-03-19, zpksoft <zpksoft> wrote:

[...]

>> Bo jest. Tak jak kiedyś nowoczesnym było programowanie w C, a nie na kartach perforowanych.

> A na kartach perforowanych to nie programowało się w C?


W języku maszynowym.

>> Zależy od skali projektu.

> Zdecydowana większość "projektów" to proste stronki gdzie oczywiście w nagłówku musi być zmieniający się baner a w środku jquery :)
> No i oczywiście wszystko pisane w joomli czy innym cms-ie.


No jeśli takie masz, to ok. Ja w zdecydowanej większości mam projekty dużo większe,
gdzie posłużenie się czystym javascriptem to jak pisanie gry w asemblerze.
I będą problemy z zarządzaniem projektem, ludźmi i przede wszystkim wydajnością
tych ludzi.
Wojciech Bancer (21.03.2017, 16:17)
On 2017-03-19, zpksoft <zpksoft> wrote:

[...]

>> To co opowiadasz to jest brak wiedzy, a nie złe programowanie.
>> Możliwe, że z Twojej strony.
>> --
>> Wojciech Bańcer
>> wojciech.bancer

> 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?
Cezary Tomczyk (21.03.2017, 18:35)
On 21/03/2017 15:08, Wojciech Bancer wrote:
> On 2017-03-19, zpksoft <zpksoft> wrote:
> [...]
> W języku maszynowym.
> No jeśli takie masz, to ok. Ja w zdecydowanej większości mam projekty
> dużo większe, gdzie posłużenie się czystym javascriptem to jak
> pisanie gry w asemblerze.


Ekhm, że jak? "[...] posłużenie się czystym javascriptem to jak pisanie
gry w asemblerze [...]". - to w czym pisane są projekty, w których
bieżesz udział?

> I będą problemy z zarządzaniem projektem,
> ludźmi i przede wszystkim wydajnością tych ludzi.


Najwyraźniej zrekrutowani zostali juniorzy. Jak ktoś wie, jak
programować w JavaScript, to nie ma problemu z wydajnością w ogóle. Od
tego są liderzy zespołów, by tą wydajność podnieść. Różnymi sposobami.

Tzw. niechęć do korzystania z dostępnych funkcjonalności JavaScript
wynika albo z niewiedzy, albo z lenistwa.
Cezary Tomczyk (21.03.2017, 18:43)
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 (21.03.2017, 18:52)
On 21/03/2017 15:02, Wojciech Bancer wrote:
> On 2017-03-21, Cezary Tomczyk <cezary.tomczyk> wrote:
> [...]
> 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:
>
> 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 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? :-)).

Podobne wątki