Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Javascript - czy jestem zmuszeni, by z niego korzystać?

Wpis ten jest drugą częścią wpisu powstałego na łamach tej strony.

Skąd przychodzimy?

A no z wpisu poświęconego paskudności i niedoskonałości JS.
W tym wpisie pokażę kilka rozwiązań, pseudorozwiązań i rzeczy, które rozwiązaniami być nie powinny. A więc od początku. Zacznijmy od rozwiązań.

Rozwiążmy problem. Problem gwoździa i młotka

JS jest dość paskudny, urodziwość to nie jest zaleta tego języka. Co jednak, nie znaczy, że nie należy się go uczyć. Język niemiecki urodą nie grzeszy, ale uczyć się go trzeba.
Co zrobić, by bylo nam lepiej, wygodniej i przyjemniej?
M. in. lepiej organizować kod i zamiast makaronu i funkcji o wiele mówiących nazwach "Funkcja1", gdzie nie nikt normalny ( z autorem włącznie) odczytać nie może.
Po to są komentarze, by ich używać. Inna sprawa to minimalizacja naszych skryptów i zbijanie ich w jeden ogromny ciasny blok o czytelności parsera html zbudowanego z użyciem regexpów w Perlu. Wtedy brak komentarzy jest dozwolony. By jednak pomóc innym warto mieć czasem zakładkę dalej (każdy normalny edytor taby obsługuje*) prosty plik napisany z użyciem Markdown. I taki prosty plik zawierający opisy funkcji dodać. Jeśli to nam nie pasuje, czy tak trudno stworzyć namiastkę tego w jakimś języku skryptowym, który przeleci nam przez plik i skopiuje to co pomiędzy znakami @ komentarz @ @ Ta funkcja robi to @ Już wymieniony Perl, czy chociażby dodatki w Vimie pozwalają na coś takiego. Nie bójmy się komentować.
Czym jest (pod)tytułowy problem "gwoździa i młotka". Mamy jeden gwóźdź i jeden młotek. zy, aby zbić parę desek potrzeba nam nowego narzędzia, gdy stare jeszcze daje (z trudem to fakt), ale radę. Jeśli tyle ci wystarczy skończ tutaj. Niżej pokażę kilka młotków, które mogą się przydać. Choć w sumie trochę strach dawać programiście młotek. Jak to mówią, gdyby programiści budowali domy, te były by pełne dziur. A więc ta da dam.

CoffeScript

Dalej po prostu CS. Ten język pozwala pisać mniej i mieć więcej. Nie możliwe! A jednak.
Pozwolę sobie zacząć od przykład var Animal, Horse, Snake, sam, tom, __hasProp = {}.hasOwnProperty, __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; }; Animal = (function() { function Animal(name) { this.name = name; } Animal.prototype.move = function(meters) { return alert(this.name + (" moved " + meters + "m.")); }; return Animal; })(); Snake = (function(_super) { __extends(Snake, _super); function Snake() { return Snake.__super__.constructor.apply(this, arguments); } Snake.prototype.move = function() { alert("Slithering..."); return Snake.__super__.move.call(this, 5); }; return Snake; })(Animal); Horse = (function(_super) { __extends(Horse, _super); function Horse() { return Horse.__super__.constructor.apply(this, arguments); } Horse.prototype.move = function() { alert("Galloping..."); return Horse.__super__.move.call(this, 45); }; return Horse; })(Animal); sam = new Snake("Sammy the Python"); tom = new Horse("Tommy the Palomino"); sam.move(); tom.move(); Sporo kodu. No cóż fakt. No i dość mało zrozumiałego kodu
A teraz coffescript class Animal constructor: (@name) -> move: (meters) -> alert @name + " moved #{meters}m." class Snake extends Animal move: -> alert "Slithering..." super 5 class Horse extends Animal move: -> alert "Galloping..." super 45 sam = new Snake "Sammy the Python" tom = new Horse "Tommy the Palomino" sam.move() tom.move() Teraz może zagramy w znajdź różnicę,
Co daje nam CoffeeScript?

Cukier, cukier i więcej cukru. Składniowego oczywiście

Otrzymujemy na starcie masę nowości. No i może nie nowości, ale wspomagaczy.
Znika słówka var i mało urodziwy znak === od teraz zastąpiony regularnym ==.
Dochodzą nowe słówka kluczowe. Kod jest ładniejszy.
Naszego c++ fora w stylu (zmienna;warunek;iteracja) zastępuję "for zmienna in zakres".
Jest czytelniej, przynajmniej dla mnie, zielonego. Ponadto dostajemy pięknie źródło informacji.
Dziesiątki dodatkowych elementów. A co z bibliotekami? Jako, że CS jest tłumaczony do JS - działają. I to jak, a jQuery zyskuje nieco na urodzie i traci posmak makaroniarstwa.formValues = (elem.value for elem in $('.input'))Tak wygląda CS, a jak JS robiący to samo var elem, formValues; formValues = (function() { var _i, _len, _ref, _results; _ref = $('.input'); _results = []; for (_i = 0, _len = _ref.length; _i < _len; _i++) { elem = _ref[_i]; _results.push(elem.value); } return _results; })();

