У subj на клиенте не находится SAX либы.
fast-xml-parser декларирует, что он "быстр" и что быстрее нативного XMLHttpRequest (через которого всё затягивается afaik).
$>У subj на клиенте не находится SAX либы.
$>fast-xml-parser декларирует, что он "быстр" и что быстрее нативного XMLHttpRequest (через которого всё затягивается afaik).
Здравствуйте, Pzz, Вы писали:
Pzz>А в чем заключается наброс?
Алгоритмы XML парсера известны, DOM- самый первый и самый медленный, а реально быстрый SAX не реализован. Собственно XMLHttpRequest, который DOM, уже с самого начала был с XML, но ему зачем-то отрезали эту фичу в ангуларе и потому люди колхозят свои DOM-парсеры.
$>Алгоритмы XML парсера известны, DOM- самый первый и самый медленный, а реально быстрый SAX не реализован. Собственно XMLHttpRequest, который DOM, уже с самого начала был с XML, но ему зачем-то отрезали эту фичу в ангуларе и потому люди колхозят свои DOM-парсеры.
DOM и SAX — это лишь стандартные интерфейсы к парсеру. Парсер может быть медленным и с SAX интерфейсом, а может быть быстрым, но с DOM интерфейсом. А может быть и наоборот.
Здравствуйте, Mamut, Вы писали:
_>>Алгоритмы XML парсера известны,
M>да, известны
_>>DOM- самый первый и самый медленный, а реально быстрый SAX не реализован.
M>потому что HTML — не XML.
И что? При чём тут это?
_>>Собственно XMLHttpRequest, который DOM
M>XMLHttpRequest — не DOM
_>>, уже с самого начала был с XML
M>не изначально. Ему пофиг, что гонять по сети, просто первыми данными, которые гоняли в 2001-м году, был XML
_>>но ему зачем-то отрезали эту фичу
M>никто ее не отрезал
_>> в ангуларе
M>при чем тут ангуляр?
Здравствуйте, Pzz, Вы писали:
Pzz>DOM и SAX — это лишь стандартные интерфейсы к парсеру. Парсер может быть медленным и с SAX интерфейсом, а может быть быстрым, но с DOM интерфейсом. А может быть и наоборот.
OMG. Прочитай про типы парсеров XML, потом возвращайся.
$>У subj на клиенте не находится SAX либы.
$>fast-xml-parser декларирует, что он "быстр" и что быстрее нативного XMLHttpRequest (через которого всё затягивается afaik).
nodejs либы славятся своим количеством но не качеством
2. Из-за того, что кто-то в каком-то фреймворке сделал свою обертку, которая что-то там не делает, ты делаешь далеко идущие выводы... о чем-то. О чем твои выводы, совсем непонятно. Смешались в кучу XML, DOM, XMLHttpRequest, ангуляр, парсеры...
M>>не колхозят
$>Ок, велосипедят.
Никто не велосипедит собственные DOM-парсеры уже очень давно.
* This assumes the BSD realloc, which only copies the block when its size
* crosses a power-of-two boundary; for v7 realloc, this would cause quadratic
* behavior.
Здравствуйте, $$, Вы писали:
Pzz>>DOM и SAX — это лишь стандартные интерфейсы к парсеру. Парсер может быть медленным и с SAX интерфейсом, а может быть быстрым, но с DOM интерфейсом. А может быть и наоборот.
$>OMG. Прочитай про типы парсеров XML, потом возвращайся.
Не, ну так не честно. Я думал, будет настоящий честный наброс, а ты просто хамишь, как продавец на рынке, которого поймали за попыткой впарить гнилую морковку.
Здравствуйте, Mamut, Вы писали:
GIV>>>ЗЫЖ SAX отстой, StAX рулит. M>$>Там просто целиком XML в JSON конвертится.
M>Потому что это заявленная возможность и цель библиотеки
M>
M>Validate XML, Parse XML to JS/JSON and vice versa, or parse XML to Nimn rapidly without C/C++ based libraries and no callback
M>$>С промежуточным DOM внутри либы, и к этому у меня вопросы.
M>Потому что ты не понимаешь ни что библиотека делает, ни ее цель, ни что именно заявляют авторы библиотеки:
M>
M>Faster than any pure JS implementation.
Я заглянул к ней внутрь. Написать простой XML парсер (без валидации) можно даже просто в качестве разминки. И он будет быстрее, чем эта имплементация, тоже без валидации. О том и речь, если настолько печалька с алгоритмами у жаваскриптистов, что эти ребята открыли для себя Америку и делают громкие заявления "быстрей чем любой JS парсер".
M>Вот бредятина, что ты несешь:
M>
M>fast-xml-parser декларирует, что он "быстр" и что быстрее нативного XMLHttpRequest
