Если вы следите за KDE Planet, то наверняка заметили очередной холивар вокруг KHTML и WebKit (а если следите давно, то знаете, что эта тема поднимается далеко не в первый раз).

KHTML нельзя назвать плохим продуктом. Не случайно ведь Apple, создавая WebKit, взяла за основу именно его. Но ситуация с современным развитием веба такова, что требования к браузерам и веб-приложениям стремительно растут, маленькие команды не успевают за этими изменениями, стандарты не отображают реального положения дел, а веб-разработчикам приходится во многих случаях адаптировать свой код для каждого браузера.

За разработчиками основных браузерных движков стоят большие организации и финансовая поддержка. За разработкой KHTML стоят три человека, которым просто нравится работать над ним в свободное время.

В результате, попытавшись воспользоваться единственным входящим на настоящий момент в KDE4 браузером, вы будете весьма ограничены в возможности использовать современные веб-приложения, игнорировать популярность которых просто невозможно. Но самое ужасное — многие дистрибутивы даже не включают в свой состав другие браузеры! Представьте себе впечатления человека, начавшего знакомство с Linux’ом с Kubuntu LiveCD. Не имея возможности даже воспользоваться своими любимыми веб-сервисами, он надолго потеряет желание повторять такие эксперименты.

Почему же KHTML до сих пор входит в KDE?

Есть ряд причин, по которым KHTML продолжает своё развитие. Во-первых, он используется не только в Konqueror, но и в KMail, Kopete и других приложениях. Из-за этого KHTML не может быть исключён из состава KDE, по крайней мере, на протяжении разработки KDE4.

Но самое главное — KHTML существует потому, что есть разработчики которые хотят над ним работать. Если человек работает над каким-либо проектом бескорыстно в своё свободное время, имеем ли мы право от него требовать, чтобы он вместо этого занялся чем-то другим, что его вовсе не интересует? WebKit — очень большой проект, над которым работает множество людей, многие из которых получают за это зарплату. Вячеслав Токарев говорит, что ему не интересно следить за работой такого множества людей и стараться успевать за ними.

Тут, конечно, играет роль и психологический аспект: если в команде KHTML каждый разработчик — «демиург», то влившись в команду WebKit, они будут одними из тысячи.

Таков закон развития открытого ПО: разработка должна поддерживаться мотивацией разработчиков. Если разработчик не хочет работать над чем-либо сам, или же ему не платят за это деньги, то наступает застой. Мы видим это на примере KDE Windows, который, при большом спросе на этот проект, развивается довольно медленно из-за сликом малого количества мотивированных разработчиков и проблем с взаимодействием между энтузиастами и работниками компаний. Мы видим, как при работе по несколько лет без релизов, как это было с KDE4 до выхода 4.0 и KOffice2 до выхода KOffice 2.0, многие разработчики теряют мотивацию и опускают руки. Мы видим, как разработчикам KOffice не интересно заниматься поддержкой форматов MS Office, а релиз KDE4-версии K3b появился на горизонте только после того, как Mandriva начала спонсировать его разработку.

А что же с WebKit KPart?

Здесь снова налицо проблема с мотивацией разработчиков. О проекте WebKit KPart, который позволил бы в Konqueror и других приложениях свободно переключаться между движками KHTML и WebKit, говорят очень много, но лишь немногие разработчики занимаются его разработкой.

Сегодня, правда, один из разработчиков, работавший над этим проектом, признался, что есть гораздо более сложная проблема: Konqueror слишком глубоко интегрирован с KHTML, и простая замена KPart не приведёт к хорошему результату. Konqueror очень сильно завязан на API KHTML, а различия между KHTML и WebKit в настоящее время очень глубокие.

Вдобавок, как пишут многие разработчики, использующие QtWebKit, его развитие происходит довольно медленно. К примеру, в Plasma совсем не использует KHTML, а исключительно QtWebKit, и как пишет её главный разработчик Аарон Сейго, он разочарован текущим состоянием интеграции WebKit в Qt.

В комментариях к его заметке разработчик основанного на QtWebKit HTML-редактора также жаловался на отсутствие нужного ему функционала. Впрочем, представитель Qt Software Ariya Hidayat посоветовал разработчикам высказывать свои замечания на IRC-канале #qtwebkit.

Что ж, похоже, решения проблемы с KDE-браузером приходится ждать со стороны разработчиков QtWebKit и таких браузеров, как Arora и Rekonq. Оба этих проекта пока ещё находятся в ранней стадии развития, но обещают надлежащую интеграцию с KDE.