Cóż za paskudztwo. Kolejne plusy CS to m.in.

  • Wygodne testy - wraz z Mochą
  • Ci którzy spojrzą na nasz kod za powiedzmy kilka miesiecy nie będą krzyczeć
  • CS może zostać w pełni zintegrowany z Node.js to kolejny plus
A minusy. Ciężko powiedzieć. CS to dość jeszcze młody projekt. Także osiągi są nie rzadko słabsze. Kolejna sprawa to białe znaki, które coś znaczą. Dla fanów C/C++/JS to źle. Dla Pythonowego światka i browser śpiewa Alleluja.
Polecam zerknąć Tutaj - to przydatne fragmenty kodu
i Strona, która może nie jednemu devowi się przydać.

Syrup - początek czegoś ciekawego.

Lisp. Kto wie co to jest, ręka w górę. Kto lubi ten język? No cóż, raczej po tym pytaniu lasu rąk nie uświadczymy. Są jednak takie dziwne typki, które lubią sobie życie komplikować.
Syrup to nic innego, jak parser. Kolejna nakładka, oparta na CoffeScript.
Ma to jakieś plusy. Co raz bardziej Lispowa składnia. W planach jest współpraca z Node.js i przepisanie kompilatora / parsera.
Czy to jakaś alternatywa? Może, choć nie teraz. Na razie warto się tym pobawić. To nie boli.
Przy okazji pozwolę sobie na 2 rzeczy.
Po pierwsze przykład fib = fn: [n] calc-fib = fn: [n a b] print: "Fib:", n a b if: (n == 0) a calc-fib: (n - 1) b (a + b) calc-fib: n 0 1 print: fib: 10 Ten krótki kod liczy kolejne liczby w ciągu Fibonacciego.
Druga sprawa: jeśli naprawdę lubicie Lispową składnię, i tryliardy nawiasów to Syrup może nie być lekiem na wasze bóle. Są lepsze i gorsze opcję.
Polecam zapoznanie się z Clojurescriptem, ParentScriptem LispyScriptem. A jeśli na prawdę chcecie się zapoznać z Lispowym wersjami JS polecam ten post na jesdnym z akregatorów treści --> HackerNews.
Nie będę się nad tym tu rozwodzić. Te kompilatory mogą być fajną zabawką, lub ciekawą alternatywą. Ale idźmy dalej. Oto....

Coś co alternatywą może być...

Mowa tu o dość mało znanym, acz w/g mnie bardzo ciekawym kawałku zupełnie darmowego kodu, który sporo może. Nazwa jego brzmi - Haxe.
Po mimo tej nazwy, to nie jest język Haker Friendly. Haxe jest całkiem przyjemny, ma własny język, można go kompilować do JS, na telefony z Androidem, do C/C++. Jest właściwie do wszystkiego, ale czy na pewno. Do wszystkiego, to jak znane porzekadło pszczół mówi, do niczego. Składniowo przypomina trochę ActionScript3 lub Javę/ C#. Dla fanów tych języków super. Dla reszty pewnie też. Warto go poznać. To kawałeczek kodu, zwykły alert znany wszystkim Zielonym Beretom JS, zawierający po kompilacji URL naszej strony.

class Test { static function main() { js.Lib.alert(js.Lib.window.location.href); } }

Haxe zapewnia całkiem przyjemne tworzenie stron w technologii Flash.
Czy może się wam przydać?
Pewnie tak, ale jako ciekawostka, wstęp. Możliwości są spore, ale suport ze strony firm marny. Szukając czegoś z poparciem warto zerknąć też na inne języki.
Może z nie tak różną składnią, ale nadal przydatne.

Googlowy DartNo-namowy OpaA co ja będę się tu wypisywał.

Długa i w miarę świeża lista języków kompilowanych do JS.

Link

Kończąc ten nudny i przydługi wpis

Pragnę podziękować tym, którzy przetrwali cały wpis. Pragnę też wyjaśnić skąd taki, a nie inny wybór.
Wybierałem najciekawsze języki stworzone, by pomóc devom.
Pominąłem przydatny GWT - gdyż to m.in. Java, która najładniejszym językiem nie jest również.
Darta też nie opisałem, bo efekt kompilacji Dart do JS, nawet w wypadku Hello Worlda, to gigantyczny plik, jak poprawią go to go opiszę.
Nie ma również Flasha, czy NaCl. Dlaczego, bo są ograniczone, stanowią raczej powrót do czasu Webu zamkniętego niż do otwartego webu przyszłości.
Amber, Pyjamas i inne ominąłem. Może w przyszłości.

