Схоже, більшість поширених веб-браузерів (Firefox, Chrome, Safari) розробляються за допомогою C ++. Чому це так?

Ще один спосіб задати питання - яка підтримка потрібна браузеру? Короткий список:

• Підтримка розбору (потрібна для розуміння [X] HTML, CSS та сценарію [ECMA / Java])
• Особливості прогулянки / інтерпретації дерева (частина розбору та побудови інтерфейсу)
• Підтримка прискореної графіки
• Швидка мережа
• Для більш просунутих браузерів: контроль над процесами та ізоляція пам'яті між сторінками
• Повинна працювати на всіх підтримуваних платформах

Більшість мов мають якусь підтримку розбору. У вас є генератори парсерів для C, C ++, C #, Java і т. Д. Однак у C і C ++ є досить багато років, що стосуються решти альтернатив, тому алгоритми та реалізації є більш зрілими. Доступ до прискореної графіки на Java - це не піде, якщо ви не маєте власних розширень, щоб змусити її працювати. WPF на C # надає доступ до прискореної графіки, але це занадто ново, щоб мати серйозний браузер, побудований за допомогою цієї технології.

Налагодження мереж - це найменше з причин вибору C ++ через Java або C #. Причина полягає в тому, що зв’язок у багато разів повільніше, ніж решта обробки, яка триває для відображення сторінки. Обмежуючим фактором є сира швидкість дроту. І Java, і C # мають неблокуючу підтримку вводу-виводу, як і C ++. Тож справді немає чіткого переможця у цій галузі.

Чому б не Java? Ви коли-небудь намагалися створити інтерфейс з Java? Він відчуває себе громіздким і повільним порівняно з чим-небудь іншим там, бо це так. Жодна прискорена графіка також не є великим негативом. Пісочниця Java справді хороша і може допомогти підвищити безпеку веб-переглядача, якщо він використовується правильно, але налаштовувати та працювати потрібно. Не кажучи вже про підтримку графічного формату, відстає від більшості сучасних браузерів.

Чому б не C #? Якщо ваша єдина мета - Windows, C # може насправді добре представити. Проблема виникає, коли ви хочете підтримати що-небудь інше. Mono не настиг достатньо, щоб вважатись кросплатформою, достатньою для цього завдання - особливо з прискореною підтримкою графіки та WPF. Хто знає, скільки часу знадобиться, щоб змінитись.

Чому б не С? Там є компілятор C майже для кожної платформи (включаючи вбудовані пристрої). Однак є багато, що C не робить для вас, що вам доведеться бути пильними. У вас є доступ до всіх найнижчих рівнів API, але більшість розробників C не мають графічних інтерфейсів. Навіть бібліотеки C GUI записані в об'єктно-орієнтованій формі. Як тільки ви починаєте розмовляти з інтерфейсом користувача, мова, орієнтована на об'єкти, починає мати більше сенсу.

Чому б не мета C? Якщо ваша єдина мета - Apple, це має багато сенсу. Однак більшість розробників не знає Objective-C, і єдиною причиною дізнатися це є робота над NeXT або Apple коробками. Звичайно, ви можете використовувати будь-яку бібліотеку C за допомогою Objective-C, і для багатьох платформ є компілятори, але знайти людей, які працюють над нею, буде складніше. Хто знає? Можливо, Apple може перетворити цей сприйнятий недолік.

Чому C ++? Там є компілятор C ++ для майже кожної платформи. Практично кожна бібліотека GUI має інтерфейс C ++, іноді це краще, а іноді просто інше. Наприклад, ATL Microsoft набагато краще, ніж дзвінки функцій win32 C або навіть бібліотека MFC. На Unix є обгортки C ++ для GTK, і я би здивувався, якби хтось не мав обгортки C ++ навколо бібліотеки GUI Objective-C GUI. Управління процесом у C ++ простіше, ніж Java або C # (ці деталі вилучені для вас). Воно сприймає швидкість більше, ніж апаратне прискорення, ніж продуктивність. C ++ дбає про більше речей для вас, ніж для сирої C (наприклад, обмежених рядків), але все ж дає вам свободу підлаштовувати речі.

