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

Roman Tyczka (30.07.2018, 11:19)
Witam,

W JS jestem zielony, ale musze cos zrobic, wiec próbuje zorganizowac
srodowisko.
Wybralem edytor VS Code, zainstalowalem NodeJS, skonfigurowalem VSC:

"configurations": [
{
"type": "node",
"request": "launch",
"name": "Launch Program",
"program": "${workspaceFolder}/Tss/TssClient.js",
"cwd": "${workspaceFolder}",
"runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"
},

I teraz zakladam pulapki, odpalam skrypt i nic, pojawia sie na pól sekundy
toolbar debugera i koniec dzialania, a w debug console mam:

t:\tools\NodeJS\x64\ --inspect-brk=44200 Tss\TssClient.js
Node process
error: Error: spawn t:\tools\NodeJS\x64\ ENOENT

Co robie zle?
Czy fakt, ze VSCode uzywa NodeJS do debugowania i odpalania skryptów
wymusza jakis specjalny sposób pisania tych skryptów?
Borys Pogorelo (30.07.2018, 14:03)
Dnia Mon, 30 Jul 2018 11:19:03 +0200, Roman Tyczka napisal(a):

> "runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"


Nie znam tej aplikacji, ale jak dla mnie w powyzszym brakuje Ci pelnej
sciezki do node.exe
Roman Tyczka (30.07.2018, 14:44)
On Mon, 30 Jul 2018 14:03:37 +0200, Borys Pogorelo wrote:

>> "runtimeExecutable": "t:\\tools\\NodeJS\\x64\\"

> Nie znam tej aplikacji, ale jak dla mnie w powyzszym brakuje Ci pelnej
> sciezki do node.exe


No widzisz, rzut oka praktyka i jestem krok dalej, dzieki :-)

Kolejne pytanie.
Mam skrypt, który korzysta z jQuery, w przegladarce skrypty sie "widza"
wzajemnie, wiec mój skrypt moze sie odwolywac do jQuery i z niego
korzystac, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
Masz pomysl jak to ominac? Googluje i nic sensownego nie moge osiagnac.

ps. czy móglbys polecic inne srodowisko do debugowania JS?
Borys Pogorelo (31.07.2018, 00:08)
Dnia Mon, 30 Jul 2018 14:44:52 +0200, Roman Tyczka napisal(a):

> Mam skrypt, który korzysta z jQuery, w przegladarce skrypty sie "widza"
> wzajemnie, wiec mój skrypt moze sie odwolywac do jQuery i z niego
> korzystac, w przypadku VSCode i NodeJS debuger nie "widzi" klas jQuery.
> Masz pomysl jak to ominac? Googluje i nic sensownego nie moge osiagnac.


Wszystko zalezy od tego w jaki sposób siegasz do jQuery i jak sie do niej
pózniej odwolujesz. W przegladarce zapewne wrzucasz te biblioteke do
globalnej przestrzeni nazw (czy tez raczej do obiektu window), w node jej
nie masz - musisz biblioteke zaimportowac i korzystac z tak stworzonej
zmiennej. Najlepiej wrzuc kawalek swojego kodu.

> ps. czy móglbys polecic inne srodowisko do debugowania JS?


Chrome devtools ;) Zalezy co chcesz uzyskac. Korzystasz z node, ale nie
wiem czy faktycznie chcesz budowac aplikacje node, czy tylko ten debugger
tak dziala.
Roman Tyczka (02.08.2018, 14:35)
On Tue, 31 Jul 2018 00:08:41 +0200, Borys Pogorelo wrote:

> Dnia Mon, 30 Jul 2018 14:44:52 +0200, Roman Tyczka napisal(a):
> Wszystko zalezy od tego w jaki sposób siegasz do jQuery i jak sie do niej
> pózniej odwolujesz. W przegladarce zapewne wrzucasz te biblioteke do
> globalnej przestrzeni nazw (czy tez raczej do obiektu window), w node jej
> nie masz - musisz biblioteke zaimportowac i korzystac z tak stworzonej
> zmiennej. Najlepiej wrzuc kawalek swojego kodu.


