W tej chwili jedynym w pełni obsługiwanym językiem i de facto standardem manipulacji drzewem DOM w przeglądarce jest JavaScript. Wygląda na to, że ma poważne problemy projektowe, które sprawiają, że jest to pole minowe błędów i luk w zabezpieczeniach dla nowicjusza.

Czy znasz jakąś istniejącą lub planowaną inicjatywę wprowadzenia lepszego (przeprojektowanego) języka dowolnego rodzaju (nie tylko javascript) do manipulacji drzewem DOM i żądań HTTP w przeglądarkach nowej generacji? Jeśli tak, jaki jest plan jego integracji z, powiedzmy, Firefoksem, a jeśli nie, z jakich powodów (poza interoperacyjnością) powinien być jedynym obsługiwanym językiem na platformie przeglądarki?

Korzystałem już z jQuery i przeczytałem też "javascript: dobre części". Rzeczywiście sugestie są dobre, ale nie jestem w stanie zrozumieć: dlaczego tylko javascript? Po stronie serwera (platforma Twojego ulubionego systemu operacyjnego) możemy manipulować drzewem DOM w każdym języku, nawet w języku fortran. Dlaczego strona klienta (platforma przeglądarki) obsługuje tylko javascript?

Problem z javascriptem nie polega na samym języku - to doskonale prototypowany i dynamiczny język. Jeśli pochodzisz z wykształcenia OO, jest trochę krzywej uczenia się, ale nie jest to wina języka.

Większość ludzi zakłada, że ​​Javascript jest podobny do Java, ponieważ ma podobną składnię i podobną nazwę, ale w rzeczywistości bardziej przypomina lisp. Właściwie całkiem dobrze nadaje się do manipulacji DOM.

Prawdziwym problemem jest to, że jest kompilowany przez przeglądarkę, a to oznacza, że ​​działa w bardzo różny sposób w zależności od klienta.

Nie tylko rzeczywisty DOM różni się w zależności od przeglądarki, ale istnieje ogromna różnica w wydajności i układzie.

Edytuj następujące wyjaśnienie

Załóżmy, że obsługiwanych jest wiele języków tłumaczonych - nadal masz te same problemy. Różne przeglądarki nadal byłyby wadliwe i miały różne DOM.

Ponadto musiałbyś mieć interpreter wbudowany w przeglądarkę lub w jakiś sposób zainstalowany jako wtyczkę (którą możesz sprawdzić przed wyświetleniem strony) dla każdego języka. Ujednolicenie języka JavaScript zajęło wieki.

Nie możesz używać języków kompilowanych w ten sam sposób - wtedy wprowadzasz plik wykonywalny, którego nie można łatwo zbadać pod kątem tego, co robi. Wielu użytkowników nie pozwoliłoby mu działać.

OK, a co z jakąś piaskownicą dla skompilowanego kodu? Brzmi jak aplety Java. Lub ActionScript we Flashu. Lub C # w Silverlight.

A co z jakimś standardem IL? To ma większy potencjał. Opracuj w dowolnym języku, a następnie skompiluj go do IL, który przeglądarka następnie JIT.

Z wyjątkiem tego, że Javascript jest już tym IL - wystarczy spojrzeć na GWT . Pozwala pisać programy w Javie, ale rozprowadzać je jako HTML i JS.

Edytuj po dalszych wyjaśnieniach

Javascript nie jest, a raczej nie był, jedynym językiem obsługiwanym przez przeglądarki: w ciemnych epokach Internet Explorera można było wybierać między Javascriptem a VBScriptem do uruchamiania w IE. Technicznie rzecz biorąc, IE nawet nie uruchamiał Javascript - uruchamiał JScript (głównie w celu uniknięcia konieczności płacenia firmie Sun za słowo java , Oracle nadal posiada nazwę Javascript ).

Problem polegał na tym, że VBScript był własnością Microsoftu, ale także po prostu nie był zbyt dobry. Podczas gdy JavaScript dodawał funkcjonalność i uzyskiwał najlepsze narzędzia do debugowania w innych przeglądarkach (takich jak FireBug), VBScript pozostał tylko dla IE i praktycznie nie można go było debugować (narzędzia deweloperskie w IE4 / 5/6 nie istniały). W międzyczasie VBScript również się rozwinął, stając się całkiem potężnym narzędziem do tworzenia skryptów w systemie operacyjnym, ale żadna z tych funkcji nie była dostępna w przeglądarce (a kiedy były, stały się ogromnymi lukami w zabezpieczeniach).

