2 сентября Google выпустил публичную бета-версию собственного браузера – Chrome. Событие легко списать на маркетинг: Internet Explorer держит около 70% рынка, Firefox уверенно растёт, и место для четвёртого игрока кажется тесным. Но Chrome бьёт не в долю рынка, а в архитектуру. И именно архитектура определяет, насколько серьёзно бизнес сможет переносить свои системы в браузер.

Что Google изменил под капотом

Главное в Chrome – движок JavaScript под названием V8. Он компилирует код в машинные инструкции вместо построчной интерпретации, и на тяжёлых сценариях это даёт прирост в разы по сравнению с IE 7. Для статичного сайта разница незаметна. Для интерфейса, где половина логики крутится на стороне клиента – почтовый клиент, CRM, система согласования заявок – это разница между «терпимо» и «работает как настольное приложение».

Второе решение – изоляция вкладок. Каждая вкладка в Chrome выполняется отдельным процессом. Зависший скрипт на одной странице не валит весь браузер и не уносит несохранённые данные в соседних окнах. Для пользователя, который весь день держит открытым рабочий портал, это не косметика, а вопрос сохранности работы.

Microsoft, к слову, тоже движется в эту сторону: вышедшая в августе бета IE 8 обещает изоляцию вкладок и ускоренный JavaScript. Конкуренция запущена, и проигравшим окажется тот, кто остановится.

Почему это касается корпоративных систем

Несколько лет отрасль спорила, можно ли вообще строить серьёзные бизнес-приложения в браузере. Появление Gmail и Google Maps показало, что AJAX-интерфейсы способны на многое, но упирались они в одно – производительность движка. Гонка браузеров снимает этот потолок. Чем быстрее исполняется JavaScript и чем стабильнее работает вкладка, тем меньше причин ставить пользователю отдельный клиент.

Для заказчика из бизнеса и госсектора выгода прямая. Веб-приложение не требует установки на каждое рабочее место, обновляется централизованно и одинаково доступно из любой точки. Снимается боль администрирования сотен машин – особенно там, где парк техники разнороден, а штат поддержки ограничен. Поэтому при разработке корпоративных информационных систем заказчики всё чаще просят именно браузерный интерфейс вместо толстого клиента.

Но у медали есть оборотная сторона. Пять браузеров с разными движками – это пять сред, в которых интерфейс обязан вести себя одинаково. Кроссбраузерная вёрстка и тестирование перестают быть необязательной строкой в смете. Закладывать их нужно с самого начала, и здесь полезно заранее решить, что писать своими силами, а что отдать подрядчику – мы разбирали это в материале о моделях разработки на аутсорсе.

Что учесть при планировании

Перенос системы в браузер не отменяет базовых требований к надёжности. Логика на клиенте ускоряет интерфейс, но данные по-прежнему живут на сервере, и их сохранность остаётся зоной ответственности заказчика. Перед переходом на веб стоит ещё раз пройтись по схеме резервного копирования и непрерывности бизнеса – централизованное приложение делает сервер единой точкой отказа, и эту точку нужно прикрыть.

Практический вывод на сегодня простой. Не спешите менять корпоративный стандарт браузера ради беты – Chrome ещё сырой, и в продакшене ему рано. Но закладывайте в новые проекты ориентир на быстрый JavaScript и кроссбраузерность. Гонка движков началась всерьёз, и через год-два планка производительности веб-приложений будет совсем другой. Кто проектирует системы с запасом сегодня, тот не будет переписывать их завтра.