Jakie są historyczne podstawy używania Javascript w programowaniu internetowym?


9

Pochodzę z biologii naukowej, gdzie często używamy Pythona.

Teraz, kiedy zacząłem od programowania, konsekwentnie zastanawiam się, dlaczego JavaScript jest podstawowym językiem po stronie klienta w Internecie.

Czy przewaga JavaScript jest wypadkiem historycznym, czy czymś innym? Ciekawe też, czy są jakieś przeszkody w integracji Pythona ze skryptami po stronie klienta?


Czy wymaga to uwagi moderatora na podstawie meta.programmers.stackexchange.com/questions/363/... ?
Rein Henrichs,

@ Rein - możesz, vote to closejeśli uważasz, że jest to nie na temat. Jeśli inni czują to samo, albo oni, albo moderator, pójdą za tobą.
jmort253

@ jmort253 (Być może powinienem przejść do meta) W wątku nie było konsensusu i jestem ambiwalentny. :(
Rein Henrichs,

@Rein - Proces myślowy w komentarzach jest w porządku (ponieważ służy jako drogowskaz, dlaczego lub dlaczego nie, społeczność postanowiła podjąć działania dotyczące postu. Jeśli nie ma porozumienia, zrób to, co uważasz za najlepsze. :) Osobiście uważam, że te historyczne informacje mogą pomóc innym zrozumieć przyszłość JavaScript jako języka i dlaczego ważne jest, aby zrozumieć i adoptować ten język.
jmort253

Odpowiedzi:


16

JavaScript był pierwszym językiem skryptowym, który został udostępniony w popularnej przeglądarce internetowej, dlatego został zaimplementowany niemal powszechnie. Będąc jedynym językiem programowania dostępnym we wszystkich popularnych przeglądarkach, nie było innego wyboru, jak być dominującym językiem programowania po stronie klienta.

Internet Explorer zaimplementował JavaScript w sposób umożliwiający podłączanie silników skryptowych (dostarczany z VBScript i JScript). Jeśli wolisz (tak jak ja) pisać kod w PerlScript lub PythonScript, możesz, ale wszyscy twoi klienci muszą mieć zainstalowany ten język skryptowy i muszą korzystać z IE. Możesz to zrobić w przypadku projektów wewnętrznych, ale nie ma mowy, aby działało to w Internecie.


Coś innego, co mnie zainteresowało, to projekty pisania kompilatorów Python-na-javascript, np. Pyjamas pyjs.org .
rd108

„Piżama to platforma programistyczna Rich Internet Application (RIA) dla sieci i komputerów. Zawiera kompilator języka Python-JavaScript, platformę AJAX i interfejs API widżetów. Piżama rozpoczęła życie jako port Python w zestawie narzędzi Google Web Toolkit Kompilator Java-to-JavaScript. Przeczytaj FAQ i listę funkcji. ”
rd108

Istnieje mnóstwo kompilatorów typu coś do javascript. CoffeeScript, TypeScript, ClojureScript, LispyScript itp.
Florian Margaine,

7

JavaScript został pierwotnie stworzony przez Brendan Eich. Został on po raz pierwszy dostarczony z wersją beta Netscape Navigator 2.0 we wrześniu 1995 roku jako LiveScript, ale został przemianowany na JavaScript we wspólnym ogłoszeniu z Sun Microsystems w grudniu 1995 roku. Dopiero później (w 1996) JavaScript został przesłany do Ecma International i ostatecznie stał się znormalizowany skrypt ECMAScript.

Obecna dominacja rynku wynika głównie z historycznej bezwładności.

Źródło: http://en.wikipedia.org/wiki/JavaScript#History


2

Nie jestem pewien, ale jest to lekki język skryptowy po stronie klienta. Myślę, że jego początki sięgają wczesnych przeglądarek Netscape (choć mogę się mylić). Rzeczywiście, jego nazwa została zmieniona przed wydaniem, aby zawierała słowo „java”, mimo że nie miało to nic wspólnego z java. W tamtym czasie była to taktyka szybka, by zyskać popularność.


1

Jestem pewien, że ma to wiele wspólnego z historią.

Ale jestem też pewien, że nie chcę, aby strony internetowe mogły uruchamiać w mojej przeglądarce w pełni funkcjonalne języki programowania, takie jak python. Implikacje bezpieczeństwa odstraszyłyby mnie od takich stron (lub musiałbym być bardzo bardzo pewny, że piaskownica przeglądarki jest szczelna).


To nie ma sensu. Dział IT decyduje, które interfejsy API są dostępne dla języka programowania. Oczywiście, gdyby Python był wysyłany w przeglądarkach, miałby on dostęp do tych samych interfejsów API, które ma teraz Javascript (jak DOM), więc nie miałby możliwości wyrządzenia żadnych szkód.
Andrea,

@Andrea - można argumentować, że język ma tyle samo standardowych bibliotek, co składnia i semantyka. JavaScript nie ma standardowej biblioteki dla operacji we / wy pliku, i jest to celowe ze względów bezpieczeństwa. Python ma standardowe biblioteki dla plików I / O i wiele innych rzeczy, które można uznać za problemy z bezpieczeństwem. Odrzuć je i prawdopodobnie nie masz już do czynienia z Pythonem. Dawno temu Python miał piaskownicę - pamiętam, że był tam w wersji 1.5 - ale został upuszczony IIRC, ponieważ nie był wystarczająco używany i był daleki od hermetyczności.
Steve314,

Trwają pisanie standardowych bibliotek dla I / O w Javascript. Oczywiście nie są one dostępne w przeglądarce. Mówię tylko, że gdyby Python został zaimplementowany w przeglądarce, niebezpieczne biblioteki nie byłyby dostępne. I prawdopodobnie nie przegapisz ich, ponieważ nie są przeznaczone do użycia na stronie internetowej.
Andrea,

-2

„Czy przewaga JavaScript jest wypadkiem historycznym, czy czymś innym?”

Osobiście uważam, że sukces JS jest tak samo kwestią projektową, jak wiele z nich było i nadal będzie nienawidzić przyznania się do tego, a nie tylko jakiś wypadek lub tylko dlatego, że był to pierwszy dzieciak na placu zabaw.

Brendan Eich, choć nazwany tak, aby odwoływać się do programistów Java i składni jak składnia języka Java opartego na C, również w celu odwołania się do programistów Java, podjął jedną z najbardziej złych decyzji w historii strony internetowej, która miała czerpać przede wszystkim ze schematu rzeczywistej mechaniki języka inspiracja, która wydaje się, że deweloperzy Java w ogóle nie lubili (co wydaje mi się bardzo zabawne).

JavaScript korzysta z wysoce elastycznego / szczegółowego dziedziczenia prototypowego dla OOP, ma zamknięcia, typy są w 100% dynamiczne, same funkcje są najwyższej klasy, co pozwala na ich przekazywanie jak każdy inny obiekt lub typ danych i ponowne użycie w różnych kontekstach, a nawet są stosowane do obiektów w locie, jakby od samego początku zostały zadeklarowane jako rzeczywiste elementy obiektu. Praktycznie krzyczy, że można go stosować w architekturach sterowanych zdarzeniami, które muszą znormalizować tonę zastrzeżonych śmieci lub obsługiwać wysoce nieliniowe problemy z interfejsem użytkownika.

Pod koniec zarania internetu jest to jedyny język, który poważnie podjął się zadania normalizacji przeglądarek podczas rzeczywistej wojny przeglądarkowej, w której Netscape i IE próbowały robić rzeczy inaczej, a następnie ponad 10 lat przeglądarki rozejm, w którym IE po prostu działało inaczej, ponieważ stwardnienie rozsiane jest leniwe i zakorzenione w niektórych słusznie głupich antykonkurencyjnych praktykach powodujących stagnację przeglądarki, a teraz świat, w którym przeglądarki zaczynają w końcu zgadzać się na tę samą ogólną specyfikację w odniesieniu do HTML, CSS i DOM API z IE są zaledwie 2-3 lata za najnowszymi osiągnięciami, a nie 10, dzięki Google i Mozilli, która wypuściła kompilatory JIT, które sprawiły, że liczby wydajności IE wyglądały tak żałośnie, że MS w końcu zawstydziło się na odpowiednią modernizację swoich przeklętych przeglądarek.IE9 jest pierwszym, który poważnie zaktualizował obsługę DOM API do poziomów obsługiwanych przez Netscape w 2000 roku.

JS miał konkurencję w postaci apletów Java i ActionScript Adobe dla Flasha. To tyle na poważnym froncie rywali. Stwardnienie rozsiane próbowało naciskać VB, ale poniosło porażkę, ponieważ ... cóż ... VB. Również zastrzeżone. Tak naprawdę było o wiele więcej stron Flash, niż większość ludzi zdaje sobie sprawę. Po prostu nie można znaleźć głupich rzeczy w wyszukiwarkach. Aplety zrobiły swoje, a to było brzydkie. Naprawdę brzydka. JS był jedynym językiem, który naprawdę rozwiązał problem pracy w kontekście wielu przeglądarek przez osoby, które nie zgadzały się z tym, kto ustawiał specyfikacje, z którymi mieli się zgadzać.

W ostatnich latach JS eksplodowało w znacznie szerszej dziedzinie zastosowań. W połączeniu z innymi technologiami internetowymi ma na celu przede wszystkim przewrócenie wszystkich innych rozwiązań na froncie mobilnym, ponieważ technologia internetowa + jest obecnie naprawdę jedynym realistycznym wyborem, jeśli naprawdę chcesz napisać jedną aplikację i sprawić, by działała na wszystko.

Więc nie, i tak, jestem wielkim fanem, ale nie sądzę, że przypadkowo zablokował on wszystkich innych konkurentów po stronie klienta, podobnie jak to, że stało się wybuchowo popularne poza przeglądarką, można teraz uznać za wypadek. Przed JS nie było wielu języków podobnych do schematu, które nie byłyby głównie akademickie. Daje to JS kilka potężnych zalet, a wyjątkowe potrzeby po stronie klienta umożliwiły, aby te zalety powoli stawały się krystalicznie czyste.


Wspominasz o Schemacie dwa razy, nigdy nie mówiąc, jak JS odnosi się do Schematu. Na pewno nie uważasz, że JS ma makra, wyrażenia S, rekurencję ogona, kontynuacje lub jakąkolwiek inną cechę wyróżniającą Schemat - prawda?
Gabe,

@Gabe. Sprawdź 4. blok tekstu. Zamknięcia, dynamiczne pisanie i funkcje pierwszej klasy są dość duże. Fakt, że JS używa składni podobnej do c, uniemożliwi korzystanie z makr Scheme. Nie jest to kopia programu według funkcji, ale na pewno ma na nią wpływ.
mike30,

Więc zamykanie i dynamiczne pisanie sprawia, że ​​język przypomina system? Czy to oznacza, że ​​C # jest podobny do schematu? Co z Ruby, Python i Perl? A dlaczego Schemat zamiast Lisp lub innego podobnego języka?
Gabe,

@Gabe Nie jestem ekspertem od Scheme, ale na zwykłej wikipedii powiedziałbym, że kombinacja zakresu leksykalnego, pierwszorzędnych funkcji i zamknięć to trzy, które zbliżają JS do Schematu, a nie do Javy. W przeciwnym razie po prostu wierzyłem na słowo Brendana Eicha i przyjąłem, że najważniejsze funkcje to pierwszorzędne funkcje.
Erik Reppen

OK, więc JS ma domknięcia (które moim zdaniem implikują funkcje najwyższej klasy i zakres leksykalny) i dynamiczne pisanie, takie jak Scheme. Skoro C # ma zamknięcia, dynamiczne pisanie i ograniczoną formę wyrażeń S, czy to oznacza, że ​​C # jest jeszcze bardziej podobny do schematu niż JS?
Gabe,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.