1. 39

Using generators to modernize a geriatric javascript API for $CURRENT_YEAR. Up to this, I hadn’t found a use for generators.

  1.  

  2. 9

    XPath is a funny little technology. Along with XML Schema and XML itself, it comes from an era when JSON didn’t yet exist, web APIs were new, and we thought all web pages were going to become “valid” XML documents via XHTML. Funny, because, even though JSON largely replaced XML, it turned out that XPath and XML Schema were mostly YAGNI technologies, and so we hardly use alternatives to them when we work with JSON. And, nowadays, the idea of an HTML page being valid structured data against some schema seems quaint – what with the focus on “does it render across browsers?”, “is it responsive?”, “Is it fast?”, etc.

    1. 12

      And don’t forget XSLT! ;-) Dredging up these old technologies can feel like wandering into an alternate reality.

      XPath is indispensable for quick-and-dirty web-scraping, and XSLT is, well, something—there isn’t really any direct replacement for it! I find myself writing XSLT about once a year. Most recently: rendering ALTO files as SVG overlays on scanned newspapers (to make the text selectable) completely on the client-side!

      1. 5

        XSLT is interesting for sure. I used it on a job for about 4 years. It was great for converting source documents into the specific format our system knew how to ingest.

        I haven’t written any since I left that project and can’t say I miss it, even though it was really effective for our use case.

        1. 1

          Hi5 XSLT buddy!

          I used it early in my career for more years than I’d like to remember but it was on point for that specific employer: It was a publisher that converted XML into a whole load of other formats and also added meta-data.

          The ‘crown’ of my work was converting the XML into RTF.

          1. 2

            Ha ha ha! Yeah, it’s a good tool for those jobs. Sounds like we did the opposites. I took in lots of different XML sources and converted them all into our one XML format.

      2. 10

        And, nowadays, the idea of an HTML page being valid structured data against some schema seems quaint

        I don’t think it’s surprising or necessarily bad that web pages aren’t, but the state of schema validation for JSON that does represent structured data makes me kinda sad. JSON Schema seems to have enough momentum that I’m not worried about its future, but the validator ecosystem doesn’t feel particularly healthy… and also, it’s just not as capable as XML schema.

        As for the rest of the XML tooling, it still does get used in some areas, and for me personally it’s a massive relief when I need to analyse data from some random proprietary thing and it turns out to be backed by XML, because it means the tooling to let me write queries about it is just there. Despite how popular JSON is, it hasn’t really ever got there (jq is good but limited by design; jsoniq… exists, I guess).

      3. 8

        Mind blown; I am having an on-off-relationship with web development since ~2004 and am a fan of XPath since at least 2009 and I never knew that there was a cross-browser JS API for XPath until I read your post. Not sure how that happened, thanks a lot!

        1. 3

          NodeIterator can also filter on Node.TEXT_NODE.

          1. 2

            I have two three problems with this.

            1. Namespaces in XML/HTML are not “voodoo”. The MDN docs specify exactly what the resolver function does. Just because you don’t understand something, doesn’t make it “voodoo”.

            2. Really, you’re still extending native prototypes? I guess the JavaScript community really hasn’t learn it’s lesson from the “smoosh”-pocalypse a few years ago?

            3. The third attempt, where the author attempts to access the text node directly, could have easily been adapted to simply iterate over text nodes checking for existence of the string to be replaced. I think XPath actually is a good tool to use here, but the author is clearly out of his/her depth if namespaces are “voodoo”, so iterating over nodes using the DOM is probably a safer alternative.

            1. 5

              but the author is clearly out of his/her depth if namespaces are “voodoo”, so iterating over nodes using the DOM is probably a safer alternative.

              This is needlessly exclusionary, and is exactly the sort of attitude that gives XML-related technologies a bad rap. You absolutely do not need to have a thorough understanding of namespaces to use XPath effectively.

              1. 1

                I didn’t say you need a thorough understanding.

                Calling something “voodoo” is a long way from “I don’t understand this thing in depth”

              2. 2

                Really, you’re still extending native prototypes? I guess the JavaScript community really hasn’t learn it’s lesson from the “smoosh”-pocalypse a few years ago?

                What event was this?

                1. 5

                  There’s a whole writeup about it here: https://developers.google.com/web/updates/2018/03/smooshgate

                  TL;DR: There was a proposal to add Array.prototype.flatten to JavaScript, but it turns out that would have been incompatible with MooTools’s Array.prototype.flatten, so some websites which used MooTools would have been broken. The proposal’s author jokingly suggested renaming the new function to “smoosh,” which is where the name comes from.

                  1. 2

                    I would have expected a more local implementation of the method to override the default implementation. Isn’t this the case for JS?

                    1. 1

                      No. The impact is page-global. If you’re doing webdev, you absolutely should not extend native prototypes (polyfills excepted).

                      (That said, the “javascript community” extends beyond webdev. In certain (mostly non-webdev) contexts, extending native prototypes can be completely harmless.)

                      1. 1

                        Well it depends how the JS implementation is written. Some will only add the method if it doesn’t already exist (imagine a polyfill). Why you would do that for a method that isn’t a polyfill I have no idea..