Вопросы, касающиеся JavaScript, WebSockets, WebGL

Я видел много вопросов о stackoverflow, касающихся других языков сценариев на стороне клиента.

Интернет становится очень насыщенным и динамичным местом. Спецификации HTML и CSS пытаются вывести Интернет на новый уровень — мы получаем поддержку WebSockets, которая очень удобна для полнодуплексной связи клиент-сервер, позволяя появляться некоторым интересным шаблонам проектирования. Кроме того, у нас есть работающая реализация WebGL на JavaScript, с которой я до сих пор очень развлекался.

Но это вызвало некоторые опасения, по крайней мере, у меня. Я настольный программист, C/C++/Objective-C - в зависимости от платформы. В частности, архитектор рендеринга.JavaScript прекрасно послужил всем нам, не так ли? Мы использовали его для получения базовых взаимодействий пользователей с двухмерными линейнымивеб-сайтами, реагирования на простые события и объединения всего этого с HTML и CSS.

Учитывая тот факт, что двери для общения в реальном времени и визуализации на основе графического процессора были открыты для Интернета, повлияет ли это на JavaScript?Я видел реакцию на Dart и другие попытки вытеснить JavaScript. . JavaScript слабо типизирован, что вызывает у меня всевозможные тревоги (учитывая интенсивную математическую библиотеку, которая зависит от скорости, ненужная проверка во время выполнения не доставляет удовольствия).

Я перенес большую часть кода на графический процессор, но даже тогда мой внутренний рендерер просто привязан к центральному процессору (HD6990 не может быть проблемой, не говоря уже о коде, который приводит в действие настольный/встроенный движок). ).

Итак, вот оно:

• Код лежит обнаженнымиз-за дизайна интерпретатора. Технологии и решения рендеринга стоят больших денег. Это единственная основа моей компании, и она оплачивает счета. Обфускация не помогает (поправьте меня, если я ошибаюсь). Я всегда задавался вопросом, почему нет промежуточного процесса компиляции в форму байт-кода, которая может быть обработана виртуальной машиной?

• Он слабо типизирован. Жонглирование матрицами, векторами, кватернионами, массивами и всеми другими видами данных, характерными для высокоинтерактивных приложений, просто раздувает обработку проверкой во время выполнения. Несмотря на то, что в конечном итоге он переходит на сторону графического процессора, вам все равно приходится выполнять изрядную часть работы на стороне процессора, которая увязла в JavaScript.

• Парадигма, основанная на прототипах, ослабит усилия крупных игроков по переносу кода рендеринга, которые могут продвигать внедрение WebGL/WebSockets. (помните, что многое из этого управляется процессором). Сохранится ли парадигма, основанная на прототипах, по мере того, как все больше и больше пользователей будут требовать высококачественного 2D/3D-контента?

• Веб-сокеты зарекомендовали себя как прекрасное новое дополнение к веб-играм (BrowserQuest), не говоря уже о динамических веб-сайтах, и в будущем многие люди будут использовать их для разработки потрясающего контента (моя компания ведет небольшой закрытый проект который реализует небольшую MMO в 3D-среде, управляемой WebSockets).

Итак, имеют ли мои опасения под собой реальную основу?

Есть ли какие-либо новые движения в отношении этих проблем?

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