Що зупиняє програми HTML5 та JS настільки ж добре, як рідні програми?

З того, що я розумію,

HTML є мовою розмітки, як і вміст XAML, XIB та будь-якого Android, що використовується, та інших натурних систем розробки інтерфейсу.
JavaScript - це мова програмування, яка використовується разом із ним для обробки сценаріїв на стороні клієнта, які включатимуть такі речі, як обробка подіями, перевірка на стороні клієнта та все інше, що C #, Java, Objective-C або C ++ роблять у різних таких рамках.
Є схеми MVC / MVVM, доступні у таких формах, як Sencha, Angular тощо.
У нас є localStorage у вигляді зберігання sqlite та ключа-значення, як у інших фреймворках, і у вас є специфікація API для майже всього, чого у нього немає.
Кожен раз, коли нативний фреймворк інтерфейсу повинен надавати інтерфейс користувача, він повинен проаналізувати подібну розмітку та надати інтерфейс користувача.

Розбір питань

Що не дозволяє робити те ж саме в HTML та JS?
Замість того, щоб веб-контроль або браузер були шаром між тим, чому HTML (разом із CSS) і JS не можуть бути виконані так само?
Навіть якщо є шар, так само .net час виконання і JVM є в інших випадках, коли C ++, C не використовуються.
Тож давайте візьмемо у випадку Android, як Dalvik, чому Can't Chromium є іншим варіантом (поряд з dalvik та NDK), де HTML робить те, що робить розмітка Android, а JavaScript використовується для того, що робить Java?

Отже, Питання:

Навіть якщо поточні реалізації не такі хороші, але теоретично чи можна змусити додатки на базі HTML5 працювати як інші вбудовані програми спеціально на мобільних пристроях?

— Амо Талпалікар
джерело

прошу уточнити, з яких тверджень ви починаєте, і що є власне питанням.

— funkybro

Чи можете ви пояснити, що ви маєте на увазі під "Що не дозволяє робити те саме в HTML і JS?" Я не розумію, що ви маєте на увазі під "тим же самим" - ви раніше робили чотири заяви, і я не впевнений, про що ви маєте на увазі в цьому питанні.

— апсилери

Якщо у мене є власна платформа розробки, яка використовує HTML як розмітку замість чогось нового. і використовує JS як мову, чи буде продуктивність кращою? У цьому вході / виводу Google зазначив, що вони практичні та використовують Android на телефоні, а не на Chrome OS. Так це означає, що FF OS не є практичною концепцією? чи можна, щоб додатки FFOS працювали так само добре, як програми для Android на відповідних платформах, якщо дотримуватися всіх найкращих практик?

— Amogh Talpallikar

Погляньте на програми Windows Metro. Це рідні програми, які використовують HTML для розробки графічного інтерфейсу та Javascript для логіки.

— Філіпп

Продуктивність HTML / JS, як правило, більш ніж хороша для користувальницького інтерфейсу, який відображає інформацію, і на основі дій користувача робить запити на зовнішній сервер. Спочатку він не будувався для цього більше, але на сьогоднішній день він вражаючий. Тим не менш, для ситуацій, що передбачають більш прямий доступ до пристроїв, взаємодію з нативним кодом або взаємодію з операційною системою (тобто сповіщення), все ще не існує хорошого способу використання веб-технологій загального призначення для цього.

— Katana314

Відповіді:

Хлопчик з плакатів для програм HTML5, LinkedIn пішов рідним на початку 2013 року. В інтерв'ю в VentureBeat вони пояснюють, чому.

Я думаю, що це частина, найбільш відповідна для вашого питання:

Прасад сказав, що проблеми з продуктивністю не спричиняють збоїв або змушують програму працювати повільно. Що він сказав, це свідчить про те, що HTML5 для мобільної мережі все ще має світле майбутнє - але лише якщо розробники готові створити інструменти для його підтримки.

...

Є кілька речей, яких критично не вистачає. Одне - це підтримка інструментарію - наявність налагоджувача, який фактично працює, інструменти для виконання, які підказують, де вичерпано пам'ять. Якщо ви подивитесь на Android та iOS, є дві дуже великі корпорації, які зосереджені на побудові інструментів, щоб дати багато детальної інформації, коли справи йдуть не так у виробництві. Що стосується мобільного Інтернету, отримати ці інструменти на робочому столі для мобільних пристроїв дуже важко. Другий великий фрагмент, з яким ми боремося, - це працездатність, діагностика часу виконання. Навіть зараз, коли ми створюємо HTML5, ми створюємо його як додаток для клієнта. Це більше архітектура клієнт-сервер. … Працездатність цього, що дає нам інформацію, коли ми розповсюджуємо велику кількість користувачів, також не так багато чудових інструментів для підтримки.

