Skad hejt na JavaScript

Witam, jakieś 2 miesiące uczyłem się Javy, niekoniecznie po to aby pracować z tym językiem ale aby zrozumieć obiektowość. Tak teraz pomyślałem co naprawde chciałbym robić i co mi się podoba i.... no właśnie... Podoba mi się możliwość zrobienia aplikacji webowej i jednocześnie na przykładowo androida. Poczytałem trochę poczytałem i stwierdziłem, że będzie dla mnie idealne nauczyć się JS > Angular + NativeScript lub JS>React>ReactNative ... bo w końcu gier na androida/ios i tak nie chcę robić a czytałem że w JS powstają frameworki na desktop również takie jak Electron w którym napisany jest Discord.

No więc skąd ten cały hejt na javascript? Jest to spowodowane tym, że kiedyś frontend to był głównie html + css + ociupinka kodu JS? Zauważyłem, że bloggerzypodzieleni są na trzy części: na tych kórzy uważają że JavaScript to nie jest programowanie nawet w dzisiejszych czasach oraz na tych, którzy mówią, że JavaScript ma przed sobą świetlaną przyszłość (frameworki).

Po ofertach pracy, widzę też że programiści np Reacta nie zarabiają wcale mniej niż inni w Php, czy C# lub Javie.

Podstawowym problemem JavaScriptu z perspektywy programisty Javy/ C#/ C++/ itd jest jego pokręcona semantyka. Obiektówka w JSie działa zupełnie inaczej niż w każdym innym języku i to jest powód do frustracji - co z tego, że składni można się szybko nauczyć skoro wiedza nabyta podczas programowania w Javie/ C#/ C++/ itd przeszkadza zamiast pomagać? Ja w JSie grzebię okazjonalnie, pierwszy raz miałem okazję w nim grzebać kilkanaście lat temu, ale w zasadzie za każdym razem czuję się jakbym grzebał w g****e. Poradnik https://github.com/getify/You-Dont-Know-JS pomógł mi nieco rozjaśnić JSową niefrasobliwość, ale przez to, że JSa rzadko tykam to i tak zapomniałem co i jak się dzieje (w sensie głównie np do czego odnosi się słówko kluczowe this w rozmaitych przypadkach).

Do tego dochodzi rozwój różnej maści frameworków i narzędzi do JS. Nowe powstają raz na miesiąc i coś co używałeś rok temu, dzisiaj już jest przestarzałe. To też troszkę demotywuje.

czy js stanie sie mlotkiem do wszystkiego?

http://bonsaiden.github.io/JavaScript-Garden/pl/

https://www.destroyallsoftware.com/talks/wat

Są pewne limity złego zaprojektowania języka programowania. Akurat js ma dosyć dużo złych cech, by móc spokojnie na niego narzekać. Natomiast należy zwrócić uwagę na pewne bardzo pozytywne cechy jak np. Dziedziczenie prototypowe czy świetny engine v8.

A ja zamówiłam książkę z heliona pt. "Mistrzowski JavaScript. Programowanie zorientowane obiektowo". Zamierzam sie rozwijać w kierunku JS i JS-owych FW.

Nie lubię JS, ponieważ programiści tego języka nie traktują go jako obiektowy. Większość kodu pisanego w tym języku używa klas, bo framework to wymusza i trzeba rozszerzyć jakąś klasę. Przypomina to trochę programowanie w Delphi albo C++ Builder na końcu lat 90 i początku lat 00, gdzie aplikacja składała się z jednej, ew, kilku klas TForm1, TForm2 itd. a resztę leciało się proceduralnie.

Głównym problemem JSa jest absolutny brak biblioteki standardowej. Tylko absolutne minimum helperów jest zawarte w specyfikacji, co powoduje, że drzewo zależności zawiera czasem absurdalne elementy (left-pad czy const-pi).

