Dlaczego JavaScript zamiast standardowej maszyny wirtualnej przeglądarki?

Czy nie miałoby sensu obsługiwanie zestawu języków (Java, Python, Ruby itp.) Za pośrednictwem standardowej maszyny wirtualnej hostowanej w przeglądarce, zamiast wymagać użycia specjalistycznego języka - tak naprawdę wyspecjalizowanego paradygmatu - tylko do obsługi skryptów klienta?

Aby wyjaśnić tę sugestię, strona internetowa zawierałaby kod bajtowy zamiast dowolnego języka wyższego poziomu, takiego jak JavaScript.

Rozumiem pragmatyczną rzeczywistość, że JavaScript jest po prostu tym, z czym musimy teraz pracować z powodów ewolucyjnych, ale myślę bardziej o perspektywie długoterminowej. Jeśli chodzi o kompatybilność wsteczną, nie ma powodu, aby wbudowany JavaScript nie mógł być jednocześnie obsługiwany przez pewien czas i oczywiście JavaScript może być jednym z języków obsługiwanych przez maszynę wirtualną przeglądarki.

No tak. Z pewnością gdybyśmy mieli wehikuł czasu, cofnięcie się i upewnienie się, że wiele funkcji Javascript zostało zaprojektowanych inaczej, byłoby główną rozrywką (to i zapewnienie, że ludzie, którzy zaprojektowali silnik CSS IE, nigdy nie weszli do IT). Ale to się nie wydarzy i teraz z tym utknęliśmy.

Podejrzewam, że z czasem stanie się „językiem maszynowym” dla sieci, z innymi, lepiej zaprojektowanymi językami i interfejsami API, które będą się do niego kompilować (i będą obsługiwać różne słabości silnika wykonawczego).

Nie sądzę jednak, aby którykolwiek z tych „lepiej zaprojektowanych języków” był językiem Java, Python lub Ruby. Javascript jest, pomimo możliwości użycia w innym miejscu, językiem skryptowym aplikacji sieci Web. Biorąc pod uwagę ten przypadek użycia, możemy zrobić lepiej niż którykolwiek z tych języków.

Myślę, że JavaScript to dobry język, ale chciałbym mieć wybór podczas tworzenia aplikacji internetowych po stronie klienta. Ze starszych powodów utknęliśmy w JavaScript, ale są projekty i pomysły, które chcą zmienić ten scenariusz:

1. Klient macierzysty Google : technologia do uruchamiania kodu natywnego w przeglądarce.
2. Emscripten : kompilator kodu bajtowego LLVM do javascript. Umożliwia uruchamianie języków LLVM w przeglądarce.
3. Pomysł: .NET CLI w przeglądarce, twórca Mono: http://tirania.org/blog/archive/2010/May-03.html

Myślę, że długo będziemy mieć JavaScript, ale prędzej czy później to się zmieni. Jest tak wielu programistów, którzy chcą używać innych języków w przeglądarce.

Odpowiadając na pytanie - nie, to nie miałoby sensu.

Obecnie najbardziej zbliżone do wielojęzycznej maszyny wirtualnej są JVM i CLR. To nie są do końca lekkie bestie i nie ma sensu próbować umieszczać czegoś takiego rozmiaru i złożoności w przeglądarce.

Przeanalizujmy pomysł, że można napisać nową, wielojęzyczną maszynę wirtualną, która byłaby lepsza niż istniejące rozwiązanie.

• Zalegasz ze stabilnością.
• Zalegasz ze złożonością (o wiele za wiele, ponieważ próbujesz uogólniać na wiele języków)
• Zalegasz z adopcją

Więc nie, to nie ma sensu.

Pamiętaj, że aby obsługiwać te języki, będziesz musiał rozebrać ich interfejsy API w coś gwałtownego, wycinając wszelkie części, które nie mają sensu w kontekście skryptu przeglądarki. Jest tu do podjęcia ogromna liczba decyzji projektowych i duża szansa na popełnienie błędu.

Jeśli chodzi o funkcjonalność, prawdopodobnie i tak naprawdę pracujemy tylko z DOM, więc tak naprawdę jest to kwestia składni i języka, w którym momencie warto zapytać „Czy to naprawdę jest tego warte?”