Wciąż istnieją korporacyjne aplikacje wewnętrzne, które używają VBScript (a niektóre opierają się na tych lukach w zabezpieczeniach) i nadal działają z IE7 (zatrzymały IE6 tylko dlatego, że MS w końcu go zabiło).

Przywrócenie JavaScript do jego obecnego stanu było koszmarem i zajęło 20 lat. Wciąż nie ma spójnego wsparcia, z funkcjami językowymi (określonymi w 1999 r.) Wciąż brakuje niektórych przeglądarek i wymaganych jest wiele podkładek.

Dodanie alternatywnego języka do tłumaczenia w przeglądarkach wiąże się z dwoma głównymi problemami:

• Skłonienie wszystkich dostawców przeglądarek do wdrożenia nowego standardu językowego - coś, czego wciąż nie zarządzali w Javascript od 20 lat.

• Drugi język potencjalnie osłabia wsparcie, które już masz, pozwalając (na przykład) IE na obsługę JavaScript drugiej klasy, ale świetny VBScript (ponownie). Naprawdę nie chcę pisać kodu w różnych językach dla różnych przeglądarek.

Należy zauważyć, że Javascript nie jest „skończony” - wciąż ewoluuje, aby stać się lepszym w nowych przeglądarkach. Najnowsza wersja jest rok przed wdrożeń przeglądarek, a oni pracują na następny.

Skompiluj do Javascript

Na razie używanie języka, który kompiluje się do Javascript wydaje się być jedynym realistycznym sposobem dotarcia do wszystkich platform podczas pisania inteligentniejszego kodu i prawdopodobnie tak będzie przez długi czas. W przypadku każdej nowej oferty zawsze będzie jakiś powód, dla którego jeden lub więcej dostawców nie spieszy się z jej wysyłką.

(Ale nie sądzę, żeby to był problem. JavaScript został już ładnie zoptymalizowany. Kod maszynowy jest również niebezpieczny, jeśli jest napisany ręcznie, ale działa dobrze jako cel kompilacji i język wykonywania).

Tak wiele opcji

Istnieje stale rosnąca pula języków, które można kompilować do Javascript. Dość obszerną listę można znaleźć tutaj:

• Lista języków, które kompilują się do JS na Coffeescript Wiki

Godny uwagi

Wymienię kilka, które moim zdaniem są godne uwagi (bez wątpienia zaniedbując niektóre klejnoty, których nie jestem świadomy):

• Spider pojawił się w 2016 roku. Twierdzi, że czerpie najlepsze pomysły z Go, Swift, Pythona, C # i CoffeeScript. Nie jest bezpieczny, ale ma kilka drobnych zabezpieczeń .

• Elm : Haskell może być najmądrzejszym językiem z nich wszystkich, a Elm to wariant Haskell dla Javascript. Jest wysoce świadomy typów i zwięzły, i oferuje funkcjonalne programowanie reaktywne jako zgrabną alternatywę dla szablonów reaktywnych lub spaghetti MVC. Ale może to być szok dla programistów proceduralnych .

• Google's Go ma na celu zwięzłość, prostotę i bezpieczeństwo. Kod Go można skompilować do Javascript przez GopherJS .

• Dart to późniejsza próba zastąpienia JavaScript przez Google. Oferuje interfejsy i klasy abstrakcyjne za pomocą składni podobnej do C / Java z opcjonalnym wpisywaniem.

• Haxe jest podobny do ActionScript Flasha, ale może kierować reklamy na wiele języków, dzięki czemu Twój kod może być ponownie użyty w programach Java, C, Flash, PHP i Javascript. Oferuje bezpieczne i dynamiczne obiekty.

• Opalang dodaje cukier składniowy do Javascript, aby zapewnić bezpośredni dostęp do bazy danych , inteligentne kontynuacje, sprawdzanie typów i pomoc w separacji klient / serwer. (Powiązane z NodeJS i MongoDB).

