> А когда json генеришь в бекенде не подключаешь допендасов электрона?Нет. Это что ещё js в проект тащить? То есть, если бы я уже затащил полэлектрона в проект, то какая уж разница, теперь, но если я не затащил их? Если я их не затащил, то сериализацию/десериализацию json'а можно на коленке сделать за вечер. Или можно найти библиотеку, которая сериализует и десериализует, которая была сделана на коленке кем-то ещё, а потом ещё десяток человек эту библиотеку допиливал, вычищая её от багов и неудобств. Эта библиотека будет на гораздо проще, чем парсинг html'я. Если использовать SLOC в качестве измерительного инструмента, то я предполагаю, что на порядок, на два будет меньше.
С html'ем тоже так можно, в принципе, его синтаксис (согласно стандарту) довольно простой, написать его парсер за вечер вполне реально. Но где ты найдёшь html, с которым такой парсер справится, если весь html порос синтаксическими ошибками? И вот тебе уже нужен парсер, который создаёт DOM, с бэктрекингом, чтобы находя синтаксические ошибки, исправлять их модифицируя DOM. И вот уже твой парсер без динамического выделения памяти просто никак не может работать. То есть, допустим, есть у нас статья, мы хотим вынуть оттуда заголовки, чтобы создать содержание, параллельно посчитав какую-нибудь статистику (скажем количество символов/слов/абзацев/таблиц/изображений/внешних-ссылок в каждом из разделов отражённых в содержании), и мы не можем это сделать качественно без создания DOM, потому что без DOM мы не можем грамотно справляться с синтаксическими ошибками, а не справляясь с ними мы не можем распарсить html.
Ты в курсе, что если бы html с синтаксическими ошибками не существовал бы в природе, то парсинг необходимый для этой задачи не требовал бы динамического выделения памяти? Буфер бы пришлось выделить, куда читать html чанками, и под содержание надо было бы выделить память, но на этом бы всё и кончилось. Не надо было бы под каждый span/div/a/img выделять память. И под каждый атрибут каждого тега тоже не надо было бы. То есть такой парсер был бы не только резко проще, он был бы на порядок быстрее, чем то, что есть в electron. Он был бы реально O(n) парсер, в то время как про парсеры в браузерах я, допустим, не уверен совершенно, что они не могут в каких-то случаях показывать производительность уровня O(n^2) или даже O(exp(n)). Но даже если не могут, они умножают n на время выделения/освобождения памяти, а куча -- это кошмарно тормозная вещь. Хуже кучи только сисколлы.
> Имхо конечно, но здесь уже вопрос удобства работы с жсон или хтмл для каждого свой.
Я не спорю с тем, что универсальной истины не существует, но здесь ты перегибаешь палку постмодернизма. Ты, ковыряясь с бекендом и подключая электрон в депендансах, не получаешь совершенно никаких выгод от того, что тебе на вход влетает синтаксически неверный html. Ты получаешь лишь недостатки: электрон из-за этого толще, парсинг жрёт больше памяти и работает на порядки медленнее. Может быть эти недостатки несущественны для твоей задачи, но они не прекращают быть недостатками от этого, они становятся несущественными недостатками.
Преимуществ же ты не получаешь ровно никаких.
Мне в принципе, фиолетово -- json, html, s-expressions, или что там использовать в качестве способа кодирования. Я не вижу принципиальной разницы. Все эти разговоры о том, что что-то из этого нечитабельно, из-за чего-то вытекают глаза... эти разговоры меня нисколько не впечатляют, потому что я знаю способы, как таких недостатков можно избежать. Но html содержит синтаксические ошибки, и содержит их он потому, что вся инфраструктура заточенная на html позволяет содержать синтаксические ошибки. И я не вижу способа исправить это, кроме как выкинуть html в окно и заменить чем угодно ещё.