Sprawa wyglada tak, mam serwer restowy (napisany w Delphi), teraz chce sie
do niego podlaczyc z JS. W JS napisalem przy uzyciu jQury swoja klase
klienta tegoz serwera restowego, ta klasa jest w pliku TssClient.js i
chcialbym ja podebugowac, potestowac. Ale marzy mi sie srodowisko
zintegrowane do jakiego mnie przyzwyczailo Delphi (czy nawet PHP), z
debugerem, wygodnym edytorem, etc. Dlatego po chwili googlowania wybralem
VS Code, ale moze to blad.

>> ps. czy móglbys polecic inne srodowisko do debugowania JS?

> Chrome devtools ;) Zalezy co chcesz uzyskac. Korzystasz z node, ale nie
> wiem czy faktycznie chcesz budowac aplikacje node, czy tylko ten debugger
> tak dziala.


Nie chce aplikacji node tylko wlasnie VS Code tak dziala. Dlatego pytalem o
inne sensowne srodowisko, które nie jest przegladarka. Moze czegos takiego
po prostu nie ma?

ps. NodeJS ma cos takiego jak moduly i mozna podobnie jak w PHP stosowac
funkcje require(), ale to wymaga po stronie inkludowanego skryptu
zarejestrowania exportu, a przeciez nie dopisze do jQuery tego.

Borys Pogorelo (02.08.2018, 20:36)
Dnia Thu, 2 Aug 2018 14:35:33 +0200, Roman Tyczka napisal(a):

> Nie chce aplikacji node tylko wlasnie VS Code tak dziala. Dlatego pytalem o
> inne sensowne srodowisko, które nie jest przegladarka. Moze czegos takiego
> po prostu nie ma?


Jest, jest. Skoro chcesz to zrobic tak, to mozesz sie po prostu podlaczyc
pod debugger wbudowany w node. Wiekszosc IDE to zapewnia:



> ps. NodeJS ma cos takiego jak moduly i mozna podobnie jak w PHP stosowac
> funkcje require(), ale to wymaga po stronie inkludowanego skryptu
> zarejestrowania exportu, a przeciez nie dopisze do jQuery tego.


Wiele pakietów jest dostosowanych do takiego uzycia, w tym jQuery:

Roman Tyczka (03.08.2018, 14:29)
On Thu, 2 Aug 2018 20:36:29 +0200, Borys Pogorelo wrote:

>> Nie chce aplikacji node tylko wlasnie VS Code tak dziala. Dlatego pytalem o
>> inne sensowne srodowisko, które nie jest przegladarka. Moze czegos takiego
>> po prostu nie ma?

> Jest, jest. Skoro chcesz to zrobic tak, to mozesz sie po prostu podlaczyc
> pod debugger wbudowany w node. Wiekszosc IDE to zapewnia:
>


Odpuszczam Node, to zbyt dla mnie zagmatwane i przerosniete. Zwlaszcza, ze
odkrylem iz VSCode pozwala jednak na "lokalne" debugowanie, trzeba w nim
doinstalowac rozszerzenie debugera dla Chrome lub Firefoxa, odpalic te
przegladarke z parametrem --remote-debugging-port=9222 i sie podlaczyc
edytorem do przegladarki, która ma API od debugowania, wtedy mozna w miare
wygodnie debugowac kod w sensownym edytorze choc wykonuje sie po stronie
przegladarki. Ale lepsze to niz debugowanie w samej przegladarce.

W sumie to mnie troche dziwi, ze najpopularniejszy jezyk swiata nie ma
jakichs prostych IDE z wbudowanym debugerem i cala otoczka narzedzi
developerskich tylko trzeba sie tak gimnastykowac.

>> ps. NodeJS ma cos takiego jak moduly i mozna podobnie jak w PHP stosowac
>> funkcje require(), ale to wymaga po stronie inkludowanego skryptu
>> zarejestrowania exportu, a przeciez nie dopisze do jQuery tego.

> Wiele pakietów jest dostosowanych do takiego uzycia, w tym jQuery:
>


No to juz niepotrzebne i dziala tak jak chcialem. Tymczasem kolejne
problemy i nowy watek :-)
Borys Pogorelo (03.08.2018, 15:30)
Dnia Fri, 3 Aug 2018 14:29:40 +0200, Roman Tyczka napisal(a):

> W sumie to mnie troche dziwi, ze najpopularniejszy jezyk swiata nie ma
> jakichs prostych IDE z wbudowanym debugerem i cala otoczka narzedzi
> developerskich tylko trzeba sie tak gimnastykowac.


