Co sprawia, że ​​aplikacje HTML5 i JS działają tak dobrze, jak aplikacje rodzime?

Z tego co rozumiem

• HTML jest językiem znaczników, podobnie jak zawartość XAML, XIB i wszelkich innych aplikacji Android oraz innych natywnych platform programistycznych.
• JavaScript jest językiem programowania używanym wraz z nim do obsługi skryptów po stronie klienta, który będzie obejmował między innymi obsługę zdarzeń, sprawdzanie poprawności po stronie klienta i cokolwiek innego, co C #, Java, Objective-C lub C ++ robią w różnych takich ramach.
• Istnieją wzorce MVC / MVVM dostępne w ramach formy, takich jak Sencha, Angular itp.
• Mamy localStorage w postaci zarówno sqlite, jak i magazynu kluczy-wartości, podobnie jak inne frameworki, i masz specyfikację API dla prawie wszystkiego, czego brakuje.
• Ilekroć natywne frameworki interfejsu użytkownika muszą wyświetlać interfejs użytkownika, muszą analizować podobny znacznik i renderować interfejs użytkownika.

Podział pytania

• Co powstrzymuje się od robienia tego samego w HTML i JS?
• Zamiast mieć kontrolę sieci lub przeglądarkę jako warstwę pośrednią, dlaczego HTML (wraz z CSS) i JS nie mogą działać tak samo?
• Nawet jeśli istnieje warstwa, tak samo środowisko uruchomieniowe .net i JVM są w innych przypadkach, w których C ++, C nie są używane.
• Weźmy więc przykład Androida, takiego jak Dalvik, dlaczego Chromium nie może być kolejną opcją (wraz z Dalvik i NDK), w której HTML robi to, co robi znaczniki Androida, a JavaScript robi to, co robi Java?

Pytanie brzmi:

Nawet jeśli obecne implementacje nie są tak dobre, ale teoretycznie jest możliwe, aby aplikacje oparte na HTML5 działały jak inne aplikacje natywne specjalnie na urządzenia mobilne?

Chłopiec plakatu dla aplikacji HTML5, LinkedIn wyszedł na rynek na początku 2013 roku. W wywiadzie dla VentureBeat wyjaśniają dlaczego.

Myślę, że jest to część najbardziej odpowiednia dla twojego pytania:

Prasad powiedział, że problemy z wydajnością nie powodują awarii ani nie spowalniają działania aplikacji. To, co powiedział, pokazuje, że HTML5 dla mobilnej sieci wciąż ma przed sobą świetlaną przyszłość - ale tylko wtedy, gdy programiści są gotowi stworzyć narzędzia do jej obsługi.

...

Krytycznie brakuje kilku rzeczy. Jednym z nich jest obsługa narzędzi - posiadający działający debugger, narzędzia wydajności, które informują o tym, gdzie kończy się pamięć. Jeśli spojrzysz na Androida i iOS, istnieją dwie bardzo duże korporacje, które koncentrują się na tworzeniu narzędzi, które dostarczają wielu szczegółowych informacji, gdy coś pójdzie nie tak w produkcji. Po stronie mobilnej uruchomienie narzędzi komputerowych do pracy na urządzeniach mobilnych jest naprawdę trudne. Drugi duży fragment, z którym zmagamy się, to funkcjonalność i informacje diagnostyczne środowiska wykonawczego. Nawet teraz, gdy budujemy HTML5, budujemy go jako aplikację po stronie klienta. To bardziej architektura klient-serwer. … Funkcjonalność tego, dostarczając nam informacji, gdy jesteśmy dystrybuowani do dużej liczby użytkowników, nie ma tak wielu świetnych narzędzi do obsługi tego.

[Prasad zauważył również, że narzędzia programistów i operatorów do szybkiego rozwiązywania problemów „nie istnieją”]

Ponieważ te dwie rzeczy nie istnieją, ludzie wracają do ojczystych. Nie chodzi o to, że HTML5 nie jest gotowy; to, że ekosystem go nie obsługuje. … Są narzędzia, ale są na początku. Ludzie po prostu zastanawiają się nad podstawami.

Brak standardowej biblioteki Javascript jest strasznym inhibitorem. Istnieją świetne frameworki, takie jak jQuery, Dojo, YUI, aby wymienić tylko kilka, ale wszystkie z nich są skoncentrowane wyłącznie na warstwie prezentacji i XHR.

Czy chcesz konfigurowalnego rejestrowania, narzędzi kryptograficznych, algorytmów grafowych, generatorów UUID, map, zestawów, drzew, szablonów, zarządzania zależnościami, manipulacji datami, lokalizacji / internacjonalizacji, operacji matrycowych, wstrzykiwania zależności, testów jednostkowych, redukcji map, przetwarzania XML? Trivial dla języków JVM lub .NET - w Javascripcie często musisz stworzyć własną implementację.

Jednym z powodów, dla których Javascript jest wolny, jest całkowity brak bezpieczeństwa typu. Każda zmienna może być dowolnego typu w dowolnym momencie. Ponadto większość operacji jest prawidłowa dla wielu różnych typów, ale ma inną semantykę . Prosty termin

a += b;

nie jest to takie proste dla interpretera, ponieważ ai bmoże być cyframi lub łańcuchami. Gdy oba są liczbami, jest to dodatek arytmetyczny. Gdy oba są ciągami, jest to konkatenacja ciągów. Jeśli jeden jest ciągiem, a drugi jest liczbą, liczbę należy sformatować przed wykonaniem konkatenacji ciągu. Są to całkowicie różne operacje, które wymagają różnej interpretacji argumentów.

W zależności od typu ai b, typem amoże być teraz liczba całkowita, podwójna lub ciąg, niezależnie od tego, jaki był wcześniej.

Ponieważ zmienne w JS mogą zmienić swój typ w dowolnym momencie, interpreter prawie nie przechodzi do oceny typów za każdym razem, gdy wywoływana jest ta instrukcja, aby uniknąć wykonania niewłaściwej operacji. Wymaga to dodatkowych cykli procesora.

Inne funkcje, które znacznie utrudniają optymalizację, to rzadkie tablice lub odśmiecanie pamięci i procedury obsługi zdarzeń, które mogą być uruchamiane w dowolnym momencie.

Spójrz na asm.js - jest to podzbiór Javascript, który pozwala na znacznie lepszą optymalizację poprzez pozbycie się niektórych funkcji JS, w szczególności dynamicznego pisania.