In the last year, I can remember maybe 2 instances of broken HTML that took me some time to find, but I run into JS errors weekly, if not daily, where the exception and stack trace are useless and I spend a good 20+ minutes tracing through the code or stepping through in a debugger before I can find the bug.
In general, HTML is significantly less complex by its nature, so there's just less that can go wrong. And HTML validators are pretty solid at this point, and have been for a long time.
Sure, all of the above. Both of those are (again, in my experience) 100x easier to track down and solve than, e.g., an obscure bug caused by mistyping a property name in some callback halfway down an RxJS pipe.
And in fact, both of those can also be caught by IDEs and/or HTML validators, since attributes and elements are standardized, and anyway, the cases where "an element was used incorrectly" will cause significant problems are usually cases that are visually obvious, and thus easy enough to trace, or that cause accessibility problems, which should also be clear enough if you're doing a11y testing in the first place.
Sure it is. For one, attributes typically have effects that are obvious when missing. For another, HTML5 doesn't allow custom attributes that aren't prefixed with data-, and most HTML validators will catch them.
And anyway, you wanna talk JS, how about mistyped event names? Just last week my teammate lost hours in a weird bug that boiled down to a '$destroy' event mistyped as '$destory'.
I mean, then it would be your own fault for not checking the attribute to begin with. What's the difference?
Congratulations Ken for your patience in this conversation. I am impressed
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.