konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

W związku z małą burzą jaką spowodowałem moim poprzednim postem:
Dlaczego zrezygnowałem z pisania w JavaScript'cie?
napisałem prosty artykuł, który może zainteresować osoby piszące w CoffeeScript'cie, opisujący sprawdzone praktyki pisania przejrzystego kodu w CS:

http://codefedonarts.com/2013/02/23/writing-good-coffe...
Polecam.

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

"Zrezygnowałem z pisania JS, żeby pisać w CS, żeby następnie CS kompilować do JS" - seems legit...

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Piotr L.:
"Zrezygnowałem z pisania JS, żeby pisać w CS, żeby następnie CS kompilować do JS" - seems legit...
Co ma swoje poważne zalety i nie oznacza całkowitej rezygnacji z JavaScript'u.Błażej K. edytował(a) ten post dnia 24.02.13 o godzinie 17:00

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Błażej K.:
Piotr L.:
"Zrezygnowałem z pisania JS, żeby pisać w CS, żeby następnie CS kompilować do JS" - seems legit...
Co ma swoje poważne zalety i nie oznacza całkowitej rezygnacji z JavaScript'u.

Jednak w tamtym temacie oprócz innej składni (zaznaczam - po prostu innej) nie podałeś żadnej gdzie wad jest sporo.
Nie mówiąc o tym że pomysł przeniesienia 20-osobowego zespołu programistów JS na CS to marny pomysł ( to o czym mówiłeś ) bo okres tranzytu będzie ciężki zarówno dla nich jak i dla samych projektów.

Same porady powyżej są cokolwiek dziwne. Zalecasz dodawanie {} gdzie dopiero chwaliłeś ich brak. Mówisz o {} na liście parametrów gdzie przecież bez nich nie zgadzała by się lista parametrów (zamiast 1 obiektu 2 parametry). Mówisz o camelCase gdzie przecież w JS jest on naturalny i wymuszony tym że sam JS z niego korzysta. Zresztą nawet jak by ludziska pisali z podkreśleniem to też OK (chociaż nie pochwalam) - byle się trzymać tego w całym projekcie.
Tym pisaniem stałych mnie rozbawiłeś bo to dość normalne.

Swoją drogą mówisz że JS nie ma kontroli prywatności gdzie nie jest to do końca prawdą. Może nie ma private, public, protected wbudowanych w język ale spójrz na to:



function MyConstructor() {
if ((this instanceof MyConstructor) === false) {
return new MyConstructor();
}

var thisIsPrivate = 5;

function thisIsAlsoPrivate() {
return 'Hello secret agent!';
}

this.isPublic = 4;

this.setThisIsPrivate = function (value) {
thisIsPrivate = value;
return this;
}

this.getThisIsPrivate = function () {
return thisIsPrivate;
}

}



Można osiągnąć podobny efekt jasno i przejrzyście przy okazji nie kombinując z _. Co do callback hell czy jak to nazywasz. Rozwiązania zależą od okoliczności. Same funkcje nazwane mogą dużo nie pomów. Często takie callbacki zagnieżdżone znacznie lepiej zastępować wzorcem promise czy też obserwatorem.

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Błażej K.:
Piotr L.:
"Zrezygnowałem z pisania JS, żeby pisać w CS, żeby następnie CS kompilować do JS" - seems legit...
Co ma swoje poważne zalety i nie oznacza całkowitej rezygnacji z JavaScript'u.

Jakie? Konkretny, bez lania wody.

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Piotr L.:
Błażej K.:
Piotr L.:
"Zrezygnowałem z pisania JS, żeby pisać w CS, żeby następnie CS kompilować do JS" - seems legit...
Co ma swoje poważne zalety i nie oznacza całkowitej rezygnacji z JavaScript'u.