PS. Wszelki flejm mile widziany (oczywiście ten konstruktywny, poparty argumentami). Zapominam się, konstruktywny flejm to nie flejm.

PPS. Może wy kojarzyć coś ciekawego z takich kombinacji.

A na razie żegnam i dziękuje za uwagę.

* Nazwanie Notepada edytorem dla programisty, to jak nazwanie Painta namiastką Photoshopa.  

internet programowanie inne

Komentarze

0 nowych
Mifczu   12 #1 25.09.2012 14:41

JavaScript to niestety standard dla kogoś kto chce pisać jakieś serwisy Internetowe. Pisanie w czymś zupełnie innym i kompilowanie tego do JS w moim odczuciu nie ma sensu. Twój przykład "rozbudowanego" kodu JavaScript jest sporo nadmiarowy. Sam fakt szukania innego języka którego i tak trzeba się nauczyć by przekompilować go do JS jest głupie. Jedyne uzasadnienie to pokazanie, że się da ;) Debugowanie go będzie masakryczne a i tak zmusi nas do poznania JS.

Nie bójmy się JavaScriptu on nie gryzie i obok swoich wad ma sporo zalet.

Olej   4 #2 25.09.2012 14:46

Jestem zmuszeni czy nie jestem zmuszeni o to jest pytani!

  #3 25.09.2012 15:11

Polecam poczytać więcej o Dart, to język z potężnymi możliwościami - łączy w sobie to co najlepsze we wszystkich innych i był od podstaw projektowany z myślą o webie. I jeżeli byś się martwił, że tylko jedna przeglądarka go natywnie obsługuje to powiem, że dart można bez problemu "kompilować" do JS. Jakbyś chciał doczytać: http://www.dartlang.org/

  #4 25.09.2012 15:29

Zastanawiam się, do kogo kierowany jest ten tekst...

Kto pisze klasy w JS i po kij? Kto używa JS jako języka rozbudowanej aplikacji? Zgaduję, że 99,99999 użytkowników JS to webmasterzy, którzy są zapewne dalecy od deklarowania w tym języku klas, że o dziedziczeniu nie wspomnę.

Druga sprawa, że dla ludzi starej daty (którzy znają "stare" języki programowania), to właśnie CS jest makabrycznie nieczytelny i przypomina mi pseudojęzyki używane w programach edukacyjnych dla dzieci.

Trzecia sprawa, że CS jest podobną bzdurą jak SMARTY - aby dobrze w nim programować i tak trzeba znać język "omijany" (PHP w przypadku Smarty, tutaj JS).
Przykładowo taki jQuery rzeczywiście skraca zapis niektórych operacji i dostarcza nowych metod - spróbuj w czystym JS zmienić atrybuty wszystkich elementów na stronie posiadających daną klasę.

Tutaj (w CS) natomiast w przypadku prostego kodu (przykład z klasami obiektów i dziedziczeniem jest wg mnie bezużyteczny w codziennym życiu) pisanie sprowadza się do zastępowania znanych wszystkim zasad i słów kluczowych przez inne, które spełniają dokładnie tą samą funkcję. Jak ktoś programuje od lat, to zapis proponowany przez CS jest po prostu nieczytelny i nielogiczny. Przyzwyczajenie to druga natura człowieka i jak już człowiek ma pewne nawyki, wyuczone konstrukcje kodu które może pisać nie używając przy tym świadomości, to nie będzie się uczył czegoś, co wywraca wyuczone zasady do góry nogami.

Nigdy nie byłem fanem JS i nie lubię go, ale używam go gdyż nikt jeszcze nie wymyślił języka mogącego go zastąpić - tzn pewnie jest kilka języków lepszych składniowo, ale obecnie tylko JS działa praktycznie pod każdą przeglądarką i posiada szerokie wsparcie w środowisku deweloperów.

Demagog   4 #5 25.09.2012 15:29

Nic nas nie broni, by poznać coś nowego. Wpis i przykłady są dla ludzi znających już JS, a którzy kosztem nauki chcą poprawić swoje możliwości.

budda86   9 #6 25.09.2012 15:45

Podtrzymuję swoją opinię z komentarza do poprzedniego wpisu - to nie język jest do niczego, tylko niektórzy programiści. W każdym języku można napisać kod zły, nieczytelny i zbyt rozbudowany. W JS takiego złego kodu powstaje dużo dlatego, że jest popularny, zresztą to samo dotyczy php. Tylko co z tego?

Moim skromnym zdaniem ocena języków programowania na podstawie tego, czy Tobie podoba się kawałek kodu napisany w tym języku, jest co najmniej dziecinna. Język programowaina to znacznie więcej, niż subiektywne odczucia estettyczne dotyczace składni i okolic.

