Czy Python byłby zbyt wolny do użycia po stronie klienta w przeglądarkach?


17

Słyszałem stwierdzenie, że Python będzie zbyt wolny, aby mógł być wykorzystywany w przeglądarkach.

Sądzę, że JavaScript jest lepszy pod tym względem tylko dlatego, że firmy takie jak Google potrzebują go szybko (i zrobiły to szybko), ponieważ potrzebują go, aby przetrwać, ale mogę się mylić.

Czy są jakieś różnice w sposobie projektowania Python i Javascript, które mają wpływ na to, jak będą (działały) w przeglądarkach?

Ponieważ na razie nie ma implementacji Pythona po stronie klienta, moje pytanie pochodzi od wypowiedzi, którą ktoś wypowiedział, więc może ma to coś wspólnego z samymi językami (chociaż nie wierzę w to).


2
Python w przeglądarce? Kiedy to się stało?
yannis

6
Nie udało się. Zauważ would?
Profpatsch

16
Cóż, jeśli tak się nie stało, to nie rozumiem, o co chodzi w tym pytaniu. Kiedy mówimy o wydajności, nie mówimy o językach, ale o implementacjach języków (istnieje kilka implementacji dla Pythona, podobnie jak dla Javascript). Jeśli nie ma implementacji języka Python po stronie klienta, o czym można porozmawiać?
yannis

1
Teoretyczna nauka! : D Moje pytanie pochodzi od wypowiedzi, którą ktoś wypowiedział, więc może ma to coś wspólnego z samymi językami (chociaż nie wierzę w to).
Profpatsch

1
Kiedyś istniała implementacja integracji Pythona dla Internet Explorera za pośrednictwem interfejsu COM, która również umożliwiała opcję VBScript do skryptowania DOM. Myślę, że MS przerwał opcję korzystania z integracji COM w wersji 5 lub 6, nie mogę sobie przypomnieć.
Martijn Pieters,

Odpowiedzi:


23

Na początek musimy wyraźnie rozróżnić języki i implementacje . Język jest rzeczą abstrakcyjną, implementacja jest konkretną rzeczą, którą można zmierzyć pod względem wydajności. Na przykład Lisp był kiedyś uważany za zbyt nieefektywny do praktycznego zastosowania, ale kompilatory ciągle dojrzewały, a ostatecznie opracowano dla niego dedykowany sprzęt; w pewnym momencie w latach 80. była to platforma programistyczna z wyboru do tworzenia stacji roboczych o wysokiej wydajności.

To powiedziawszy, najprostszą odpowiedzią jest to, że szybka implementacja Javascript, taka jak Google V8, wysadza standardową implementację Pythona (CPython) z wody . V8 to wysoce zoptymalizowana maszyna wirtualna z JITerem, który jest niesamowicie szybki, podczas gdy CPython jest dość prostą maszyną wirtualną w porównaniu. Istnieje implementacja Pythona z JIT, ale wciąż jest tylko około 5-6x szybsza.

Pięć lat temu byłaby inna historia. Przeglądarki miały uproszczone implementacje Javascript, ponieważ szybkość nie była problemem, ponieważ nikt nie zbudował z nim „prawdziwego” oprogramowania, a Python byłby równy, jeśli nie szybszy.


To najbardziej wnikliwa jak dotąd odpowiedź. Więc to nie jest potencjał, a czas i pieniądze.
Profpatsch,

7
„Pięć lat temu byłaby to inna historia” ... a za pięć lat może być inaczej.
Bryan Oakley,

1
>> Język jest abstrakcyjną rzeczą, implementacja jest konkretną rzeczą, którą można zmierzyć pod względem wydajności << Tak, implementacja języka programowania jest konkretna. Nie, implementacja języka programowania nie ma mierzalnej wydajności właściwości. Wydajność jest właściwością określonych programów korzystających z implementacji języka w określonym kontekście.
igouy 13.03.13

2
@igouy Więc gdybym napisał dwa funkcjonalnie identyczne programy, jeden w C i jeden w Pythonie, uważałbyś różnicę wydajności za właściwość aplikacji, a nie implementację języka?
ConditionRacer

1
@ConditionRacer: Istnieje wiele różnych sposobów pisania tego samego programu, więc nawet jeśli wersja programu w języku Python ma inną charakterystykę wydajności niż wersja C, nie dowodzi to, że żadna wersja języka Python nie może być odpowiednikiem wersji C. Zobacz rzeczy takie jak asm.js ... w dowolnym języku możesz użyć gigantycznej tablicy do przechowywania wszystkich stanów programu i możesz użyć małego, łatwo zoptymalizowanego podzbioru podstawowych operacji języka. (Jak mówią „możesz pisać C w dowolnym języku”).
Mankarse