[Прасад також зазначив, що інструменти розробки та оперативної системи для вирішення питань швидко "не існують".]

Оскільки ці дві речі не існують, люди повертаються до рідного. Справа не в тому, що HTML5 не готовий; це те, що екосистема її не підтримує. … Є інструменти, але вони на початку. Люди лише з'ясовують основи.

— vartec
джерело

Я не розумію. У нас дуже великі корпорації: Google, Microsoft, Apple, орієнтовані на підтримку Chrome, Safari та IE. У нас Mozilla прихильна до Firefox. У нас є інструменти Chrome Dev, веб-інспектор, Firebug. А Прасад каже, що інструментів немає?

— niutech

@niutech: дозволяє сказати, що ви хочете такий інструмент, як Valgrind для програми HTML5. Тут не так багато.

— vartec

Відсутність стандартної бібліотеки Javascript - жахливий інгібітор. Існує велика кількість фреймворків, таких як jQuery, Dojo, YUI, але всі вони зосереджені виключно на презентаційному шарі та XHR.

Ви хочете настроювати журнал, криптографічні інструменти, алгоритми графіків, генератори UUID, Карти, набори, дерева, шаблони, управління залежностями, маніпуляцію датами, локалізацію / інтернаціоналізацію, матричні операції, введення залежності, тести одиниць, зменшення карт, обробку XML? Trivial для мов JVM або .NET - у Javascript вам часто доводиться прокручувати власну реалізацію.

— Марос Урбанек
джерело

Додайте до цього звітність.

— Алан Б

ECMAScript 6 додає більшість цих функцій. Бібліотека закриття Google - це ще одне рішення.

— niutech

Кутовий забезпечує приємний декларативний шлях зараз.

— Amogh Talpallikar

Однією з причин того, що Javascript повільний, є його повна відсутність безпеки типу. Будь-яка змінна може бути будь-якого типу в будь-який час. Крім того, більшість операцій дійсні з багатьма різними типами, але мають різну семантику . Простий термін

a += b;

НЕ то, що тривіальне для перекладача, так aі bможуть бути числами або рядками. Коли обидва - це числа, це арифметичне доповнення. Коли обидва є рядковими, це об'єднання рядків. Коли один - це рядок, а один - число, це число слід відформатувати перед тим, як здійснити конкатенацію рядків. Це абсолютно різні операції, які вимагають інтерпретувати аргументи по-різному.

Залежно від типів aі b, тип aможе тепер бути цілим, подвійним або рядковим, незалежно від того, який тип він був раніше.

Оскільки змінні в JS можуть змінити свій тип у будь-який час, інтерпретатор навряд чи може обійтися оцінкою типів, коли ця інструкція викликається, щоб уникнути неправильної операції. Для цього потрібні додаткові цикли процесора.

Інші функції, які роблять оптимізацію значно складнішою, - це розріджені масиви чи збирання сміття та обробники подій, які можуть вистрілити в будь-який час.

Погляньте на asm.js - Це підмножина Javascript, яка дозволяє значно покращити оптимізацію, позбувшись деяких функцій JS, особливо динамічного набору тексту.

— Філіп
джерело

Сучасні компілятори Javascript JIT генерують спеціалізований машинний код на ходу для типів, які ви використовуєте, якщо вони стабільні при вашому фактичному використанні під час виконання. Якщо ви дійсно кодуєте таким чином, що aможе бути цілим, рядковим чи подвійним тощо, то ви маєте рацію. І звичайніші браузери, які все ще використовують інтерпретатори, звичайно, також не мають цих оптимізацій.

— Есаїлія

@Esailija Сучасні середовища JavaScript набагато-набагато швидші, ніж старі. Але вони все ж повільніші порівняно зі статично типовими сучасними середовищами, такими як .NET, JVM, ErlangVM тощо.

— Девід Сергій

@nirth так, я не кажу про це, просто кажу, що цей пост описував, як інтерпретатор / неоптимізуючий компілятор jit зробив би це, і це серйозно повільно.

— Есаїлія