Основной причиной создания форка является возросшая трудоёмкость параллельного поддержания разработки отдельной многопроцессной модели, изначально используемой в Chromе, но неприемлемой для универсального движка WebKit и некоторых других браузеров. Суть различий сводится к тому, что WebKit2 предоставляет специальный фреймворк для разделения по разным процессам обработки контента и формирования интерфейса, а механизм разделения по процессам Chrome основан на идее использования WebKit WebCore в качестве одного из многопроцессных модулей, взаимодействующих с другими модулями через отдельный диспетчер ресурсов. Последнее время наблюдается постоянное усложнение кода как WebKit, так и Chromе, что заметно тормозит разработку Chromе из-за необходимости постоянного портирования кода. Кроме того, отмечается, что с созданием форка у Google появятся новые возможности по оптимизации движка и увеличению производительности, требующих внесения кардинальных изменений в WebKit.

В представленном в 2008 году браузере Chrome компания Google использовала подсистему WebKit WebCore для рендеринга HTML и CSS, но вместо JavaScript-движка WebKit JavaScriptCore использовала собственный движок V8. Фактически компания Google изначально развивает в Chrome форк WebKit, так как использует в своём браузере отдельную ветку WebKit, непосредственно внося в неё собственные изменения и портируя сторонние изменения из WebKit, после чего возвращая свои улучшения в upstream. В WebKit2 появилось много новых возможностей и особенностей, которые не намерена использовать Google, но которые приходится учитывать при портировании. В итоге затрачиваемые на портирование ресурсы стали неприемлемо велики. Создание Blink снимает с Google обязательства по возврату изменений в WebKit.

О намерении перейти к использованию движка Blink, уже заявила компания Opera, находящаяся в процессе миграции на WebKit с собственного движка Presto. Таким образом, сформированное вокруг WebKit сообщество раскололось на два лагеря, представляющих технологии и интересы проектов Google Chrome и Apple Safari. Следует напомнить, что, в свою очередь, проект WebKit был создан в 2001 году как форк движка KHTML, развиваемого сообществом KDE.

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

Дополнительно можно отметить решение избавиться от CSS-префиксов для экспериментальных возможностей. Вместо префикса "-webkit" решено не вводить префиксы "-blink" или "-chrome", а последовать примеру Mozilla и добавлять все экспериментальные возможности без префиксов, но включать их только при изменении специальных настроек в браузере.

Из планов по дальнейшему развитию архитектуры Blink можно отметить:

• Реализация обработки содержимого iframe в отдельном изолированном процессе. В WebKit указанная возможность не может быть интегрирована, так как она требует значительной реструктуризации методов обработки iframe и завязана на особенностях sandbox-изоляции и методов управления процессами в Chrome.
• Ускорение и упрощение кода для обеспечения сетевого взаимодействия. Сетевая подсистема WebKit ограничена необходимостью обеспечения совместимости со старым API для платформ Mac, что не позволяет интегрировать в WebKit некоторые улучшения и вынуждает использовать в Chrome ряд обходных методов, реализация которых оставляет желать лучшего.
• Перевод обработки Document Object Model (DOM) на плечи JavaScript-движка, что позволит существенно ускорить доступ к DOM из JavaScript-скриптов. Воплощение в жизнь подобной идеи требует полной переработки реализации DOM в WebKit и затруднено в свете поддержки в WebKit одновременно двух движков JavaScript;
• Разбиение WebKit WebCore на модули и расширение средств распараллеливания обработки контента (парсинг HTML, движок для обработки стилей, парсер JavaScript);
• Прямое использование в движке основного Platform API для управления sandbox-изоляцией;
• Переход на использование высокопроизводительного менеджера распределения памяти tcmalloc;
• Использование JIT-компиляции при организации доступа из JavaScript кода к некоторым атрибутам DOM, таким как div.id и div.firstChild;
• Поддержка сохранения снапшотов в движке V8, что позволит избавиться от стадии разбора для уже загруженных ранее страниц;
• Улучшение изоляции нити, отвечающей за формирование вывода (сompositor).