Mając na uwadze, jedyne , o czym mówimy, to skrypty po stronie klienta, ponieważ skrypty po stronie serwera są już dostępne w dowolnym języku. To stosunkowo niewielka arena programowania, więc korzyści z wprowadzenia wielu języków są wątpliwe.

Jakie języki warto byłoby wprowadzić? (Ostrzeżenie, następuje subiektywny materiał)

Wprowadzenie języka takiego jak C nie ma sensu, ponieważ jest stworzony do pracy z metalem, aw przeglądarce nie ma naprawdę dużo dostępnego metalu.

Wprowadzenie języka takiego jak Java nie ma sensu, ponieważ i tak najlepszą rzeczą w tym jest API.

Wprowadzenie języka takiego jak Ruby czy Lisp nie ma sensu, ponieważ JavaScript jest potężnym dynamicznym językiem bardzo zbliżonym do Scheme.

Wreszcie, który twórca przeglądarki naprawdę chce obsługiwać integrację DOM dla wielu języków? Każda implementacja będzie miała swoje własne, specyficzne błędy. Przeszliśmy już przez ogień, radząc sobie z różnicami między MS Javascript i Mozilla Javascript, a teraz chcemy pomnożyć ten ból pięć lub sześć razy?

To nie ma sensu.

W systemie Windows możesz zarejestrować inne języki w Hostie skryptów i udostępnić je IE. Na przykład VBScript jest obsługiwany od razu (chociaż nigdy nie zyskał dużej popularności, ponieważ w większości zastosowań jest nawet gorszy niż JavaScript).

Rozszerzenia Pythona win32 pozwoliły dość łatwo dodać Pythona do IE w ten sposób, ale nie był to dobry pomysł, ponieważ Python jest dość trudny do piaskownicy: wiele funkcji językowych ujawnia wystarczającą liczbę haków implementacji, aby umożliwić rzekomo ograniczoną aplikację .

Generalnie problemem jest to, że im bardziej złożona jest aplikacja internetowa, taka jak przeglądarka, tym większe prawdopodobieństwo wystąpienia problemów z bezpieczeństwem. Kilka nowych języków z pewnością pasowałoby do tego opisu, a są to nowe języki, które również szybko się rozwijają.

JavaScript jest brzydkim językiem, ale dzięki uważnemu użyciu selektywnego podzbioru funkcji i wsparciu odpowiednich bibliotek obiektów można go ogólnie uczynić dość znośnym. Wydaje się, że przyrostowe, praktyczne dodatki do JavaScript są jedynym sposobem, w jaki skrypty internetowe mogą się rozwijać.

Zdecydowanie chciałbym mieć maszynę wirtualną niezależną od standardowego języka w przeglądarkach (wolałbym kodować w języku statycznym).

(Technicznie) Stopniowo jest to całkiem wykonalne: najpierw obsługuje to jedna z głównych przeglądarek, a serwer ma możliwość albo wysłania kodu bajtowego, jeśli aktualne żądanie pochodzi z kompatybilnej przeglądarki, albo przetłumaczyć kod na JavaScript i wysłać zwykły tekst JavaScript.

Istnieją już języki eksperymentalne, które kompilują się do JavaScript, ale posiadanie zdefiniowanej maszyny wirtualnej pozwoliłoby (być może) na lepszą wydajność.

Przyznaję, że część „standardowa” byłaby jednak dość skomplikowana. Wystąpiłyby również konflikty między funkcjami języka (np. Typowanie statyczne a dynamiczne) dotyczące biblioteki (przy założeniu, że nowa rzecz będzie używać tej samej biblioteki). Dlatego nie sądzę, że to się stanie (wkrótce).

Jeśli czujesz, że brudzisz sobie ręce, oznacza to, że albo zostałeś poddany praniu mózgu, albo nadal odczuwasz skutki „lat DHTML”. JavaScript jest bardzo potężny i dobrze nadaje się do swojego celu, jakim jest skryptowanie interaktywności po stronie klienta. To dlatego JavaScript 2.0 otrzymał tak złą opinię. Mam na myśli, dlaczego pakiety, interfejsy, klasy i tym podobne, skoro są to wyraźnie aspekty języków po stronie serwera. JavaScript jest dobry jako język oparty na prototypach, ale nie jest w pełni zorientowany obiektowo.