Mifczu   12 #7 25.09.2012 15:59

@Demagog ale przykłady są nieuczciwe :) Bo to coś co wygląda brzydko w JS nigdy nie jest tak pisane. Wiele powtórzeń kodu by na siłę udowodnić, że czysty JS jest brzydki a CoffeeScript nie. Kompletnie bez sensu. Jak robić o czymś wpis na blogu to rób to uczciwie. Takie wpisy mogą być opiniotwórcze i ktoś kto się dopiero uczy może na starcie odebrać mylne wrażenie, że faktycznie CS to same zalety bo naprawia brzydkiego JS. A dobrze wiadomo, że tak nie jest.

iluzion   5 #8 25.09.2012 17:24

Jak to zwykle bywa, CoffeeScript rozwiązuje część problemów JS, dodaje kilka swoich, ale mimo wszystko jest fajny i zapowiada się ciekawie.

Są tacy, którzy nie wierzą w sukces CoffeeScript i mają silne argumenty, ale są też tacy którzy pokładają w nim spore nadzieje i robią z niego użytek już teraz. Np. Dropbox obecnie migruje (albo już to zrobił) z JavaScript na CoffeeScript. Polecam przeczytać relację z tej operacji ;)

https://tech.dropbox.com/?p=361
http://osworld.pl/dropbox-migruje-z-javascript-na-coffeescript/

Warto też sprawdzić wymieniony w tekście js2coffee http://js2coffee.org/.

Kojarzy ktoś generator statycznych stron internetowych Wintersmith? http://jnordberg.github.com/wintersmith/ Też jest w CoffeeScript napisany. Przykładów pewnie jest sporo, ale nie śledzę tego tematu, więc więcej nie podam.

mikolaj_s   14 #9 25.09.2012 18:17

@Obserwator_911:
"Kto pisze klasy w JS i po kij? Kto używa JS jako języka rozbudowanej aplikacji? Zgaduję, że 99,99999 użytkowników JS to webmasterzy, którzy są zapewne dalecy od deklarowania w tym języku klas, że o dziedziczeniu nie wspomnę. "

Każdy szanujący swój czas i innych pisze klasy w JS. Pisanie obiektowe nie jest aż tak bardzo trudne w JS, choć nie tak wygodne jak w innych językach. Ale znacznie ułatwia modyfikację i utrzymanie kodu.

@Demagog :
Moim zdaniem CoffeeScript jest dużą wygodniejszym językiem. Może kiedyś będzie natywnie obsługiwany przez przeglądarki ;) Osobiście chętnie bym z niego korzystał, ale musiałby go wspierać używany przeze mnie framework.
Dropbox chwiali się, że przepisał swoją stronę na CoffeeScript i zajmuje o 1/3 mniej linii, tym nie można pogardzić.

Draqun   9 #10 25.09.2012 21:33

@Demagog
"Na starcie pragnę podkreślić iż dopiero co swą karierę z programowanie lub jak kto woli skryptowaniem zaczynam i w wielu kwestiach jestem zielony, jak szczypiorek na wiosnę (lub Irlandia w/g pana Tuska)."

Pozwoliłem sobie przytoczyć twoje słowa z poprzedniego wpisu. Nie pochwaliłeś się znajomością innych języków, coś wspominasz o Pythonie i Ruby(którego przyznam się nie tykałem) co jest podstawą twierdzenia przeze mnie, że masz niewielkie doświadczenie (blisko mojego ;)).

Jeśli potrafisz programować w Pythonie spójrz
http://pl.wikipedia.org/wiki/Python#Struktura_przez_wci.C4.99cia <-czym twoim zdaniem różną się te dwa fragmenty kodu? Jeden stosuje wcięcia a drugi nawiasy. Jeśli przyzwyczaisz się tylko do tej drobnej różnicy (i kilku innych) to nie zrobi ci różnicy, którego języka będziesz używac bo to tylko narzędzie.

Przypomnę jeszcze, że języki które podałeś stoją na granicy ciekawostek a pracy dla garstki osób. Taki JS, Java, C, C++, PHP czy C# mają bardzo podobną składnie i klasują się w czołówce używanych języków. Teraz pomyśl. Uczysz się jednego z powyższych i nauka pozostałych to tylko kwestia nauki nazw funkcji (ew OOP gdy zaczynałeś jak ja od C). Wszystko jest unormowane. Bloki kodu są widoczne i łatwo je odnaleźć. Dodatkowo żaden z tych języków nie narzuca nam stylu pisania jak to mamy w Pythonie, co nie dla wszystkich jest zaletą, bo słabi programiści zaciemniają kod.


Dodam jeszcze, że jeśli nieodpowiednia osoba bierze się za programowanie to można dać jej świetne narzędzie a ona i tak napisze to syfiasto.

