Comments 114
Да, забавная история. В принципе, многое в нашей истории сделано какими-то выскочками.
Но если подумать о "современном вебе" сразу в мыслях появляется Electron, который так часто используют "разработчики", и так сильно ненавидят пользователи. А в его появлении виновато распространение техники Эппл за пределами США. Ведь если бы не появилась мода на маки в последнее десятилетие, никто бы и не думал о кроссплатформенных приложениях. Линукс на десктопах ведь не влияет так сильно, рост аудитории с 1% до 2% уж точно.
Например, в тормозах и в десятки раз большем потреблении памяти, чем у нативных прог.
Видимо вы не эклектрон-приложения запускаете 5-6 штук. Может быть еще и памяти >16Гб?
Памяти небось 16 гигов, а то и 32, да?
В мире полно техники, у которой по 2-4 гига памяти. И там работает win10, и огромное количество нативного софта, но стоит запустить что-нибудь "электронное" сразу начинает тупняк. А о шести таких приложениях страшно подумать.
Да, тимз, бывает выжирает 1-1,5 гб если долго запущен. Так он и "нативный" в винде столько жрет, разве нет?
Нативный тоже на электроне же.
Есть например действительно нативный телеграм, который со временм выжирает столько же, но там хоть понятно, почему - всё кешируется-перекешируется и между беседами переключения происходят как из пушки не то что с медленным подключением, а даже с отсутствующим.
С другой стороны имеем Teams, в котором переключение куда угодно (напр. вкладки Activity или Teams) очень вязкое, будто всё загружается заново.
А еще веб доступен не в пример лучше многих нативных платформ.
Вот прям сейчас пишу свой gui велосипед для git на react + nest + ts. Потому что из всего богатства выбора все либо недоступно, либо не подходит под мои сценарии пользования. А js экосистема в этом плане очень демократична. Я если честно от нее пока просто в восторге.
Я пользуюсь Teams на работе. Из последнего:
Порой тупо не показывает окно. Сидит в трее, при попытке его оттуда поднять ничего не делает. Помогает перезагрузка программы через трей.
Адово тормозит на большом количестве чатов/команд. Задержки интерфейса видны невооруженным глазом.
При загрузке картинки в чат на время пропадает вообще весь контент чата. Приходится перетыкнуть, чтобы все появилось.
В целом интерфейс работает с существенными задержками - он не кажется отзывчивым.
Глядя на тот же vscode, полагаю, что все эти проблемы можно преодолеть. Но зачем? Пипл же и так съест.
Логика? Ненавидят пользователи <> ненавидят все пользователи!
Вы закупили памяти с избытком , чтобы компенсировать оверхед от нескольких загруженных экземпляров хромиума, а также неаккуратность в использовании технологии, которая "всё прощает". Я могу понять системный электрон, который подгружается для кучи приложений, но по факту, каждое приложение тащит свой экземпляр.
Далее, не буду говорить за всех, меня лично бесит веб-вёрстка в десктопных приложениях. Потому что какой-то гигантизм получается (видимо, дань популярности hdpi-мониторам).
Вообще, мне кажется, тут законодательство хромает. Если производитель электроники техники производит неэффективную бытовую технику, ей снижают рейтинги и, потенциально, не пускают на часть рынков. Если очередной стартап создаёт неэффективный мессенджер и умудряется попасть в аудиторию, то он начинает греть воздух на миллионах устройств (косвенно ускоряя выход из строя батареи, если говорить о смартфонах, а это в конечном счёте оставит свой след в экологии) и никто этого не замечает, кроми кучки народу, ноющей о том, что этот софт - говно. Зато факндеры экономят на оптимизации. И всё это потому, что нет никаких норм для ПО.
В мире полно техники, у которой по 2-4 гига памяти. И там работает win10
На <4 гигах? Зачем?
Но это не ответ на ваш вопрос, просто история из жизни)
Какие-то чудеса. У меня ноут lenovo c 8Гб ОЗУ, и мне однажды пришёл заказ на несколько уроков по программированию. Я не смог их сделать (осуществить запись с экрана), т.к. WebStorm + 3 вкладки в хроме сожрали всю память и винда начала прибивать приложения. И избавиться от запуска системы по 40 минут удалось только увеличением ОЗУ до 20 Гб.
Затем, что у вас (как и у почти всех программистов, впрочем) произошла профдеформация на этот счёт. Я понимаю вас, новый ноут с цп < i5/ryzen5 последнего поколения и озу < 16gb страшно брать, так как "да что на них вообще может идти?".
Но для обычных людей, которые не интересуются техникой, нет разницы, 4gb 8gb или 16gb, это лишь циферки в описании. Ну и учтите, что сейчас для многих людей (+- для половины) 30к - это минимум месячная зарплата (а часто и 2-3 месяца), и это без учёта любых трат, с учётом трат это вообще минимум полгода копить. А дешевле 30к сложно найти ноут с 8+gb оперативки, там обычно железо очень слабое. И это уж не говоря уж о том, что существуют такие уникумы, которые кто-то покупает.
кажись, эти уникумы официально не совместимы с 10кой по объёму диска.
В принципе, людей можно понять. Мне вот 16 Гб мало. Но мне надо много вкладок, пару виртуалок, да ещё и САПР при работе отъест. А зачем покупать комп с большим количеством памяти для серфинга по инету? Винда отъёст 1-1,5 Гб, пользователю останется 2,5-3 Гб. Неужели этого мало? Может хоть нынешний дефицит чипов, если он никуда не исчезнет, заставит отрасль заняться оптимизацией не на словах, а на деле.
/me вспоминает как Win95 достала BSoD'ами при работе в Delphi.
Пришлось ставить WinNT Workstation. При том что установщик активно сопротивлялся установке на компьютер с 8 Mb RAM. Но получилось.
8Гб, а Слэк выдаёт дичайшие тормоза. Приходится юзать вжб-версию ибо так быстрее
С одной стороны да, а с другой, у вас есть альтернативы? На чем ещё я могу написать кроссплатформенный (да даже и фиг с ней, с кроссплатформенностью) десктоп апп, желательно на языке высокого уровня и не прибегая к нелюбимому мной c++?
Есть только какие-то проприетарные малопопулярные фреймворки на java ну и веб. В вебе любые кнопки, элементы и стили накидываются без лишнего геморроя, а распространённость браузеров гарантирует кроссплатформенность. Да, жрёт много и да, js как язык ни разу не идеальный.
Но сравните это скажем с gtk, тут недавно были статьи о том, что банальный hello world с офф сайта у них без приседаний не компилируется :D
Так что извините пользователи, но пока альтернативных инструментов для простой разработки приложений нет, это будет js.
Может, jetbrains с их jetpack compose +kotlin native в итоге победят, буду рад.
Flutter?
Free Pascal. У некоторых получаются очень качественные проги. Тот же Total Commander (вроде на Дельфи), сейчас Transmission Remote GUI отлично работает и ест 10МБ ОЗУ сейчас.
Да, технология старая, но будет работать и на древнем железе.
Ну это уже экзотика, делфи как язык всё же скорее мёртв, чем жив.
Я не застал уже этот момент, но вкратце не расскажете, почему он умер?
Актуальность языка прекрасно выражена в вебинарах от MVP и разработчиков Embarcadero. Новые фичи, информация по новым библиотекам, поддержка Apple M1, поддержка Cocoa, разработка новых фреймворков, выход новых книг, обучающих ресурсов и т.д. Рекомендую ознакомиться с последними новостями, например в блоге на оф. сайте.
Активность проявляется не только самой компанией, но и сторонними компаниями, пока не так активно, как хочется и в основном не в России. Однако много разработчиков из России являются MVP, участвуют как в международных вебинарах, так и проводят вебинары для России. Выпускают уроки, обзоры, демонстрации. Открываются сайты для обучения современному Делфи. Выпущена Community Edition версия среды для бесплатного использования. Многие крупные проекты для Делфи (в контексте пакетов и инструментов) частично или полностью становятся бесплатными для использования.
Помимо этого есть открытая площадка для заявок, как репортов так и хотелок. Несколько из моих репортов были приняты и исправлены в том числе и хотелки для фреймворков.
Расширяется охват аудитории, внедрением новых платформ или технологий. Например, взят под крыло компании проект Python4Delphi, который позволяет тесно интегрировать питон в язык позволяя вызывать функции из языка Делфи или получать прямой доступ к классам, например для управления формой, что позволяет использовать Делфи как фреймворк для питона или использовать все преимущества питона напрямую в Делфи.
На слайдах очередной презентации то и дело появляются шильдики новых партнёров.
Так что на самом деле здесь нет ничего грустного, если действительно знать изнутри положение дел. Например, в последнем роадмапе появился рисёрч компиляции под WebAssembler.
Так что грустить нет смысла. Среда пилится, язык меняется. Новые технологии поддерживаются.
Так что говорить о смерти Delphi сейчас - это показывать свою не компетентность в этом вопросе и не более.
Если писать как хобби для себя, то еще приемлемо. Но отсутствие библиотек на любые случаи жизни, зрелой экосистемы и опытных разработчиков делают этот стек малопригодным для большинства проектов. Хотя не скрою, было очень приятно, когда около 80 юнит тестов компилируются за секунду (киллер фича Pascal), а выполяются в сумме за какие-то миллисекунды.
А вы точно в курсе текущего положения дел Delphi/FreePascal?
Предлагаю по факту, здесь и сейчас, это опередить. Вы приводите список библиотек и технологий, которые, по вашему мнению отсутствуют, а я постараюсь сказать так ли это.
Так чтобы прямо совсем ничего не было, с таким не сталкивался, но у меня и спектр решаемых задач был сильно ограничен. Гораздо чаще бывает, что вместо целого зоопарка альтернатив на других платформах находится одна библиотека, которая либо заброшена, либо без танцев с бубном ее не подключить. Даже если решение и нашлось, оно может отсавать от мейнстрима разработки лет на 20.
Вот с чем несколько лет назад были трудности. Все под FP, под Delphi может чуть полегче.
Инструментарий:
линтер фактически отсутсвует
централизованное управление зависимостями тоже
для unit тестов есть решения, но настолько топорные, что трудно бороться с желанием написать свое с нуля
как бы хорош не был Lazarus как IDE, до уровня продуктов от JetBrains или чего-то подобного очень далеко в плане рефакторинга и автокомплита. Картину немного сгладил I-Pascal, но он развивается очень медленно. Автору тяжело тянуть продукт такого уровня в одного.
Библиотеки:
так и не нашел жизнеспособного клиента MongoDB. Сейчас вроде добавили клиент в mORMot.
Банально HTTP сервер. Из всего зоопарка в mORMot самое вменяемое решение. Но при специфических хотелках могут быть к проблемы. Например, в mORMot был баг с HTTP 1.0, из-за малой восстребованости баг репорт остался без ответа.
Спасибо авторам mORMot, без него пришлось бы совсем тяжко, единое решение покрывает большую часть проблем. Но времени чтобы разобраться с ним ушло изрядно. Если самые популярные решения хорошо документированы, то с более редкими приходится достаточно долго разбираться, часами читая исходники фреймворка.
Инструментарий RAD и Lazarus сильно разнятся. В RAD на порядок больше инструментов как рефакторинга, так и форматирования, помощника кода и т.д.
Управление зависимостями:
Нужно отличать простые библиотеки, представляющие собой в большинстве языков - набор файлов (модулей), для работы с которыми достаточно иметь путь до них и библиотеки - пакеты (именно пакеты для Делфи), где пакет представляет собой проект внедряющийся непосредственно в среду разработки. Имеющий возможность менять саму среду добавляя визуальные компоненты, мастеры, редакторы свойств и просмотра и т.д.
Ну и для этого сейчас есть GetIt и можно указать зависимости проекта из GetIt. Вдобавок, имеется несколько сторонних решений - менеджеров пакетов.
Юнит тесты плохо ложатся на десктоп проект. Тестируются отдельные его части, для чего стандартного решения достаточно, если разобраться как он работает.
Делфи имеет штатный клиент для работы с MongoDB - пакет FireDAC (где поддерживаются десятки провайдеров). Всё корректно работает.
По поводу сервера. В Делфи есть несколько как штатных решений, так и сторонних (тот же mORMot). Например, есть официальное решение с REST сервером (в стиле Делфи, без лишнего кода).
Даже за последние пару лет Делфи очень сильно изменился и даже я не успеваю обо всё узнавать во время. Прошедший на прошлой неделе вебинар открыл для меня, как оказалось, уже давно имеющихся вещей.
Очень много библиотек для Делфи располагается на GitHub и через обычный поиск в гугле их сложно найти. А вот если подписаться на людей и следить за их подписками через ленту, то можно найти не мало интересных решений. Например, Keras4Delphi или Vulkan4Delphi, CUDA, TensorFlow, новую обертку для OpenCV, либы для блокчейнов и т.д.
Я исключительно про FP писал, с современным состоянием Delphi слабо знаком.
Да, речь про UI, а главное про отсутствие посредников/прослоек между UI и данными в стандартном подходе в проектах на Делфи.
Речь о стандартном подходе. И по сути там MVC. Но ни кто не мешает сделать MVVM и даже MVP. Или систему основанную на сообщениях (сигналах) и т.д.
Не нужно накладывать устоявшиеся "вебовские" приёмы в десктоп приложения. Действия UI легко управляются напрямую, а данные без проблем обновляются по удобной модели: колбэки, сообщения, события, да хоть по таймеру, после выполнения в тасках.
А система LiveBindings вообще позволяет обходиться без кода обновляя данные UI лишь указав визуально в дизайнере связи.
И не обязательно помимо контроллеров создавать "модель", которая будет управлять UI, если всё и так работает асинхронно. Обновляет данные в режиме реального времени без задержек и прослоек.
Можешь бесконечно говорить о том, что этот метод "устарел", однако для начала разберись как устроено Delphi-приложение и какие основы заложены в его работу.
А ещё, FL Studio, AIMP, KMPlayer, Game Maker Studio, Auslogics, HeidiSQL, Toad for Oracle, ...
FL Studio, HiediSQL, Toad тормозят так же, как и SQL Managment Stuido от MS, который фактически обрезанная MS Visual Studio стал.
FL Studio прекрасно работает и имеет не малую популярность, а HeidiSQL тоже не был замечен (мною) в тормозах. Toad - соглашусь, временами доставал. Однако, мой список лишь демонстрация того, что проектов не мало в том числе и свежих.
И существуют и другие проекты, о которых я не упомянул, например CudaText, Greenfish Icon Editor, RadioBOSS, Inno Setup, Guitar Pro, Heaventools, ESET Nod, Tunngle
Инфу брал отсюда. Может накосячили.
https://delphi.fandom.com/wiki/Good_Quality_Applications_Built_With_Delphi
Альтернативой я вижу system-wide движок исполнения JavaScript на уровне ОС. Сейчас ситуация такова, что каждое Electron-приложение тащит с собой браузер, и потому ресурсы многократно прожираются для одного и того же функционала. Так вот, такого быть не должно.
То есть, во всех ОС должна быть однотипно реализована как минимум отрисовка?
А что, сейчас веб-сайты отображаются сильно по-разному?
И как, есть такое?
Что-то похожее представляет из себя ChromeOS (на самом деле нет, но очень бы хотелось).
А что, сейчас веб-сайты отображаются сильно по-разному?
Внезапно, да, просто вы этого не видите, как пользователь.
Вот пример того, какие ужасы от глаз пользователя тщательно скрывают, чтобы у него «всё работало»: habr.com/company/infopulse/blog/424369
Delphi поддерживает кроссплатформенность (FMX: Win, Linux, Android, iOS, MacOS, Raspberry)
C# поддерживает кроссплатформенность (Avalonia: Win, Linux, Android, ...)
С++ поддерживает кроссплатформенность (Qt: Win, Linux, Android, ...)
Java поддерживает кроссплатформенность (JavaFX: Win, Linux)
"сравнимо по сложности с тем же електроном"
Давайте вы будете здраво размышлять. Для сравнения нужно иметь два одинаковых по функционалу приложения. А это достаточно сложно сделать с крупным проектом.
Здесь проиллюстрирован способ создания простого приложения на нескольких языках. Скорость разработки на электрон не выше и тем более не в разы.
У Microsoft он уже есть и встроен в систему — разумеется, на базе Edge. Но Apple ни за что не станет встраивать его в macOS. А Microsoft не станет встраивать решение от Apple. А где-то на заднем плане сейчас хор линуксоидов кричит о том, что они лучше умрут, чем поставят в систему хоть один байт от этих корпораций и вообще вы продались, раз предлагаете втыкать анальные зонды (ну, примерно такую риторику я постоянно вижу на том же Opennet). При этом, по условиям задачи вам нужно осчастливить и таких пользователей.
Вот и получается, что выход только один — приложение тащит всё необходимое с собой.
Наивный код! Язык с кроссплатформенными фреймворками. Таких языков не мало. И создавать приложения с нативным исполнением не так сложно. Вдобавок ко всему, многие фреймворки имеют дизайнеры интерфейса, что очень помогает в разработке.
А почему вы называете нас скриптомакаками? Мне вот не нравится с++ по целой куче причин, начиная от абсолютно нездоровой истории с UB и заканчивая дичайшей разнородностью экосистемы.
И вообще идею абстрагирования управления памятью я считаю скорее прикольной, далеко не всем и не всегда нужно байты считать и упарываться с указателями. В конце-концов, не все из нас пишут драйвера или игры, обычное приложение с набором кнопок по идее не должно потреблять слишком много памяти.
Тот же электрон скорее всего жрёт так много из-за того, что там под капотом прям браузер, с кучей каких-то ненужных приложению свистелок. Ну или это говнокод уже конкретных разработчиков, потому что сам v8 работает довольно эффективно.
Я даже больше скажу, такое большое количество скриптомакак по вашей терминологии - это прямое следствие ужасного дизайна с++ и долгого отсутствия альтернатив для натива.
И это не только моё мнение, кто-то из мэтров недавно высказывался, что вероятно именно разнообразие архитектур и осей послужило таким толчком для роста популярности java и скриптовых языков, всем просто хотелось, чтобы их код мог исполняться на любом компьютере без лишних проблем и необходимости дебажить 100500 сборок.
А почему вы называете нас скриптомакаками?Т — токсичность. А когда их называешь плюсодрочерами и дельфиё**ми в ответ, они обычно обижаются.
заканчивая дичайшей разнородностью экосистемы
Чего ну уж точно по веб ведь не скажешь...
QML с биндингами к любому языку который вам нравится
У Qt все прекрасно, кроме условий лицензирования.
что там такого ужасного в условиях по сравнению с другими инструментами?
Стоимость коммерческой лицензии, без которой на современном Qt почти нереально написать приложение, так как все новые компоненты под GPLv3, если мне не изменяет память. То есть там двойное лицензирование коммерческая + разные варианты (L)GPL для разных моделей. Раньше была возможность использовать LGPLv2 и просто размещать библиотеки Qt рядом со своим бинарником, а теперь либо open source, либо плати. Где-то пол года назад смотрел, на одно разработчика а год было около 75-80к р., причем лицензию по их условиям нужно оплатить до начала разработки. В общем для каких-то личных проектов с туманной перспективой монетизации предложение не выглядит привлекательно, как и для небольших команд в стартапах. Да и lts-патчи теперь только по платной подписке. В общем, они решили сосредоточиться на крупных клиентах и забить на сообщество (мое личное мнение).
Откуда эти нелепые слухи? Все также под LGPL как и раньше.
Например, отсюда.
Старые модули остались под LGPL, может, и какие-то новые тоже под LGPL, но есть и масса тех, что под GPL, что я и сказал в предыдущем комментарии. Если хотите знать точные имена - можете самостоятельно поизучать документацию или исходники. В основном, это касалось QtQuick-компонентов, но то было несколько лет назад, как сейчас ситуация обстоит - надо уточнять. Но факт есть факт: без коммерческой лицензии нельзя полностью использовать Qt в закрытых проектах.
Но факт есть факт: без коммерческой лицензии нельзя полностью использовать Qt в закрытых проектах.
Какой факт? Все модули QtCore, QtGui, QtQuick, QtControls, QtSvg, QtConnectivity и т.д. они все под LGPL. То есть по сути все что лежит в основном репозитории Qt это LGPL. В marketplace есть модули под GPL, но там могут быть модули под любой лицензией.
Так что же мешает использовать Qt, если все модули под LGPL?
Но естественно это будет посложнее чем на электроне стряпать, особенно вначале. И для production оно очевидно (пока что) не подходит.
Пишите на .net с использованием Авалонии или OneUI.
Снять все же ограничение про C++ и использовать Qt?
Там все было сильно лучше чем с Gtk.
Под виндовс на чем писать?
На винапи — многим неприятно.
WPF (или как там его) — медленнее электрона.
Вот и получается, что электрон — норм.
"Нативные проги" предполагают написание на С/С++ ?
Думаю, гораздо больше разработчиков выбирали бы эти языки, если была бы возможность взять чей-то проект с гитхаба, склонить себе, скачать нужные зависимости и собрать.
К сожалению, экосистема с/с++ все еще слишком молода и до сих пор не написаны средства сборки.
Зачем C/C++? Сейчас к вашим услугами имеются Rust и Go.
В Расте всё плохо с GUI, про Го не знаю.
Не знаю как там с гуи на го, мне сам язык не нравится настолько, что лень даже интересоваться этим.
Экосистема раста все еще не готова к гуям: https://www.areweguiyet.com/
Сам пользуюсь egui на расте, очень неплохая библиотека, легко делать свои виджеты и отлично кросс-компиляется даже в браузер, рекомендую. Со сборкой и зависимостями ноль проблем, npm-like experience.
Но массовому разработчику все равно сложно на расте писать, плюс асинхронщина на TS (очень важно для быстрых интерфейсов) значительно проще.
выглядит так же как в винде
фиговый аргумент "за"
вот тебе хороший аргумент "против": выглядит НЕ как остальная система
а если хочешь на самом деле получить ответ на вопрос "чем плох электрон" спроси у мейнтейнеров какого нибудь тырпрайзного дистрибутива (например suse).
Я, как пользователь, не вижу в электроне ничего плохого.
Софт работает, полноценно интегрируется в систему, выглядит так же как в винде, ставится одной командой из аура.
В чем проблема-то?
А я вот вижу проблему. Мы отказались от Скайпа полностью. Который работает отвратительно в том числе и 'благодаря' электрону, хотя до этого использовали его более десяти лет. Мы все перешли в нативную 'телегу' чем невероятно довольны. И на десктопе и на телефоне. Пока скайп работал не Делфе, всё было замечательно. Однако Майкрософт видимо скорее удавится, чем будет Делфю использовать. Перешли на электрон и в том числе и поэтому загубили отличный проект. Сейчас мой скайп с двумя сотнями контактов выглядит так же сиротливо как когда-то аська. За месяц ни одного сообщения. Боюсь, что его ждет судьба аськи.
Ведь если бы не появилась мода на маки в последнее десятилетие, никто бы и не думал о кроссплатформенных приложениях
Дело не только в кроссплатформенных приложениях. Электрон (да и браузер) просто очень сильно повышают уровень абстракций. Поэтому писать приложения на электроне просто, а цена разработчиков низкая. А рынок интересуют дешёвые технологии, а не правильные.
А вы думаете все до сих пор в компилируемых языках начинают с определения собственных строк? В С++ может быть, но в других языках уже давно не так. Уже очень давно разработка почти сразу начинается с разработки логики и подключение к БД, бэку или другим вещам. Например, описание сущностей и их атрибут для ОРМ. Дизайн и шаблоны тоже могут применяться отдельно и из других проектов.
Так что ваше представление о том, что "на Электроне быстрее" очевидно не отражает действительность.
ваше представление о том, что "на Электроне быстрее" очевидно не отражает действительность.
Чем ещё, в таком случае, объяснить такую любовь к написанию приложений, работающих именно через эту ОС внутри ОС, если не дешевизной?
Тем, что "разработчиков" пишущих на JS сейчас хоть задницей жуй. И они не хотят изучать другие языки. Вместо этого у нас Node.js, react и прочие поделки.
Так что да, с какой-то стороны это дешево.
Какая разница, что кто-то не хочет учить ничего, кроме JS — ради них нет смысла специально начинать новые проекты на нём, и уж тем более нет смысла на JS переводить существующие проекты, как нынче всё чаще делают.
Вешаем вакансию с требованиями по технологиям, которыми сами пользуемся, а не по тем, которых на рынке проще найти. Такой подход как раз создаст вакуум нужного рода, который смотивирует больше людей учить что-то помимо Node.js, а потакание минимальному общему деноминатору только подтолкнёт планку ещё ниже ко дну.
Да, забавная история. В принципе, многое в нашей истории сделано какими-то выскочками.
Многое в нашей истории сделано людьми. :-)
Разница между KHTML и Webkit громаднейшая. Поэтому не стоит забывать и о бесчисленных часах труда инженеров Apple и Google. Да, база - это KDE, но начальный росток, и конечный продукт это две большие разницы. Каждый, кто что-то делал, знает, как это сложно - завершить, довести до отполированного вида.
Т.е. вы долго учились, потом десять лет работали, и наконец получили нобелевскую премию и наслаждаетесь успехом. В своей речи при получении премии вы говорите огромное спасибо своему отцу, который оплачивал вашу учебу и поддерживал вас, когда вы уже были готовы разочароваться в науке. Благодарите вы и своего деда, который брал вас с собой на кафедру в детстве и тем самым заинтересовал наукой.
И тут репортеры берут интервью у вашего прадеда, который заявляет, что прорыва в науке не было бы, если бы он не трахнул вашу прабабку на сеновале после сбора урожая. И это попадает в газеты с заголовком «Нобелевский лауреат всем обязан пьяному сексу». Вот примерно так я вижу эту статью.
Чуваки сделали KHTML, потом пришла Apple и они долго вместе работали над WebKit, потом пришёл Google и долго работал над WebKit вместе с ними, потом он решил форкнуться, выкинули KDE из списка авторов и впилили свой WebCore.
KDE продолжает поддерживать WebKit, Safari всё ещё на нём а не на Chromium, WebKit используется во многих встраиваемых приложениях типа телевизоров.
А почему это всё произошло? Потому что у KHTML была хорошая архитектура и удобная лицензия. Так что конечно современный веб не сделан в одно лицо командой KDE (да и команда ли это?) но вклад тут явно больше любви на сеновале.
В становлении веба TCP где-то участвовал, конечно, им продиктованы некоторые вещи в вебе, например, упаковка спрайтов в одну картинку, но он не определял веб в целом. Если бы у протокола появились ограничения, не дающие передавать видео, к нему бы быстро написали новую версию, потому что люди хотят смотреть видео в интернете, протоколы без видео не выживут в эволюции.
Т.е. можно говорить о том, что Серф стоял у истоков современных сетей связи, но к ютубу он уже имеет опосредованное отношение, ютуб и видео-хостинги это сущность-над-сетями: люди хотели делиться видео, поэтому это стало реализовано. Можно говорить о том, что гугл стоял у истоков ютуба и видео-хостинга в целом, потому что именно его управление определило то, как ютуб сейчас выглядит и работает, а рабочие механики утаскивают на другие хостинги.
С браузерами так же. Можно говорить о том, что разработчики KHTML, как и Серф, заложили хороший фундамент в виде хорошей архитектуры, но если бы не KHTML, вряд ли Apple решили бы не писать браузер вообще. Ну, выбрали бы что-то другое. И гугл выбрал бы что-то другое. У них было достаточно денег и ресурсов, чтобы написать свою реализацию или лицензировать движок у оперы. Или взять фаерфоксовый. Повлияло бы это на текущую ситуацию кардинально? Да что-то мне не верится: у гугла была задача сделать свой легковесный быстрый браузер для обычных пользователей, были ресурсы для продвижения и люди, которые могут это сделать, и они бы добились такого плюс-минус эффекта на любом движке.
Ну, или другой пример: человек пишет на питоне алгоритм для автономных машин, и он получается настолько хорошим, что через пять лет 70% машин ездят под управлением этого алгоритма. Можно ли говорить о том, что за автономно-автомобильное будущее надо благодарить питон? Библиотеки питона, которые он использовал? Библиотеку openCV? Да нет, он писал алгоритм, и пусть реализация сильно зависела от ЯП, он бы написал его плюс-минус с той же успешностью на другом языке. А вот без этого человека уже все развалится.
Вы так много знаете! Может подскажете, как пропатчить KDE под FreeBSD?
Мы должны сказать спасибо KDE за современный веб