Ogólnie JS ma wiele wad, gdzie główną wadą są programiści, którzy "odkrywają" nagle wiele rzeczy, które cała reszta zna od dawien dawna, i nazywają to "rewolucją". Olbrzymia ilość osób o bardzo niskich kompetencjach ląduje na różnego rodzaju kursach i potem stara się "zabłysnąć" co powoduje u reszty epickiego facepalma.

Mnie najbardziej boli brak dobrych narzędzi do statycznej analizy i IDE. Dla przykładu WebStorm ma problem z:

• Podpowiedzi "po kropce", extendowanie czegokolwiek jest równoznaczne pozbawieniem się sensownych podpowiedzi.
• Kolorowanie składni jest dosyć losowe np. czasem obj.start (gdzie start to pole obiektu obj) zostaje pokolorowany jak metoda, bo gdzieś w zaimportowanym module jest klasa, która ma taką metodę, albo w ogóle nie może znaleźć takiego pola, działa to też w drugą stronę, to że IDE nie zgłasza błędu w obj.start nie oznacza, że obj faktycznie zawiera cokolwiek nazwanego start.

Przez co refaktorowanie przypomina bardziej znajdź i zastąp w notatniku niż operacje na kodzie. Pisanie JSDoc do każdej funkcji i każdego obiektu rozwiązuje większość z ww. problemów, ale stanowi problem sam w sobie, bo jest relatywnie wolniejsze niż zdefiniowanie klasy w języku silnie typowanym dodatkowo przy zmianie w kodzie trzeba pamiętać o zaktualizowaniu JSDoca.

Nie do końca przemawia do mnie idea zbudowania języka bazując na pojedynczym event loopie z magią libuv. Bardziej uniwersalne są rozwiązania przyjęte w Go czy Elixirze.

Niesamowicie frustrujące jest też to, że nawet syntax errory są zgłaszane dopiero w runtime. Szczególnie, że można poprosić V8/node.js o wyplucie bytecodu/assemblera.

A moim osobistymi faworytami są:

• parseFloat(x).toFixed(n) zwracający stringa... Bo przecież właśnie po to sparsowałem stringa do floata, żeby dostać znowu stringa.
• zastąpienie overloadowania funkcji drabinką ifów z przypisywaniem wartości do argumentów funkcji. Z czego powstaje takie uj wie co https://github.com/DoctorMcKay/node-steamstore/blob/master/components/account.js#L233

Tak właściwie nie lubię języków Interpretowanych, ale np. Python ma wystarczająco dużo zalet, żeby warto było przeboleć jego wady. JavaScript nie oferuje na dobrą sprawę nic.

Podsumowując, pisząc JSa czuję się bardziej jakbym pisał esej po węgiersku niż programował. Także jeśli JS to raczej TypeScript, który zresztą ma swoje ułomności.

Ja tam JS lubię, ale tylko dlatego, że jeśli w nim programuje to tylko własne projekty. Firmowy kod w JS to g*wno, które mnoży się w nieskończoność.

Podstawowa rzecz jaka sprawia, że ten język nie nadaje się do pracy zespołowej to jego giętkość (podobnie mam z lispami), dlatego żeby tutaj coś z tego wyszło to konieczne jest wyjście od pragmatycznych decyzji (lista poniżej) oraz konsekwentnego przestrzegania.

[0] Najważniejsze to poznać ograniczenia i używać możliwie proste narzędzia. Często zwykłe jQuery styknie.
[1] Stosować testy jednostkowe jeśli projekt ma pożyć dłużej niż 1 miesiąc.
[2] Najtrudniejsze: nie wymóżdżać kodu <- co rok to pojęcie co innego dla mnie znaczy więc i tak pewnie tu się nie zrozumiemy
[3] Stosować spójne nazewnictwo.