Jeśli w aplikacjach brakuje płynności, ponieważ po stronie serwera i po stronie klienta nie komunikują się dobrze, warto rozważyć ponownie sposób tworzenia architektury aplikacji. Pracowałem z niezwykle solidnymi witrynami i aplikacjami internetowymi i nigdy nie powiedziałem: „Hmm, naprawdę chciałbym, żeby JavaScript mógł to zrobić (xyz)”. Gdyby mógł to zrobić, nie byłby to JavaScript - byłby to ActionScript, AIR lub Silverlight. Nie potrzebuję tego, podobnie jak większość programistów. To fajne technologie, ale próbują rozwiązać problem za pomocą technologii, a nie… cóż, rozwiązania.

Nie sądzę, aby standardowa internetowa maszyna wirtualna była tak niewyobrażalna. Istnieje wiele sposobów na wprowadzenie nowego standardu internetowej maszyny wirtualnej z wdziękiem iz pełną obsługą starszych wersji, o ile zapewnisz, że dowolny format kodu bajtowego VM, którego używasz, można szybko zdekompilować do javascript, a wynikowe dane wyjściowe będą wystarczająco wydajne ( Posunąłbym się nawet do zgadywania, że ​​inteligentny dekompilator prawdopodobnie wygenerowałby lepszy javascript niż jakikolwiek javascript, który człowiek mógłby sam stworzyć).

Dzięki tej właściwości każdy format maszyny wirtualnej sieci Web można łatwo zdekompilować na serwerze (szybko), na kliencie (powolny, ale możliwy w przypadkach, gdy masz ograniczoną kontrolę nad serwerem) lub może być wstępnie wygenerowany i załadowany dynamicznie przez klient lub serwer (najszybszy) w przypadku przeglądarek, które natywnie nie obsługują nowego standardu.

Te przeglądarki, które natywnie obsługują nowy standard, skorzystałyby na zwiększonej szybkości działania aplikacji opartych na maszynach wirtualnych sieci Web. Co więcej, jeśli przeglądarki opierają swoje starsze silniki javascript na standardzie wirtualnej maszyny wirtualnej (tj. Analizują javascript do standardu maszyny wirtualnej sieci Web, a następnie uruchamiają go), nie muszą zarządzać dwoma środowiskami wykonawczymi, ale to zależy od dostawcy przeglądarki .

Chociaż Javascript jest jedynym dobrze obsługiwanym językiem skryptowym, z którego można bezpośrednio sterować stroną, Flash ma kilka bardzo przydatnych funkcji dla większych programów. Ostatnio ma JIT i może również generować kod bajtowy w locie (zobacz przykład oceny wyrażeń środowiska uruchomieniowego, w którym używają Flash do kompilowania wyrażeń matematycznych wprowadzanych przez użytkownika aż do natywnych binarnych). Język Haxe umożliwia statyczne pisanie z wnioskiem, a dzięki możliwościom generowania kodu bajtowego można zaimplementować prawie każdy wybrany system wykonawczy.

Szybka aktualizacja tego starego pytania.

Nikt, kto potwierdził, że „strona internetowa zawierałaby kod bajtowy zamiast jakiegokolwiek języka wyższego poziomu, takiego jak JavaScript”, „się nie wydarzy”.

Czerwiec 2015 W3C ogłosiło, że WebAssembly

nowy, przenośny, efektywny pod względem rozmiaru i czasu wczytywania format, odpowiedni do kompilacji w Internecie.

Jest to nadal eksperymentalne, ale jest już kilka prototypowych implementacji w Firefoksie Nightly i Chrome Canary i już działa demonstracja .

Obecnie jednak WebAssembly jest głównie zaprojektowana do tworzenia z C / C ++

w miarę ewolucji WebAssembly będzie obsługiwać więcej języków niż C / C ++ i mamy nadzieję, że inne kompilatory również go obsługują .

Pozwalam wam przyjrzeć się bliżej oficjalnej stronie projektu, to naprawdę ekscytujące!

to pytanie pojawia się regularnie. moje stanowisko w tej sprawie jest następujące:

A) nie wydarzy się i B) już tu jest.

przepraszam, co? pozwól mi wyjaśnić:

ad A

