nokogiri

Sort of. Go packages have the source baked into the package name. It would be like needing to say `require "github.com/sparklemotion/nokogiri"` rather than what we do today, `require "nokogiri"` and then if you want to change the source wrapping `gem "nokogiri"` in an alternate `source` block.

It seems to have an in-tree libxml 2.11 for XPath support, which was released in 2023-04. Almost every second libxml release comes with a CVE, so I'm curious if there's plans to upgrade the libxml version, since it doesn't use the system libxml (same as nokogiri). One of the reasons I still use nokogiri is because it puts a lot of effort into keeping libxml updated: https://github.com/sparklemotion/nokogiri/releases

There's three different modes of running a selector in typical browsers: (a) Element#matches (b) Element#querySelector(All) (c) By the engine for updating style and layout The GP seems to be talking about (b), but even then browsers are checking each element one by one not advancing through the selector state machine in parallel for every element. (There's one exception in the old Cobalt which did advance the state machines IIRC). (a) and (c) are conceptually very similar except that when doing (c) you're checking many elements at the same time so browsers will do extra upfront costs like filling bloom filters for ancestors or index maps for nth-child. In TFA they're doing .matches() which I would expect to be slower than a hash map lookup, but for a simple selector like they're doing (just tag name) it shouldn't do much more then

The problem is that libxml2's 20-year old HTML parser never supported HTML5 [1], leading to more and more problems with downstream consumers like lxml, PHP or Nokogiri. PHP recently switched to Lexbor [2] and Nokogiri to libgumbo [3]. That said, I'm hopeful to receive enough funding to implement a HTML5 parser in libxml2. [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/211 [2] https://wiki.php.net/rfc/domdocument_html5_parser [3] https://github.com/sparklemotion/nokogiri/issues/2204

> In some ways, XPath is like regex. It's got insane power, but comes with a relatively steep learning curve. Remember reading regex for the first time? What? But unlike regex, the number of people using it are few in comparison. IMO the learning curve of XPath is not that high though, it has a somewhat alien syntax but the only thing I remember giving me trouble is axis, because most tutorials just go on with the "shortcut" syntax so the first time you encounter axis everything goes pear-shaped. > There are functions in XPath 2.0 that I would love to have, but Nokogiri for Rails is stuck in 1.0 world with no plan to go to 2.0. Sad, but I'll live. Nokogiri should support function extensions[0] and most of the XPath 2.0 functions were originally extensions to 1.0[1], so even if these functions are not distributed with nokogiri you should b

You may be interested in precompiled native Nokogiri: https://github.com/sparklemotion/nokogiri/issues/2075

yes, to be fair they patch vulnerabilities in their vendored version of libraries https://github.com/sparklemotion/nokogiri/issues/1992

Nokogiri comes with a command-line tool for just that purpose: https://github.com/sparklemotion/nokogiri/blob/master/bin/no... Example: nokogiri https://news.ycombinator.com -e 'puts $_.css("td.title a @href")'

This is the specific example that happened not long after I abandoned Windows development altogether (I'd been using RoR since 2007, and Linux since 1995, but hadn't gone full time with both except through my own company): https://github.com/sparklemotion/nokogiri/pull/554 Gave me the warm fuzzies, even though I broke everything temporarily :)

Since this sounds like it affects a lot of people in a lot of places, I went about auditing my own code and found that if you're using libxml2 >= 2.9.0, you should be safe, unless you're explicitly requesting entity expansion: https://mail.gnome.org/archives/xml/2012-October/msg00045.ht... For the nokogiri users, there are a couple of proofs-of-concept in this ticket: https://github.com/sparklemotion/nokogiri/issues/693 - they should be patched with modern versions of nokogiri and libxml2, but if you're running older versions, you might want to verify their behavior before someone else does it for you.