Autor edytował komentarz.
Comandeer   1 #11 25.09.2012 23:22

@Obserwator_911, JS bez obiektówki jest trochę nie bardzo. Zważając na fakt, że tam wszystko jest obiektem, to naturalne jest pisać obiektowo ;)
@mikolaj_s, kompilowanie z CS (cukru składniowego? ;)) do JS jest śmieszne. Co z tego, że kod jest 1/3 krótszy? A czy jest wydajniejszy? Raczej nie. Nie dość, że jest przerabiany na JS, to jeszcze później trzeba ten JS wykonać
@Maurycy, Dart to JS podany jako Java. Niestrawny dla większości. A jego kompilacja do JS... No cóż, kod jest po prostu monstrualny :D
@Demagog, Haxe umie bez zająknięcia wypluć kod, który można po prostu wywalić przez okno. A twoje przykłady "brzydkiego" JS... Crockford by cię zabił ;) Nie znam chyba żadnego programisty JS, który uprawiałby hoisting. Poza tym przykład z wyciąganiem wartości pól formularza można ładniej napisać. Ba, tym bardziej, że stosujesz tam jQ (pomijając fakt, że twój przykład i tak nie działa...). Moja wersja?
var results=[]; $('input').each(function() {results.push(this.value);});
Raptem trochu dłuższe niż CS. A bez jQ coś takiego:
var results, e=document.querySelectorAll('input'),i=e.length; while(i--) results.push(e[i].value);
Wciąż krótkie i zwięzłe
O przykładzie z prototypami powiem tak: po prostu się pisze funkcję do dziediczenia i problemu ni ma :)

Mifczu   12 #12 26.09.2012 08:18

JavaScript ma ten problem, że ma niski poziom wejścia. Czyli aby napisać proste zdarzenie nie trzeba znać jakoś bardzo dobrze tego języka. Problem zaczyna się gdy chce się napisać coś bardziej poważnego tu jak ktoś nie ma większej wiedzy szybko się pogubi. Dla osób które nie bardzo czują się w programowaniu obiektowym itp jest pełno frameworków lepszych lub gorszych które wymagają min. znajomości języka lub praktycznie w ogóle dla standardowych komponentów.

Ale nie oszukujmy się, jeżeli chcemy robić coś dobrze i na poważnie to język w którym chcemy to robić też powinniśmy znać dobrze i na poważnie. ;)

  #13 26.09.2012 11:28

@mikolaj_s & @Comandeer:
Zrobiłem już kilka rozbudowanych stron (wprawdzie bez rozbudowanych akcji po stronie użytkownika) ze sporą ilością kodu JS i jakoś nigdy nie miałem potrzeby definiowania swoich klas (a przynajmniej nie kojarzę takiej w tym momencie).
Zazwyczaj używa się klas już zdefiniowanych (a właściwie obiektów DOM) i obsługuje się je poprzez jQuery. Ostatecznie obiekty spotkałem jedynie w mapach Google, lecz one już tam są zdefiniowane - nie miałem potrzeby wymyślać struktury klasy.
Generalnie proste rzeczy robi się prosto. Do wszystkiego bardziej skomplikowanego klasy i całe biblioteki zostały już napisane, więc ich użycie sprowadza się do utworzenia obiektu i używania jego funkcji.
Reszta (czyli zdecydowana większość) stron to proste strony, na których JS można ograniczyć do podmiany obrazków czy innych prostych efektów wizualnych. Dla leniwych jest nawet jQuery.Cycle (z możliwością konfiguracji) i setki innych bibliotek opartych właśnie na JS/jQ, które mają ogromne możliwości. Nawet generowanie obrazków w odcieniach szarości (na canvas) na podstawie obrazka JPG/PNG nie wymaga klepania klas. Całość jQ i bibliotek dodatkowych jest na tyle obszerna i spójna, iż używanie czegoś takiego jak CS jest bezsensowne.

Tak, jak napisał ktoś wyżej - jak znasz C/C++/PHP (a ten ostatni wypada znać zabierając się za strony) to CS jest zupełnie zbędny i niepotrzebne komplikuje sprawy oczywiste, psuje wyrobione nawyki.

Comandeer   1 #14 26.09.2012 14:25

