Dlaczego nie ma innych języków skryptowych po stronie klienta dla stron internetowych? [Zamknięte]

Dlaczego obecnie jest dostępna obsługa JavaScript i niektórych VBScript w przeglądarkach? Wiem, że JavaScript jest dobry, ale czy opcja użycia innego języka programowania nie pomogłaby w promowaniu różnych stylów programowania?

Nie ma potrzeby dodawania suportu dla wielu języków, rozwiązaniem byłoby ujednolicenie ogólnego kodu bajtowego, który mógłby być stosowany przez implementatory języków. Ale obecnie nie ma na to żadnych planów (zostało to zasugerowane).

Języki można również zaimplementować oprócz Javascript. JavaScript jest na tyle dobry, że można na nim zaimplementować inne języki. I jest już wiele tego przykładów.

JavaScript jest de facto standardem i istnieje od 1996 roku. Bycie standardem po prostu dlatego, że nie ma konkurencji, nie jest do końca uczciwe, ale nie słyszałem dużo narzekań na to, dlaczego nie ma innego języka.

Dodanie kolejnego „standardowego” języka promuje różne zabawne małe problemy.

• Jak będą działać z innymi językami?
• Czy DOM będzie udostępniany?
• Czy skrypty napisane w obu mogą nadal działać?
• Przenoszenie bibliotek do obu

Pomyśl o niespójności między przeglądarkami pod kątem obsługi samego języka JavaScript. Pomyśl teraz, jak by to było, gdyby było więcej języków.

Przeglądarki muszą być znormalizowane, aby wszystko, co tworzysz, działało wszędzie, we wszystkich przeglądarkach.

Jeśli masz wiele języków, musisz upewnić się, że wszystkie działają bardzo podobnie. Jeśli jesteś programistą i masz wybór języków, które mogą, ale nie muszą być obsługiwane w niektórych lokalizacjach, oznacza to dodatkowy ból głowy.

JavaScript jest bardzo elastycznym językiem, jest konieczny, funkcjonalny, może być OOP (po modzie z prototypami) i jest interpretowany. Teraz z przyzwoitymi silnikami, jak w Chrome, jest w stanie zrobić dobre rzeczy. Dodatkowe języki po prostu przywróciłyby tę sytuację, popatrzą tylko na VBScript, IE, a więc wszystko, co jest w nim napisane, jest powiązane z konkretną przeglądarką i platformą, koszmarem.

Zamiast wbudowywać je w przeglądarki, producenci lubią budować nieporęczne wtyczki do przeglądarek - Java, Flash, Silverlight itp. Gwarantuje to spójność między platformami.

Jednym z powodów jest to, że praktycznie różni dostawcy różnych przeglądarek nie mogą nawet uzgodnić standardowej implementacji Javascript, a Javascript istnieje już od zawsze, przynajmniej z perspektywy języka WWW. Dlatego większość ludzi słusznie uważa, że ​​wprowadzenie innego języka po stronie klienta do ekosystemu i zapewnienie wszystkim dostawcom wsparcia, jest praktycznie niemożliwe, a większość ludzi, którzy mogliby to zrobić, jest już zaangażowana w problemy ze standaryzacją Javascript, które moim zdaniem są znacznie lepsze wykorzystanie ich czasu.

Istnieje kilka odpowiedzi, które twierdzą, że obsługa wielu języków sprawiłaby, że twórcy przeglądarek internetowych bardzo obrzydliwie upewnili się, że są zgodni ze wszystkimi językami. Wydaje mi się to nieprawidłowe.

Na przykład Java jest niezwykle dobrze zdefiniowanym standardem. Zasadniczo wszystko, co musisz zrobić, to ujawnić DOM przeglądarki jako API Java i uruchomić wirtualną maszynę Java (JVM) w przeglądarce internetowej. Można określić, że kod skryptowy będzie musiał być dostarczony w postaci skompilowanych i podpisanych plików JAR lub w postaci kodu źródłowego JavaScript. Jeśli przeglądarka napotka JavaScript, może albo uruchomić go przez dedykowanego interpretera (jak ma to miejsce dzisiaj), albo przez Rhino na JVM. Jeśli napotka pliki jar, tworzy nowy moduł ładujący i piaskownicę bezpieczeństwa, ładuje kod bajtowy Java do pamięci i wykonuje go. Byłoby to całkowicie wstecznie kompatybilne z istniejącymi stronami internetowymi i pozwoliłoby przeglądarce, jednym pociągnięciem, obsługiwać dziesiątki języków, które działają w JVM.

Inne zalety:

1. JVM skorzystał z dekady ulepszeń wydajności. Jest teraz bardzo szybki, stabilny i dojrzały. Założę się, że zobaczysz znaczną poprawę wydajności w stosunku do interpretowanego javascript.
2. W miarę jak aplikacje po stronie klienta stają się coraz większe i bardziej złożone, zwiększają się zalety ustrukturyzowanych języków pisanych na maszynie, takich jak Java i Scala.
3. Miałbyś dostęp do prawdziwej wielowątkowości, a za pośrednictwem Scali biblioteka kolekcji zoptymalizowana pod kątem przetwarzania wielordzeniowego.
4. Możesz użyć dowolnej z tysięcy bibliotek Java typu open source w przeglądarce.
5. Dzięki bibliotekom takim jak openGL przeglądarka może zapewnić dostęp do zaawansowanych możliwości obliczeniowych grafiki i kart graficznych.
6. Jeśli miałeś uruchomioną Javę po stronie klienta i serwera, możesz dodatkowo skorzystać z komunikacji klient-serwer poprzez bardzo skompresowaną, binarną serializację obiektów-grafów = szybsze ładowanie i wykonywanie stron internetowych.

Wierzę, że JavaScript zyska jeszcze większą popularność jako standardowy język dla sieci. Obserwujemy wzrost JavaScript po stronie serwera. Oto kilka przykładów implementacji tego potężnego języka na serwerze:

• Serwer WWW POW SJS - JavaScript po stronie serwera dla serwera WWW POW, który działa jako rozszerzenie przeglądarki Firefox lub jako aplikacja XULRunner. SJS odgrywa podobną rolę jak PHP w Apache, ponieważ może łączyć się z bazami danych i generować treści po stronie klienta.

• NodeJS - JavaScript po stronie serwera, który wykorzystuje model oparty na zdarzeniach. Jest zbudowany przy użyciu silnika JavaScript V8 Google . NodeJS jest reklamowany jako narzędzie do tworzenia skalowalnych programów sieciowych. Serwer WWW „Hello World” można napisać tylko w 6 krótkich liniach!

• Jaxer - serwer JavaScript, który interpretuje wszystkie bloki skryptów runat="server"jako JavaScript po stronie serwera. Całe aplikacje internetowe można pisać w JavaScript.

• Rhino - JavaScript dla Java - Mozilla stworzyła tę implementację JavaScript po stronie serwera, która działa na Javie. Jest to zasadniczo podobna koncepcja do Querces PHP dla Java , Jython, JRuby i wielu innych abstrakcji innych języków, które działają na JVM. Rhino jest zwykle używane do osadzania JavaScriptu w Javie w celu zapewnienia narzędzi skryptowych dla użytkowników końcowych, ale może być również używane do przenoszenia kodu po stronie klienta na serwer bez konieczności przepisywania logiki biznesowej w innym języku!

• JQuery Claypool - framework JavaScript po stronie serwera wykorzystujący moc JQuery na serwerze. Bardzo fajny! Został opracowany przy użyciu implementacji JavaScript po stronie serwera EnvJs w przeglądarce.

• EnvJs - bezgłowa przeglądarka zbudowana na Rhino.

Wiele z tych implementacji i struktur pokazuje, że JavaScript staje się tak potężną siłą w rozwoju sieci, że liderzy społeczności już zaczęli przenosić JavaScript na serwer. JavaScript jest niezwykle potężnym funkcjonalnym językiem programowania, a wraz z upływem czasu wydaje mi się, że będzie ewoluował.

Podsumowując, wydaje się sprzecznością przenosić inne języki do przeglądarki, gdy zamiast tego możemy przenieść ten jeden język przeglądarki na serwer i wypełnić tę lukę w bardziej jednolity sposób.

Istnieje kilka przykładów narzędzi, które będą kompilować inne języki dla javascript, w tym Haskel, Lisp i Python (prawdopodobnie inne). Jeśli więc chcesz pracować w jednym z tych języków, możesz to zrobić.

I myślę, że jeden z moich profesorów z uniwersytetu napisał implementację programu w JavaScript. Więc jeśli lubisz schemat, możesz to zrobić.

Ludzie pracowali nad brakiem wbudowanej różnorodności na dwa sposoby: używając wtyczek, takich jak aplety Flash lub Java, i budując warstwy, które używają javascript jako swojego „kodu maszynowego”, takiego jak jquery lub Google Toolkit. Gdyby istniał nowy styl rozwoju, który byłby wystarczająco popularny, ludzie mogliby znaleźć sposób, aby go wprowadzić.

Pamiętaj, że jeśli utworzysz środowisko uruchomieniowe .net w javascript i stanie się ono popularne, niektóre kręgi będą przeklinać twoje imię w Internecie na zawsze.