Cóz, jaki jezyk, takie narzedzia ;)
Roman Tyczka (03.08.2018, 15:47)
On Fri, 3 Aug 2018 15:30:45 +0200, Borys Pogorelo wrote:

> Dnia Fri, 3 Aug 2018 14:29:40 +0200, Roman Tyczka napisal(a):
>> W sumie to mnie troche dziwi, ze najpopularniejszy jezyk swiata nie ma
>> jakichs prostych IDE z wbudowanym debugerem i cala otoczka narzedzi
>> developerskich tylko trzeba sie tak gimnastykowac.

> Cóz, jaki jezyk, takie narzedzia ;)


E, nie taki zly, podoba mi sie jego ekspresja i elastycznosc.
Mam fajna ksiazke "JS, mocne strony" Crockforda i koles opisuje to co uwaza
za udane i dobre w JS przestrzegajac przed niedoróbkami i bledami w
implementacji standardu (bledy juz w definicji). Bardzo fajna pozycja, z
dystansem i bez wychwalania.
Borys Pogorelo (03.08.2018, 19:59)
Dnia Fri, 3 Aug 2018 15:47:44 +0200, Roman Tyczka napisal(a):

>> Cóz, jaki jezyk, takie narzedzia ;)

> E, nie taki zly, podoba mi sie jego ekspresja i elastycznosc.
> Mam fajna ksiazke "JS, mocne strony" Crockforda i koles opisuje to co uwaza
> za udane i dobre w JS przestrzegajac przed niedoróbkami i bledami w
> implementacji standardu (bledy juz w definicji). Bardzo fajna pozycja, z
> dystansem i bez wychwalania.


;)

Jeszcze zaplaczesz nad tym jezykiem. Zacznij od razu uczyc sie Typescriptu
- prosta rzecz, a przynajmniej mocno ograniczysz problemy wynikajace z
niejawnych konwersji typów.
Roman Tyczka (04.08.2018, 22:42)
On Fri, 3 Aug 2018 19:59:22 +0200, Borys Pogorelo wrote:

>> E, nie taki zly, podoba mi sie jego ekspresja i elastycznosc.
>> Mam fajna ksiazke "JS, mocne strony" Crockforda i koles opisuje to co uwaza
>> za udane i dobre w JS przestrzegajac przed niedoróbkami i bledami w
>> implementacji standardu (bledy juz w definicji). Bardzo fajna pozycja, z
>> dystansem i bez wychwalania.

> ;)


:-)
A ta druga cegielka to... no, konkret widze :-)

> Jeszcze zaplaczesz nad tym jezykiem. Zacznij od razu uczyc sie Typescriptu
> - prosta rzecz, a przynajmniej mocno ograniczysz problemy wynikajace z
> niejawnych konwersji typów.


Dlatego debuger jest mi tak bardzo potrzebny, wtedy wszystko widze jak na
dloni.
A propos TypeScripta, na czym polega jego uzycie? To sie potem jakos
przekompilowuje do JS czy przegladarki go tez kumaja? No i na jakim etapie
jest kontrola typów?
Cezary Tomczyk (05.08.2018, 13:33)
On 04/08/2018 23:42, Roman Tyczka wrote:
[...]
> A propos TypeScripta, na czym polega jego uzycie? To sie potem jakos
> przekompilowuje do JS czy przegladarki go tez kumaja? No i na jakim etapie
> jest kontrola typów?


TypeScript tak naprawde transpiluje sie do ES5/ES6/ES6. Niemniej jednak
z wlasnego doswiadczenia moge napisac, ze na dzien dzisiejszy wszystkie
projekty rozpoczynam w TypeScripcie.

Co najmniej kilka powodów:

* Pilnuje typów danych. To powoduje, ze wiem jakiego typu danych sie
spodziewam. Oczywiscie, to dziala tylko na etapie pisania kodu w
edytorze, bo jak napisze:

example(status: boolean): void {
this.status = status;
}

a REST API zwróci null to taka wartosc bedzie zapisana pod this.status.

* Znacznie lepsze mozliwosci refactoringu. Zmiana nazwy metody czy pliku
powoduje zmiany w calym kodzie.

* Definicje: interface, enum, return type, public, private, static, itd.

No i wazna rzecz: mozesz mieszac swobodnie TypeScript i JavaScript!

