Widzę leci tu dużo hejtu na obecny stan frontendu.
Dla mnie to co się dzieje fakt faktem bywa czasem trochę męczące, ale moim zdaniem jest całkiem naturalne...
Środowisko dotyczy już nie tylko aplikacji webowych ale i mobilnych (cordova/nativescript/react native) i backendu (Node). Aby appki były szybsze i lepsze dla userów spora część logiki jest ogarniana właśnie na froncie, a backend coraz częściej sprowadza się do serwowania API.
Jak już będę za stary żeby szybko uczyć się nowych technologii to pójdę do banku, mrugnę znacząco do szefa it i poproszę o wrzucenie do piwnicy z dinozaurami od cobola.
A ja machnąłem ręką na JS w czasach kiedy trzeba było pisać odrębne wersje skryptu (no dobra... całęj strony) na IE i resztę. Teraz jak przeczytałem ten artykuł to odnoszę wrażenie że lepiej już cały frontend zrealizować za pomocą WebGL'a który będzie się komunikował z serwerem wydłubanym własnoręcznie w asemblerze na jakimś egzotycznym procesorze...
Najbardziej posraną rzecz w JS to dziedziczenie, coś mnie normalnie strzela jak muszę użyć zewnętrznej biblioteki (np. util.inherits) do rozszerzania klasy inna klasą bez robienia burdelu w deklaracji klasy nadrzędnej (w jej prototype).
Z drugiej strony dzięki asynchroniczności i Promise to w node.js czuję się jak ryba w wodzie, jak wracam do PHP to czuję się jakbym, pływał w smole.
@sciana: ale po kiego grzyba Ci to w php który kończy wywołanie z końcem skryptu a do ciągłego działania nie jest przystosowane bo 99.9% libów pho ma takie memory leaki że świat nie widział. Php nigdy nie będzie sie wykonywał tak długo żeby async miał znaczenie.
@znudzony_programista: ale async moze miec wielkie znaczenie przy pojedynczym requescie. Jak masz np kilka zrodel danych to mozesz je odpyrac jednoczesnie.
Odnoszę dziwne wrażenie, że kolejne pokolenie programistów wchodzi na stare tory, z których zeszło już "pokolenie" poprzedników. Ten sam problem niesamowitej komplikacji rzeczy prostych przechodziła dobre 10 lat temu java. Tony XMLi, autogenerowanych stubów, wynalazki z ery przed-adnotacyjnej (ktoś pamięta xdoclety?), potem zachłyśnięcie adnotacjami i pakowanie ich w każde możliwe miejsce tylko po to żeby wygenerować "hello world". Nie wspominając o systemach budowania (ant anyone?). Java potrzebowała kupę czasu (i kilku dodatkowych
@umrzyk: "Nauczyć się javascriptu a nie frameworków. " no tak, ale poczytaj wymagania w ofertach pracy, jakiś react / ember trzeba znać. Faktem jest, że hr-rzy wpisują co się da i później są kwiatki: wymagana doskonała znajomość języka angielskiego...firma oferuje bezpłatne lekcje języka angielskiego :D ... darmową kawę (napraaaaawdeeeę)" Do tego jak rozumieć "doskonała znajomość underscore, jquery" - przecież to trudne do oceny, underscore to pare funkcji na krzyż, jquery tez
JS to jest dobre środowisko dla pasjonatów, którzy lubią codziennie dowiadywać się, że ktoś wymyślił w dziedzinie coś nowego. Zdecydowanie brakuje stabilności znanej z innych języków. Generalnie panuje taka anarchia, że każdy może sobie wymyślić jak coś zrobić na swój własny sposób. Według mnie wynika to z nieudolności w implementowaniu elementów kolejnych wersji przez przeglądarki. W jednej robią to szybciej, w innych później. Brakuje ujednoliconego interpretera - środowiska, które byłoby jednolite w
Wiadomo, że tekst jest prześmiewczy, ale problem można rozwiązać już na samym początku - dobierając narzędzia pod potrzeby. Do malutkiego skryptu nie jest potrzebny framework do dynamicznego renderowania widoków, system do zarządzania modułami i transpiler do ES6. Ale oczywiście niektórzy o tym zapominają i dlatego mamy 1000 frameworków, a wystarczyłoby po prostu trochę zdrowego rozsądku.
A co do wspomnianego w tekście bowera i npm, to nie jest tak że bowera nikt nie
@Marmite: faktycznie npm dziala, ale troche mozna wtopic: npm i jquery-validation i obok dogra jquery 2.2.4 (zaleznosc) robisz odniesienie do tego jquery pozniej cos odbija i robisz npm i jquery@3 jquery 2.2.4 przenosi (lub "przenosi") do katalogu z jquery-validation a jquery@3 daje do katalogu z jquery. No i moze sie sypnac.
Pół roku temu przesiadłem się z node na Go. Od tamtej pory mam orgazm - nigdy więcej JSa na backendzie. Szkoda tylko, że w rozwiązaniach frontowych nie ma alternatywy.
@JestemD: kiedyś za free było openshift.com ale ostatnio coś zmieniają i juz raczej nie będzie. Także mam doświadczenie z vps z ovh też całkiem spoko. Bodajże linuxcom.pl też nie robią problemu.
@szeptweb: mam w ovh jeszcze kilka dedyków, ale jedynie do konwersji wideo. Podchodziłem do ich vpsów - ale używają openstacka a on nie wyrabiał przy mojej ilości połączeń (mam apkę rozłożoną jako mikrousługi). W Amazonie nie mam takich problemów, do tego korzystam z ich api gateway i load balancera, który działa na poziomie softowym (mogę pod urle podpinać endpointy).
To co się dzieje w środowisku JS, to jest jakiś dramat. Rozumiem dopracowywanie istniejących rozwiązań, czy wypuszczenie czegoś nowego lub rewolucyjnego raz na jakiś czas, ale te wszystkie frameworki wynajdują po kilka razy koło na nowo i dodają nową poetykę, to stworzenia tego samego, co wcześniej już było. Jeszcze rozumiem tworzenie nowych bibliotek, ale robienie hajpu na nowy framework JS co pół roku zakrawa na żart.
@pawciow88: Chyba mnie nie zrozumiałeś ( ͡°͜ʖ͡°). Oracle sobie kupił Suna i prawa do Javy, ale nie kupił licencji na wszystkich programistów, Androida, wszystkie biblioteki, Maven Central Repository, build systemy (Ant, Maven, Gradle), IDE (np. IntelliJ), wszystkie języki JVM-owe, wszystkie narzędzia, itd. Oracle nie ma nad tymi większością tych spraw prawie żadnej kontroli.
@tomaszk-poz: Jest, ale Oracle jest właścicielem licencji na API. Tzn. Jeśli chciałbyś napisać własną implementację JDK (jest ich wiele) i wykorzystywać ją do celów komercyjnych, to w przypadku osiągnięcia sukcesu, musiałbyś mieć dobrych prawników. M.in. z tego powodu Oracle sądziło się niedawno z Google w sprawie Androida, który wykorzystuje swoją własną implementację Javy.
Komentarze (201)
najlepsze
Dla mnie to co się dzieje fakt faktem bywa czasem trochę męczące, ale moim zdaniem jest całkiem naturalne...
Środowisko dotyczy już nie tylko aplikacji webowych ale i mobilnych (cordova/nativescript/react native) i backendu (Node). Aby appki były szybsze i lepsze dla userów spora część logiki jest ogarniana właśnie na froncie, a backend coraz częściej sprowadza się do serwowania API.
Rozwija się sam też język
Z drugiej strony dzięki asynchroniczności i Promise to w node.js czuję się jak ryba w wodzie, jak wracam do PHP to czuję się jakbym, pływał w smole.
Php nigdy nie będzie sie wykonywał tak długo żeby async miał znaczenie.
Do tego jak rozumieć "doskonała znajomość underscore, jquery" - przecież to trudne do oceny, underscore to pare funkcji na krzyż, jquery tez
A co do wspomnianego w tekście bowera i npm, to nie jest tak że bowera nikt nie
npm i jquery-validation i obok dogra jquery 2.2.4 (zaleznosc)
robisz odniesienie do tego jquery
pozniej cos odbija i robisz npm i jquery@3
jquery 2.2.4 przenosi (lub "przenosi") do katalogu z jquery-validation a jquery@3 daje do katalogu z jquery.
No i moze sie sypnac.
@Marmite: Chodziło mi oczywiście o "to jest wina autorów danej paczki [na npm/bower] a nie samego npm/bower"