The correct answer doesn't just depend on what you mean by "regular expressions", it also depends on what you mean by "parse". And perhaps also what you mean b

The correct answer doesn't just depend on what you mean by "regular expressions", it also depends on what you mean by "parse". And perhaps also what you mean by "HTML". Case in point: A while back I ran into a nasty bug in our software which would cause it to crash with a stack overflow exception. It turned out to be that the problem was in how HTML Agility Pack would respond to certain kinds of particularly poorly-formed HTML documents. Now, we had chosen to use HTML Agility Pack in part because of all the comments to the effect of "NOOOOOO don't use regex, use Agility Pack!" complete with links to a certain famous Stack Overflow answer that are littered around the internet. But in analzying the situation in more detail, we discovered a few things: First, we were just stripping tags, so our parsing needs were very minor compared to what HTML Agility pack does. Second, generating a full-on parse tree for an HTML document was kind of harming us, in that doing so takes both time and RAM, two things we were trying to be light on. Third, we could afford to be fairly tolerant of a missed tag or some lost content, but the parser giving up was a minor tragedy. Noisy results were far better than no results for our purposes. The upshot of all this being, for our "HTML parsing" needs, regular expressions turned out to be exactly the right tool for the job. Following that realization, it was the work of only one afternoon to fix the bug, and as a side benefit dramatically improve both the engine's performance and the quality of its output. Long story short, what passes for common wisdom on the Internet is no substitute for knowing what you're doing.