Наразі C ++ вирішує альтернативи.

Я вирішив написати роман про це, сподіваючись, що люди заглянуть за це і викличуть мене. Ні, ні, просто жартую! Я страждав над кожним словом. Кожне слово, я вам кажу!

Запитайте "коли" перед "чому"

Усі основні веб-браузери можуть простежити своє походження ще до 90-х. Konqueror став Safari і Chrome; Netscape став Firefox; IE і Opera все ще є IE і Opera. Усі ці веб-переглядачі мають 15-річний початок діяльності місцевих службовців.

Я пропоную вам навіть спробувати назвати прийнятну кросплатформенну (Windows / Mac / Unix та ще гіршу) мову, яка була доступна приблизно в 1995 році, коли виникли сучасні браузери. Щоб побудувати ядро ​​в будь-якому, окрім C / C ++, вам, мабуть, довелося б будувати або купувати та змінювати бібліотеки компілятора та платформи.

Як щодо сьогодні? Які альтернативи?

Просто для розваги, давайте подумаємо про проблему сьогодні. Так, є альтернативи, але все ж є основні проблеми.

Вибір мови подає щонайменше такі проблеми:

1. Проблеми зі знаннями - найм / навчання розробників або залучення учасників
2. Організаційні / соціальні проблеми - Прийняття мови
3. Мовна реалізація: Швидкість, підтримка платформи, інструментарій
4. Мовна сила

1: Проблеми знань

Звідки ви берете людей, які знають мову або можуть її вивчити? Це перешкода для таких мов, як OCaml, F #, Haskell, Common Lisp і D, які досить швидкі та високорівневі, щоб добре писати браузер, але вони мають мало підписників (можливо, в діапазоні 10k-100k, можливо) навіть якщо ви вільно порахуйте всіх любителів та вчених.

2: Соціальні / організаційні проблеми

Слідство з вантажно-культовою відповіддю вище:

• Браузер із відкритим кодом, який не використовує C, C ++, C # або Java, мабуть, матиме труднощі з розробниками.
• Власний веб-переглядач, який не використовує C, C ++, C # або Java, отримає від більшості організацій керівників проектів.

3. Технічні проблеми

Навіть у сучасний час вам потрібна досить швидка мова для обчислювальних інтенсивних частин візуалізації сторінок та роботи Javascript. Ви можете доповнити цю мову мовою високого рівня для побудови елементів графічного інтерфейсу тощо (наприклад, підхід Firefox C ++ та Javascript), але ви повинні мати тісну інтеграцію між мовами; ви не можете просто сказати "Гаразд, C # і Луа". Можливо, вам доведеться самостійно створити та налагодити цей міст, якщо ви не виберете C або C ++ як основну мову.

Розробка крос-платформ - ще одна сумка глистів. Ви можете використовувати C # або F # і схрещувати пальці на GTK # і Mono, будучи живими і здоровими в майбутньому. Ви можете спробувати Common Lisp, Haskell, OCaml ... Удачі отримують все працює на Windows , і Mac і Linux.

4. Мовна сила

Зрештою з цим вам доведеться створити величезну кількість функціональних можливостей, тому якщо ви вибираєте мову низького рівня, вам потрібна рівномірна армія кодерів, ніж раніше. Зауважте, що ніхто не створив браузер з нуля протягом п’ятнадцяти років. Це частково тому, що (сюрприз!) Важко.

Зокрема, наявність інтерпретатора Javascript - це проблема 3 (придбати один) або проблема 4 (побудувати один).

Висновок:

Якщо ви сьогодні (на початку 2011 р.) Розробили триплатформенний браузер (Windows / Mac / * nix), які варіанти є?