5

W dawnych czasach internetu, gdy aplety Java były główną jedyną formą interaktywnych treści po stronie klienta, ludzie zdali sobie sprawę, że musi istnieć sposób na uzyskanie formularzy na stronie internetowej, aby móc wchodzić w interakcje z apletami na stronie internetowej.

Na tej podstawie utworzono język skryptowy do połączenia apletu Java ze stroną internetową o nazwie ... javascript.

Pozostałości tego dziedzictwa można zobaczyć dzięki pytaniom SO, takim jak [ 1 ], [ 2 ], [ 3 ] - oraz dwóm oficjalnym dokumentom: Wywoływanie kodu JavaScript z apletu i Wywoływanie metod apletu z kodu JavaScript

Przy takim języku dostępne przeglądarki czasu (przeważnie Netscape) udostępniły javascript jako przewagę konkurencyjną (javascript zaprojektowany w Netscape - Netscape był pierwszym javascript po stronie serwera z jego serwerem w 1994 roku - prawie dwie dekady przed węzłem .js). Inne przeglądarki poszły w tym samym kierunku. Ludzie piszą strony, które używają javascript, inne próby tworzenia skryptów po stronie klienta oznaczałyby całkowicie niekompatybilne strony między rzeczami, które działają, a rzeczami, które nie działają - lub powielaniem kodu (tutaj blok {wstaw język tutaj}, który robi to w przypadku kodu innego niż javascript przeglądarki i tutaj jest blok javascript dla wszystkich innych).

Ponieważ Netscape był przez pewien czas dominującą przeglądarką, JavaScript został utrzymany. Podczas gdy dziedzictwo Netscape zaginęło w przypisach plików źródłowych Mozilli, javascript żyje dalej i nic nie było w stanie go przerzucić.

Problem pozostaje w przypadku każdego innego języka skryptowego slajdów klienta. JavaScript jest obsługiwany w każdej przeglądarce. Jeśli ktoś stworzyłby przeglądarkę obsługującą Python (na przykład) zamiast javascript, nie byłby w stanie korzystać ze zdecydowanej większości stron internetowych. Ponadto, chyba że ta przeglądarka była w stanie uzyskać znaczny udział w ruchu przeglądarki, projektanci stron internetowych nie chcą tworzyć dwóch zestawów stron z różnymi językami skryptowymi dla tej samej strony.

Można spróbować stworzyć wtyczkę do skryptów Pythona dla niektórych przeglądarek, które włączyły skrypt Pythona na stronie ... podobnie jak dzisiaj działa vrml. Ale chyba, że ​​słyszałeś i widziałeś stronę internetową, która używa vrml, jest równie prawdopodobne, że znajdzie zastosowanie dla innej strony internetowej dla innego języka skryptowego.


1
Jest to bardzo dobry przegląd „jak to się stało…” i choć chciałbym zaznaczyć to jako poprawną odpowiedź, odpowiada on na pytanie „Dlaczego Javascript jest dzisiaj używany po stronie klienta?”, A nie „ Czy istnieje problem projektowy, który spowodowałby, że Python byłby zbyt wolny do użytku po stronie klienta? ”
Profpatsch

VRML ... wow, co zabiera mnie z powrotem!
FrustratedWithFormsDesigner

1
@Profpatsch nie ma technicznego problemu z javascript, który sprawia, że ​​jest nieodpowiedni do bycia językiem po stronie klienta - poza tym, że nic go nie używa i chyba że oferuje znaczącą przewagę (prawdopodobnie włączając interaktywność z apletami Java), nic nigdy nie będzie. Problemy nie mają charakteru technicznego i dopóki nie zrozumie się historii „dlaczego javascript”, nie można odpowiedzieć „dlaczego nie python”.

2
@MichaelT: Napisałeś „nie ma technicznego problemu z javascript, który sprawia, że ​​jest nieodpowiedni do bycia językiem po stronie klienta”. Masz na myśli Python, a nie JS?
Carl Smith

@CarlSmith Ahh tak. Mój błąd ... i nie mogę edytować komentarzy po upływie określonego czasu. Dziękuję za poprawę.

4