To jak to wszystko działa? Przykładowo w Gdańsku i Poznaniu, 2 miasta które biorę pod uwagę, większośc ofert dla programistów to java i c#/php dla seniorów a dla mid i juniorów c#(głównie .net) ale zawsze z dołączonym javascriptem jako wymagania lub też bezpośrednio javascript developer ze znajomością np react/angular/nodejs

Jak ktoś nie zna JavaScript, to go nienawidzi, bo próbuje w nim robić Javę/C#, a ten język ma zupełnie inne zasady działania (np. nie ma klas i koniec - nie ma co ich na siłe robić (ok w ECMA 6 są) )
Jak ktoś pozna JS to go nienawidzi za zmarnowany potencjał. Za bardzo ciekawy rdzeń (Lispowy) do którego ktoś dosrał zupełnie nonsensowne reguły i pułapki (truthy/falsy, equality ===/==, var hoisting, this/context, implicit semicolon ).

Ogólnie po wprowadzeniu szkoleń i narzędzi (JSHint/Lint + Testy) da się z JS pracować... ale po jakimś czasie i tak wychodzi duża wada... jest skrajnie nieprzyjemny w refaktoringu.

chyba np stąd:
![] - false
[] - true

![] == [] - true

ale ja tam go lubie :P

Mnie najbardziej wkurzało:
null == false // -> false

Z tego co czytam, to niemal wszędzie jest mówione, że javascript to przyszłość... A jednak wiele ludzi nie lubi tego języka.... Tylko teraz pytanie, czy nie lubią go głównie np c#'powcy lub javovcy czy programisci którzy piszą głównie w JavaScript? Czy w takim razie mój plan z poświęceniem 2-3 miesiące na nauke JavaScript jest stratą czasu? bo tak czy siak chciałbym kiedyś nauczyć się c# ale chwilowo bardzo podoba mi się możliwość budowania API i chciałbym mieć coś z np Reacta do portfolio, coś własnego. To źle czy dobrze?

@Akinwoktyzuawzan:
kiedyś mi powiedziano, że jak się czegoś nie umie to się nie lubi - i to jest wg mnie odpowiedź na pytanie
obstawiam że z całego grona hejterów JSa nieliczni będą go na prawde dobrze umieć, a po prostu nie lubić

azalut napisał(a):

kiedyś mi powiedziano, że jak się czegoś nie umie to się nie lubi - i to jest wg mnie odpowiedź na pytanie

W przypadku JS smutne jest to, że mało kto go lubi, a jeszcze rzadziej umie.

Prav napisał(a):

Mnie najbardziej boli brak dobrych narzędzi do statycznej analizy i IDE. Dla przykładu WebStorm ma problem z:

• Podpowiedzi "po kropce", extendowanie czegokolwiek jest równoznaczne pozbawieniem się sensownych podpowiedzi.
• Kolorowanie składni jest dosyć losowe np. czasem obj.start (gdzie start to pole obiektu obj) zostaje pokolorowany jak metoda, bo gdzieś w zaimportowanym module jest klasa, która ma taką metodę, albo w ogóle nie może znaleźć takiego pola, działa to też w drugą stronę, to że IDE nie zgłasza błędu w obj.start nie oznacza, że obj faktycznie zawiera cokolwiek nazwanego start.

Przez co refaktorowanie przypomina bardziej znajdź i zastąp w notatniku niż operacje na kodzie. Pisanie JSDoc do każdej funkcji i każdego obiektu rozwiązuje większość z ww. problemów, ale stanowi problem sam w sobie, bo jest relatywnie wolniejsze niż zdefiniowanie klasy w języku silnie typowanym dodatkowo przy zmianie w kodzie trzeba pamiętać o zaktualizowaniu JSDoca.

Niesamowicie frustrujące jest też to, że nawet syntax errory są zgłaszane dopiero w runtime. Szczególnie, że można poprosić V8/node.js o wyplucie bytecodu/assemblera.