• С: Див. (2). Усі збираються вимагати C ++. Приємно вибираючи інструментарій для різних платформ або будуючи його (1, 2, 3 і 4). Див. Також (4); весело будуючи в ньому стабільний надійний браузер.
• C ++: отримуйте задоволення від вибору інструментарію для різних платформ або створення його (1, 2, 3 і 4). Приємно (4) будувати в ньому стабільний, безпечний браузер.
• C або C ++ і HLL: Ваша найкраща ставка. Підберіть свою отруту на динамічну мову; Див. (1) і (2). Занадто багато хороших мов, занадто мало підписників на кожній. (1, 2, 3 і 4) на інструментарії.
• Java: Друга найкраща ставка, якщо вам доведеться порадувати середнє керівництво. Див. (4); побудова величезних речей на Java займає набагато більше коду, ніж у будь-якому іншому в цьому списку, але, можливо, C.
• Scala: б'є Java увімкнено (4); (1) і (2), але це наганяє.
• C і Javascript: Як особливий випадок, це привабливо, оскільки ви вже повинні створити або придбати та засвоїти інтерпретатор Javascript. (Звідси Firefox.) (1, 2, 3 і 4) на інструментарії; люди Mozilla побудували власний IIRC.
• C #: Веселіться на (3). Ви, мабуть, застрягли з GTK #, як би добре це не було, або ви створюєте власний шар і рендерінг вище GTK # та Windows Forms.
• Ruby / Python / Perl / Racket / Lua / Erlange тощо. Ви отримали (3) бібліотеки віджетів між платформами та швидкість. Закон Мура з вами про (4); зростаючий попит на браузери проти вас.
• OCaml, Haskell, Common Lisp, Smalltalk: (1) і (2) в лопатах. Мабуть, немає проблем зі швидкістю, але (3) для розвитку платформ, і вам доведеться якось будувати своє власне все або переходити до бібліотек C / C ++.
• Завдання-C: (3) Я не впевнений, як розвиватиметься міжплатформна розробка.

Якщо ми побачимо ще один великий підйом браузера в найближчі кілька років, я б сподівався, що він буде написаний на C або C ++ і динамічною мовою (як Firefox), незалежно від того, з відкритим вихідним кодом чи власником.

