Еще с 90-х я пытался освоить javascript, html и позже css. Я не смог. Я редко жалуюсь на трудности использования указателя и шаблона C ++, но я ненавижу стек веб-интерфейса.
Хотя ситуация постоянно меняется, от использования тега ‹table› повсюду до повсеместного распространения Angular.js и React.js, основы ощущаются одинаково. Для меня каждое обновление технологии веб-разработки - это всего лишь небольшой пластырь, прикрывающий взрывную рану.
Html был впервые изобретен как формат документа, как и файл .docx в офисе Microsoft. Сегодня, если вас попросят использовать слово Microsoft для разработки приложения, вы подумаете, что это просто смешно. Однако эта нелепость давно стала нормой для разработки веб-приложений.
Когда мы проектируем фреймворк, платформу или библиотеку, мы хотим создать для них разные уровни абстракций. Например, у нас есть язык ассемблера для низкоуровневой быстрой логики, у нас есть C ++ для разработки драйверов и операционных систем среднего уровня, а также у нас есть Python для продуктивной и кроссплатформенной разработки. Мы определяем tcp / ip как основу, а затем http поверх. Мы создаем низкоуровневые графические API, такие как OpenGL, и на его основе мы создаем игровые движки. Это распространенный и разумный шаблон проектирования. Преимущество этого в том, что вы, как пользователь, можете выбирать уровень функций. Если вам нужен более тонкий контроль, вы выбираете вещи низкого уровня. Если вы просто хотите использовать готовые решения и не нуждаетесь в настройке, вы выбираете высокоуровневые API. Вы можете наслаждаться безопасностью, имея возможность изменить все, если захотите.
В качестве примера возьмем библиотеку пользовательского интерфейса iOS. Он построен на основе низкоуровневого графического элемента под названием CALayer. CALayer - это не что иное, как прямоугольный патч, на котором вы можете рисовать свою графику. Вдобавок к этому у нас есть UIView, который использует CALayer для создания графики, а также имеет обработку событий и так далее. Вы всегда можете использовать элементы пользовательского интерфейса по умолчанию, такие как UIButton. Но всякий раз, когда вы хотите иметь более привлекательный компонент пользовательского интерфейса, который не является частью значений по умолчанию, вы знаете, что всегда можете перейти на более низкий уровень, нарисовать все, что вам нравится.
Уровневое проектирование - это концепция, которую редко можно найти в веб-стандартах. По сути, все теги обрабатываются одинаково. Можете ли вы, например, настроить тег ‹a›? Вы можете, только до определенной степени, например, украсить его с помощью css. Или вы подделываете настройку, комбинируя множество тегов, что неэффективно для загрузки и отображения (например, используя теги ‹div› для формирования индикатора выполнения).
Другой пример - стандарты веб-видео, такие как WebRTC и Media Source API. Если бы я разрабатывал эти стандарты, я бы делал это уровень за уровнем. Во-первых, сделаю стандарт, который ничего не делает, кроме декодирования видео. Затем я добавляю еще один уровень для улучшения качества видеопотока, например, добавляю буфер дрожания для улучшения плавности. Затем, наконец, в дополнение к этому, я решаю проблему подключения, например, добавляя P2P.
Пользователи смогут выбирать и настраивать каждый уровень, если захотят. Сценарий использования потоковой передачи игр или настольных компьютеров предпочел бы низкую задержку плавности, в этом случае разработчики могут настроить логику буферизации. Однако случай с видеотрансляцией предпочел бы плавность, они меньше заботятся о своевременной доставке.
Однако и WebRTC, и Media Source API были спроектированы как большой монстр, который выполняет только одну конкретную задачу. У вас нет возможности настроить его в соответствии с вашими потребностями. Вы задавались вопросом, почему качество удаленного рабочего стола Chrome такое плохое? Потому что он использует WebRTC, предназначенный для P2P-чата.
Как метафора, написание C ++ похоже на использование карандашей. Качество ваших художественных работ зависит от вашей способности их использовать. На освоение требуется время, но теоретически, если вы хотите и достаточно хороши, вы можете рисовать карандашами все, что вам нравится. Однако написание веб-приложений похоже на заполнение книжек-раскрасок. Вы можете делать только то, что ограничено линией книжки-раскраски. Вам сложно сделать что-то нестандартное.
И все же javascript, html и css настолько популярны, что у нас нет выбора. У нас, безусловно, есть спрос на веб-приложения, ведь их очень удобно запускать. Нет необходимости устанавливать, поддерживать и создавать резервные копии файлов. Но действительно ли веб-приложениям нужны javascript, html и css? Я думаю, что на самом деле они зависят от способа их загрузки без установки, от широко распространенного межплатформенного бинарного стандарта и от среды выполнения в песочнице. На самом деле нет необходимости в медленном дереве документов, это имеет смысл только для «документа».
Но я думаю, что с введением WebAssembly все может измениться. Я, как программист на C ++, который чувствовал себя отстраненным от разработки внешнего интерфейса, наконец-то чувствую себя подходящим. Хотя в моем идеальном мире WebAssembly выйдет первым и станет фундаментальным, а затем мы построили html и дерево документов поверх него. . Сейчас все наоборот, но все же улучшение.
В 2007 году, работая над своим проектом 3D-моделировщика, я разработал библиотеку графического интерфейса OpenGL на C ++ под названием AssortedWidgets. Недавно я без особых усилий перенес этот код в WebAssembly. Это действительно потрясающе - видеть его работающим в сети!
