re: A JavaScript-Free Frontend VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION
 

By "mistyped HTML tag" I don't just mean broken HTMl, but also cases where an attribute was misspelled, or when an element was used incorrectly.

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.

Again, it boils down to HTML having much less in-built complexity to it. I think that's the big takeaway from this article: most of the stuff we use JavaScript frameworks to accomplish are not complex enough problems to justify such a complex solution. As the author points out, there are cases where this is not true, and in those cases, sure, sprinkle in some JS. But you can get pretty far without it.

Not necessarily. A non-existent attribute isn’t gonna be caught as easily as as trying to read a non-existent variable.

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'.

That’s his own fault for not checking the event handler to begin with.

I mean, then it would be your own fault for not checking the attribute to begin with. What's the difference?

The attribute where it went wrong might not be obvious.

The same can be said of events. I guess my point boils down to: anything that can go wrong in HTML has a direct analog in JavaScript, and there's a thousand extra things that can go wrong in JS as well.

code of conduct - report abuse