Pull to refresh

Common Language Infrastructure (CLI) для веба

Reading time 4 min
Views 2.1K
Original author: Miguel de Icaza
Внимание, перевод одного интересного поста из блога Мигеля!

Последние дни Joe Hewitt в твиттере сильно переживал за состояние клиентских веб технологий. TechCrunch вели репортаж о состоянии прогресса в их обзоре The State Of Web Development Ripped Apart In 25 Tweets By One Man (Состояние Веб Разработки в 25 твитах одного человека).

Сегодня Joe предложил блестящую идею:

Если встроить ECMA CLI в браузеры вместо ECMAScript, веб стал бы намного гибче.

ECMA CLI дала бы вебу и строго типизированные и динамические языки программирования. Она дала бы разработчикам выбор между производительностью и скриптуемостью. Выбор языка программирования (использование оптимальных инструментов под конкретную задачу) сделал бы веб страницы намного быстрее, просто переведя жизненно важный код на строго типизированные языки.

Разнообразные языки программирования стали бы первоклассными жителями клиенского веба. Много языков доступно уже и сейчас, но они работают при помощи плагинов. Они могут исполняться на Flash или Silverlight, но этот путь пока не настолько гладок: они работают на отдельных виртуальных машинах, они ограничены тем, как происходит взаимодействие с браузером через убогий API (существует около 20 методов интеграции плагина с браузером, и наиболее продвинутые сценарии взаимодействия требуют серьезных хаков и глубоких знаний внутреннего устройства конкретного браузера).

Возможно настало время поэкспериментировать с интеграцией ECMA CLI в браузер. Не как отдельным плагином, не как плагином-платформой, а как первоклассной виртуальной машиной внутри самого браузера, работающую параллельно с движком Javascript-а.

Эти исследования ставили бы перед собой две цели:
  1. Доступ к новым языкам внутри браузера, опционально статически типизированные языки для значительного прироста производительности.
  2. Новая платформа для инноваций браузера, обеспечивающая безопасный механизм расширения API браузера.

Мы могли бы сделать это, напрямую прилинковав Mono к браузеру. Это позволило бы разработчикам писать код типо такого:

<script language="csharp">
  from email in documents.ElementsByTag("email") 
    email.Style.Font = "bold";
</script>

Или подгружая исходники с сервера:

<script language="csharp" source="ImageGallery.cs"/>

Мы могли бы заменить 'csharp' любым существующим open-source компилятором (C#, IronPython, IronRuby и т.д.).

Или по-другому, если разработчики не хотят распространять свои исходники, вместо этого публикую компактный бинарник для конечных пользователей, они могли бы встраивать бинарный CIL напрямую:

<script language="cil" source="MailApp.dll"/>

Сразу предвижу вопрос насчет «незащищенных исходников»: да, вы можете использовать .NET Reflector, чтобы просмотреть исходные тексты скомпилированного бинарника. Но если код обфусцирован, вам это доставит приблизительно такое же удовольствие, как чтение Javascript-а в современном вебе.

Внедрение CIL в браузеры создало бы изолированную исполняемую среду для каждой страницы (AppDomain в терминах ECMA) и «песочницу» для исполняющей системы.

Модель безопасности предлагаемая Silverlight, предоставляет как раз столько, сколько нужно для того, чтобы безопасно выйти за пределы CLI рантайма. Эта модель безопасности различает между ненадежным (untrusted) кодом, который необходимо проверять по жестким требованиям того, что этому коду разрешено делать и что — нет, а также между т.н. «платформенном» кодом, которому мы целиком и полностью доверяем (trusted).

Trusted коду даются специальные полномочия, которых у untrusted кода нет. Рантайм гарантирует, что ненадежный код не сможет вызвать критический (с точки зрения безопасности) и защищенный код.

Это позволило бы производителям браузеров предоставить новый API, который бы дал полный доступ к низлежащей операционной системе (к примеру, прямой доступ к такому специализированному железу как микрофон и веб-камера), в то же время гарантируя то, что пользовательский код получает доступ к ней только безопасными способами.

Очень важно дать разработчикам попробовать новый доверенный «платформенный» API: новые UI модели, системы рендеринга и API, все построенные на одном и том же ядре.

Я абсолютно очарован этой идеей и сожалею только, что не мне первому она пришла в голову. Мы были слишком сконцентрированы на нашем плагине Moonlight для того, чтобы вернуться на шаг назад и взглянуть на проблему шире: как мы можем использовать ядро ECMA CLI для *всех* приложений без браузерного плагина вообще.

Joe, как и многие другие из нас, находятся в противоречии между страшной силой проникновения веба и той филигранностью и скоростью, которыми обладают GUI toolkit-ы.

Хотя Silverlight обеспечивает прекрасную UI систему внутри плагина, идея Joe в том, что нам нужна платформа, на которой мы могли бы еще быстрее изобретать и обкатывать новые UI идеи, и возможно даже кардинально новые UI. И с ECMA моделью «песочницы», мы могли начать тестировать новые идеи без ожидания того, когда там производители браузеров сами добавят нужные нам новые функции. Мы могли бы интегрировать наши плагины в браузер сильнее, чем это сейчас вообще возможно.

Существующая модель плагинов не обеспечивает необходимых возможностей, чтобы развивать веб-инновации. Нам нужна новая модель, и я готов начать с прототипа идеи Joe.

Единственный вопрос — с какого браузера начать — Firefox или Chrome.

Gestalt

Gestalt позволяет разработчикам использовать CLI внутри браузера, а также демонстрирует то, как в браузерах можно использовать другие языки. Он требует Silverlight плагин, но взаимодействие между кодом и браузером ограничено тем уровнем интеграции, которая доступна браузерному плагину.

Итак, решена только половина проблемы — многоязычность ЯП, да и то, делается это достаточно ограниченным способом.

[Примечания переводчика]
CLI — Common Language Infrastructure, подсистема .NET/Mono
CIL — Common Intermediate Language, байткод язык .NET/Mono
Tags:
Hubs:
+20
Comments 143
Comments Comments 143

Articles