История изменений

ну, люди пишут на Си, в том числе, и браузеры. на Си написан кернел.

Это не показатель.

Архитектурно ядро ОС - это одна из самых простых в реализации задач. Их в мире написано намного больше, чем браузеров.

Ты не хуже меня знаешь, что в линуксячьем ядре, собственно «ядро» - это 1% кода, а все остальное - это модули поддержки. Их писали годами. Разные люди, в разное время. Из-за этого складывается ложное впечатление законченности ядра, но это не так.

Вот возьми ядро допустим 1998 года, или современное ядро только обрезанное, без модулей. Они рабочие? Разумеется рабочие. Ими можно пользоваться, но функционал будет жестко ограничен, программно-аппаратное окружение придется выбирать и со многим придется мириться. И тем не менее это будет функциональное ядро.

С браузером так не получится. Ты не сможешь написать браузер, который к примеру не будет поддерживать ~~ext4~~ CSS, потому он банально не будет востребован среди конкурентов, умеющих в CSS - ему будет уготована роль инструмента для скачки Chrome. Нет, ну написать ты конечно сможешь, но и пользоваться им будешь сама, и то не везде. А написать все и сразу - все таки не сможешь, это даже крупные компании вроде MS и Apple не тянут, хотя и очень хотят.

К тому моменту, когда ты на своем Си напишешь браузер, поддерживающий необходимые в 2025 году фишки - уже наступит 2027-й, где будут уже другие необходимые фишки.

Разумеется я говорю за независимый браузер на своем движке, которым будут пользоваться люди, а не очередной клон вебкита.

Поэтому логично браузер писать на ЯП, который сокращает время разработки.

вопрос мотивации. ну и времени, конечно

Время уже упущено.

Конечно же я рассуждаю в разрезе конкуренто-способного полного аналога. Парсер хтмл и немного цсс я тебе за день напишу на пыхе, и на Си за несколько дней. Но это будет не браузер, а просмотрщик хтмл и цсс =)

Видишь ли, все что связано с ГУЯтиной - неизбежно связано с двумя аспектами: иерархическим деревом элементов, и какой-никакой, но мультипоточностью, с передачей больших и разношерстных объемов данных вместе с потоками.

Если мультипоточность с горем пополам еще можно осилить в короткие сроки, то построение огромного количества взаимозависимых элементов с обработкой событий и вывода друг друга - потребует колоссальной работы с переменными, массивами, а главное строками.

Это на любом самом идеальном языке сложно организовать без пинания сторонних фреймворков. Не невозможно. Не невыполнимо. А просто сложно в контексте количества тыков на клавиатуре =)

Именно поэтому эволюция толкнула человечество на создание других ЯП, более для этого подходящих. Прям как в свое время сложность ассемблера (на котором тоже пишут, и можно написать все) толкнула к созданию Си.

Мы с тобой в другом треде спорили, и я упомянул «метрику» - как объективную шкалу, которой можно замерять ... качество кода, которое является субъективной мерой.

Так вот, использование ЯП, предназначенного для таких задач, напрямую влияет на метрику, называемую «время разработки» - измеряемую в часах\днях\неделях и тп. Оно решает проблему долгой разработки от старта до завершения, по сравнению с Си.