Редагувати (31 липня 2013 р.) : Здається, коментатори "Хакерських новин" згадують "Іржу і Го" (не конкретно у зв'язку з моєю відповіддю), які нечітко потрапляють у відро "інше швидке". Спроба зберегти цей перелік мов, що є егілітарними та оновленими, буде програшною битвою, тому натомість я називаю це репрезентативним зразком на час написання і залишаю його в спокої.

Швидкість

Як неприємно це, C ++ - це все-таки те, що ви використовуєте, коли хочете швидкого застосування та повного контролю над кодом.

Ось чому ігри, неосновні частини (наприклад, імпортери файлів) Office та багато іншого все ще написані на C ++.

Відредаговано, щоб включити відповідь від MSalters

Переносність

Я можу лише здогадуватися, але ви згадуєте програмні продукти, націлені на декілька платформ, а C ++ можна компілювати на будь-яку платформу.

(Я працюю над Firefox близько п'яти років.)

Опитуючий прав, що багато коду Firefox - це C ++, а насправді C ++ - це більшість, якщо рахувати за рядками коду (хоча це не говорить про всю історію, оскільки у нас дуже багато JavaScript, а JS - це більше лаконічніше ніж C ++).

Але насправді Firefox написаний багатьма різними мовами:

• C ++
• C (NSS, NSPR, різні бібліотеки, які ми імпортували)
• x86 та збірка ARM
• JavaScript
• XUL (HTML-схожа мова розмітки) та CSS
• Завдання C (код лише для MacOS)
• Java (код лише для Android)
• Кілька спеціальних мов визначення інтерфейсу (XPIDL, IPDL)
• WebIDL (інша мова визначення інтерфейсу, але ця не є власною, хоча генератор коду є)
• Python (генератори коду)

Я впевнений, я дещо забув.

Цей список важливий, тому що він натякає на неймовірну складність, що стоїть за веб-браузером.

Так, Firefox має багато C ++ коду, і так, це пов'язане з тим, що C ++ була найкращою мовою для подібних речей, коли Netscape був заснований. Але я також заперечую, що на сьогоднішній день не існує кращої мови для багатьох, що ми робимо.

Жодна інша мова не має настільки сильну екосистему бібліотек (ми сильно покладаємось на зовнішній код). Мало хто з інших мов дає вам повноцінний контроль, як C ++ (ми регулярно підганяємо наш спеціальний розподільник купи і робимо всілякі небезпечні для пам'яті речі, щоб бути швидшими або використовувати менше пам'яті). Мало хто з інших мов дозволяє повторно реалізувати більшість стандартних бібліотек здоровим способом (у нас є власні рядки та реабілітації колекцій, налаштовані на наші потреби). Мало хто з інших мов дозволяє реалізувати власний сміттєзбірник. І так далі.

Хоча C ++ є очевидним вибором для багатьох із того, що ми робимо, люди, які припускають, що ми могли б написати браузер на Java та написати власний JVM, якщо потрібно, на щось. Це по суті те, що ми робимо, але з JavaScript замість Java. Звичайно, значна частина браузера не написана на JavaScript. Але дивовижна сума.

Ну, ви повинні запитати у розробників цих продуктів безпосередньо , щоб отримати в відповідь, але я підозрюю , що це поєднання знайомства (це те , що ці розробники краще знали), продуктивність (зведену до рідного довічним , на відміну від байткод), і інструменти (порівняно з мовами на зразок C, C ++ рясніє приємними гаджетами, що економія праці, як STL)

Історія

Кожен із браузерів має певну історію, яка вплинула на вибір мови.

Наприклад, і Chrome, і Safari засновані на WebKit, який бере початок у частині KHTML проекту KDE. KDE спочатку був створений (частково) як демонстрація набору інструментів Qt GUI, тому KDE загалом є проектом C ++. На той час усі нові проекти KDE були написані повністю на C ++, тому це був логічний вибір для KHTML. З тих пір він перенесений для використання інших наборів інструментів GUI.

Двигун Presto Opera був написаний з продуктивністю та малим двійковим розміром на увазі: C ++ був логічним вибором.

IE Майкрософт був написаний як набір компонентів ActiveX, який міг бути написаний будь-якою мовою, що має COM-прив’язки, але, ймовірно, написаний у підмножині C ++, оскільки більшість їх бази коду вже написані цією мовою.

Мозила Netscape написана на мові C ++, ймовірно, тому, що їхня головна турбота про мобільність. Компілятори C і C ++ є (практично) всюдисущими, і тому це був логічний вибір.

Немає властивих технічних причин для цих виборів. Це просто "здавалося гарною ідеєю в той час".

Мережі в C і C ++ легко оптимізувати, оскільки вам не потрібно використовувати бібліотеки, якщо цього не хочете. Я підозрюю, що мова C ++ є мовою вибору, оскільки вона дає переваги C:

• Швидкість
• Оптимізація
• Певна кількість портативності
• Складена мова, не інтерпретується

у поєднанні з перевагами OOP:

• Розширюваність
• Легша візуалізація
• Краща підтримка бібліотеки для некритичних завдань, таких як обробка рядків та структури даних

Коли були написані перші рядки коду для першого раунду браузерів, C # та Java не існували. Ні Рубі. Python, можливо, був поруч, але це все ще був крихітний доморощений проект на той момент.

В основному, не було жодного іншого вибору, крім C ++, який би дозволив створити браузер, який був би швидким і працював на багатьох різних платформах.

То чому їх писали на С ++? Тому що це була єдина доступна мова, на якій вони могли бути написані.

Тому що браузери (наприклад, HotJava, очевидно, достатньо написані на Java), написані іншими мовами, ніколи не були досягнуті суттєвої ступеня прийняття / проникнення на ринок.

Я не можу нічого сказати про поточну ітерацію (або останню - не оновлювалась досить довго) HotJava, але коли я спробував це, відсутність проникнення на ринок здавалося (принаймні для мене) надзвичайно простим для розуміння - це було некрасиво, повільно і несумісно з досить кількома веб-сторінками. Зрештою, здавалося, вона базується на припущенні, яке ніколи не виходило з ладу: що Інтернет буде складатися головним чином з аплетів Java, HTML-код - трохи більше, ніж обгортка, яка повідомляє, які аплети потрібно відображати.

Частина цього, мабуть, також є історичною: більшість великих веб-браузерів існують вже давно. Коли вони вперше були написані, пейзаж був набагато іншим: C ++ була "гарячою" новою мовою, тому його використовували для багатьох нових розробок. Веб-браузери стали одними з найбільш широко використовуваних програмних засобів навколо, тоді як багато інших з того часу відійшли у небуття.

Я думаю, що відображене "ставлення" до мови також має ефект: C ++ (як і С до нього) завжди підкреслювало практичність та прагматизм. Це основне ставлення, як правило, залучає програмістів, які також є прагматичними. Багато інших мов приділяють значно більше уваги таким речам, як елегантність - і тим самим вони залучають програмістів, які думають так само. Проблема з цим полягає в тому, що я називаю "ефектом Ліспа". Симптоми включають:

1. Нескінченні спори про найбільш елегантною реалізації самих тривіальних речей.
2. Неможливість заморозити функції та закінчити щось, що можна поставити (навіть із недоліками)
3. Неможливість йти на компроміси. Той, хто не погоджується зі мною, не просто помиляється, але повинен бути або дурним, або злим.

Є більше, але ви отримуєте загальне уявлення (і так, я певною мірою перебільшую - але лише до певної міри). Так, якийсь код, який ви отримаєте, буде приголомшливо прекрасним - але ймовірність того, що він запізниться на півроку, і, як правило, несумісний з будь-яким іншим фрагментом коду в (що має бути) системі, і до моменту її отримання досить справедливий шанс, що щось інше досить змінилося, що ви взагалі не можете його використовувати.

Існують також мови, які, безперечно, спрацювали б чудово, але (правильно чи неправильно) просто не мають (або у вирішальний час не мали) частки ринку, щоб хто-небудь коли-небудь писав у них браузер. Враховуючи розмір і складність повноцінного браузера, на розробку цього потрібно багато людей і зовсім небагато часу. Завдяки такому інвестуванню багато людей відносно консервативні щодо таких речей, як інструменти розвитку.

Вантажно-культове програмування. Сприйняття того, що "C ++ швидкий" все ще існує (незважаючи на погано продумані функції рівня мови, як-от погано розбита об'єктна модель, яка сповільнює роботу), і люди хочуть, щоб їх браузери були швидкими, тому вони пишуть на C ++ .

У розумному світі люди, що пишуть програмне забезпечення для мереж, будуть жахатись лише однієї думки про використання мови, яка навантажена всіма властивими питаннями безпеки С, і фактично це буде злочинною недбалістю. (Подивіться лише, скільки подвигів переповнення буфера було виявлено проти різних браузерів протягом останніх 15 років чи більше! За скільки мільйонів доларів шкоди відповідають ці кодери?)

Є й інші мови, що складаються, здатні створювати швидкі бінарні файли. Проблема полягає в тому, що вони не мають такої ж експозиції, як сімейство C, і ми всі повинні страждати за це.

Веселий факт: До моменту, коли Червіс Морріс потрапив в Інтернет у 1988 році, переконливо продемонструвавши проблеми із написанням ОС та мережевого програмного забезпечення на C (які досі не вирішені донині, оскільки їм властиві вади мови ,) Apple вже кілька років випускає найдосконалішу операційну систему, яку світ бачив досі, написану на Паскалі.

Доступ до API системного рівня

Усі браузери в якийсь момент повинні взаємодіяти з ОС, а більшість основних ОС мають добре встановлені API C і C ++ та бібліотеки. Зазвичай, простіше працювати з цими API в C або C ++, ніж писати обгортки.

Контроль та портативність

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

Спадкова сумісність - не можна викинути старий код

Це не має нічого спільного з достоїнствами C ++ та інших мов. Ви точно можете написати кращий браузер з нуля такою мовою, як Haskell; такий важливий проект міг би навіть реалізувати власний JVM, якщо їм потрібно гарантувати деякі характеристики роботи. Як, наприклад, як Facebook написав власний компілятор / оптимізатор PHP.

Веб-переглядач, який працює на нестандартній розмітці, гірший, ніж марний. Спадковий компат настільки критичний і настільки складний, що переписати це просто не варіант. Багато грошей і часу вкладається в перевірену битвою безпеку тощо. Ви не можете просто відкинути цю інвестицію. Знову ж таки, як, як Facebook все ще пишеться в PHP.