To, że nie znasz takich narzędzi, nie znaczy, że nie istnieją. Jeśli WebStorm serio tak słabo sobie radzi z kodem (raczej wątpię, choć kto wie) to przerzuć się na inne IDE/edytor. Ja używam VS Code i lintera:

• nie ma problemów z podpowiedziami (nawet bez JSDoców, tyle, że wiadomo - wszędzie gdzie typu nie da się inferować masz podpowiadane any),
• błędy składniowe i wtf'y języka załatwia ESLint,
• nieistniejące metody, sporą cześć niezgodnych typów itp. wykrywa opcja "javascript.implicitProjectConfig.checkJs": true w edytorze (lub // @ts-check na poziomie pojedynczego pliku),
• o aktualność JSDoców też dba typechecker w edytorze (dodatkowo jest też plugin do ESLinta, choć nie tak dobry),
• rename symbol dzaiła jak powinno

Ogólnie pisanie kodu JS z JSDocami wyłapuje znakomitą większość błedów jeśli wiesz jakich narzędzi uzyć, choć TS jest tu oczywiście lepszy.

Eh, trochę zabawne te hejty - o wadach JSa możnaby książkę napisać, ale duża część argumentów z tego watku jest tak bardzo nietrafiona i świadczy o nieogarnięciu piszącego ;)

Jeśli jest tu ktoś kto głównie w JS pisze(a raczej w głównej mierze) a po komentarzach zakładam że jest to mam pytanie. Czy pogodzenie przykładowo pisania w c# i np w react w js naprawdę tak bardzo utrudnia życie? Chciałbym zaznaczyć że nie chodzi o łączenie tych języków w jednym projekcie ale przykładowo jeśli ktoś pisze w c# a jednocześnie czasami lubi walnąć sobie apke na weba w react js to to jest taka mordęga, czy zwyky hejt bo ktoś nie lubi jsa ale w jakimś projekcie musiał go użyć a nie chciało mu się go uczyć?

@Prav
Tu masz listę moich pluginów, możesz obczaić:

DavidAnson.vscode-markdownlint
PeterJausovec.vscode-docker
Zignd.html-css-class-completion
christian-kohler.npm-intellisense
dbaeumer.vscode-eslint
eamodio.gitlens
eg2.tslint
eriklynd.json-tools
formulahendry.code-runner
joelday.docthis
kisstkondoros.vscode-codemetrics
msjsdiag.debugger-for-chrome
robertohuertasm.vscode-icons
shyykoserhiy.vscode-spotify
streetsidesoftware.code-spell-checker
vscodevim.vim
wix.vscode-import-cost
xabikos.JavaScriptSnippets

i config:

{
    "editor.fontFamily": "Fira Code",
    "editor.fontLigatures": true,
    "editor.fontSize": 14,
    "editor.tabSize": 2,
    "editor.tabCompletion": true,
    "editor.minimap.enabled": true,
    "editor.renderIndentGuides": true,
    "vim.disableAnnoyingNeovimMessage": true,
    "workbench.editor.showTabs": false,
    "explorer.openEditors.visible": 0,
    "docker.showExplorer": true,
    "gitlens.gitExplorer.enabled": true,
    "gitlens.blame.line.enabled": false,
    "workbench.iconTheme": "vscode-icons",
    "javascript.implicitProjectConfig.checkJs": true
}

Klasyczne śmieszki, ale całkowicie się zgadzam z @jarekr000000, że każdy widzi w JSie inne wady, w zależności od tego jak ten język zna.

Wszystko można polubić. Dla mnie takim złem wcielonym jest CSS, a jednak mimo wszystko lubię pisać animacje w CSS, czy bawić się efektami, bo to jest po prostu cool. Mimo, że dla mnie CSS to jak dla jakiegoś backendowca coś takiego jak JavaScript, że nielogiczne i pełne WTFów.

azalut napisał(a):

