Мне всегда нравилась История. История дает понять мотивацию и причины произошедших событий, она срывает покровы, обличая случайные успехи и спланированные крахи. Сегодня я попытаюсь проследить одну ветвь эволюции браузерных движков и показать — насколько велика связь в мире открытых технологий.
ПРИМЕЧАНИЕ: Ссылки в тексте на информацию о названиях и аббревиатурах, употребленных в статье, ведут в основном на русскоязычные страницы сайта Wikipedia, а не оригинальные сайты проектов, чтобы русскоговорящему читателю было проще понять контекст, если данное именование ему незнакомо. Внизу приведены ссылки на оригинальные ресурсы.
От CDE к KDE
Linux появился в нужном месте в нужное время, пока участники проекта GNU пытались спроектировать идеальное ядро для своей операционной системы, простой финский студент сделал как умел, и, сам того не ожидая, перетащил одеяло на себя.
Тогда были XFree86 и twm, и, по существу, все. CDE (для коммерческих Unix) появился лишь в 1993 году. В свободном же мире GNU/Linux балом правили оконные менеджеры, а рабочее окружение каждый собирал сам для себя по кусочкам. Появление закрытого Common Desktop Environment не давало покоя энтузиастам, и в 1996 году, Маттиас Эттрих основывает проект KDE. История и цели самого проекта, а также его влияние на возникновение GNOME - тема для отдельной статьи. Нас же интересует появление в составе KDE в том же 1996 году комбайна под названием Konqueror, который использовался не только в качестве браузера на движке khtmlw, но и как файловый менеджер (те, кто пользовался KDE до появления Dolphin помнят эту боль). Почему нельзя было просто взять Gecko, а не изобретать велосипед? Ответ прост — разработка Gecko началась лишь в 1997.
KHTML/KJS
В ранних версиях Konqueror использовался khtmlw (KDE HTML Widget), ко второй половине 1998 года, в связи с переходом на Qt2, движок попытались освежить и произвести рефакторинг, тогда еще не было поддержи DOM и JavaScript в KHTML. Однако уже в марте 1999 года Ларс Кнолл заявил, что завершил проверку почти полностью переписанной библиотеки KHTML, поддерживающей стандарты w3c. Такие кардинальные изменения позволили Гарри Портену внедрить поддержку JavaScript уже через несколько месяцев (KJS). Спустя год — в марте 2000, благодаря совместной работе Ларса, Антти Койвисто и Дирка Мюллера в HTML появилась поддержка CSS, что сделало KHTML полноценным веб-движком наряду с Gecko и Trident тех лет. Так как KHTML должен был выполнять дополнительные задачи в составе KDE, он обзавелся возможностью запускать полноценные веб-приложения, а не только веб-документы. В данном аспекте, пожалуй, его стоит сравнить со сладкой парочкой Trident и ActiveX.
Safari и WebKit
Из письма Дона Мелтона от 7 января 2003, отправленного Дирку Мюллеру.
Здравствуйте,
Я — технический менеджер Safari, нового веб-браузера Apple Computer, основанного на KHTML и KJS. Я отправляю вам это электронное письмо, чтобы поблагодарить вас за создание такого замечательного проекта с открытым исходным кодом и представить себя и свою команду разработчиков. Я также хочу объяснить, почему и как мы использовали вашу превосходную технологию. Важно, чтобы вы знали, что мы стремимся к открытому исходному коду и вносим свои изменения сейчас и в будущем, обратно к вам, первоначальным разработчикам. Надеюсь, это положит начало диалогу между нами на благо обоих наших проектов.
В письме Дон рассказывает о том, что над Safari работали люди, принявшие участие в создании проекта Mozilla и браузера Chimera (он же Camino). Выбор пал именно на KHTML и KJS в том числе из-за того, что в сумме эти два проекта, имеющие понятную архитектуру, содержали менее 140 000 строк кода. В кратце Дон описывает изменения: багфиксы, некоторое количество улучшений и оптимизаций, а также создание прослойки совместимости KWQ (читается как "кварк"), которая служила для работы KHTML вне библиотек Qt и KDE.
Итоговый код проекта был опубликован под свободной лицензией, KHTML был переименован в WebCore, а KJS — в JavaScriptCore, новый проект получил имя WebKit.
К сожалению, обратного слияния с KHTML/KJS не последовало. Такие попытки изначально предпринимались с обеих сторон, но они провалились. Виной всему стала политика Apple, которая не была заинтересована в поддержке сообщества. Код WebKit существенно отличался от KHTML/KJS, стили были изменены согласно внутренним требованиям к оформлению кода компании, что ликвидировало возможность автоматического слияния изменений. Также руководство Apple давило на разработчиков Safari с тем, чтобы подготавливать новые фичи к следующим релизам, и не выделяло время на работу с командой KDE. Тем не менее, часть изменений все же попала в KHTML, а разработчики Safari в свободное от работы время содействали развитию материнского проекта.
WebKit-based browser by Google
Google наняла нескольких бывших сотрудников Mozilla, которые на основе WebKit и создали проект Chromium, результатом которого стала первая версия Chrome. 2 сентября 2008 года вышла первая публичная бета для Windows. Под капотом трудился WebCore, а вот JavaScriptCore в состав нового браузера не вошел, его место занял разработанный самостоятельно JavaScript-движок V8, ставку на производительность которого и делала Google.
Blink
К 2013 году, по словам представителей Google, количество патчей, которые им приходилось накладывать на WebCore для поддержки совместимости с актуальной версией V8, превысило критическую массу, и было решено сделать официальный форк, получивший имя Blink в честь тега blink, создающего эффект мерцация текста. Впрочем, в сети бытует и альтернативное мнение, мол, Google пожелала уйти в отрыв от конкурента в лице Apple, лишив их своих новых наработок. Так или иначе, истинные причины, скорее всего, навсегда останутся за закрытыми дверями алфавитных офисов.
Забавный факт: поддержка тега blink была упразднена всеми актуальными на тот момент браузерами как раз в 2013 году, а сам Blink и вовсе никогда не поддерживал данный тег.
Заключение
На сегодняшний день разработка KHTML остановлена, в репозитории наблюдаются лишь коммиты, реализующие поддержку современных версий KDE Frameworks. Последняя активность, связанная с улучшением кода, в репозитории KJS датируется июнем 2020 года. Актуальная версия Konqueror поддерживает этот движок, но по умолчанию использует WebKit. Safari сохраняет свою нишу на устройствах Apple. Google Chrome почти полностью захватил рынок настольных и мобильных (Android-) браузеров и уже начинает использовать свое монопольное положение. Такие компании как Microsoft и Opera отказались от разработки своих движков в пользу Chromium. Mozilla Firefox потерял существенную часть рынка и продолжает падение. Несмотря на плачевное состояние разработки собственного браузерного движка проекта KDE, он смог доказать, что небольшая команда увлеченных энтузиастов может создать решение, способное стать отправной точкой глобального изменения мира, сегодня уже не представляющего жизнь без веб-технологий. Кто-то может возразить, что инженеры Apple, не будь в доступе KHTML/KJS могли взять что-то другое или написать с нуля, и будет прав, но история не терпит сослагательного наклонения.
Ссылки
Источники
Другие источники в интернете, ссылок на которые не сохранилось
Комментарии (113)
vvzvlad
21.11.2021 19:32+15Чуваки сделали KHTML, их наработки взяла Apple и долго-долго работала над Safari, потом гугл взял их наработки, долго работал над JS-движком, сделал новый браузер и потратил кучу средств на его пиар. Но спасибо конечно говорить надо KDE.
Т.е. вы долго учились, потом десять лет работали, и наконец получили нобелевскую премию и наслаждаетесь успехом. В своей речи при получении премии вы говорите огромное спасибо своему отцу, который оплачивал вашу учебу и поддерживал вас, когда вы уже были готовы разочароваться в науке. Благодарите вы и своего деда, который брал вас с собой на кафедру в детстве и тем самым заинтересовал наукой.
И тут репортеры берут интервью у вашего прадеда, который заявляет, что прорыва в науке не было бы, если бы он не трахнул вашу прабабку на сеновале после сбора урожая. И это попадает в газеты с заголовком «Нобелевский лауреат всем обязан пьяному сексу». Вот примерно так я вижу эту статью.
tzlom
21.11.2021 20:41+16Чуваки сделали KHTML, потом пришла Apple и они долго вместе работали над WebKit, потом пришёл Google и долго работал над WebKit вместе с ними, потом он решил форкнуться, выкинули KDE из списка авторов и впилили свой WebCore.
KDE продолжает поддерживать WebKit, Safari всё ещё на нём а не на Chromium, WebKit используется во многих встраиваемых приложениях типа телевизоров.
А почему это всё произошло? Потому что у KHTML была хорошая архитектура и удобная лицензия. Так что конечно современный веб не сделан в одно лицо командой KDE (да и команда ли это?) но вклад тут явно больше любви на сеновале.vvzvlad
21.11.2021 20:51-8«Я, конечно, не получил нобелевскую премию сам, это сделал мой правнук, но вы же не будете отрицать, что я серьезно вложился в премию: и своей генетикой, и генетикой выбранной мной девушки, и тем, что я смазливый и ей понравился, и нужным моментом..»
vvzvlad
21.11.2021 21:32+9Тут ведь вопрос в чем. Вот есть такой чувак, Винтон Серф, который приложил руку, по сути, к созданию стандарта TCP/IP. На TCP/IP работает существующий веб. Можно ли сказать, что он родоначальник веба? Да едва ли. Не было бы HTTP over TCP over IP, был бы Gopher over NCP. Изменился бы сам веб? Стал бы он текстовым, без картинок и видео? Без JS? Да нет, вряд ли: картинки, JS и видео — это не последствия выбора протокола, это то, что возникает в головах одних людей на запросы других людей в тот момент, когда это становится возможным для реализации. Люди хотели быстро выполнять код, не запрашивая сервер, клиенты стали достаточно мощными, и вот, появился JS. Люди хотят картинки, которые мало весят, и появился JPEG. Не появился бы JPEG, жили бы с TIFF+ZIP, но картинки в вебе остались бы.
В становлении веба TCP где-то участвовал, конечно, им продиктованы некоторые вещи в вебе, например, упаковка спрайтов в одну картинку, но он не определял веб в целом. Если бы у протокола появились ограничения, не дающие передавать видео, к нему бы быстро написали новую версию, потому что люди хотят смотреть видео в интернете, протоколы без видео не выживут в эволюции.
Т.е. можно говорить о том, что Серф стоял у истоков современных сетей связи, но к ютубу он уже имеет опосредованное отношение, ютуб и видео-хостинги это сущность-над-сетями: люди хотели делиться видео, поэтому это стало реализовано. Можно говорить о том, что гугл стоял у истоков ютуба и видео-хостинга в целом, потому что именно его управление определило то, как ютуб сейчас выглядит и работает, а рабочие механики утаскивают на другие хостинги.
С браузерами так же. Можно говорить о том, что разработчики KHTML, как и Серф, заложили хороший фундамент в виде хорошей архитектуры, но если бы не KHTML, вряд ли Apple решили бы не писать браузер вообще. Ну, выбрали бы что-то другое. И гугл выбрал бы что-то другое. У них было достаточно денег и ресурсов, чтобы написать свою реализацию или лицензировать движок у оперы. Или взять фаерфоксовый. Повлияло бы это на текущую ситуацию кардинально? Да что-то мне не верится: у гугла была задача сделать свой легковесный быстрый браузер для обычных пользователей, были ресурсы для продвижения и люди, которые могут это сделать, и они бы добились такого плюс-минус эффекта на любом движке.
Ну, или другой пример: человек пишет на питоне алгоритм для автономных машин, и он получается настолько хорошим, что через пять лет 70% машин ездят под управлением этого алгоритма. Можно ли говорить о том, что за автономно-автомобильное будущее надо благодарить питон? Библиотеки питона, которые он использовал? Библиотеку openCV? Да нет, он писал алгоритм, и пусть реализация сильно зависела от ЯП, он бы написал его плюс-минус с той же успешностью на другом языке. А вот без этого человека уже все развалится.
Devoter Автор
22.11.2021 00:01Позвольте поинтересоваться: с какой именно частью текста статьи вы не согласны? Если все претензии только к заголовку, то, каюсь, он немного желтоват, но лишь с благой целью привлечения внимания к содержанию.
Revertis
Да, забавная история. В принципе, многое в нашей истории сделано какими-то выскочками.
Но если подумать о "современном вебе" сразу в мыслях появляется Electron, который так часто используют "разработчики", и так сильно ненавидят пользователи. А в его появлении виновато распространение техники Эппл за пределами США. Ведь если бы не появилась мода на маки в последнее десятилетие, никто бы и не думал о кроссплатформенных приложениях. Линукс на десктопах ведь не влияет так сильно, рост аудитории с 1% до 2% уж точно.
alpik
Я, как пользователь, не вижу в электроне ничего плохого.
Софт работает, полноценно интегрируется в систему, выглядит так же как в винде, ставится одной командой из аура.
В чем проблема-то?
Revertis
Например, в тормозах и в десятки раз большем потреблении памяти, чем у нативных прог.
alpik
Постоянно запущено 5-6 приложений, подобного не наблюдаю. Чяднт?
UdarEC
Видимо вы не эклектрон-приложения запускаете 5-6 штук. Может быть еще и памяти >16Гб?
alpik
ответил ниже.
Stalker_RED
Памяти небось 16 гигов, а то и 32, да?
В мире полно техники, у которой по 2-4 гига памяти. И там работает win10, и огромное количество нативного софта, но стоит запустить что-нибудь "электронное" сразу начинает тупняк. А о шести таких приложениях страшно подумать.
alpik
Ребят, у вас логика сыпется.
Я отвечал конкретно на "ненавидят пользователи". Я - пользователь. Я - не ненавижу. Но мне начинают доказывать, что у меня тормозит и все плохо. Ок, ВАМ, конечно же, виднее.
Памяти 16Гб. И что с того? Утверждение было однозначное, а не "пользователи с 16гб и выше не ненавидят". Подумайте, на что именно вы отвечаете.
Те же "нативные" браузеры жрут поболее.
Да, тимз, бывает выжирает 1-1,5 гб если долго запущен. Так он и "нативный" в винде столько жрет, разве нет?
Посчитал, запущено 7: 2*teams + edge + outlook + tutanota-desktop + XMind2020 + trilium
Свободно 4гб, еще 6гб файловый кэш. Как бы вообще не страшно, честно.
2-4 гига памяти, на винде 10? серьезно, часто таким пользуетесь?
наверное это работает, если не открывать в браузере больше 3 вкладок, особенно фейсбук и какой-нибудь ютуб. Только не пойму, зачем вам на винде електрон с тормозами, если все нативное?
Может, не стоит натягивать сову на глобус? И если что-то лично вам не нравится - это ваше право - но не самоочевидное правило для всех случаев?
Fenzales
Нативный тоже на электроне же.
Есть например действительно нативный телеграм, который со временм выжирает столько же, но там хоть понятно, почему - всё кешируется-перекешируется и между беседами переключения происходят как из пушки не то что с медленным подключением, а даже с отсутствующим.
С другой стороны имеем Teams, в котором переключение куда угодно (напр. вкладки Activity или Teams) очень вязкое, будто всё загружается заново.
DistortNeo
Меня Teams выбешивает тем, что им нельзя полноценно пользоваться из браузера. И он тормозит, адово тормозит по сравнению с Google Docs/Meet, и UI у него просто отвратный.
vsh797
А еще веб доступен не в пример лучше многих нативных платформ.
Вот прям сейчас пишу свой gui велосипед для git на react + nest + ts. Потому что из всего богатства выбора все либо недоступно, либо не подходит под мои сценарии пользования. А js экосистема в этом плане очень демократична. Я если честно от нее пока просто в восторге.
yroman
Я пользуюсь Teams на работе. Из последнего:
Порой тупо не показывает окно. Сидит в трее, при попытке его оттуда поднять ничего не делает. Помогает перезагрузка программы через трей.
Адово тормозит на большом количестве чатов/команд. Задержки интерфейса видны невооруженным глазом.
При загрузке картинки в чат на время пропадает вообще весь контент чата. Приходится перетыкнуть, чтобы все появилось.
В целом интерфейс работает с существенными задержками - он не кажется отзывчивым.
Глядя на тот же vscode, полагаю, что все эти проблемы можно преодолеть. Но зачем? Пипл же и так съест.
alpik
То что тимз - адово тормознутое приложение - я и не спорил, заметьте.
Да, он тормозит. К счастью, меня это не сильно напрягает.
И я более чем уверен, что дело в самой архитектуре, а не в електроне - во вкладке браузера он тормозит не меньше.
DistortNeo
Я ещё добавлю, что пока он сидит в трее, он жрёт CPU, примерно 3-5%, причём чем именно занимается, не особо понятно.
rrrad
Логика? Ненавидят пользователи <> ненавидят все пользователи!
Вы закупили памяти с избытком , чтобы компенсировать оверхед от нескольких загруженных экземпляров хромиума, а также неаккуратность в использовании технологии, которая "всё прощает". Я могу понять системный электрон, который подгружается для кучи приложений, но по факту, каждое приложение тащит свой экземпляр.
Далее, не буду говорить за всех, меня лично бесит веб-вёрстка в десктопных приложениях. Потому что какой-то гигантизм получается (видимо, дань популярности hdpi-мониторам).
Вообще, мне кажется, тут законодательство хромает. Если производитель электроники техники производит неэффективную бытовую технику, ей снижают рейтинги и, потенциально, не пускают на часть рынков. Если очередной стартап создаёт неэффективный мессенджер и умудряется попасть в аудиторию, то он начинает греть воздух на миллионах устройств (косвенно ускоряя выход из строя батареи, если говорить о смартфонах, а это в конечном счёте оставит свой след в экологии) и никто этого не замечает, кроми кучки народу, ноющей о том, что этот софт - говно. Зато факндеры экономят на оптимизации. И всё это потому, что нет никаких норм для ПО.
dartraiden
На <4 гигах? Зачем?
tempick
помню, был нищим студентом в общаге, но очень хотел быть программистом. Мне сосед-одногруппник дал в пользование свой мааленький нетбук, в котором 2гб оперативы и десятая винда. В целом, работало относительно! неплохо. Я юзал редактор brackets и первый заказ на фрилансе сделал именно на нем.
Но это не ответ на ваш вопрос, просто история из жизни)
Praksitel
Какие-то чудеса. У меня ноут lenovo c 8Гб ОЗУ, и мне однажды пришёл заказ на несколько уроков по программированию. Я не смог их сделать (осуществить запись с экрана), т.к. WebStorm + 3 вкладки в хроме сожрали всю память и винда начала прибивать приложения. И избавиться от запуска системы по 40 минут удалось только увеличением ОЗУ до 20 Гб.
GarretThief
Затем, что у вас (как и у почти всех программистов, впрочем) произошла профдеформация на этот счёт. Я понимаю вас, новый ноут с цп < i5/ryzen5 последнего поколения и озу < 16gb страшно брать, так как "да что на них вообще может идти?".
Но для обычных людей, которые не интересуются техникой, нет разницы, 4gb 8gb или 16gb, это лишь циферки в описании. Ну и учтите, что сейчас для многих людей (+- для половины) 30к - это минимум месячная зарплата (а часто и 2-3 месяца), и это без учёта любых трат, с учётом трат это вообще минимум полгода копить. А дешевле 30к сложно найти ноут с 8+gb оперативки, там обычно железо очень слабое. И это уж не говоря уж о том, что существуют такие уникумы, которые кто-то покупает.
rrrad
кажись, эти уникумы официально не совместимы с 10кой по объёму диска.
GarretThief
Как ни странно, но `Up to 20 GB available hard disk space`. Хотя я имел дело с win10 на 32гб, и это было ужасно даже для "развернуть небольшое приложение для показать заказчику", не представляю, как этим пользоваться как домашним компом.
rrrad
вроде-бы в прошлом году была новость, что мелкомягкие после какого-то обновления, ломающего систему из-за окончания свободного места, подняли минимальные системные требования по объёму диска в два раза
AlexanderS
Вы так удивляетесь, как будто не в этом мире живёте) На рынке полно ноутбуков с 4 Гб с предустановленной Win 10. Раз они продаются — значит спрос есть.
В принципе, людей можно понять. Мне вот 16 Гб мало. Но мне надо много вкладок, пару виртуалок, да ещё и САПР при работе отъест. А зачем покупать комп с большим количеством памяти для серфинга по инету? Винда отъёст 1-1,5 Гб, пользователю останется 2,5-3 Гб. Неужели этого мало? Может хоть нынешний дефицит чипов, если он никуда не исчезнет, заставит отрасль заняться оптимизацией не на словах, а на деле.
vikarti
/me вспоминает как Win95 достала BSoD'ами при работе в Delphi.
Пришлось ставить WinNT Workstation. При том что установщик активно сопротивлялся установке на компьютер с 8 Mb RAM. Но получилось.
IGR2014
8Гб, а Слэк выдаёт дичайшие тормоза. Приходится юзать вжб-версию ибо так быстрее
alpik
Давно пробовали? Со временем становится всё лучше.
Nova_Logic
Да, со временем стало лучше, после того как поставил 32 Гига оперативки????????????
Self_Perfection
RipCord в качестве клиента к Slack не тормозит.
eyudkin
С одной стороны да, а с другой, у вас есть альтернативы? На чем ещё я могу написать кроссплатформенный (да даже и фиг с ней, с кроссплатформенностью) десктоп апп, желательно на языке высокого уровня и не прибегая к нелюбимому мной c++?
Есть только какие-то проприетарные малопопулярные фреймворки на java ну и веб. В вебе любые кнопки, элементы и стили накидываются без лишнего геморроя, а распространённость браузеров гарантирует кроссплатформенность. Да, жрёт много и да, js как язык ни разу не идеальный.
Но сравните это скажем с gtk, тут недавно были статьи о том, что банальный hello world с офф сайта у них без приседаний не компилируется :D
Так что извините пользователи, но пока альтернативных инструментов для простой разработки приложений нет, это будет js.
Может, jetbrains с их jetpack compose +kotlin native в итоге победят, буду рад.
Devoter Автор
Flutter?
Revertis
Free Pascal. У некоторых получаются очень качественные проги. Тот же Total Commander (вроде на Дельфи), сейчас Transmission Remote GUI отлично работает и ест 10МБ ОЗУ сейчас.
Да, технология старая, но будет работать и на древнем железе.
eyudkin
Ну это уже экзотика, делфи как язык всё же скорее мёртв, чем жив.
GarretThief
Я не застал уже этот момент, но вкратце не расскажете, почему он умер?
elektroschwein
Умирать он начал ещё лет 10-15 назад из-за провальной маркетинговой политики компании-разработчика и ряда очень неудачных релизов.
Да, до сих пор выходят новые версии и на нем до сих пор где-то пишут, но это об актуальности и востребованности языка не говори вообще - вон, компиляторы COBOL'а тоже до сих пор выходят и на нем до сих пор где-то пишу олды, но никому в голову не придет утверждать что COBOL в наше время живее всех живых.
А так достаточно взглянуть на количество проектов на гитхабе, количество вопросов на stackoverflow, и самое главное - на количество вакансий на Delphi (и указанный в них уровень зарплат) особенно для новых проектов, а не для покрытого мхом легаси, в Москве/Питере, странах ЕС и США и сравнить эти показатели с любым актуальным языком (C#, Java, Python), и главное, динамику всего этого по годам - картина будет очень и очень печальная, может и не "умер", но в состоянии зомби.
Мне, как бывшему разработчику на Delphi от этого очень грустно.
HemulGM
Актуальность языка прекрасно выражена в вебинарах от MVP и разработчиков Embarcadero. Новые фичи, информация по новым библиотекам, поддержка Apple M1, поддержка Cocoa, разработка новых фреймворков, выход новых книг, обучающих ресурсов и т.д. Рекомендую ознакомиться с последними новостями, например в блоге на оф. сайте.
elektroschwein
К сожалению, активности компании-производителя здесь недостаточно. Каким бы не был навороченным и активно пилящимся инструмент, он не будет актуальным при невостребованности его в индустрии. А эта востребованность легко оценивается как написано выше: простым сравнительным анализом количества вакансий на этом и конкурирующих стеках в Мск/СПб/EU/US (можно ещё со сравнением зарплатных предложений) и тому, сколько % из них легаси, а сколько новые проекты. Ну и анализ трендов в динамике (опять же, в сравнении).
И со всем вышеописанным очень и очень грустно.
HemulGM
Активность проявляется не только самой компанией, но и сторонними компаниями, пока не так активно, как хочется и в основном не в России. Однако много разработчиков из России являются MVP, участвуют как в международных вебинарах, так и проводят вебинары для России. Выпускают уроки, обзоры, демонстрации. Открываются сайты для обучения современному Делфи. Выпущена Community Edition версия среды для бесплатного использования. Многие крупные проекты для Делфи (в контексте пакетов и инструментов) частично или полностью становятся бесплатными для использования.
Помимо этого есть открытая площадка для заявок, как репортов так и хотелок. Несколько из моих репортов были приняты и исправлены в том числе и хотелки для фреймворков.
Расширяется охват аудитории, внедрением новых платформ или технологий. Например, взят под крыло компании проект Python4Delphi, который позволяет тесно интегрировать питон в язык позволяя вызывать функции из языка Делфи или получать прямой доступ к классам, например для управления формой, что позволяет использовать Делфи как фреймворк для питона или использовать все преимущества питона напрямую в Делфи.
На слайдах очередной презентации то и дело появляются шильдики новых партнёров.
Так что на самом деле здесь нет ничего грустного, если действительно знать изнутри положение дел. Например, в последнем роадмапе появился рисёрч компиляции под WebAssembler.
Так что грустить нет смысла. Среда пилится, язык меняется. Новые технологии поддерживаются.
Так что говорить о смерти Delphi сейчас - это показывать свою не компетентность в этом вопросе и не более.
megahertz
Если писать как хобби для себя, то еще приемлемо. Но отсутствие библиотек на любые случаи жизни, зрелой экосистемы и опытных разработчиков делают этот стек малопригодным для большинства проектов. Хотя не скрою, было очень приятно, когда около 80 юнит тестов компилируются за секунду (киллер фича Pascal), а выполяются в сумме за какие-то миллисекунды.
HemulGM
А вы точно в курсе текущего положения дел Delphi/FreePascal?
Предлагаю по факту, здесь и сейчас, это опередить. Вы приводите список библиотек и технологий, которые, по вашему мнению отсутствуют, а я постараюсь сказать так ли это.
megahertz
Так чтобы прямо совсем ничего не было, с таким не сталкивался, но у меня и спектр решаемых задач был сильно ограничен. Гораздо чаще бывает, что вместо целого зоопарка альтернатив на других платформах находится одна библиотека, которая либо заброшена, либо без танцев с бубном ее не подключить. Даже если решение и нашлось, оно может отсавать от мейнстрима разработки лет на 20.
Вот с чем несколько лет назад были трудности. Все под FP, под Delphi может чуть полегче.
Инструментарий:
линтер фактически отсутсвует
централизованное управление зависимостями тоже
для unit тестов есть решения, но настолько топорные, что трудно бороться с желанием написать свое с нуля
как бы хорош не был Lazarus как IDE, до уровня продуктов от JetBrains или чего-то подобного очень далеко в плане рефакторинга и автокомплита. Картину немного сгладил I-Pascal, но он развивается очень медленно. Автору тяжело тянуть продукт такого уровня в одного.
Библиотеки:
так и не нашел жизнеспособного клиента MongoDB. Сейчас вроде добавили клиент в mORMot.
Банально HTTP сервер. Из всего зоопарка в mORMot самое вменяемое решение. Но при специфических хотелках могут быть к проблемы. Например, в mORMot был баг с HTTP 1.0, из-за малой восстребованости баг репорт остался без ответа.
Спасибо авторам mORMot, без него пришлось бы совсем тяжко, единое решение покрывает большую часть проблем. Но времени чтобы разобраться с ним ушло изрядно. Если самые популярные решения хорошо документированы, то с более редкими приходится достаточно долго разбираться, часами читая исходники фреймворка.
HemulGM
Инструментарий RAD и Lazarus сильно разнятся. В RAD на порядок больше инструментов как рефакторинга, так и форматирования, помощника кода и т.д.
Управление зависимостями:
Нужно отличать простые библиотеки, представляющие собой в большинстве языков - набор файлов (модулей), для работы с которыми достаточно иметь путь до них и библиотеки - пакеты (именно пакеты для Делфи), где пакет представляет собой проект внедряющийся непосредственно в среду разработки. Имеющий возможность менять саму среду добавляя визуальные компоненты, мастеры, редакторы свойств и просмотра и т.д.
Ну и для этого сейчас есть GetIt и можно указать зависимости проекта из GetIt. Вдобавок, имеется несколько сторонних решений - менеджеров пакетов.
Юнит тесты плохо ложатся на десктоп проект. Тестируются отдельные его части, для чего стандартного решения достаточно, если разобраться как он работает.
Делфи имеет штатный клиент для работы с MongoDB - пакет FireDAC (где поддерживаются десятки провайдеров). Всё корректно работает.
По поводу сервера. В Делфи есть несколько как штатных решений, так и сторонних (тот же mORMot). Например, есть официальное решение с REST сервером (в стиле Делфи, без лишнего кода).
Даже за последние пару лет Делфи очень сильно изменился и даже я не успеваю обо всё узнавать во время. Прошедший на прошлой неделе вебинар открыл для меня, как оказалось, уже давно имеющихся вещей.
Очень много библиотек для Делфи располагается на GitHub и через обычный поиск в гугле их сложно найти. А вот если подписаться на людей и следить за их подписками через ленту, то можно найти не мало интересных решений. Например, Keras4Delphi или Vulkan4Delphi, CUDA, TensorFlow, новую обертку для OpenCV, либы для блокчейнов и т.д.
megahertz
Я исключительно про FP писал, с современным состоянием Delphi слабо знаком.
elektroschwein
Простите, что? Вы сейчас точно про юнит-тесты говорите, а не про интеграционные или про UI?
Юнит-теств тестируют логику работы отдельных функций и модулей. И тут не имеет значения, модули ли это десктопного, бэкенд-монолит, бэкенд-микросервисного или даже мобильного проекта.
Если у вас "юнит-тесты плохо ложатся", стоит хорошо задуматься, что не так у вас в архитектуре проекта.
HemulGM
Да, речь про UI, а главное про отсутствие посредников/прослоек между UI и данными в стандартном подходе в проектах на Делфи.
elektroschwein
У вас там что, серьезно логика прямо сразу в обработчики UI-событий запихана, а обновление данных на форме происходит прямым изменением свойств компонентов из логики? Про MVVM я так понимаю даже спрашивать бесполезно.
Не, ну лет так 15 назад это ещё нормальным бы считалось, но в наше время это скорее уровень студенческого курсача...
HemulGM
Речь о стандартном подходе. И по сути там MVC. Но ни кто не мешает сделать MVVM и даже MVP. Или систему основанную на сообщениях (сигналах) и т.д.
Не нужно накладывать устоявшиеся "вебовские" приёмы в десктоп приложения. Действия UI легко управляются напрямую, а данные без проблем обновляются по удобной модели: колбэки, сообщения, события, да хоть по таймеру, после выполнения в тасках.
А система LiveBindings вообще позволяет обходиться без кода обновляя данные UI лишь указав визуально в дизайнере связи.
И не обязательно помимо контроллеров создавать "модель", которая будет управлять UI, если всё и так работает асинхронно. Обновляет данные в режиме реального времени без задержек и прослоек.
Можешь бесконечно говорить о том, что этот метод "устарел", однако для начала разберись как устроено Delphi-приложение и какие основы заложены в его работу.
elektroschwein
Ну собственно я на Delphi писал довольно много и довольно долго в былые времена, лет 10 назад по причине запустения и стагнации платформы перешёл на другой стек. До сих пор примерно треть времени пишу под десктоп (с чего вы взяли про Web вообще не ясно).
И при всем при этом мне все ещё не понятно, в чем же заключается специфика современного Delphi, что заставляет избегать прослоек (в результате чего у вас трудности с тестами) и в целом нарушать общепринятые и естественные практики проектирования ПО.
HemulGM
А ещё, FL Studio, AIMP, KMPlayer, Game Maker Studio, Auslogics, HeidiSQL, Toad for Oracle, ...
n0isy
FL Studio, HiediSQL, Toad тормозят так же, как и SQL Managment Stuido от MS, который фактически обрезанная MS Visual Studio стал.
HemulGM
FL Studio прекрасно работает и имеет не малую популярность, а HeidiSQL тоже не был замечен (мною) в тормозах. Toad - соглашусь, временами доставал. Однако, мой список лишь демонстрация того, что проектов не мало в том числе и свежих.
И существуют и другие проекты, о которых я не упомянул, например CudaText, Greenfish Icon Editor, RadioBOSS, Inno Setup, Guitar Pro, Heaventools, ESET Nod, Tunngle
elektroschwein
Шта? Вы с чего это взяли? В интернете нет ни одного достоверного упоминания о том, что NOD32 написан на Delphi. Более того, в ESET испокон веков не было открытых позиций delphi-разработчиков :)
titsi
Видел где-то что он написан на С++(и ассемблере ).(хотя могу ошибаться)
HemulGM
Инфу брал отсюда. Может накосячили.
https://delphi.fandom.com/wiki/Good_Quality_Applications_Built_With_Delphi
DannyTrejo
Вот и получаем кучу скриптомакак, в нативный код не хочу и не умею, буду делать какашку на электроне, я у мамы программист 300к/нс. Что не так, холоп? Лагает моя программулька? Так ты поди ещё пару плашек озу прикупи по 128гб.
alpik
Альтернатива какая?
DistortNeo
Альтернативой я вижу system-wide движок исполнения JavaScript на уровне ОС. Сейчас ситуация такова, что каждое Electron-приложение тащит с собой браузер, и потому ресурсы многократно прожираются для одного и того же функционала. Так вот, такого быть не должно.
alpik
То есть, во всех ОС должна быть однотипно реализована как минимум отрисовка?
Вопрос не в том как вы видите.
А в том, что реально есть и применимо + сравнимо по сложности с тем же електроном.
И как, есть такое?
DistortNeo
А что, сейчас веб-сайты отображаются сильно по-разному?
Что-то похожее представляет из себя ChromeOS (на самом деле нет, но очень бы хотелось).
dartraiden
Внезапно, да, просто вы этого не видите, как пользователь.
Вот пример того, какие ужасы от глаз пользователя тщательно скрывают, чтобы у него «всё работало»: habr.com/company/infopulse/blog/424369
alpik
А при чем тут веб сайты, если речь о кросплатформенных приложениях?
То что эти приложения и делают в виде сайтов, и тащат для их отрисовки браузеры - не устраивает здешних экспертов.
Вот мне и интересно - что, прямо есть альтернативы ? Вы уклоняетесь от ответа.
HemulGM
Delphi поддерживает кроссплатформенность (FMX: Win, Linux, Android, iOS, MacOS, Raspberry)
C# поддерживает кроссплатформенность (Avalonia: Win, Linux, Android, ...)
С++ поддерживает кроссплатформенность (Qt: Win, Linux, Android, ...)
Java поддерживает кроссплатформенность (JavaFX: Win, Linux)
alpik
"сравнимо по сложности с тем же електроном" - вы, видимо, не увидели :)
ну да ладно, все эти войны перфекционистов меня не сильно трогают.
лично мне все равно, на чем будут писать софт, если он у меня запускается и работает без проблем.
HemulGM
"сравнимо по сложности с тем же електроном"
https://blogs.embarcadero.com/delphi-delivers-impressive-zero-dependency-deployment-over-wpf-and-electron/
alpik
Сделать калькулятор для винды - это, конечно, мило.
Но, увы, не вижу как это иллюстрирует кроссплатформенность.
Может покажете тимз для линукса на делфи, который занимает в 10 раз меньше памяти? Или хоть что нибудь более-менее популярное?
HemulGM
Давайте вы будете здраво размышлять. Для сравнения нужно иметь два одинаковых по функционалу приложения. А это достаточно сложно сделать с крупным проектом.
Здесь проиллюстрирован способ создания простого приложения на нескольких языках. Скорость разработки на электрон не выше и тем более не в разы.
alpik
Давайте вы будете здраво размышлять.
Давайте! После вас :)
Вы упорно игнорируете тот факт, что мне не интересны преимущества делфи, или любого другого языка.
Я - не разработчик. Есть набор приложений, которые я использую. Они работают с достаточной для меня скоростью.
И пока я не вижу альтернативной реализации этих же приложений в нужной мне среде, на вашом любимом ЯП/фреймворке - мне искренне побоку его теоретические преимущества.
Если кто-нибудь захочет переписать условный тимз с электрона на делфи, и он начнет жрать не 1,5гб, а 300Мб - отлично, я только за.
Но пока этого нет - преимущества того чего нет перед тем, что есть - вы мне не продадите )
HemulGM
Т.е. вы просите показать альтернативы, а после ещё "сравнения по сложности с тем же электроном", и теперь это вам не интересно? Что с вами не так?
alpik
Извиняюсь, конечно, но предложенные вами варианты, очевидно, не сравнимы по сложности. Иначе бы они были чуточку популярнее, и из 7 приложений на электроне, которые я запускаю, хотя бы 1-2 были бы на чем-то из предложенного вами.
Занятно, вместо попытки уточнить, что я имел в виду - вы утверждаете, что со мной что-то не так.
Ок, пусть будет со мной. Давайте уже не продолжать эту бессмысленную переписку )
dartraiden
Какова вероятность пропихнуть этот движок во все ОС?
У Microsoft он уже есть и встроен в систему — разумеется, на базе Edge. Но Apple ни за что не станет встраивать его в macOS. А Microsoft не станет встраивать решение от Apple. А где-то на заднем плане сейчас хор линуксоидов кричит о том, что они лучше умрут, чем поставят в систему хоть один байт от этих корпораций и вообще вы продались, раз предлагаете втыкать анальные зонды (ну, примерно такую риторику я постоянно вижу на том же Opennet). При этом, по условиям задачи вам нужно осчастливить и таких пользователей.
Вот и получается, что выход только один — приложение тащит всё необходимое с собой.
vvzvlad
Пишут с этими словами манифест, после чего печатают его на принтере :)
alpik
Как же неадекватны обобщения.
У меня вагон и тележка приложений от майкрософт на линуксе - и не кричу почему-то. Ничего, даже нравится. Майкрософту больше, чем гуглу доверяю.
Да и по опеннету судить - моветон. Еще бы лор упомянули.
HemulGM
Наивный код! Язык с кроссплатформенными фреймворками. Таких языков не мало. И создавать приложения с нативным исполнением не так сложно. Вдобавок ко всему, многие фреймворки имеют дизайнеры интерфейса, что очень помогает в разработке.
eyudkin
А почему вы называете нас скриптомакаками? Мне вот не нравится с++ по целой куче причин, начиная от абсолютно нездоровой истории с UB и заканчивая дичайшей разнородностью экосистемы.
И вообще идею абстрагирования управления памятью я считаю скорее прикольной, далеко не всем и не всегда нужно байты считать и упарываться с указателями. В конце-концов, не все из нас пишут драйвера или игры, обычное приложение с набором кнопок по идее не должно потреблять слишком много памяти.
Тот же электрон скорее всего жрёт так много из-за того, что там под капотом прям браузер, с кучей каких-то ненужных приложению свистелок. Ну или это говнокод уже конкретных разработчиков, потому что сам v8 работает довольно эффективно.
eyudkin
Я даже больше скажу, такое большое количество скриптомакак по вашей терминологии - это прямое следствие ужасного дизайна с++ и долгого отсутствия альтернатив для натива.
И это не только моё мнение, кто-то из мэтров недавно высказывался, что вероятно именно разнообразие архитектур и осей послужило таким толчком для роста популярности java и скриптовых языков, всем просто хотелось, чтобы их код мог исполняться на любом компьютере без лишних проблем и необходимости дебажить 100500 сборок.
RH215
>это прямое следствие ужасного дизайна с++ и долгого отсутствия альтернатив для натива.
Кстати, да. Rust и Go прекрасно показали, что компилируемые языки тоже могут быть модными и молодёжными.
dartraiden
AKonia
Чего ну уж точно по веб ведь не скажешь...
tzlom
QML с биндингами к любому языку который вам нравится
Devoter Автор
У Qt все прекрасно, кроме условий лицензирования.
Static_electro
что там такого ужасного в условиях по сравнению с другими инструментами?
Devoter Автор
Стоимость коммерческой лицензии, без которой на современном Qt почти нереально написать приложение, так как все новые компоненты под GPLv3, если мне не изменяет память. То есть там двойное лицензирование коммерческая + разные варианты (L)GPL для разных моделей. Раньше была возможность использовать LGPLv2 и просто размещать библиотеки Qt рядом со своим бинарником, а теперь либо open source, либо плати. Где-то пол года назад смотрел, на одно разработчика а год было около 75-80к р., причем лицензию по их условиям нужно оплатить до начала разработки. В общем для каких-то личных проектов с туманной перспективой монетизации предложение не выглядит привлекательно, как и для небольших команд в стартапах. Да и lts-патчи теперь только по платной подписке. В общем, они решили сосредоточиться на крупных клиентах и забить на сообщество (мое личное мнение).
apro
Откуда эти нелепые слухи? Все также под LGPL как и раньше.
Devoter Автор
Например, отсюда.
Старые модули остались под LGPL, может, и какие-то новые тоже под LGPL, но есть и масса тех, что под GPL, что я и сказал в предыдущем комментарии. Если хотите знать точные имена - можете самостоятельно поизучать документацию или исходники. В основном, это касалось QtQuick-компонентов, но то было несколько лет назад, как сейчас ситуация обстоит - надо уточнять. Но факт есть факт: без коммерческой лицензии нельзя полностью использовать Qt в закрытых проектах.
apro
Какой факт? Все модули QtCore, QtGui, QtQuick, QtControls, QtSvg, QtConnectivity и т.д. они все под LGPL. То есть по сути все что лежит в основном репозитории Qt это LGPL. В marketplace есть модули под GPL, но там могут быть модули под любой лицензией.
Так что же мешает использовать Qt, если все модули под LGPL?
Fenex
Как вариант можно UI делать на Rust'овом druid. Оно конечно ещё очень сырое, но какие-то поделки делать уже можно, особенно если брать прямо `master` ветку, а не последний доступный релиз `0.7.0` ). Виджеты есть, события есть, данные отдельно. Из плохого — отсутствие документации, хотя это немножко компенсируется хорошими примерами прямо в репозитории. Как пример использования этого «toolkit»а рекламируют Spotify-клиент Psst
Но естественно это будет посложнее чем на электроне стряпать, особенно вначале. И для production оно очевидно (пока что) не подходит.
indestructable
Есть еще iced-rs
Наверное, еще более сырое, но рабочее и кроссплатформенное, а еще там elm-architecture для ценителей /s
Вообще, достаточно приятные впечатления от раста как языка для гуи (да и вообще)
buldo
Пишите на .net с использованием Авалонии или OneUI.
vikarti
Снять все же ограничение про C++ и использовать Qt?
Там все было сильно лучше чем с Gtk.
Gordon01
Под виндовс на чем писать?
На винапи — многим неприятно.
WPF (или как там его) — медленнее электрона.
Вот и получается, что электрон — норм.
Revertis
На Дельфи, конечно :))
HemulGM
Delphi - FMX. Как под Win, так и под Linux, Android, MacOS собирай. Отрисовка на GPU, эффекты, аниматоры из коробки. Мощный дизайнер в стиле Delphi.
Gordon01
Никто никогда не вернется в 2007 (и в программирование на Delphi)
HemulGM
При чем здесь 2007? Питон младше Делфи всего на 5 лет, однако что-то я не вижу, чтоб от питона внезапно все отказались, потому что ему уже 30 лет.
Вместо того, чтобы шутить и "минусовать" лучше бы полезной информации поделились, например аргументацией своей позиции.
Gordon01
"Нативные проги" предполагают написание на С/С++ ?
Думаю, гораздо больше разработчиков выбирали бы эти языки, если была бы возможность взять чей-то проект с гитхаба, склонить себе, скачать нужные зависимости и собрать.
К сожалению, экосистема с/с++ все еще слишком молода и до сих пор не написаны средства сборки.
DistortNeo
Зачем C/C++? Сейчас к вашим услугами имеются Rust и Go.
Revertis
В Расте всё плохо с GUI, про Го не знаю.
Gordon01
Не знаю как там с гуи на го, мне сам язык не нравится настолько, что лень даже интересоваться этим.
Экосистема раста все еще не готова к гуям: https://www.areweguiyet.com/
Сам пользуюсь egui на расте, очень неплохая библиотека, легко делать свои виджеты и отлично кросс-компиляется даже в браузер, рекомендую. Со сборкой и зависимостями ноль проблем, npm-like experience.
Но массовому разработчику все равно сложно на расте писать, плюс асинхронщина на TS (очень важно для быстрых интерфейсов) значительно проще.
13werwolf13
фиговый аргумент "за"
вот тебе хороший аргумент "против": выглядит НЕ как остальная система
а если хочешь на самом деле получить ответ на вопрос "чем плох электрон" спроси у мейнтейнеров какого нибудь тырпрайзного дистрибутива (например suse).
alpik
Может, не нужно свою вкусовщину уже так откровенно навязывать?
Мне ваш аргумент "против" вообще не аргумент, окошко и окошко, одно из. Выглядит "не как остальная система" - осторожно, экстрасенсы в треде...
Мы с вами на "ты" не переходили. Мне до лампочки, почему лично вам или кому-то еще электрон плох. Я утверждаю, что для меня он - не плох. Чувствуете разницу?
trokhymchuk
Дело не только в кроссплатформенных приложениях. Электрон (да и браузер) просто очень сильно повышают уровень абстракций. Поэтому писать приложения на электроне просто, а цена разработчиков низкая. А рынок интересуют дешёвые технологии, а не правильные.
HemulGM
А вы думаете все до сих пор в компилируемых языках начинают с определения собственных строк? В С++ может быть, но в других языках уже давно не так. Уже очень давно разработка почти сразу начинается с разработки логики и подключение к БД, бэку или другим вещам. Например, описание сущностей и их атрибут для ОРМ. Дизайн и шаблоны тоже могут применяться отдельно и из других проектов.
Так что ваше представление о том, что "на Электроне быстрее" очевидно не отражает действительность.
transcengopher
Чем ещё, в таком случае, объяснить такую любовь к написанию приложений, работающих именно через эту ОС внутри ОС, если не дешевизной?
HemulGM
Тем, что "разработчиков" пишущих на JS сейчас хоть задницей жуй. И они не хотят изучать другие языки. Вместо этого у нас Node.js, react и прочие поделки.
Так что да, с какой-то стороны это дешево.
transcengopher
Какая разница, что кто-то не хочет учить ничего, кроме JS — ради них нет смысла специально начинать новые проекты на нём, и уж тем более нет смысла на JS переводить существующие проекты, как нынче всё чаще делают.
Вешаем вакансию с требованиями по технологиям, которыми сами пользуемся, а не по тем, которых на рынке проще найти. Такой подход как раз создаст вакуум нужного рода, который смотивирует больше людей учить что-то помимо Node.js, а потакание минимальному общему деноминатору только подтолкнёт планку ещё ниже ко дну.
vkni
Многое в нашей истории сделано людьми. :-)
Разница между KHTML и Webkit громаднейшая. Поэтому не стоит забывать и о бесчисленных часах труда инженеров Apple и Google. Да, база - это KDE, но начальный росток, и конечный продукт это две большие разницы. Каждый, кто что-то делал, знает, как это сложно - завершить, довести до отполированного вида.