@Obserwator_911, owszem przy małych stronach pisanie obiektowe może być armatą na muchę, ale przy większych projektach nie wyobrażam sobie klupania kodu bez jakiegoś rozsądnego rozrzucenia tego po klasach. Każdy większy projekt JS-owy zaczyna przypominać rozgotowany makaron wówczas ;)
Dla przykładu: http://comandeer.w-mod.pl/windows/
Ot, taki mój mały projekcik GUI, w fazie prealpha ;) Stwierdziłem sobie, że przecież każdy element jest przeciągalny itd. Zatem stworzyłem sobie podstawową klasę Element: http://comandeer.w-mod.pl/windows/js/gui/elements.js jest porażająco prosta i zawiera tylko kilka funkcji ;) A od niej dziedziczą wszystkie inne (nazwij sobie Element klasą abstrakcyjną ;)): Window, Dialog, InneBędąceWPlanie. Jak dla mnie taki podział jest jak najbardziej logiczny.
Ty mówisz głównie o JS w kontekście przeglądarki i głównie o jQuery. Ja natomiast nie rozpatruję JS jako język efektów specjalnych w przeglądarce (tak, jQuery, o tobie mowa), lecz jako dość potężny język szerokiego zastosowania. Osobiście używam node.js i wiem, że jak się trochu nad nim siądzie - znając JS (JS, nie jQ, bo coraz więcej "programistów JS" zna tylko tą bibliotekę) - można osiągnąć takie same efekty jak przy użyciu PHP i jego potężnej biblioteki standardowej. A w node.js bez klas można się szybko zatracić ;)
I zanim ktoś mi zarzuci hipokryzję, że jeżdżę po jQ, a sam używam ;) Używam, bo chyba nie ma wygodniejszego wrappera na DOM (nie licząc chainvasa ;)), ale gdyby ktoś mi powiedział, że mam zakaz używania jQ, byłbym w stanie samemu napisać sobie alternatywę ;)

Demagog   4 #15 26.09.2012 18:58

No cóż przyznaje bez bicia. Moja wiedza jest marna. Przykłady też dość stronnicze, bo ze strony CS.
Ale, każda pliszka swój ogonek chwali.

Dla ludzi, którzy uważają, że JS wystarczy, dla nich jest pierwszy akapit.
Może, jak chwile czasu znajdę walnę w Rubym jakiś parserek dokumentacji.
@Comandeer mimo, że twój elements.js jest całkiem prosty i schludny, to przy czymś ciut większym choćby po DP mozna dojść do wniosku, że (okiem zielonego rzecz jasna), że składni brakuje na czytelności, co jest dość dziwne, jak na język full obiektowy.

Właśnie dla tego pojawił się opis problemu młotka i gwoździa.
Dokumentowanie kodu plus jakieś drobiazgi po stronie serwera w CS to całkiem nie zły młotek.
O to też chodziło z pseudorozwiązaniami i tym co rozwiązaniem nie jest.

Może w cz. 3 pojawi się cos nowego.

Comandeer   1 #16 26.09.2012 21:42

@Demagog, ależ DP to nie jest aplikacja webowa, a zwykła strona. ;) Poza tym - zarzuć przykładem co tu jest nieczytelne (bo możliwe, że ja już mam niezłe zboczenie JS-owe i dla mnie każdy kawałek jest strawny :D). Dla mnie osobiście składnia Rubiego jest mniej strawna niż JS (chociaż i tu i tu można z liczby zrobić obiekt ;))
A dokumentowanie kodu... Dobrze napisany kod w dużej części sam się dokumentuje, a dopisanie kilku komentarzy nie sprawia problemu. A jak będę chciał coś lepszego, napiszę moduł do node.js w czystym JS i se zrobię wyciąganie komentów i nazw parametrów z funkcji i tyle :) żaden problem

mikolaj_s   14 #17 26.09.2012 22:07

@Obserwator_911: "Zrobiłem już kilka rozbudowanych stron (wprawdzie bez rozbudowanych akcji po stronie użytkownika) ze sporą ilością kodu JS i jakoś nigdy nie miałem potrzeby definiowania swoich klas (a przynajmniej nie kojarzę takiej w tym momencie). "

Przyznam się, że jeszcze do niedawna sam nie pisałem obiektowo. Ale jak musiałem poprawiać kod po roku nie rozwijania projektu, to od razu pojąłem, że muszę go poprawić przepisując obiektowo. Oczywiście dotyczy to sytuacji gdy kod składa się z więcej niż dwóch czy trzech funkcji.
Niezłym rozwiązaniem, może być użycie Backbone.

adiom   3 #18 02.10.2012 22:56

@Mifczu "JavaScript to niestety standard dla kogoś kto chce pisać jakieś serwisy Internetowe. Pisanie w czymś zupełnie innym i kompilowanie tego do JS w moim odczuciu nie ma sensu."

To wedlug Ciebie nie ma sensu. Ale prawda jest taka ze js mozna spokojnie ominac, i znac tylko podstawy, bez wdawania sie w jakies ciezkie biblioteki.....
Pierwszy z brzegu przykład to Dorpbox, cały kod przeniesli na CS i stwierdzili ze jest wygodniej, wdodatku zmniejszyli ilosc kodu...
Bardzo wiele aplikacji internetowych typu RIA, szczegolnie tych duzych i zlozonych gdzie w backendzie odwolujemy sie do innego jezyka jak java pisze sie wlasnie w GWT. GWT jest kompilowane do js i oprócz tego od wersji 2.5 przepuscic go mozemy przez closure-compiler co bardzo wydajne i gwarantuje ze nie dasz rady napisac w czystym js bardziej wydajnie...
To samo g+ jest robiony w closure (znacznie wygodniejszy niz js) ..