Jakie? Konkretny, bez lania wody.
http://codefedonarts.com/2013/02/17/why-i-have-given-u...

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Jak dla mnie konkrety to:
- Bardziej przejrzysty kod (programuję również w Pythonie)
- Krótszy kod (ok. 30%)
- "Nadpisanie" dziedziczenia prototypowego i dodanie sugar syntaxu w postaci klas spotykanych w innych językach (Java, C#)
- Łatwiejsze pisanie dla mniej doświadczonych programistów JS

Z mojego osobistego doświadczenia, ostatnio pisałem kod w CS (około 10k linii) i ten język pozwolił mi na łatwe zarządzanie kodem i utrzymaniem go w porządku.

Gwoli debaty, opinie o CS są różne, jedni zachwalają go, inni twierdzą, że jest on niepotrzebny. Ważne jest to, że jest tendencja do pisania w tym języku. Z punktu widzenia biznesu łatwiejszy kod to mniej pracy programisty, mniej błędów i przez to mniej wydanych pieniędzy na development i większy zysk.Patryk O. edytował(a) ten post dnia 24.02.13 o godzinie 19:07

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Patryk O.:
Jak dla mnie konkrety to:
- Bardziej przejrzysty kod (programuję również w Pythonie)
- Krótszy kod (ok. 30%)

I co z tego, skoro powyższe jest kompilowane do kodu JS - dodatkowo często ten kod jest gówniany i dłuższy niż miałbym to pisać ręcznie. Chyba w tym wszystkim zapomnieliście, że JS jest językiem Client Side i długość kodu wynikowego ma znaczenie.
- "Nadpisanie" dziedziczenia prototypowego i dodanie sugar syntaxu w postaci klas spotykanych w innych językach (Java, C#)

Syntactic Sugar występuje w JavaScripcie również i bez CSa.
- Łatwiejsze pisanie dla mniej doświadczonych programistów JS

Taaa. I będzie tak samo jak z jQ - frontendowcy nie znąją JSa a piszą w jQ :) LOL!
Z mojego osobistego doświadczenia, ostatnio pisałem kod w CS (około 10k linii) i ten język pozwolił mi na łatwe zarządzanie kodem i utrzymaniem go w porządku.

Gwoli debaty, opinie o CS są różne, jedni zachwalają go, inni twierdzą, że jest on niepotrzebny. Ważne jest to, że jest tendencja do pisania w tym języku. Z punktu widzenia biznesu łatwiejszy kod to mniej pracy programisty, mniej błędów i przez to mniej wydanych pieniędzy na development i większy zysk.

Mniejszy kod wcale nie musi oznaczać mniej błędów. Podobnie z kosztami.

Anyway: CS jako ciekawostka - myślę, że ma racje bytu, ale IMHO JSa jeszcze długo nie zastąpi.Piotr L. edytował(a) ten post dnia 24.02.13 o godzinie 19:18

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Patryk O.:
Jak dla mnie konkrety to:
- Bardziej przejrzysty kod (programuję również w Pythonie)

No właśnie inna składnia to pierwsza rzecz która wlatuje przy owej dyskusji. Zgadzam się że jest inna ale nie nazwał bym ją przejrzystą biorąc pod uwagę że z językami jak C, C++, Java, PHP itp mam do czynienia od lat (jak zresztą większość programistów) - JS czytam dość naturalnie.

Zresztą będąc szczerym - JS czyta mi się znacznie lepiej bo to wygląda mi na ludzką mowę:


if (opposite) {
number = -42;
}


A to:


number = -42 if opposite


Odbieram mniej i więcej tak:


Obrazek


A to tylko jeden przykład z wielu. Zastanawiam się co kierowało twórcami CS. Nie lepiej było usiąść i zrobić kolejny język programowania ?
- Krótszy kod (ok. 30%)

I pewnie było by to zaletą gdyby nie to że czas zachowany na pisaniu CS radośnie tracimy na karkołomnych próbach jego debugowania. Popraw mnie ale jak ostatnio zajmowałem się CS to nie było żadnego debuggera który by tłumaczył błędy w wygenerowanym kodzie JS do CS który go utworzył. Nie daj żeby sam CS miał w sobie bug to już kaplica.
Przynajmniej do JS mam debugger. Zarówno z phpStorm jak i przeglądarkowy który stara się przekładać mi błędy 1:1. Pisałem o tym w poprzednim temacie. Nikt nie raczył zaprzeczyć.
Nie ma to jak debugować kod bawiąc się w tym celu we wsteczną inżynierię.
- "Nadpisanie" dziedziczenia prototypowego i dodanie sugar syntaxu w postaci klas spotykanych w innych językach (Java, C#)

Znaczy się przebieramy wojownika w sukienkę i udajemy że to księżniczka ? To jest to o czym mówiłem wcześniej - próba zrobienia z JS czegoś czym nie jest.
- Łatwiejsze pisanie dla mniej doświadczonych programistów JS

Tu się nie zgodzę. Ucząc się pisać w JS masz:
- znajomą składnię bo pewnie już kojarzysz Javę czy C++. Nawet na studiach tego uczą.
- kod który masz to ten który wykonujesz
- błędy przekładają się 1:1
- brak kodu od Yody
- niemal wszystkie konstrukcje w języku są znajome

Jak Ci ktoś wciśnie w gardło CS to:
- masz nową, prawdopodobnie nieznajomą składnię
- twoje narzędzie generuje kod więc to na co patrzysz to nie jest to co się wykonuje
- zgubisz się próbując to debugować a wszelkie próby wyjaśnienia jak to robić przyprawią Cie o ból głowy
- będzie Ci się dziwnie czytało niektóre konstrukcje jeżeli nie jesteś fanem Star Wars
- większość tego co będziesz poznawał będzie INNE

A na koniec skompilujesz to wszystko i wrócisz do JS...

Z mojego osobistego doświadczenia, ostatnio pisałem kod w CS (około 10k linii) i ten język pozwolił mi na łatwe zarządzanie kodem i utrzymaniem go w porządku.

Gwoli debaty, opinie o CS są różne, jedni zachwalają go, inni twierdzą, że jest on niepotrzebny. Ważne jest to, że jest tendencja do pisania w tym języku. Z punktu widzenia biznesu łatwiejszy kod to mniej pracy programisty, mniej błędów i przez to mniej wydanych pieniędzy na development i większy zysk.

Jak do CS będzie IDE z debuggerem a całość wyjdzie poza zwykłą kompilację do JS to nie widzę przyszłości dla CS. Że ktoś pisze - a no pisze. Wystarczy popatrzeć na PHP i multum lekko mówiąc gównianych frameworków które jednak mają swoich fanów. Zawsze się ktoś znajdzie.

Interesowałem się CS ale skończyłem na wnioskach mówiących że JS tworzy tyle samo problemów co stara się rozwiązać - albo i więcej. A skoro już piszę w JS to nie ma sensu by pisać w JS tylko inaczej.

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Kolego Piotrze.. piszesz w ogóle w JS, czy sobie tak dywagujesz? Jak się chce zmniejszyć ilość kodu wysyłanego do klienta, to się stosuje minifying. CoffeeScript zatem nie robi zupełnie problemu.

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Dariusz Półtorak:
No właśnie inna składnia to pierwsza rzecz która wlatuje przy owej dyskusji. Zgadzam się że jest inna ale nie nazwał bym ją przejrzystą biorąc pod uwagę że z językami jak C, C++, Java, PHP itp mam do czynienia od lat (jak zresztą większość programistów) - JS czytam dość naturalnie.
Darku, jeśli nie lubisz wydajnych języków jak Python czy Ruby, to dalsza dyskusja z tobą powinna się z tobą zakończyć, ponieważ niczego tutaj nie wniesiesz.
Dariusz Półtorak:
Zresztą będąc szczerym - JS czyta mi się znacznie lepiej bo to wygląda mi na ludzką mowę.
To element, z którego możesz korzystać lub nie. Twój wybór, ale języki zbliżone do ludzkiego są generalnie bardziej czylene, chociaż dla mnie ta kontrukcja też wydaje się dość orientalna.
Dariusz Półtorak:
I pewnie było by to zaletą gdyby nie to że czas zachowany na pisaniu CS radośnie tracimy na karkołomnych próbach jego debugowania. Popraw mnie ale jak ostatnio zajmowałem się CS to nie było żadnego debuggera który by tłumaczył błędy w wygenerowanym kodzie JS do CS który go utworzył. Nie daj żeby sam CS miał w sobie bug to już kaplica.
Przynajmniej do JS mam debugger. Zarówno z phpStorm jak i przeglądarkowy który stara się przekładać mi błędy 1:1. Pisałem o tym w poprzednim temacie. Nikt nie raczył zaprzeczyć.
Nie ma to jak debugować kod bawiąc się w tym celu we wsteczną inżynierię.

Polecam debugger CS w RubyMine od JetBrains.
http://confluence.jetbrains.com/display/RUBYDEV/Debugg...
Dariusz Półtorak:
Tu się nie zgodzę. Ucząc się pisać w JS masz:
- znajomą składnię bo pewnie już kojarzysz Javę czy C++.
JS różni się znacznie w wykonaniu kodu od Javy, czy C++, ponieważ nie jest to język proceduralny/obiektowy, a wieloparadygmatowy.
Dariusz Półtorak:
- błędy przekładają się 1:1
Różnice w implementacjach EcmaScript-262 powodują różne zachowanie w różnych przeglądarckach i ich wersjach stąd błędy nie są wcale 1:1.
np. w IE część obiektów jest obiektami COM, a nie JS i dlatego GC potrafi działać *niespotykanie*, jak i sam kod.
Dariusz Półtorak:
- niemal wszystkie konstrukcje w języku są znajome
Tylko w językach 5 generacji nie wszytkie są znane (np. OWL), a CS podobnie jak JS jest językiem 3 generacji.

Darku, widzę, że większość twoich argumentów, pomimo zwykłej zawiści i ignorancji, wynikają z poważnych braków w twojej wiedzy.

Co do rozwiązań biznesowych napisanych w CS, polecam poczytać o tym dlaczego DropBox został przepisany z JS:
https://tech.dropbox.com/2012/09/dropbox-dives-into-cof...Błażej K. edytował(a) ten post dnia 24.02.13 o godzinie 20:32

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Jacek C.:
Kolego Piotrze.. piszesz w ogóle w JS, czy sobie tak dywagujesz? Jak się chce zmniejszyć ilość kodu wysyłanego do klienta, to się stosuje minifying. CoffeeScript zatem nie robi zupełnie problemu.

Ale co to za argument?!? zminifikowany potworek powstały z CSa dalej będzie potworkiem. minify można też użyć do JSa. Po kiego grzyba uczyć się nowej składni, skoro większość frontendowców nawet nie zna dobrze JSa?!?

Zresztą cala dyskusja nie ma sensu, bo to dyskusja w stylu "wyższość świąt bożego narodzenia nad świętami wielkanocnymi" albo kłótnia Kargula z Pawlakiem o 5 palców miedzy... Przy argumentach w stylu "jeśli nie lubisz wydajnych języków jak Python czy Ruby, to dalsza dyskusja z tobą powinna się z tobą zakończyć, ponieważ niczego tutaj nie wniesiesz", albo "piszesz w ogóle w JS" naprawdę nie ma co dalej dyskutować. Bo przecież każdy argument przeciwko CSowi można zbić takim durnym tekstem...

edit:
Jedna rada: jak nie potraficie dyskutować bez wrzucania argumentów ad personam to może idźcie przewietrzyć głowy na dwór, albo wróćcie do kodowania w CSie...
edit 2:
Liczyłem, że w tej dyskusji dowiem się o CoffeeScript czegoś nowego, bo po kilku projektach zrobionych z jego wykorzystaniem czuję niedosyt wiedzy, ale skończyło się jak zwykle: na porównywaniach kto ma dłuższego i bezpłciowych argumentum ad personam. Z mojej strony EOT.Piotr L. edytował(a) ten post dnia 24.02.13 o godzinie 20:45

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Błażej K.:
Dariusz Półtorak:
Darku, jeśli nie lubisz wydajnych języków jak Python czy Ruby, to dalsza dyskusja z tobą powinna się z tobą zakończyć, ponieważ niczego tutaj nie wniesiesz.

Kiedy to jakie języki preferuje nie ma znaczenia gdyż narzędzia z którymi pracuje wybieram nie wg preferencji a wg potrzeb.
Jak mówię - składnia to właściwie jedyna zaleta CS jeżeli pominiemy jej odmienność. Z drugiej strony tylko niektóre jej elementy wydają mi się ciekawe (chociaż wyglądają paskudnie jak ów "if e.dataTransfer?.types?.contains") a często są wręcz irytujące jak np -> przy funkcjach gdzie o wiele prościej wstawić mi {} bo nie muszę skakać w pionie przez całą klawiaturę by to wpisać (co mnie np bardzo irytuje również w PHP).

Dodatkowo jeżeli popatrzysz na przykłady swoje jak i dropboxa to nie licząc małych wyjątków - CS wycina przede wszystkim {} i (). I to w zasadzie tyle. Biorąc pod uwagę że otwierający stawiam bez problemu a zamykający się wstawia sam, jak również to że IDE podświetla na ogół zasięg w którym jesteśmy i dba o białe znaki - wychodzi na to że owego kodu CS może jest mniej ale z palca piszemy niewiele mniej go niż JS.
Dariusz Półtorak:
To element, z którego możesz korzystać lub nie. Twój wybór, ale języki zbliżone do ludzkiego są generalnie bardziej czylene, chociaż dla mnie ta kontrukcja też wydaje się dość orientalna.

Chodziło mi o przykład który podałem. Bardziej przemawia do mnie sformułowanie "JEŻELI mam pieniądze kupię chleb" niż "kupię chleb JEŻELI mam pieniądze". Może to kwestia przyzwyczajenia.
Dariusz Półtorak:
Polecam debugger CS w RubyMine od JetBrains.
http://confluence.jetbrains.com/display/RUBYDEV/Debugg...

Na razie tylko na Railsy. A są jakieś debuggery poza tym ? Ja poważnie tutaj pytam. Jestem zawsze skłonny rzucić okiem na CS ponownie jeżeli dorobili się podstawowego narzędzia każdego programisty.
JS różni się znacznie w wykonaniu kodu od Javy, czy C++, ponieważ nie jest to język proceduralny/obiektowy, a wieloparadygmatowy.

Mówię o składni. Jest znajoma bo między innymi na Javie była wzorowana o ile pamiętam.
Dariusz Półtorak:
- błędy przekładają się 1:1
Różnice w implementacjach EcmaScript-262 powodują różne zachowanie w różnych przeglądarckach i ich wersjach stąd błędy nie są wcale 1:1.

No własnie są. Odkąd pamiętam błąd który wystąpił w moim kodzie znajduje się tam gdzie go popełniłem. Nie kompiluje się do innego kodu, nie występuje w zupełnie innym miejscu i nie wymaga ode mnie bym sobie przepisał kod który został wygenerowany do napisanego by go zlokalizować.
Chyba się nie zrozumieliśmy.
np. w IE część obiektów jest obiektami COM, a nie JS i dlatego GC potrafi działać *niespotykanie*, jak i sam kod.

IE to inna brożka. Z IE trzeba sobie radzić ale zarówno w 8 jak i 9 kod debuguje się całkiem sprawnie. A przynajmniej jeszcze nie miałem z tym problemów.
Dariusz Półtorak:
- niemal wszystkie konstrukcje w języku są znajome
Tylko w językach 5 generacji nie wszytkie są znane (np. OWL), a CS podobnie jak JS jest językiem 3 generacji.

Eeeee... gratuluje inteligentnego wywodu ale mi chodziło o coś tak prostego jak np warunek IF który wygląda identycznie jak w multum innych języków programowania. To samo z pętlami itp.

Chodzi tu o prostą rzecz - programista który zna JEDEN język programowania znacznie szybciej uczy się innych dlatego że są one do siebie pod wieloma względami podobne. Rzecz nie jest taka ładna przy językach zupełnie innych (widziałem np na uczelni osoby które świetnie sobie radziły z paroma językami programowania czy nawet pracowały zawodowo jako programiści a nie mogli ogarnąć SML).

Jestem bardzo ciekaw jak przekonasz programistę do nauki CS próbując mu jednocześnie wytłumaczyć że musi kupić IDE za 100 euro (jeżeli pamiętam dobrze ceny - swoją drogą mam i polecam) a później napisać jakąś mapę kodu jeżeli nie używa Railsów żeby mógł postawić breakpoint który zatrzyma mu wygenerowany kod JS tam gdzie postawił ów bp w kodzie CS...

Darku, widzę, że większość twoich argumentów, pomimo zwykłej zawiści i ignorancji, wynikają z poważnych braków w twojej wiedzy.

Jak ktoś nie ma argumentów to na ogół rozpoczyna osobiste wycieczki. Wybacz ale na taki poziom dyskusji schodził nie będę. A jeżeli przeszkadza Ci zdanie innych to może nie umieszczaj go na forum publicznym. Blogi się lepiej redaguje. Można usunąć komentarze które Ci się nie podobają.

Co do rozwiązań biznesowych napisanych w CS, polecam poczytać o tym dlaczego DropBox został przepisany z JS:
https://tech.dropbox.com/2012/09/dropbox-dives-into-cof...

Polecam zastanowić się czego firmy jak Facebook czy Google które utrzymują kodu JS na tony tego nie zrobili. Ot jeżeli serwujemy firmami. Przepisali kupę kodu na to samo tylko inaczej. Gratz że mieli czas i chęci.
Ale oni również nie napisali wiele o realnych korzyściach.Dariusz Półtorak edytował(a) ten post dnia 24.02.13 o godzinie 23:54

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Dariusz Półtorak:
Błażej K.:
Co do rozwiązań biznesowych napisanych w CS, polecam poczytać o tym dlaczego DropBox został przepisany z JS:
https://tech.dropbox.com/2012/09/dropbox-dives-into-cof...

Polecam zastanowić się czego firmy jak Facebook czy Google które utrzymują kodu JS na tony tego nie zrobili. Ot jeżeli serwujemy firmami. Przepisali kupę kodu na to samo tylko inaczej. Gratz że mieli czas i chęci.
Ale oni również nie napisali wiele o realnych korzyściach.

Gwoli ścisłości to Google ma swoje GWT - czyli wygląda jak JavaScript, ale to tak naprawdę Java.
Na pewno używane na platformach Blogger i Orkut.

http://en.wikipedia.org/wiki/Google_Web_Toolkit

Poza tym jest jeszcze Dart - czyli język kompilowany - podobnie jak CS - do JS.
Kiedy wejdzie do użycia i czy w ogóle wejdzie - nie wiadomo.

http://en.wikipedia.org/wiki/Dart_%28programming_langu...

Sam też chętnie bym poczytał dlaczego powinienem znać CS. Bo na razie dużo się o tym mówi ale jakoś nie wiadomo dlaczego. Na razie to widzę głównie fascynację tym że mamy nowy język.
Składnia jest ciekawsza, ale jeszcze się chyba nie zdarzyło żebym zaczął naukę języka bo ma fajniejsze wcięcia. Zawsze są to jakieś powody merytoryczne - lepsza kontrola dostępu, wydajniejszy program wynikowy, popularność (= liczba istniejących rozwiązań) itd.

Jeśli JetBrains pozwala debugować CS to przydałoby się to gdzieś zobaczyć poza stroną producenta. Na stronie producenta i tak niewiele widać:

http://confluence.jetbrains.com/display/RUBYDEV/Debugg...
Daniel Częstki

Daniel Częstki senior php developer

Temat: CoffeeScript: Dobre praktyki pisania kodu

A ja lubię czytać Piotra ;)

konto usunięte

Temat: CoffeeScript: Dobre praktyki pisania kodu

Próbowałem już wielu różnych kompilatorów do JS, w tym CSa, GWT i nawet napisałem własny kompilator Scali do JS. Problem z tymi narzędziami zawsze pozostanie taki sam - DEBUGOWANIE.
Poza tym tak jak wielu programistów C, C++ i Javowych gardzę Pythonem, ten język jest po prostu nieczytelny dla ludzi którzy są przyzwyczajeni do klamr. I przeszkadza mi to że osoby zakochane w Pythonie psują kod JS pisząc w coffescript, zwyczajnie napawa mnie obrzydzeniem kod którego działanie jest zależne od spacji.

Myślałem natomiast o stworzeniu edytora który przekształcał by kod JS do czegoś bardziej czytelnego i przy zapisie jak i odczycie plików JS konwertował kod zachowując wcięcia i inne elementy. JavaScript był by o wiele czytelniejszy gdyby zamiast function(x) { return x+1} móc pisać (x) => x+1, albo x=>{x+1}. Myślę że da się to zrobić na poziomie edytora kodu.



Wyślij zaproszenie do