Я видел разработчиков, которые долгое время работали с C, но все еще разрабатывали с использованием MFC (Microsoft Foundation Classes). Причина проста: реальных альтернатив для создания пользовательских интерфейсов на C не существует. Хотя Qt существует, для его профессионального использования требуется коммерческая лицензия, поэтому MFC является единственным вариантом.

MFC предоставляет базовые компоненты пользовательского интерфейса, но при этом позволяет создавать программы производственного уровня, такие как программное обеспечение САПР или приложения для больниц.

Текущее состояние экосистемы JavaScript очень похоже.

Не существует какой-либо структуры, специально созданной для достижения целей HPSE. Хотя существуют игровые движки, такие как Babylon.js, они предлагают только функции для 3D-графики и не предоставляют всеобъемлющей структуры, как React.

Итак, в конце концов, все возвращается к Vanilla JavaScript и TypeScript. Дело не в том, что разработчики используют Vanilla JavaScript потому, что им он нравится; они используют его, потому что другого выбора нет. Точно так же, как в первые дни, когда разработчикам приходилось создавать все с нуля на C из-за отсутствия коммерческих фреймворков, сейчас мы сталкиваемся с той же ситуацией в JavaScript. Не существует существующей платформы, полностью отвечающей требованиям HPSE, поэтому нам приходится вручную разрабатывать с использованием Vanilla JavaScript.

И, честно говоря, это касается не только JavaScript. Это справедливо и для большинства других языков.

Есть поговорка: «Бесплатных обедов не бывает».

Многие программы, которые начинались с грандиозных амбиций выйти за новые границы, в конечном итоге в значительной степени полагались на специальные функции, встроенные непосредственно в язык программирования. HPSE тоже начиналась с идеи, что когда-нибудь нативные программы будут запускаться в браузере, а сейчас ее нужно писать по частям на Vanilla JavaScript.

Некоторые могут возразить: «Почему бы просто не отказаться от JavaScript и не использовать C или Rust для создания модуля WebAssembly (WASM) и вместо этого запускать его в браузере?»

Есть хорошая история, которая отвечает на этот вопрос.

Лидеров Babylon.js и Three.js однажды спросили в комментарии, станет ли технология WASM будущим их движков. Их ответ был «Нет».

Причина проста: код C/Rust не запускается напрямую в веб-среде, что усложняет отладку. А благодаря достижениям движка V8 JavaScript теперь может достигать высокой производительности. JavaScript — это язык сценариев, который запускается непосредственно в браузере и обеспечивает высокую производительность — нет необходимости отказываться от этих преимуществ.

В прошлом программисты соревновались в разработке собственных операционных систем. Но после того, как Windows, Mac и Linux стали стандартами, акцент сместился на создание программ, работающих поверх этих систем. Точно так же современные браузеры развились до такой степени, что разумно задуматься о том, как создавать программы, работающие в них.

Если бы были четкие границы того, для чего следует и не следует использовать JavaScript, и если бы высокопроизводительные задачи действительно не подходили для JavaScript, то Microsoft никогда бы не запустила проект Babylon.js, а Three.js никогда бы не запустил его. были созданы. То же самое касается и WebGPU, который устанавливается как новый веб-стандарт.

Недавно я размышлял о своей личности как разработчика, задаваясь вопросом, что именно означает «интерфейсный интерфейс» и может ли этот термин действительно охватывать сферу разработки веб-клиентов.

Я уверен, что в моих мыслях много дезинформации, но я опубликую это как свою первую запись в блоге, чтобы закрепить свои мысли.