A dla lubiacych phyton : mozna zerknac na projekt http://pyjs.org/ gdzie jest port GWT.

A jesli sie pisac chce o wadach js to imo wada nie jest skladnia, (no chyba ze ktos jest fanem skladni phytona ) a wydajnosc i pewne braki jakie ma do tej pory i inne (coprawda czesc niedawno uzupelniono).

Comandeer   1 #19 03.10.2012 18:05

@adiom, AFAIR to co daje GWT to już skompilowany i przepuszczony przez gcc JS. a CS najczęściej spotkać można jako na żywca kompilowany język w browserze. jak myślisz - co jest wydajniejsze? ;)
"stwierdzili ze jest wygodniej"
a ja od dawna piszę w JS i nie mogę znieść widoku czegoś takiego jak class ;) istnieją prototypy i fajnie. wygoda zależy od programisty. jedni wolą JS, drudzy Javę. i niech se nawet piszą w tym CS czy Typescript, ale niech to będzie kompilowane przed wrzuceniem do Sieci, a nie - jak często widzę - kompilowane na szybko w przeglądarce. bo to się mija z celem. a jak piszesz sobie w tym, kompilujesz itd. to raczej wówczas będziemy mieć narzędzie typu LESS, Stylus dla CSS - czyli nie zamiennik, a pomocnik ;)
"przepuscic go mozemy przez closure-compiler co bardzo wydajne i gwarantuje ze nie dasz rady napisac w czystym js bardziej wydajnie.."
a co wyrzuca gcc jak nie czysty JS? a jego zasady kompresji kodu wymyślili przecież ludzie. ergo - da się
"pewne braki jakie ma do tej pory"
tzn? brak typowych klas i tego typu rzeczy? po prostu nie są potrzebne. i mam nadzieję, że class z ES6 umrze, bo... to już nie będzie JS ;)

adiom   3 #20 03.10.2012 23:24

@Comandeer "AFAIR to co daje GWT to już skompilowany i przepuszczony przez gcc JS"
Nie do końca. Kod Java od strony klienta jest kompilowany przez JVM i przez narzedzia gwt tłumaczony do kilku wersji JS w zaleznosci od przegladarki (lub dodatkowo od innych rzeczy w zaleznosci jak ustawisz plik gwt.xml ). Natomiast teraz ten koncowy kod js (ktory był wynikiem gwt) mozna opcjonalnie przepuścić jeszcze przez gcc. https://developers.google.com/web-toolkit/doc/latest/ReleaseNotes#optimization
Takze teraz kod jest optymalizowany podwójnie...

Co do CS to Ci nie odpowiem bo nie wiem. Nie znam szczegółów, nie widziałem żadnych testów wydajnościowych etc. Wiem tylko tyle ze pisanie w CS duzych aplikacji jest wygodniejsze niz w js. Oczywiście zgadzam się tez ze to zależy od piszącego i co kto lubi.... Ale CS jest bardziej objektowo zorientowany, i wielu devow od Javy wybrali by bardziej CS niz js (w tym ja ale tylko ze wzgledu na skladnie i upodobania, a nie na wydajnosc)....

" a jego zasady kompresji kodu wymyślili przecież ludzie. ergo - da się "
Owszem da się. Ale jak piszesz kod to na ogół jest on human friendly, a nie machine friendly. Dopiero kod po skompilowaniu jest machine friendly. Jest to właśnie ta szczególna przewaga języków kompilowanych nad skryptowymi .... N dowód wejdz sobie na http://closure-compiler.appspot.com/home wstaw wiekszy skrypt dodaj w opcjach Advanced i skompiluj ... na pewno nie chciałby Ci się az tak optymalizować kodu żeby wyglądał jak po prawej stronie... A przy większych aplikacjach ta kompilacja ma znaczenie w wydajnosci.

"tzn? brak typowych klas i tego typu rzeczy?"
Nie tylko. Chodzi mi o to że wydajnosc tez zależy wiele od składni języka. Gdyby js posiadało w składni mozliwosc silnego typowania (tak jak Dart) , lub pare innch rzeczy - silniki przegladarek mogłyby wydajniej go interpretować... Nie mówie od razu zmieniać język na silnie typowany, bo tak sie nie da, ale rozbudować to jako opcje. Dzieki temu mozna było by pisać duzo wydajniejsze biblioteki w js ...