• GorillaScript , „język kompilacji do JavaScript zaprojektowany, aby wzmocnić użytkownika i zapobiec niektórym typowym błędom”. jest podobny do Coffeescript, ale jest bardziej wszechstronny, zapewniając szereg dodatkowych funkcji zwiększających bezpieczeństwo i zmniejszających powtarzające się wzorce.

• LiteScript plasuje się gdzieś pomiędzy Coffeescript a GorillaScript. Oferuje składnię asynchroniczną / dochodową dla wywołań zwrotnych „wbudowanych” i sprawdza zmienne literówki.

• Microsoft TypeScript to mały nadzbiór Javascript, który pozwala na umieszczenie ograniczeń typu w argumentach funkcji, co może wyłapać kilka błędów. Podobnie BetterJS pozwala na stosowanie ograniczeń, ale w czystym Javascript, poprzez dodanie dodatkowych wywołań lub określenie typów w komentarzach JSDoc. A teraz Facebook zaoferował Flow, który dodatkowo przeprowadza wnioskowanie o typie.

• LiveScript to produkt uboczny Coffeescript, który był popularny ze względu na swoją zwięzłość, ale nie wygląda dla mnie zbyt czytelnie. Prawdopodobnie nie najlepszy dla drużyn.

Jak wybrać?

Przy wyborze alternatywnego języka, istnieje kilka czynników, które należy rozważyć :

• Jeśli inni programiści dołączą do Twojego projektu w przyszłości, ile czasu zajmie im przyspieszenie i nauczenie się tego języka lub jakie są szanse, że już go znają?

• Czy język ma zbyt mało funkcji (kod nadal będzie pełen schematu) lub zbyt wiele funkcji (opanowanie zajmie dużo czasu, a do tego czasu niektóre prawidłowe kody mogą być nieczytelne)?

• Czy ma funkcje potrzebne do Twojego projektu? (Czy Twój projekt wymaga sprawdzania typu i interfejsów? Czy potrzebuje inteligentnych kontynuacji, aby uniknąć piekła zagnieżdżonych wywołań zwrotnych? Czy istnieje duża reaktywność? Czy w przyszłości może być konieczne kierowanie na inne środowiska?)

Przyszłość...

Jeff Walker napisał skłaniającą do myślenia serię postów na blogu o „problemie z Javascriptem”, w tym dlaczego uważa, że ​​ani TypeScript , ani Dart, ani Coffeescript nie oferują odpowiednich rozwiązań. Na zakończenie sugeruje pewne pożądane cechy dla ulepszonego języka .

czy JavaScript powinien być jedynym obsługiwanym językiem na platformie przeglądarki?

Tak i nie. Istnieje alternatywa o nazwie Dart firmy Google, która kompiluje się do JavaScript i podobnie jak jQuery stara się nieco ułatwić manipulowanie DOM. Może fajnie byłoby poeksperymentować, sprawdź to.

• Z Google zobacz język rzutek
• W firmie Microsoft zobacz język TypeScript

Zobacz też

• Wiąz
• Kal

Prawdą jest, że w pewnym momencie Javascript był bardzo trudny do pokonania, ale społeczność programistów internetowych przeszła długą drogę. Zamiast tego zachęcałbym do przyjrzenia się jQuery . Jest to łatwe i usuwa wszystkie różne problemy.

I naprawdę nie ma alternatyw, które działałyby we wszystkich przypadkach. Przychodzi mi na myśl Flash, ale to też jest skrypt ECMA i prawdopodobnie w przypadku większości rzeczy jest przesadzony.

Krótko mówiąc, użyłbym rzeczy takich jak jQuery, aby ukryć niezgodności przeglądarki. W dłuższej perspektywie technologie takie jak Silverlight czy Adobe AIR mogą sprawić, że w przyszłości będzie to zupełnie inne pole minowe (ale wciąż pole minowe).

Doug Crockford wygłosił wykład dla Google, szczegółowo opisując złe i dobre strony JavaScript oraz jego przyszłość. Właściwie niewiele się zmieniło od 1999 roku - co można powiedzieć, że jest dobrą rzeczą (prawie wszystkie przeglądarki mogą uruchamiać ten sam kod, o ile jesteś świadomy ich ograniczeń), a Doug pokazuje, gdzie są dobre strony były przeważnie nieporozumieniami, które okazały się bardzo potężne.

