Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Я, возможно, ошибаюсь, но выглядит как какое-то костыльное решение. Половину напишем на CSS, для трети используем стороннюю либу у которой аж 128 звезд на умирающем кодохостинге, а все оставшееся забросаем патчами. И будет высокопроизводительный новый браузер…
Мне кажется, гораздо логичнее было портировать MSXML, который уже прошел огонь, воду и медные трубы.
Мне кажется, гораздо логичнее было портировать MSXML, который уже прошел огонь, воду и медные трубы.
Могу только предложить автору почитать про Selenium, про Selenium WebDriver API, и забыть про вещи, которые принимали в 2004 году.
Новый браузер, новые костыли, нашли чем гордиться… 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 же. Не хипстерский стартап.
На мой взгляд, отличное инженерное решение. Почти хакерское (в исконном, не попсовом, смысле этого слова). Собственно, потому я и перевёл статью, что читал, и думал «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 селекторы и новый сложный хак. Именно чтобы избавиться от таких хаков и решили выпустить новую версию.
Всем известно чего ожидать от этого полифила и как с ним работать. Тут же, еще одна версия реализации, потраченные человеко-часы на трансляцию XPath в CSS селекторы и новый сложный хак. Именно чтобы избавиться от таких хаков и решили выпустить новую версию.
С аргументами согласен, но hasLayout в свое время был тоже интересным «временным» инженерным решением… :-)
Не будем забывать, что JS давно уже JIT-ится в нативный код, и не столь важно, на каком языке велосипед написан — C++ или JS, исполняться он будет одинаково быстро.
Ох уж эти сказки, ох уж эти сказочники!..
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поддержка DOM L3 XPath в Project Spartan