@Akinwoktyzuawzan:
kiedyś mi powiedziano, że jak się czegoś nie umie to się nie lubi - i to jest wg mnie odpowiedź na pytanie
obstawiam że z całego grona hejterów JSa nieliczni będą go na prawde dobrze umieć, a po prostu nie lubić

To rozumowanie można zaaplikować do każdego innego języka, np: hejterzy Javy nie lubią jej, bo jej nie umieją. QED
Pokażcie mi hejtera Javy, który potrafi się nią płynnie posługiwać :]

somdekin?

Główny problem polega na tym, że fanatycy mylą krytykę z hejtem. Ktoś zwróci uwagę na prosty fakt jak np. to, że w JS jest wiele nieintuicyjnych konstrukcji, albo że Java nie ma generyków w runtime, i zaraz rzucają się na niego stada fanbojów wyzywając od hejterów.

Rozumiem... a tak teraz z innej beczki żeby nie zakładać nowego tematu... Czy dla .netowca bardziej przyszłościowe jest nauczyć się Reacta, czy Angular bedzie królował? Ja stawiam na Reacta bo mi się bardziej podoba ale chciałbym poruszyć tę kwestię i co o niej myślicie.

Angular jest bardziej "naturalnym wyborem" dla .NET'owca.

Akinwoktyzuawzan napisał(a):

Rozumiem... a tak teraz z innej beczki żeby nie zakładać nowego tematu... Czy dla .netowca bardziej przyszłościowe jest nauczyć się Reacta, czy Angular bedzie królował? Ja stawiam na Reacta bo mi się bardziej podoba ale chciałbym poruszyć tę kwestię i co o niej myślicie.

Czy (...) bardziej przyszłościowe jest nauczyć się Reacta, czy Angular bedzie królował?

Nie myśl o tym, co będzie przyszłościowe w kategoriach frontendu, bo w 2018 może zdobyć popularność jakiś inny framework. Więc okej, nauczysz się Angulara albo Reacta, to i tak będzie inwestycja krótkotrwała (we frontendzie okresowo się zmieniają frameworki i potem wszystko trzeba przepisywać na nowy bardziej modny framework). Chociaż myślę, że najbardziej przyszłościowe może być paradoksalnie nauka AngularJS (wersja 1.*), bo zawsze będą jakieś kobyły do utrzymywania z legacy kodem albo do przepisywania na jakiś nowszy framework.

(Tak ogólnie piszę o frontendzie, bo na trendach dot netowych to się nie znam).

somekind napisał(a):

Główny problem polega na tym, że fanatycy mylą krytykę z hejtem. Ktoś zwróci uwagę na prosty fakt jak np. to, że w JS jest wiele nieintuicyjnych konstrukcji, albo że Java nie ma generyków w runtime, i zaraz rzucają się na niego stada fanbojów wyzywając od hejterów.

Ja za to dodam, że trzeba odróżnić konstruktywną krytykę od zwykłego narzekania. Jak powiem, że w C# nie ma wielodziedziczenia to znaczy, że przez to C# jest upośledzony? Wymazywanie typów nie zachodzi tylko w Javie ale też np w Haskellu. Czy Haskell na tym traci?

Mechanika wokół słówka this jest podobna w C++, Javie, C# i innych popularnych językach obiektowych natomiast w JavaScripcie jest zupełnie odmienna. To mocno utrudnia pisanie poprawnego kodu ludziom nieprzyzwyczajonym do JavaScriptu, ale za to do innych języków obiektowych. Natomiast brak genericsów w runtime mi rzadko kiedy przeszkadzał. Jak dla mnie jest nawet plusem bo zmniejsza ilość okazji do (nielubianego przeze mnie) przeciążania metod. W zasadzie to w dużej mierze zgadzam się z tym gościem: https://stackoverflow.com/a/22667958

Nie ma preferencji, część projektów pisze się w Angularze, część w Reakcie, część w jeszcze czymś innym.