Jeśli chodzi o manipulację DOM, spójrz na JQuery jako bibliotekę po stronie klienta, która zastępuje większość okropnego DOM API operacjami, których pisanie na dość eleganckich fragmentach kodu, które są łatwiejsze do napisania, jest trudne.

Jeśli myślisz, że JavaScript ma poważne problemy, polecam książkę Douga Crockforda, JavaScript: The Good Parts . (Lub Google dla „Crockford JavaScript”, aby znaleźć kilka prezentacji wideo, które wykonał). Crockford szkicuje bezpieczny podzbiór i zestaw praktyk, a konkretnie wymienia niektóre części języka, których należy unikać.

Nie jestem świadomy planów zastąpienia JavaScript jako de facto sposobu manipulowania DOM. Dlatego najlepiej naucz się go używać bezpiecznie i dobrze.

Z punktu widzenia klienta, JavaScript jest jedynym sposobem manipulowania DOM. Jeśli chodzi o stronę serwera, istnieje wiele sposobów.

Internet Explorer obsługuje podłączane języki skryptowe, chociaż jedynym niezawodnie dołączonym do IE oprócz JScript jest VBScript.

Z tego, co widziałem, wydaje się, że istnieje ogólny rodzaj uprzedzeń w stosunku do języków dynamicznych w przeglądarce, a JavaScript wydaje się wypełniać tę potrzebę na tyle wystarczająco, że efekty sieciowe sprawiają, że każdy inny język nie jest początkowy. Język jest właściwie dość potężny, chociaż jego implementacja w przeglądarkach pozostawia wiele do życzenia.

Jeśli chcesz ograniczyć swoich klientów / odwiedzających do określonych przeglądarek i prawdopodobnie chcesz wymagać od nich zainstalowania wtyczki, możesz spojrzeć na MS Silverlight - czytelny przegląd znajduje się na Wikipedii . Dzięki Silverlight 2 możesz uruchamiać po stronie klienta kod napisany w języku C #, IronPython, IronRuby, VB.NET itp .; darmowy klon Moonlight Silverlight, z projektu Mono, obiecuje przynieść tę samą funkcjonalność do Linuksa.

W praktyce większość twórców aplikacji i witryn internetowych woli dotrzeć do szerszej publiczności niż Silverlight (i ostatecznie Moonlight) jest obecnie w stanie dostarczyć - co oznacza trzymanie się Javascript lub prawdopodobnie Flasha (który używa podobnego języka programowania, Actionscript).

Tak więc zdobywanie znacznego zaangażowania, adopcji i trakcji dla czegokolwiek innego okazuje się żartobliwą walką nawet dla firmy Microsoft z jej dużymi grupami inżynierów i budżetami marketingowymi oraz projektem wolnego oprogramowania na boku (aby prawdopodobnie złagodzić obawy dotyczące zastrzeżonego ) - co może pomóc wyjaśnić, dlaczego jest bardzo małe zainteresowanie, np. ze strony Fundacji Mozilla, dążeniem do takiego celu. „Oprócz interoperacyjności”, mówisz: ale wyraźnie kwestia interoperacyjności jest tutaj najważniejsza, biorąc pod uwagę to, co obserwujemy w trakcie postępów Silverlight ...

Jak już powiedziano, masz Flash (ActionScript, który jest językiem pochodnym JavaScript) i Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #), które można uruchomić w przeglądarce za pomocą wtyczek (pierwszy jest znacznie bardziej wszechobecny) .

Istnieje również inna alternatywa, jeśli lubisz Ruby: HotRuby , jest to implementacja Ruby w javascript, która będzie działać w przeglądarce. Nie jest jeszcze bardzo dojrzałe, ale możesz się temu przyjrzeć.