Jeszcze 1 rok temu bylem stosunkowo sceptycznie nastawiony do
TypeScriptu, ale dzis polecam go kazdemu. Spróbuj, sam ocenisz po jakims
czasie.
Borys Pogorelo (05.08.2018, 14:59)
Dnia Sat, 4 Aug 2018 22:42:11 +0200, Roman Tyczka napisal(a):

> A propos TypeScripta, na czym polega jego uzycie? To sie potem jakos
> przekompilowuje do JS czy przegladarki go tez kumaja?


Tak, musisz go przeksztalcic do standardowego JS. I z tym niestety musisz
sie pogodzic - jakiekolwiek wyjscie poza ramy "standardowego" JS oznacza
wlaczenie osobnego procesu transpilacji. Niewazne czy to bedzie
TypeScript/CoffeScript, czy tez caly framework typu React czy chocby uzycie
kodu ES6 - czeka Cie nauka gulp / webpack / rollup (a do tego npm / yarn +
babel).

Co do samego TS - sa metody na uzycie go bezposrednio w przegladarce, ale
to bardziej w celu ulatwienia pisania i testowania kodu, niz uzycia na
produkcji.
Roman Tyczka (05.08.2018, 23:11)
On Sun, 5 Aug 2018 14:59:59 +0200, Borys Pogorelo wrote:

> wlaczenie osobnego procesu transpilacji. Niewazne czy to bedzie
> TypeScript/CoffeScript, czy tez caly framework typu React czy chocby uzycie
> kodu ES6 - czeka Cie nauka gulp / webpack / rollup (a do tego npm / yarn +
> babel).


Poczytalem o tym... wlosy staja deba... to jest tak pokrecone i
przekombinowane, ze podziwiam tych, co w tym sie sprawnie poruszaja.

Juz sama idea calego procesu jest kuriozalna z punktu widzenia
"klasycznego" programowania. Pisze w nieistniejacym jezyku, likwidujacym
wady JS czyli w TypeSripcie, potem konwertuje to do JS, a potem tegoz JS
konwertuje do ...ups... takze JS ale starego, bo nie wszystkie przegladarki
kumaja nowe wersje. Jednoczesnie uzywam podobnych patentów przy CSS. A zeby
jeszcze móc odnalezc blad wystepujacy w srodowisku produkcyjnym (w starym
JS lub CSS!) musze sobie zmapowac mój kod w TS na JS za pomoca Source Maps!
Ponadto cale srodowisko pracy i wszystkie narzedzia opieraja sie o NodeJS,
bo ...nie wiem czemu. I kazde z narzedzi ma inna konfiguracje zapisana w
plikach JSONowych w dziesiatkach katalogów.
Oczywiscie kazde narzedzie ma kilka odpowiedników z rzesza zwolenników i
kazdy developer uzywa innego zestawu narzedzi, z innymi parametrami, innymi
zachowaniami, innymi wadami i zaletami. Ufff...

To wszystko brzmi jak sen wariata i ogarniecie wymaga pewnej formy autyzmu
:-)
Na razie goly VSCode i klasyczny JS mi wystarczy, nie mam dodatkowego zycia
na rozkminienie tego wszystkiego :-(
Borys Pogorelo (08.08.2018, 22:19)
Dnia Sun, 5 Aug 2018 23:11:07 +0200, Roman Tyczka napisal(a):

>> wlaczenie osobnego procesu transpilacji. Niewazne czy to bedzie
>> TypeScript/CoffeScript, czy tez caly framework typu React czy chocby uzycie
>> kodu ES6 - czeka Cie nauka gulp / webpack / rollup (a do tego npm / yarn +
>> babel).

> Poczytalem o tym... wlosy staja deba... to jest tak pokrecone i
> przekombinowane, ze podziwiam tych, co w tym sie sprawnie poruszaja.


Polece klasykiem:

nic sie nie zestarzalo w tym tekscie ;)

> To wszystko brzmi jak sen wariata i ogarniecie wymaga pewnej formy autyzmu
> :-)


Tak, swiat JS dokladnie tak wyglada. Musisz nabyc odpornosci i przestac
myslec o tym calym bajzlu dziejacym sie pod spodem. I miec mocne CPU, by
proces transpilacji nie przeszkadzal az tak bardzo.

A pózniej sie okazuje, ze kodu beda uzywac w korpo na IE11 i zalamujesz
sie.
Podobne wątki