VM to nie tylko jakieś uniwersalne urządzenie magiczne. większość maszyn wirtualnych jest zoptymalizowana pod kątem określonego języka i niektórych funkcji językowych. weź JRE / Java (lub LLVM): zoptymalizowane pod kątem statycznego pisania i zdecydowanie istnieją problemy i wady podczas implementowania dynamicznego pisania lub innych rzeczy, których java nie obsługiwała w pierwszej kolejności.

tak więc „ogólna uniwersalna maszyna wirtualna”, która obsługuje wiele funkcji językowych (optymalizacja wywołań ogonowych, pisanie statyczne i dynamiczne, foo bar boo, ...) byłaby kolosalna, trudna do wdrożenia i prawdopodobnie trudniejsza do optymalizacji, aby uzyskać dobrą wydajność to. ale nie jestem projektantem języków ani guru vm, może się mylę: to właściwie całkiem proste, tylko nikt jeszcze nie wpadł na ten pomysł? hrm, hrm.

ad B

już tutaj: może nie być kompilatora / vm kodu bajtowego, ale tak naprawdę go nie potrzebujesz. afaik javascript jest kompletny, więc powinno być możliwe:

1. stwórz tłumacza z języka X na javascript (np. coffeescript)
2. utwórz interpretera w javascript, który będzie interpretował język X (np. brainfuck ). tak, wydajność byłaby fatalna, ale hej, nie można mieć wszystkiego.

ad C

co? na pierwszym miejscu nie było punktu C !? ponieważ nie ma ... jeszcze. google NACL. jeśli ktoś może to zrobić, to google. jak tylko Google zacznie działać, Twoje problemy zostaną rozwiązane. tylko, uh, to może nigdy nie zadziałać, nie wiem. ostatnim razem, gdy o tym czytałem, było kilka nierozwiązanych problemów bezpieczeństwa tego naprawdę trudnego rodzaju.

oprócz tego:

• javascript istnieje od ~ 1995 = 15 lat. mimo to implementacje przeglądarek różnią się dzisiaj (chociaż przynajmniej nie jest już nie do zniesienia). więc jeśli zaczynasz już coś nowego, możesz mieć wersję działającą w różnych przeglądarkach około 2035 r. przynajmniej działający podzbiór. to tylko nieznacznie się różni. i wymaga kompatybilności bibliotek i warstw. nie ma sensu jednak nie próbować niczego ulepszać.

• a co z czytelnym kodem źródłowym? Wiem, że wiele firm wolałoby nie udostępniać swojego kodu jako „swego rodzaju” open source. Osobiście jestem bardzo szczęśliwy, że jestem w stanie przeczytać źródło, jeśli podejrzewam coś podejrzanego lub chcę się z niego czegoś nauczyć. hura za kod źródłowy!

W rzeczy samej. Silverlight jest właśnie tym - maszyną wirtualną opartą na platformie .Net po stronie klienta.

W twoim rozumowaniu jest kilka błędów.

1. Standardowa maszyna wirtualna w standardowej przeglądarce nigdy nie będzie standardowa. Mamy 4 przeglądarki, a IE ma sprzeczne interesy w odniesieniu do „standardowej”. Trzy pozostałe szybko się rozwijają, ale tempo wdrażania nowych technologii jest powolne. A co z przeglądarkami na telefonach, małych urządzeniach, ...

2. Integracja JS z różnymi przeglądarkami i jego przeszła historia prowadzi do niedoszacowania mocy JS. Deklarujesz standard, ale nie akceptujesz JS, ponieważ standard nie działał we wczesnych latach.

3. Jak powiedzieli inni, JS to nie to samo, co AIR / .NET / ... i tym podobne. JS w swoim obecnym wcieleniu doskonale wpisuje się w swoje cele.

W dłuższej perspektywie Perl i Ruby mogłyby z powodzeniem zastąpić javascript. Jednak adopcja tych języków jest powolna i wiadomo, że nigdy nie przejmą one JS.

Jak najlepiej definiujesz? Najlepsze dla przeglądarki czy najlepsze dla programisty? (Plus ECMAScript różni się od Javascript, ale jest to kwestia techniczna).

Uważam, że JavaScript może być jednocześnie potężny i elegancki. Niestety większość programistów, których spotkałem, traktuje to jak zło konieczne, a nie prawdziwy język programowania.

Niektóre z funkcji, które lubię, to:

• traktowanie funkcji jako obywateli pierwszej kategorii
• możliwość dodawania i usuwania funkcji do dowolnego obiektu w dowolnym momencie (mało przydatne, ale oszałamiające, gdy jest)
• jest to język dynamiczny.

Fajnie się z tym radzi i zostało ustalone. Ciesz się nim, gdy jest w pobliżu, ponieważ chociaż może nie być „najlepszy” do obsługi skryptów klienta, z pewnością jest przyjemny.

Zgadzam się, że tworzenie stron dynamicznych jest frustrujące z powodu niezgodności przeglądarek, ale może to zostać złagodzone przez biblioteki interfejsu użytkownika. Nie powinno to być już dłużej traktowane przeciwko samemu JavaScriptowi, niż Swing powinno być przeciwko Javie.

JavaScript to standardowa maszyna wirtualna przeglądarki. Na przykład, OCaml i Haskell mają teraz kompilatory, które mogą generować JavaScript. Ograniczeniem nie jest JavaScript - język, ograniczeniem są obiekty przeglądarki dostępne za pośrednictwem JavaScript oraz model kontroli dostępu używany do zapewnienia bezpiecznego uruchamiania JavaScript bez narażania komputera. Obecna kontrola dostępu jest tak słaba, że ​​JavaScript ma bardzo ograniczony dostęp do obiektów przeglądarki ze względów bezpieczeństwa. Projekt Harmony chce to naprawić.

To fajny pomysł. Dlaczego nie pójść o krok dalej?

• Napisz parser HTML i silnik układu (tak naprawdę wszystkie skomplikowane bity w przeglądarce) w tym samym języku VM
• Opublikuj silnik w sieci
• Wyświetl stronę z deklaracją, który silnik układu ma być używany, i jego adresem URL

Następnie możemy dodawać funkcje do przeglądarek bez konieczności wypychania nowych przeglądarek do każdego klienta - odpowiednie nowe bity będą ładowane dynamicznie z sieci. Moglibyśmy również publikować nowe wersje HTML bez całej absurdalnej złożoności związanej z zachowywaniem wstecznej kompatybilności ze wszystkim, co kiedykolwiek działało w przeglądarce - za zgodność odpowiada autor strony. Możemy także eksperymentować z innymi językami znaczników niż HTML. I, oczywiście, możemy napisać fantazyjne kompilatory JIT w silnikach, abyś mógł napisać swoje strony internetowe w dowolnym języku.

Byłbym mile widziany w każdym języku oprócz javascript jako możliwego języka skryptowego.

Fajnie byłoby używać innych języków niż JavaScript. Java prawdopodobnie nie pasowałaby świetnie między tagiem, ale korzystne byłyby języki takie jak Haskell, Clojure, Scala, Ruby, Groovy.

Jakiś czas temu przeszedłem przez Rubyscript ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby i http://code.google.com/p/ruby- w przeglądarce /
Wciąż w fazie eksperymentalnej i w toku, ale wygląda obiecująco.
Dla .Net właśnie znalazłem: http://www.silverlight.net/learn/dynamic-languages/ Właśnie znalazłem witrynę, ale też wygląda interesująco. Działa nawet z mojego Apple Mac .

Nie wiem, jak dobrze powyższe działa jako alternatywa dla Javascript, ale na pierwszy rzut oka wygląda całkiem fajnie. Potencjalnie pozwoliłoby to na używanie dowolnego środowiska Java lub .Net natywnie z przeglądarki - w piaskownicy przeglądarki.

Jeśli chodzi o bezpieczeństwo, jeśli język działa wewnątrz JVM (lub silnika .Net w tym przypadku), maszyna wirtualna zajmie się bezpieczeństwem, więc nie musimy się o to martwić - przynajmniej nie więcej niż powinniśmy w przypadku wszystkiego, co działa wewnątrz przeglądarki.

Prawdopodobnie, ale żeby to zrobić, musielibyśmy sprawić, by główne przeglądarki je obsługiwały. Obsługa IE byłaby najtrudniejsza do uzyskania. JavaScript jest używany, ponieważ jest to jedyna rzecz, na którą możesz liczyć.

