re: A JavaScript-Free Frontend VIEW POST

re: [deleted]

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.


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?


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.

Congratulations Ken for your patience in this conversation. I am impressed

code of conduct - report abuse