How could you miss components, the new web revolution? :) Here it is being presented by Google: https://www.youtube.com/watch?v=2toYLLcoY14 https://www.youtube

How could you miss components, the new web revolution? :) Here it is being presented by Google: https://www.youtube.com/watch?v=2toYLLcoY14 https://www.youtube.com/watch?v=2toYLLcoY14 It's basically custom HTML tags like: <tabs> <tab>Alpha</tab> <tab>Bravo</tab> <tab>Charlie</tab> </tab> and some JavaScript library ("a new type of library for the Web") that processes these custom tags to display tabs on a web page. I'm talking about pattern matching for templating rules; e.g. I want to handle a "value" token differently depending on whether the parent is a "field" or a "value-list" With XSLT I do this with a pattern: "field/value" vs "value-list/value". It's very clear and very efficient behind the scenes (about as speedy as a regex). I'm not sure I can do it in Python as easily. As for parsers: parsers are a good thing, certainly, but look at what they do: they take an unstructured sequence of symbols and try to recover the hidden structure of it using a set of grammar rules. The end result is a tree that still contains the original sequence but dissects it into a hierarchy of discovered non-terminals. Doesn't this look familiar? It's an XML document. XML documents are basically preparsed sequences or serialized parse trees. Maybe they have been parsed already by a specialized parser; or maybe the structure was added there manually when we marked up a text in a natural language; or maybe the sequence was generated by a machine in the first place and we just retained the original structure. What XML does is that it saves the result so there's no need to parse the same sequence again. (Well, there is; we still need to deserialize the XML document and to interpret certain sequences as strings and another as numbers or dates and this is also parsing; but the serialization notation is much simpler than the grammars that were involved to parse or build the original tree.) This is why parsing HTML is a waste of time regardless of whether we do this with regular expressions, recursive descent, Earley, LALR, Tomita, PEG, or whatever parsing technology we like :) It has been parsed already; we only need to deserialize it, and this is a trivial task that has been solved long time ago. (Well, maybe not with HTML, because somehow it's important to accept broken HTML and this may require a full-fledged parser and then some.)