Комментарии 7
Я, возможно, ошибаюсь, но выглядит как какое-то костыльное решение. Половину напишем на CSS, для трети используем стороннюю либу у которой аж 128 звезд на умирающем кодохостинге, а все оставшееся забросаем патчами. И будет высокопроизводительный новый браузер…

Мне кажется, гораздо логичнее было портировать MSXML, который уже прошел огонь, воду и медные трубы.
Новый браузер, новые костыли, нашли чем гордиться… Shumway и PDF.js добавляют поддержку форматов, которые к веб стандартам не имеют отношения, заодно являются хорошим стресс-тестом движка.
Воу-воу, коллеги, зачем такой скептицизм?

На мой взгляд, отличное инженерное решение. Почти хакерское (в исконном, не попсовом, смысле этого слова). Собственно, потому я и перевёл статью, что читал, и думал «damn, that's so clever!»

Поясню.

Если интеграционный порт MSXML или System.XML потребует слишком больших трудозатрат, — а интеграционные порты всегда требуют больших трудозатрат, — и при этом уже есть некий solution для очень похожей задачи, то почему нельзя использовать его повторно? Готовый, гарантированно оттестированный в боевых условиях код, уже живущий в рамках того же самого продукта? Так что реюз CSS Selectors API — это офигеть как круто. Задумайтесь на минуточку: ведь бесплатное покрытие 94% real-world кейсов случается крайне редко, особенно в проектах такого масштаба, как браузер. Я отлично понимаю восторженный тон автора оригинальной статьи, сам бы в таком случае сплясал камаринского.

Более того, сплясал бы камаринского даже и за 30% бесплатного покрытия для какого-нибудь из своих проектов, которые в разы меньше, но всё равно стоят десятки тысяч человеко-часов. С точки зрения рядового кодера, это, конечно, не аргумент. Если твоё время почти ничего не стоит, можно и с нуля что-нибудь написать. Потратить год. Или там два, зато своё будет, родное… Правда, за это время конкуренты уйдут вперёд ещё дальше. Я вот, к несчастью, сеньор, и для меня каждый человеко-час любого члена команды очень дорог, поэтому крайне приветствую решения, которые связаны с минимальной необходимостью написания какого-то нового кода.

Далее, насчёт WGX.

Ещё одно по-настоящему инженерное решение. Не изобретать собственный велосипед, а взять уже готовый, высоко оценённый экспертами (не каким-нибудь хипстером Васей, а людьми, которые что-то да сделали для индустрии), и адаптировать его. Не будем забывать, что JS давно уже JIT-ится в нативный код, и не столь важно, на каком языке велосипед написан — C++ или JS, исполняться он будет одинаково быстро. Ещё мне мерещится между строк, что для сандбоксинга использовался тот же механизм, который в Project Spartan будет для расширений, а-ля хром…

Опять же, с точки зрения рядового кодера оно выглядит как костыль, но я сам с радостью использую в своих приложениях скриптовый движок, если слишком долго или неудобно писать нативный для платформы код, который реализует какую-то мудрёную логику, но при этом вызывается раз в пятилетку. Правило 20/80 никто не отменял.

И, наконец, последнее. К следующей версии они скорее всего это всё причешут, перепишут, сделают как положено. Microsoft же. Не хипстерский стартап.
Инженерное решение отличное, но не лучше было бы не идти так далеко, а остановиться на известном полифиле?
Всем известно чего ожидать от этого полифила и как с ним работать. Тут же, еще одна версия реализации, потраченные человеко-часы на трансляцию XPath в CSS селекторы и новый сложный хак. Именно чтобы избавиться от таких хаков и решили выпустить новую версию.
С аргументами согласен, но hasLayout в свое время был тоже интересным «временным» инженерным решением… :-)
Не будем забывать, что JS давно уже JIT-ится в нативный код, и не столь важно, на каком языке велосипед написан — C++ или JS, исполняться он будет одинаково быстро.

Ох уж эти сказки, ох уж эти сказочники!..
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.