Nie sądzę, żeby Python był w ogóle zbyt wolny. Nie ma nic w języku, który uniemożliwia mu działanie wystarczająco szybko, aby przynajmniej pasowało do JavaScript. Można go skompilować do JavaScript, więc jeśli nic więcej, możesz dołączyć kompilator do przeglądarki i potencjalnie tylko wydłużyć czas ładowania strony.

AKTUALIZACJA: Przeczytaj poniższe komentarze omawiające, dlaczego kompilacja Pythona do JS byłaby znacznie bardziej kosztowna niż sugerowano tutaj.

Problemem jest próba przekonania dostawców przeglądarki i W3C, aby najpierw wybrali Python, zamiast Ruby lub innego fajnego języka skryptowego, a następnie zdefiniowali ustandaryzowany podzbiór, ponieważ nie mogą zezwolić na wywołania systemowe itp., A następnie dobrze go zaimplementowali, cały czas nadal obsługuje JavaScript. Tak się nie stanie, ale jeśli tak, wątpię, by prędkość okazała się poważnym problemem.


7
Twój pierwszy punkt nie następuje. Wszystko można skompilować do prawie wszystkiego (łącznie z kodem maszynowym), ale to nie znaczy, że program napisany w jakimś języku L i skompilowany do jakiegoś języka C jest tak szybki, jak równoważny program napisany w języku C.

1
Cóż, CoffeeScript jest zasadniczo inną składnią dla tych samych podstawowych pojęć, co JavaScript, a C jest zasadniczo przenośnym językiem asemblera. Z drugiej strony Python i JavaScript różnią się bardzo. Aby poprawnie zaimplementować Python, musisz wesprzeć (między miliardami innych) model klasy, przeciążenie operatora, metaklasy itp., A większość z nich nie odwzorowuje JavaScript w łatwy i wydajny sposób. Ten sam problem z kompilacją jednego z nich do C lub kodu maszynowego. Specjalizujący się JIT może być twoją jedyną nadzieją, ale kompilatory JIT ukierunkowane na JS jeszcze się nie sprawdzą.

3
Jednym z problemów będzie fakt, że nie możesz kompresować Pythona tak, jak możesz JS - wyeliminuj wszystkie te spacje i znaki nowej linii i zacznij ustalanie zakresu! Więc skończysz z dłuższym czasem ładowania dla każdej znacznej części Pythona.
TMN

1
@TMN interesujący punkt, choć można by mieć nadzieję, że ekspresja Pythona znacznie poprawi tę sytuację (i tak, to liczenie linii, a nie znaków, ale mimo to Python jest dość ekspresyjnym językiem).
Daniel B

2
@TMN To, co powiedział Daniel B, a także gzip powinny zmniejszyć różnicę. Aha, a Python nie potrzebuje większości tych nowych linii i spacji. Wiele (choć nie wszystkie) wiersze można dobrze połączyć w Pythonie, np. a = something(); frobincate(a); return quuxI if condition: react()są one pojedynczymi wierszami. N poziomów wcięcia potrzebuje tylko n spacji, a nie n * 4 spacji.

2

Myślę, że Python ma własną maszynę wirtualną. Nie mam dużego doświadczenia z Pythonem, ale nie widzę żadnego powodu, dla którego nie działałby tak dobrze, jak niezoptymalizowany silnik JavaScript.

Kilka przypadkowych myśli:

(1) Prawdopodobnie można uruchomić Pythona lokalnie za pomocą apletu Java przy użyciu Jython. Trudność polega na tym, że aplety są bardzo restrykcyjne, więc może być konieczne zmodyfikowanie Jython w celu dopasowania do ograniczeń dostępu. Na przykład, jeśli zapisuje do pliku dziennika, może być konieczne usunięcie kodu logowania. Aplet nie musi być zauważalnie widoczny.

(2) Ktoś może zbudować „kompilator” / konwerter Pythona na JavaScript. To byłoby dużo pracy.


5
Someone could build a Python-to-JavaScript "compiler"/converterCóż, ktoś już to zrobił .
yannis


Nigdy nie musiałem tego robić sam, ale zdaję sobie sprawę z tego, że ludzie pisali aplety Java przy użyciu Jython. To nie jest to samo, co zamiana Javascript w przeglądarce na Python.
Martijn Pieters

Brythondziała interesująco szybko, przynajmniej w przypadku raczej odizolowanych części na stronach (mała interakcja z DOM tree).
Profpatsch

