Comments 93
И как-то стыдно после нее писать о Lambda, Elastic Beanstalk, DynamoDB и прочих сервисах AWS
Каждый тренд кем-то когда-то был создан.
Конечно, не одним юзером с одной статьей, но тем не менее.
JS медленный и тежелый, но это не основная его проблема. Основная, это то, что вы позволяете исполнятся на вашем компьютере код, который вы по сути не знаете что он делает. Да, в песочнице, да вроде все герметично. Но все-таки течет. Фингерпринтинг без JS почти невозможен. По крайней мере, противостоять ему вполне можно. С JS — mission impossible.
И да, когда говорим о web приложениях и SAAS, то без JS никак. Но зачем нам JS, когда хотим просто получить документ???
Так что, я двумя руками (и ногами) за!!!
В случае нативного приложения, вы можете использовать приложения с открытом кодом и проверить код до его выполнения, а с JS, да, можете заблокировать, но только если знаете какой код вреден. А вы этого почти никогда не знаете.
Конечно можно остановить все и запускать выборочно. Но сколько из сайтов заработают после этого?
И тут приходим к тему статьи — сайты в стиле 90-х заработают все. Что и надо было доказать.
А по поводу скриптов — ну да, все заблокировано по умолчанию и разблокируется руками до обеспечения работоспособности (однако некоторые сайты требуют столько всего, что их проще закрыть).
![](https://habrastorage.org/webt/0b/0_/yg/0b0_ygm-ww23riaqrof_90ufglu.png)
В случае нативного приложения, вы можете использовать приложения с открытом кодом и проверить код до его выполнения, а с JS, да, можете заблокировать, но только если знаете какой код вреден. А вы этого почти никогда не знаете.
Ахахахаха.
Знаете. Обычный пользователь, да даже и программист, не может посмотреть код открытого продукта и проверить его. Если продукт не 100 строк, то в нем можно обсфуцировать столько, что искать будут годами.
А вот заблокировать JS может ЛЮБОЙ пользователь с плагином или даже встроенным конфигом в браузер. Без всякой квалификации.
И тут приходим к тему статьи — сайты в стиле 90-х заработают все. Что и надо было доказать.
В сайтах в стиле 90х никакой валидации не было. Почти на каждом сайте можно было в форму ввести sql-injection или кусок перл-команды, и оно могло сработать в 50% случаев. Современной песочнице в браузере доверия гораздо больше, чем бэкенду, который выполняется на сервере и имеет доступ к миллионам юзеров.
Ахахахаха.
Знаете. Обычный пользователь, да даже и программист, не может посмотреть код открытого продукта и проверить его. Если продукт не 100 строк, то в нем можно обсфуцировать столько, что искать будут годами.
Я никогда не видел обфусцированный код в свободном проекте. Что я делаю не так?
И да, я не могу проверить весь код, который я использую. Но дело в том что код этот многие читают и проверяют и кто-нибудь, да увидит вредный код. А JS просто присылают вам и запускают неизвестные люди.
Конечно большой, известный сайт не станет вредить себе используя вредоносный код. Но дело в том, что современный веб в 90% не работает без JS.
И что остается? Посещать только больших сайтов? FB/Google/VK/Yandex/Twitter? Нет, спасибо! Веб был задуман не для такое и мне такое не нравится.
В сайтах в стиле 90х никакой валидации не было...
Статья не об этом. Сайты в стиле 90х, это не сайты с уязвимостях 90х. Конечно можно делать сайты которые безопасны не используя JS или ограничено используя JS только для удобство, но не и для ключевого функционала.
Я никогда не видел обфусцированный код в свободном проекте. Что я делаю не так?
Предположим знаменитый heartbleed openssl это не баг, а бэкдор. Код не был обфусцирован, вы его нашли?
Так, нашли же. Может и не я, но все-таки нашли. А может и я. Интернет штука такая, никогда не знаешь точно с кем общаешься. :P
ну и во вторых, было же заявление
вы можете использовать приложения с открытом кодом и проверить код
вот открытость openssl лично каждому как помогла проверить его на баги? люди дождались пока не нашел дядя, точно так же как и с закрытым по.
Значит вы покупаете тот же товар за 1000, а не за 100 потому что "и там и там платить. какая разница?"
Количество имеет значение.
И нет, с закрытом ПО это так не работает. Там даже если баг и известен, дядя может пофиксить, а может и нет. Может и завтра, а может и через год. И вы ничего сделать не сможете.
А в открытом ПО скорость исправлении багов намного, намного выше. А если никто не хочет исправлять баг который вам мешает, вы можете взять и починить. Я это делаю иногда – очень удобно.
И да, я не могу проверить весь код, который я использую. Но дело в том что код этот многие читают и проверяют и кто-нибудь, да увидит вредный код. А JS просто присылают вам и запускают неизвестные люди.
1. Не факт. Баги в опенсорсе могут быть годами. Закладки могут быть годами. А специально сделанная закладка так тем более, особенно если это от основателя или контрибьютора, чей ревью почти не делается.
Обсфукция это не обязательно вставка base64 строк и пложение функций с именем _. Нужная вещь может быть скрыта в большом количестве команд довольно незаметно.
2. В современном вебе, особенно в JS стеке, принято юзать зависимости налево и направо. То есть проверять уже нужно не только этот код, но и ВСЕ ЕГО ЗАВИСИМОСТИ.
Вредоносный код может быть и в опенсорс, может быть в проприетарном софте, может быть в андроид маркете или еще где — обычный пользователь не способен и не обязан во всем этом разбираться.
Вот взять постороннего не айтишника и спросить у него а знает ли он вообще что такое опенсорс?
А как отличить хороший опенсорс от плохого? По количеству коммитов? количеству контрибьюторов? Количеству пользователей? Где смотреть? Как убедиться, что эти цифры не подделка? Видите сколько вопросов.
Основная, это то, что вы позволяете исполнятся на вашем компьютере код, который вы по сути не знаете что он делает
Кхм. Что простите? Вы используете только опенсорс программы, проверяя каждую строчку кода, и сами собираете из исходников? нет? Тогда на вашем пк уже КУЧА кода который вы запускаете и вы не знаете что именно он делает.
А с js хотя-бы есть возможность открыть код и изучить. К тому же она работает в «песочнице» и выйти за его рамки не может.
Столько раз дебажил минифицированый код… Это кстати очень интересно. А главное познавательно. Тут ничего сложного нет.
Сменяемость можно предотвратить реализовав расширение которое не будет пускать файлы с левым хешем. Правда долго будет такой интернет грузиться. Зато вы точно будете знать когда и что обновилось.
А вот нативный код покрытый каким-нибудь vmprotect — удачи вам.
К тому же, существует кеширование, позволяющая не генерировать каждый раз все заново, а сохранять результат и выдавать его сразу, если он все еще актуален.
необходимые для генерации страниц на стороне сервера, когда у Вас появится, скажем, 100 посетителей в секунду?
У владельцев сайтов наконец-то появится повод вложиться в оптимизацию! Отлично!
кто оплатит ресурсы, необходимые для генерации страниц на стороне сервера
А что такое вы там генерировать собрались?
Формирование ответа API в формате JSON сопоставимо с рендером HTML и оба требуют мизер ресурсов по сравнению с тем же походом в базу.
Рендер HTML может требовать десятков дополнительных походов в базу на каждый клик по сравнению с аналогичным JSON
Пользователю необходимы одни и те же данные, независимо от формата ответа. А значит и запросы будут одинаковые.
Как правило, один json — это одна единица контента (статья, товар, состояние счёта, и т. п.) или их список, а у пользователя страница кроме основного контента состоит из множества блоков: меню, прочие навигация, "блог на хабре", "рекомендуемые", "обсуждают сейчас" и т. п.
Соответственно, в таком случае надо сравнивать формирование одной html страницы c несколькоми запросами к json API (чтобы получить тот же результат). В таком варианте json ещё и проигрывать будет, так как множество запросов к API потребует дублирующих запросов в базу (например, на проверку прав).
Но можно и формировать страницу из нескольких запросов за html. В этом случае опять-таки, рендеринг html будет сравним с json.
Соответственно, в таком случае надо сравнивать формирование одной html страницы c несколькоми запросами к json API (чтобы получить тот же результат).
Зачем так сравнивать? Собственно основной плюс клиентского рендеринга в том, что не надо рендерить каждый раз страницу полностью, если очевидно, что только часть отображаемых данных нужно изменить в ответ на действие пользователя.
Но даже при таком сравнении несколько запросов к API могут оказаться быстрее для конечного пользователя, потому что будут исполняться параллельно и пользователь быстрее получит доступ к основному контенту.
Зачем так сравнивать? Собственно основной плюс клиентского рендеринга в том, что не надо рендерить каждый раз страницу полностью, если очевидно, что только часть отображаемых данных нужно изменить в ответ на действие пользователя.Это не является эксклюзивным преимуществом именно клиентского рендеринга. То же самое можно реализовать и при генерации HTML на серверной стороне: кэшировать ранее сгенерированные куски HTML и при ответе на запрос собирать страницу из кэшированных не изменившихся кусков и сгенеренных новых изменившихся. Все это, например, было почти изначально в древнем (хоть и не 90-х годов) SSR-фреймворке ASP.NET Web Forms.
Но даже при таком сравнении несколько запросов к API могут оказаться быстрее для конечного пользователя, потому что будут исполняться параллельно и пользователь быстрее получит доступ к основному контентуЭто тоже не является эксклюзивным преимуществом клиентского рендеринга. Ничто не мешает делать несколько асинхронных параллельных запросов данных и при генерации HTML на серверной стороне. В уже упомянутом Web Forms такая возможность появилась, хоть и не сразу, но лет семь назад она уже точно была.
В целом, конечно, клиентский рендеринг может дать меньшие задержки, чем SSR (кроме как на сосвем уж слабых клиентах), но смысл утверждения п.1 обсуждаемой статьи как раз в том, что благодаря росту мощности серверов и скорости сетей эта разница может стать для пользователя несущественной.
Вы серьёзно считаете рендеринг HTML тяжёлой задачей?
А так уж, например, Хабру, вообще необходим JS? Что в нём такого, что нельзя реализовать без JS? Текстовый редактор? Ну да, будет менее удобный, через кнопку Preview… но это Хабр! Читать его от этого не перестанут.
Веб в 90е был подушевней :)
Тогда в интернет ходили только те, кто очень хотел, и кто знал, зачем он туда идёт. Интернет был отдельным интересом человека, как детективы или джаз, а не просто ещё одной реальностью для всех. А теперь в интернете есть все школьники и все автомойщики с поварами и ветеринарами. Это больше не клуб по интересам.
только те, кто очень хотел, и кто знал, зачем он туда идёт.С одной стороны понятно, почему такая реакция, когда-то более-менее элитарное место стало массовой культурой, но это не значит, что интернет стал хуже. Годного контента стало больше, всякого остального тоже, но нельзя говорить, что первый стало сложнее искать, поиск информации средствами одними поисковыми сайтами был ужасно не эффективен, а когда-то и их не было, поиск информации сейчас заключается в отсеивании всякого мусора, тут еще можно поспорить, что из этого сложнее.
Веб, особенно в СНГ начался ближе к 2000м.
После того, как мы потратили лучшую часть последнего десятилетия на то, чтобы перенести логику рендеринга веб-страниц на клиентские системы, возникает такое ощущение, что маятник готов качнуться в направлении серверного рендеринга.
Неужели я снова смогу заниматься веб-серфингом на своем добром старом ноуте 2005 года выпуска? :)
Это была бы отличная идея, если бы ее таки воплотили в жизнь.
В вебе есть два принципиально разных класса ресурсов.
Первый класс — это документы. Изначально они были текстовые, содержали ссылки, иногда — рисунки (которых со временем становилось все больше), в более позднее время время — видеофрагменты. К классу документов можно, на самом деле, отнести также и фотоальбомы, и видео. Ценность документов для пользователя — в их содержании, которое уже готово к отображению и дополнительных действий от пользователя почти не требует. Ключевая особенность документов — неинтерактивность: пользователи ограниченно взаимодействуют с ними, причем — малым количеством заранее предусмотренных способов: текст можно прокручивать в окне, выделять и копировать в буфер обмена, по ссылке можно перейти, видео — запускать, останавливать, менять громкость и т.д. Веб изначально был основан на концепции документов. Поддержка текста с картинками была сразу после появления — поэтому развитие веб мало что дало сайтам с документами типа lib.ru. Cтандартизация поддержки видео появилась сильно позднее, но видео в концепцию документов тоже укладывается.
Второй класс ресурсов — это интерактивные приложения. Их ценность для пользователя — служить интерфейсом доступа к ресурсам в вебе — разнообразным внешним хранилищам информации (службы поиска типа Яндекса и Гугля, расписания транспорта и т.д.), средам общения (от гостевых книг до соцсетей), заказу товаров и услуг(интернет-магазины). Ключевой особенностью интерактивных приложений является именно их интерактивность — они предназначены для принятия запроса от пользователя и предоставления ему ответа. И вот с интерактивностью в вебе изначально было плохо, и основная часть развития веба — это развитие средств общения с пользователем с целью улучшения работы интеракивных приложений.
PS Есть ещё третий класс, с позволения сказать, ресурсов — реклама (тут чисто личное — рекламу я не люблю, сильно). Но поскольку она IMHO не является самостоятельной ценностью для пользователя (а служит лишь для оповещения его о наличии других ценностей), то я её рассматривать не буду. Хотя именно улучшение возможностей рекламы было на само деле одной из движущих сил развития веба, об этом — как-нибудь в другой раз.
разнообразным внешним хранилищам информации (службы поиска типа Яндекса и Гугля, расписания транспорта и т.д.), средам общения (от гостевых книг до соцсетей), заказу товаров и услуг(интернет-магазины).
Что интересно — у старых компьютеров (а к ним можно отнести те, что не удовлетворяют минимальным требованиям 10) нет проблем с гуглом, банк-клиентами, кассами по продаже билетов и с интернет-магазинами
Все это работает на удивление быстро.
А вот стоит зайти на любой другой популярный сайт (новостные, в первую очередь)- и вот там начинается.
Что сразу наводит на мысли, что дело вовсе не в классах ресурсов.
По поводу рекламы: по моим многолетним наблюдениям, хороший эффект дает скрытая реклама, содержащаяся в тексте статей и красиво подобранные иллюстрации к ним.
Вся контекстная реклама — абсолютно без толку.
(Ну, разве что дает возможность узнать, что гуглят другие члены семьи :)
И формат давно вылез за границы соцсетей — это типовой формат публикации для ресурсов, наследующих бумажным журналам, от Тиньковского до какого-нибудь InputMag.
Но давайте попробую угадать: для таких ресурсов обязательно есть мобильное приложение (или прям сейчас планируется)?
Если я угадал, то эти ресурсы — тоже приложения, хоть и специфические, развлекательные.
В принципе, для них и на десктопе браузер не особо нужен: под Win10, вроде как (ни разу не пользовался), тоже есть нечто подобное мобильным приложениям. Отстаются, кончено, еще десктопы на Linux, но что-то мне подсказывает, что аудитории таких приложений и пользовтаелей десктопного Linux пересекаются слабо.
Да кто IE тогда юзал то? Netscape у всех стоял.
SSR иногда может быть быстрее чем клиент рендер. Особенно в части получения первого экрана и его видимости для посетителя.
Но почти всегда медленнее чем SSG или fcgi-cache. Где то тут было сравнение SSR NextJS vs SSG GatsbyJS. SSG оказывался быстрее.
Если вы сделаете сайт на вордпрессе, с кучей кривого кода, где SSR и TTFB будет в районе 1 минуты, то просто fcgi-cache позволит получать страницу в те же 50-100 мс что у dev.to — если верстка будет более мене адекватная, то и показываться тоже будет быстро.
Бывают гибриды. Когда основной контент это SSG или SSR. Или SSR с кешем в SSG.
А интерактивные элементы и фрагменты страницы, контент которых зависит от пользователя — рендерятся на стороне клиента. Например похожим образом работает GitHub.
На мой взгляд ничего нового тут нет. Просто хайп вокруг клиентского ренденринга проходит. И может быть его даже перестанут пихать всюду где надо и не надо. Он останется только там где и был придуман — интерактивные веб приложения и виджеты. Например аппки типа Трелло, Чаты или виджет чата для сайта. Которые нельзя или сложно сделать через чистый SSR.
4G, tele2, Тамбовская область, 25-60 мегабит/секунду в данный момент на скачивание до hgd-speedtest-1.tele2.net
Да и проекты «интернет для бедных» предполагают основную работу на серверах и в облаке, для удешевления бомж-буков. 50 баксов за девайс, какой там JS, какие скрипты, что пришло с сервера, то и показать, хоть как то.
А если ваш сайт получит хоть какую-то популярность, его убьют таким лютым DDoS, какие в 90-е никому даже не снились.
И у кучи стартапов вообще нет монетизации, нас приучили к бесплатной почте, облакам, хостингам, стримам и видео. Как говорится, за чей счёт банкет?
За счет рекламодателей, вестимо. А в конечном счете — за счет тех, кто принимает решение на основе рекламы. Крупные фирмы, вроде Гугла, на продаже рекламы неплохо зарабатывают. Ну, а стартапы и их инвесторы надеются стать крупными — чтобы тоже на этом зарабатывать.
Это рецессия
– Я понял, – перебил Татарский. – А что в конце?
– Два варианта. Если банк, которому человек должен, бандитский, то его в какой-то момент убивают. Поскольку других банков у нас нет, так обычно и происходит. Если человек, наоборот, сам бандит, то последний кредит перекидывается на Государственный банк, а человек объявляет себя банкротом. К нему в офис приходят судебные исполнители, описывают пустые бутылки и заблеванный факс, а он через некоторое время начинает все сначала. Правда, у Госбанка сейчас появились свои бандиты, так что ситуация чуть сложнее, но в целом картина не изменилась.
– Ага, – задумчиво сказал Татарский. – Но я не понял, какое отношение все это имеет к рекламе.
– Вот здесь и начинается самое главное. Когда примерно половина «Смирновской» или «Абсолюта» еще не выпита, джип еще ездит, а смерть кажется далекой и абстрактной, в голове у человека, который все это заварил, происходит своеобразная химическая реакция. В нем просыпается чувство безграничного величия, и он заказывает себе рекламный клип. Причем он требует, чтобы этот клип был круче, чем у других идиотов. По деньгам на это уходит примерно треть каждого кредита. Психологически все понятно. Открыл человек какое-нибудь малое предприятие «Эверест», и так ему хочется увидеть свой логотипчик по первому каналу, где-нибудь между «БМВ» и «Кока-колой», что хоть в петлю. Так вот, в момент, когда в голове у клиента происходит эта реакция, из кустов появляемся мы.
Татарскому было очень приятно услышать это «мы».
– Ситуация выглядит так, – продолжал Морковин. – Есть несколько студий, которые делают ролики. Им позарез нужны толковые сценаристы, потому что от сценариста сейчас зависит все. Работа заключается в следующем – люди со студии находят клиента, который хочет показать себя по телевизору. Ты на него смотришь. Он что-то говорит. Ты его выслушиваешь. Потом ты пишешь сценарий. Он обычно размером в страницу, потому что клипы короткие. Это может занять у тебя две минуты, но ты приходишь к нему не раньше чем через неделю, – он должен считать, что все это время ты бегал по комнате, держась руками за голову, и думал, думал, думал. Он читает то, что ты написал, и в зависимости от того, нравится ему сценарий или нет, заказывает ролик твоим людям или обращается к другим. Поэтому для студии, с которой ты работаешь, ты самый важный персонаж. От тебя зависит заказ. И если тебе удается загипнотизировать клиента, ты берешь десять процентов от общей стоимости ролика.
– А сколько стоит ролик?
– Обычно от пятнадцати до тридцати. В среднем считаем, что двадцать.
– Чего? – недоверчиво спросил Татарский.
– Господи, ну не рублей же. Тысяч долларов.
Татарский за долю секунды сосчитал, сколько будет десять процентов от двадцати тысяч, сглотнул и по-собачьи посмотрел на Морковина.
.
Не забывайте, что пользователь стал избалованным. В 90-х мы готовы были минутами ждать загрузки простого гипертекстового документа и радовались, что ссылки не битые, а сервер поддерживает докачку и скачивание в несколько потоков.
Когда я смотрю на некоторые современные тренды веба, я думаю о том, что, возможно, цикличность проявляется и здесь.Когда я смотрю на современные тренды Веба, мне становится по-настоящему страшно. Потому что там я вижу две ярко выраженных тенденции.
Первое. Полный отказ от текста. Всё меньше информации можно найти в текстовом виде. Всё мало-мальски полезное — это подкасты и видео, и только так. В будущем, если всё продолжится в том же духе, никакого текста в сети вообще не останется.
Второе. Постепенное отмирание соцсетей в пользу мессенджеров. И это ужас-ужас. Соцсети и так-то выглядят деградацией по сравнению с форумами, а теперь информацию нельзя будет найти вообще. Всё затачивается под юзеркейс, где пользователь заходит в группу, задаёт шаблонный вопрос, который до него задавали два миллиона раз, тут же получает шаблонный ответ и уходит счастливым. Ну, а те 0.5%, которые хотят большего — им не повезло. Никто собирать и хранить информацию для таких малозначимых случаев не будет, не говоря уж о том, чтоб давать возможность её найти.
Ну, а те 0.5%, которые хотят большего — им не повезлоМожно поподробнее чего хотят эти 0,5%? Просто текста, который легко найти поиском?
Да, эти тенденции мне тоже не нравятся. Но здесь есть и еще момент. По сути, те старые форумы и текстовые документы никуда не делись. Они в сети. Это потребители сами движутся, впервые в соц сетях, а потом в месенджерах. И потребляют главно видео и аудио контент. (иногда мне кажется, что потребители просто разучились читать).
Я например ни туда, ни туда не ходил. Мне форумы, которые кстати существуют, вполне достаточны. И потребляю исключительно текстовой контент.
Соцсети и так-то выглядят деградацией по сравнению с форумами
Я еще помню времена, когда форумы выглядели деградацией по сравнению с ньюс-группами…
Я, вообще, тоже сторонник текстовой подачи материала, но.
Подкастов я особо не слушаю, но пристрастился к аудио-книжкам. Когда едешь за рулём на работу или топаешь с утра свои 10км, текст не почитаешь, ну никак. А вот классиков послушать — самое то! Конечно, тут случаются свои недостатки, типа упоротых чтецов. Но ведь и текстовые статьи бывают разного уровня.
Вот лежит передо мной умная железка, внутрь которой я хочу забраться и чего-нибудь починить. Великолепно, если есть статья производителя с пошаговой сборкой-разборкой и качественными картинками! Но чаще всего есть ролик(и) разного качества на ютубе, где всё то же показано вживую. «Посмотри на меня, делай как я, делай как я!» И это реально удобно!
А вот классиков послушать — самое то!
У всех аудиокниг есть один существенный недостаток — диктор (чтец) вносит свою собственную эмоциональную окраску в читаемый им текст. Причем это не всегда совпадает с тем, что, собственно, хотел сказать автор.
(интонации важны, хотя за них не сажают)
Но чаще всего есть ролик(и) разного качества на ютубе, где всё то же показано вживую.
Когда речь идет о простых и понятных вещах — все ОК (в строгом соответствии с правилом «Лучше один раз увидеть...»)
Но вот когда речь идет о сложных вещах (типа замены аккумулятора в Surface Pro) — иметь под рукой четко написанную по пунктам инструкцию намного лучше, чем снятое в ускоренном темпе видео.
"....5. Последовательность разборки и сборки блока УПЗ-15
Перед разборкой блока для ремонта отвинтите два винта, крепящие блок на плате входов усилителя.
После этого выньте блок из разъема движением вертикально вверх и снимите обе крышки экрана.
После снятия крышек экрана имеется свободный доступ к печатной плате блока. Сборку блока проводите в обратной последовательности..." (с) старая добрая инструкция по ремонту
firefox никогда не назывался нетскейпом.
Mozilla Application Suite — открытый набор программ для работы в сети Интернет. Он включает в себя web-браузер, почтовый клиент, календарь, IRC-клиент ChatZilla, простой HTML-редактор и инструменты для Web-разработчиков (инспектор DOM и отладчик JavaScript). Изначально был основан на некоторой части исходного кода Netscape Navigator, и версии NN 6 и 7 были основаны на Mozilla Application Suite.
…
Firefox был выделен из Mozilla Application Suite, код которого был создан с нуля в Mozilla Foundation вместо кода Netscape Navigator 5, часть которого была выпущена под свободной лицензией Mozilla Public License после поражения в «войне браузеров».
А ещё, между мозиллой и FF, файрфокс назывался Phoenix и Firebird.
Firefox был создан потому что Mozilla Application Suite был непомерно тяжелое приложение, которого никто не хотел использовать.
Наоборот — Phoenix браузер создавался как "только браузер и ничего другого". Так что Firefox назывался: Phonix, потом Firebird и в конце (потому что конфликтировал с БД Firebird), Firefox. И ничего другого.
То что он может и использовал код (по крайней мере рендирующий енджин) Netscape, никак не делает его "Netscape".
Чаще всего этот код представлял собой гору автоматически сгенерированного мусора
Этот тренд живее всех живых) Одни конструкторы под WP чего стоят…
Возвращение веба 90-х годов