A co do klas i polimorfizmu i typow generycznych etc, to fakt nie sa potrzebne jak sie przerzuca sporą część logiki aplikacji na strone serwera..... Ale kiedy chcemy umieścić logike po stronie klienta - te wszystkie rzeczy cholernie się przydają ... dla mnie sa one nawet niezastapione...

Comandeer   1 #21 09.10.2012 21:13

@adiom
"przez narzedzia gwt tłumaczony do kilku wersji JS w zaleznosci od przegladarki"
brzmi co najmniej dziwnie ;) rozumiem, że IE dostaje swoją wersję?
" to fakt nie sa potrzebne jak sie przerzuca sporą część logiki aplikacji na strone serwera."
owszem, przerzucam, ale na serwerze stoi... node.js ;) uwierz mi, że przy prototypach w JS da się stworzyć dużo konstrukcji z języków OOP (choćby z PHP - wiem, nienajlepszy przykład, ale zawsze ;)), np. traits - apply/call
" na pewno nie chciałby Ci się az tak optymalizować kodu"
owszem, ale da się, a o to stwierdzenie przecież chodziło ;)
" Gdyby js posiadało w składni mozliwosc silnego typowania"
IMO to pasuje do języka kompilowanego, a nie interpretowanego na żywca. Nie wyobrażam sobie JS ze statycznym typowaniem (makabra...), ale... są hacki na to ;) https://github.com/LeaVerou/StronglyTyped

adiom   3 #22 13.10.2012 23:30

"brzmi co najmniej dziwnie ;) rozumiem, że IE dostaje swoją wersję? "
Tak IE ma swoja wersje.. A dlaczego dziwnie?
W skrócie to wyglada tak: najpierw podaje sie w pliku html podstawowy i lekki skrypt nazwa.nocache.js (on oczywiscie jest tez generowany przez gwt) ten skrypt wykrywa wersje przegladarki i inne rzeczy i odrazu pobiera odpowiednia wersje hash.cache.html do odpowiedniej wersji ... Tak samo mozna zrobic z wersjami mobilnymi na androida i ios...

"Nie wyobrażam sobie JS ze statycznym typowaniem (makabra...),"
Ja tez. To całe uproszczenie i dynamika to zaleta js. I normalnie powinno sie pisac jak teraz, ale biblioteki i inne juz mona bardziej wtedy optymalizowac gdy uzywa sie statycznych typow, ma sie tez lepsza kontrole nad wszystkim.... A tak pozatym to silne typowanie nie przeszkadza tak bardzo jak sie uzywa polimorfizmu i typow generycznych. Bez tego Java bylaby strasznie nie wygodna... dlatego w js trzeba byloby wymyśleć cos podobnego ... ale takie zmiany nie przejda przez standardy...

Comandeer   1 #23 14.10.2012 19:36

"Tak IE ma swoja wersje.. A dlaczego dziwnie? "
bo to wygląda jakby GWT robił typowy browser sniffing, co jest bardzo złym pomysłem na dłuższą metę. weźmy takiego firefoxa z dodatkiem Live HTTP Headers. Będę się przedstawiał jako IE 5 na iOS 7 - ciekawi mnie co mi pośle GWT ;) jeśli jednak robi feature detection, to zwrócę mu wówczas honor ;)

  #24 05.04.2013 17:47

Witam !
Nie wiem, czy powinnam tu pytać, o komputerze wiem tyle, żeby na nim pisać.
Mam problem z rozszerzeniem .json, tak zapisują mi się automatycznienp. zakładki, a nie mam czym ich otworzyć. Ostatnio utraciłam wszystkie zakładki, a dużo było ważnych (praca). Są zapisane z rozszerzeniem json. Czy i gdzie mogę to coś bezpiecznie ściągnąć?

I jeszcze coś: mam kilka kart, których nie zamykam, żeby móc porównać stan poprzedni z obecnym. Od ok, tygodnia zamiast ustawianej na okrągło jako tytułowej strony yahoo, pojawia mi się firefox, małpa i jeszcze 2 wynalazki, a opcja przywracania zamkniętych kart jest nieaktywna. Zaczęło się to ok. tydzień temu razem z wpychającym się na chama przy starcie firefoxem, greasemonkey, googlami i jeszcze jakąś bzdurą. Nie wiem, jak się pozbyć tych nachalnych 4 stron zamiast Mein Yahooi jak otworzyć zapisane zakładki (bookmarks?) z dziadowskim rozszerzeniem .json. Aha: u mnie wszystko z konieszności jest ustawione po niemiecku, więc mam wszędzie groch z kapustą: większość rzeczy po niemiecku, pojedyncze po polsku i do tego jeszcze w całkiem obcym nachalnym języku wyspiarzy...

Błagam o pomoc !

aorg1961

  #25 05.04.2013 17:49

I jeszcze jedno: tej karty też wolę nie zamykać, bo potem mogę jej nie znaleźć :)