Zdecydowana większość programistów, z którymi rozmawiałem o ECMAScript et. glin. w końcu przyznając, że problemem nie jest język skryptowy, tylko śmieszny HTML DOM, który ujawnia. Konflikt DOM z językiem skryptowym jest częstym źródłem bólu i frustracji związanych z ECMAScript. Nie zapominaj też, że IIS może używać JScript do tworzenia skryptów po stronie serwera, a rzeczy takie jak Rhino pozwalają na tworzenie wolnostojących aplikacji w ECMAScript. Spróbuj przez chwilę pracować w jednym z tych środowisk z ECMAScript i zobacz, czy twoja opinia się zmieni.

Ten rodzaj rozpaczy krąży już od jakiegoś czasu. Sugerowałbym edycję tego, aby uwzględnić lub ponownie opublikować z określonymi problemami. Możesz być mile zaskoczony jakąś uzyskaną ulgą.

Stara strona, ale wciąż świetne miejsce do rozpoczęcia: strona Douglasa Crockforda .

Cóż, mamy już VBScript, prawda? Czekaj, tylko IE to obsługuje!
To samo dotyczy twojego fajnego pomysłu na VM. Co się stanie, jeśli skryptuję moją stronę za pomocą Lua, a Twoja przeglądarka nie ma parsera, aby przekonwertować ją na kod bajtowy? Oczywiście moglibyśmy sobie wyobrazić tag skryptu akceptujący plik kodu bajtowego, który nawet byłby całkiem wydajny.
Doświadczenie pokazuje jednak, że trudno jest wprowadzić coś nowego do sieci: przyjęcie radykalnej zmiany takiej jak ta zajęłoby lata. Ile przeglądarek obsługuje SVG lub CSS3?

Poza tym nie widzę tego, co uważasz za „brudne” w JS. Może być brzydki, jeśli zostanie zakodowany przez amatorów, propagując złe praktyki skopiowane gdzie indziej, ale mistrzowie pokazali, że może to być również elegancki język. Trochę jak Perl: często wygląda jak zaciemniony język, ale można go uczynić doskonale czytelnym.

Sprawdź to http://www.visitmix.com/Labs/Gestalt/ - pozwala używać języka Python lub Ruby, o ile użytkownik ma zainstalowany dodatek Silverlight.

To jest bardzo dobre pytanie.

Nie jest to problem tylko w JS, ale jest to brak dobrych, darmowych IDE do tworzenia większych programów w JS. Znam tylko jedną darmową: Eclipse. Drugim dobrym jest Visual Studio firmy Microsoft, ale nie darmowy.

Dlaczego miałoby to być darmowe? Jeśli dostawcy przeglądarek internetowych chcą zastąpić aplikacje stacjonarne aplikacjami online (i chcą), muszą nam, programistom, zapewnić dobre narzędzia programistyczne. Nie można utworzyć 50 000 wierszy JavaScript za pomocą prostego edytora tekstu, JSLint i wbudowanego debuggera Google Chrome. Chyba że jesteś makohistą.

Kiedy Borland stworzył IDE dla Turbo Pascal 4.0 w 1987 roku, była to rewolucja w programowaniu. Od tego czasu minęły 24 lata. Szkoda, że ​​w roku 2011 wielu programistów nadal nie używa uzupełniania kodu, sprawdzania składni i poprawnych debuggerów. Prawdopodobnie dlatego, że jest tak mało dobrych IDE.

W interesie dostawców przeglądarek internetowych jest stworzenie odpowiednich (DARMOWYCH) narzędzi dla programistów, jeśli chcą, abyśmy budowali aplikacje, za pomocą których mogą walczyć z systemami Windows, Linux, MacOS, iOS, Symbian itp.

Realnie rzecz biorąc, Javascript jest jedynym językiem, którego będą używać wszystkie przeglądarki przez długi czas, więc chociaż byłoby miło używać innych języków, nie sądzę, żeby tak się działo.

Ta „ustandaryzowana maszyna wirtualna”, o której mówisz, byłaby bardzo duża i musiałaby zostać zaadaptowana przez wszystkie główne przeglądarki, a większość witryn i tak nadal korzystałaby z Javascript, ponieważ jest bardziej dostosowana do witryn internetowych niż wiele innych przeglądarek.

Konieczne byłoby umieszczenie każdego języka programowania w piaskownicy w tej maszynie wirtualnej i ograniczenie dostępu każdego języka do systemu, co wymagałoby wielu zmian w językach oraz usunięcia lub ponownego wdrożenia wielu funkcji. Podczas gdy Javascript już o tym myśli i robi to przez długi czas.