@Profpatsch Ze stanu, w którym ostatnio patrzyłem, nie implementuje nawet bardzo dużych części języka Python. Dogodnie, wśród niezaimplementowanych funkcji są te, które są mocno implementowane na JavaScript. Parafrazując jednego z autorów PyPy: Łatwo jest szybko stworzyć nietrywialny podzbiór Pythona, a pełny Python staje się trudny.

1

Zależy to od implementacji języka, a niekoniecznie od samego języka. Większość interpreterów JavaScript jest znacznie szybsza niż prawie wszystkie implementacje Pythona.

Nie oznacza to, że języka Python nie można używać z prawie taką samą prędkością jak JavaScript. Opal implementuje prawie pełny język Ruby i standardową bibliotekę w przeglądarce, kompilując kod Ruby w kod JavaScript zawarty w zamknięciach. Pomijając koszty związane z włączeniem biblioteki Opal, jej szybkość jest znacznie bliższa prędkości prostego JavaScript niż jakikolwiek inny interpreter języka Ruby, który znam.

Nie wiem, czy istnieje opalowy odpowiednik Opala, ale taki projekt prawdopodobnie oznaczałby, że odpowiedź na twoje pytanie brzmi „nie”. Wraz ze wzrostem wykorzystania JavaScript jako „języka asemblera dla sieci”, nie zaskoczyłoby mnie, gdyby był on coraz częściej wykorzystywany jako platforma dla innych języków, zwłaszcza gdy zwiększa się moc obliczeniowa urządzeń mobilnych i narzut związany z posiadaniem języka zaimplementowany w JavaScript staje się coraz bardziej zaniedbany.

EDYCJA: Oto lista implementacji języka Python dla przeglądarki kompilującej / uruchamianej w JavaScript.

https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js#python

A jeśli jesteś zainteresowany, możesz sprawdzić Opal, który bardzo mi się podoba.

http://opalrb.org/

Ponieważ wątpię, aby przeglądarki kiedykolwiek oferowały obsługę oddzielnych tłumaczy, takie kompilatory są prawdopodobnie przyszłością pod względem używania języków innych niż JavaScript. Nawet teraz uzyskasz porównywalną wydajność w większości dziedzin. To jednak moja opinia, więc miej to na uwadze.


0

Nawet gdy zadałeś to pytanie, w javascript było już dostępnych wiele implementacji Pythona, których można dziś używać na stronach internetowych.

Zajrzyj na http://www.skulpt.org/ lub http://www.brython.info/ na początek.

Wydajność nie wydaje się być zła, ale powinieneś sam je przetestować i się dowiedzieć.


-4

Python to język „konsoli”, działający na serwerze

JavaScript to język „przeglądarki” działający na kliencie

Jako takie nie konkurują bezpośrednio

... oczywiście jest plik node.js i prawdopodobnie wtyczki do przeglądarki Python, ale wtedy jest to bardziej pytanie o wydajność konkretnej implementacji.

Co więcej, w przypadku większości aplikacji python dobrze sobie radzi, z wyjątkiem sytuacji, gdy trzeba wykonać jakieś obszerne obliczenia i wycisnąć cykle procesora.

Ostatnia uwaga: python i javascript mają wiele podobieństw. Ze względu na ich dynamiczny charakter, oba muszą być interpretowane w czasie wykonywania i nie mogą być kompilowane tak silnie, jak języki o typie statycznym. Jako takie zakładam, że ich osiągalne wyniki byłyby podobne.


2
JavaScript po stronie serwera istniał już w '94. jscpozwala pracować z javascript jako konsolą, podobnie jak można by to zrobić, gdyby pisać pythonna konsoli.

@MichaelT: Ok, odpowiednio zredagowałem swoją odpowiedź
zdiagnozowano

2
Możesz także pisać aplikacje komputerowe w Pythonie .... Nie widzę żadnego prawdziwego powodu, dla którego robisz to rozróżnienie.
Chris Travers

Dodatkowo narzędzie do modelowania 3D Blender używa Pythona do wszystkiego, od interfejsu użytkownika po generowanie siatki. Jeśli to nie jest konkurencyjne, co to jest?
Andrew Gray,

@Chris: różnica polega na tym, że javascript jest przede wszystkim technologią przeglądarki, podczas gdy Python jest głównie technologią typu desktop / konsola. Chodzi mi o to, że porównywanie obu nie ma sensu, ponieważ służą one zupełnie innym celom.
Dagnelies
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.