Jedna rzecz, o której nie wspomniałem (och, widzę, że Alcides wspomniał o HotRuby, kiedy pisałem, a Nosredna wspomniała o GWT i Script #) i chciałbym wyrzucić, że istnieje wiele implementacji [wstaw język] -on- JavaScript (np. Translatory, które pozwalają na konwersję Ruby , Python , C # , Java , Obj-J / Cappuccino [podobne do Obj-C / Cocoa] lub Processing [dla Canvas] na JavaScript na kliencie lub przed wdrożeniem [i niektóre w których znajdują się również różne biblioteki abstrakcji]). Oczywiście istnieje narzut wydajności, jeśli jest tłumaczony na kliencie, ale jeśli czujesz się bardziej komfortowo z innym językiem, pozwoli to na pewną elastyczność.

Osobiście jednak polecam pokochać JavaScript. To doskonały, mocny język i całkiem elegancki, gdy się go pozna. Stoję przed dylematem odwrotnym, czuję się trochę nad tym, aby mieć wydajne rozwiązanie JavaScript / DOM po stronie serwera, które spełnia wszystkie moje potrzeby. / niezamówiona opinia

Nie. JavaScript to wszystko, ale będzie ewoluował. Następna wersja to „JavaScript Harmony” i możesz dowiedzieć się więcej, korzystając z Google.

Od czasu do czasu ktoś sugeruje umieszczenie interpretera kodu bajtowego w przeglądarkach obok JavaScript. Prawdopodobnie się nie wydarzy, przynajmniej przez jakiś czas.

Tak się składa, że ​​uwielbiam JavaScript. Ale są też inne rozwiązania, w tym GWT, który kompiluje Javę do JavaScript i Script #, który kompiluje C # do JavaScript.

Jquery (nadal javascript, ale) naprawdę pomoże ci mieć wsparcie dla prawie wszystkich przeglądarek i nie jest naprawdę trudne do nauczenia :)

JavaScript to angielski język sieci. Angielski historycznie rozprzestrzenił się, ponieważ miał silną flotę podbijającą różne kraje. Można to porównać z dużymi firmami, które podbiły sieć za pomocą JavaScript. Jest to język połączony z wieloma źródłami europejskimi (greka, łacina, języki germańskie, francuski, a nawet niektóre chińskie i indyjskie słowa). JavaScript zapożyczył przez lata wiele pojęć z innych języków (strukturalnych, obiektowych, funkcjonalnych). Angielski jest używany w różnych miejscach z niewielkimi różnicami w dialekcie i akcentie, co może utrudniać zrozumienie. Tak jak JavaScript, różne przeglądarki interpretują go nieco inaczej.

Chociaż angielski jest początkowo łatwy do nauczenia, ma bardzo niespójną wymowę i więcej wyjątków niż reguł. Podobnie jak JavaScript, zawsze oferuje niespodziankę.

Pomimo różnych akcentów, JavaScript jest lingua franca w sieci. Tak jak możesz nie być Anglikiem i pisać tutaj po angielsku, każda przeglądarka internetowa ma pewien stopień zrozumienia języka angielskiego. IE6 jest jak facet, który w swoim CV mówi, że biegle mówi, ale poszedł tylko na dwutygodniowy kurs angielskiego jako języka obcego.

Podejmowano próby wyparcia angielskiego jako głównego języka świata, np. Esperanto. Ale wszystkie z nich zawiodły, ponieważ większość ludzi na ziemi mówi trochę po angielsku. W ten sam sposób trudno będzie wprowadzić lepsze alternatywy dla JavaScript.

Nie sądzę, aby w najbliższym czasie JavaScript został zastąpiony. Aby uzyskać zupełnie inne podejście do bogatych klientów, warto przyjrzeć się Flex, czyli technologii opartej na technologii Flash.

Może coś takiego jak haxe (patrz haxe.org) mogłoby Ci pomóc. Jest to język, który wydaje się czystszy niż JavaScript i można go skompilować do JavaScript, dzięki czemu można go uruchomić w przeglądarce.

Wiem, że nie jest to bezpośrednia odpowiedź na twoje pytanie, ale mimo wszystko pomyślałem, że może być dla ciebie interesująca.

Wiele osób rozumie, że Javascript nie jest najlepszym i najładniejszym językiem w historii. Jednak obecnie jest obsługiwany przez przeglądarki, dlatego wprowadzenie innego języka będzie niezwykle trudne. Po prostu nie potrzebujemy kolejnej wojny przeglądarek.

To wyjaśnia, dlaczego nie znam żadnych planów przejścia na inny język po stronie klienta.

Ale myślę, że Javascript nie jest taki zły, jeśli zaczniesz myśleć o modelu DOM i jak można z nim pracować. Wiele rzeczy, które są kłopotliwe w JS, jest wynikiem sposobu działania modelu DOM.