Może szukasz klienta natywnego Google.

W pewnym sensie posiadanie bardziej wyrazistego języka, takiego jak JavaScript w przeglądarce, zamiast czegoś bardziej ogólnego, takiego jak kod bajtowy Java, oznaczało bardziej otwartą sieć.

Myślę, że to nie jest taka łatwa sprawa. Możemy powiedzieć, że utknęliśmy z JS, ale czy naprawdę jest tak źle z jQuery, Prototype, scriptaculous, MooTools i wszystkimi fantastycznymi bibliotekami?

Pamiętaj, że JS jest lekki , tym bardziej z V8, TraceMonkey, SquirrelFish - nowymi silnikami JavaScript używanymi w nowoczesnych przeglądarkach.

Jest to również udowodnione - tak, wiemy, że ma problemy, ale mamy wiele z nich rozwiązanych, na przykład wczesne problemy z bezpieczeństwem. Obrazowanie pozwalające przeglądarce na uruchomienie kodu Ruby lub cokolwiek innego. Bezpieczna piaskownica musiałaby być zrobiona od podstaw. I wiesz co? Ludzie z Pythona już zawiedli dwa razy.

Myślę, że Javascript będzie z czasem poprawiany i ulepszany , podobnie jak HTML i CSS. Proces może być długi, ale nie wszystko jest możliwe na tym świecie.

Myślę, że nie „rozumiesz pragmatyczną kwestię, że JavaScript jest po prostu tym, z czym teraz musimy pracować”. W rzeczywistości jest to bardzo potężny język. Miałeś swój aplet Java w przeglądarce od lat i gdzie jest teraz?

Zresztą nie musisz "brudzić się", żeby pracować na kliencie. Na przykład spróbuj GWT.

... masz na myśli...

Java i aplet Java Flash i Adobe AIR itp.

Ogólnie rzecz biorąc, każda platforma RIA może zaspokoić Twoje potrzeby; ale za każdy trzeba zapłacić za jego używanie (np. środowisko uruchomieniowe dostępne w przeglądarce lub / i oprogramowanie własnościowe lub / i mniej opcji niż zwykły komputer) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Do tworzenia stron internetowych z dowolnymi językami innymi niż webowe, masz GWT: programuj Java, kompiluj do Javascript

Ponieważ wszystkie mają już maszyny wirtualne z interpretatorami kodu bajtowego, a kod bajtowy też jest inny. {Chakra (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Carakan).

Przepraszam, myślę, że Chrome (V8) kompiluje się do kodu maszynowego IA32.

cóż, biorąc pod uwagę, że wszystkie przeglądarki już używają maszyny wirtualnej, nie sądzę, by było tak trudno stworzyć język VM dla sieci.
Myślę, że byłoby to bardzo pomocne z kilku powodów:
1. ponieważ serwer kompiluje kod, ilość przesyłanych danych jest mniejsza, a klient nie marnuje czasu na kompilację kodu.
2. Ponieważ serwer może skompilować kod w trakcie przygotowywania i przechowywać go, w przeciwieństwie do klienta, który stara się skrócić jak najmniej czasu na szybkie kompilowanie JS, może dokonać lepszych optymalizacji kodu.
3. Kompilowanie języka do kodu bajtowego jest znacznie łatwiejsze niż transpilacja do JS.

na koniec (jak ktoś już powiedział w innym komentarzu), HTML i CSS kompilują się do prostszego języka, nie jestem pewien, czy liczy się to jako kod bajtowy, ale możesz również wysłać skompilowany html i css z serwera do klienta, co skróć czas analizowania i pobierania

IMO, JavaScript, język, nie są problemem. JavaScript jest właściwie dość ekspresyjnym i potężnym językiem. Myślę, że ma złą reputację, ponieważ nie ma klasycznych funkcji OO, ale dla mnie im więcej idę z prototypowym rowkiem, tym bardziej mi się podoba.

Moim zdaniem problemem są niestabilne i niespójne implementacje w wielu przeglądarkach, które jesteśmy zmuszeni wspierać w sieci. Biblioteki JavaScript, takie jak jQuery, znacznie ułatwiają złagodzenie tego nieprzyjemnego uczucia.