DEV Community

Discussion on: How to use the methods from other objects in JavaScript

Collapse
 
gtanyware profile image
Graham Trott • Edited

While you aptly lift the lid on some of the inner flexibility of JavaScript, you also acknowledge right at the start that it's "hard to read". Which to me implies "for academic use only". This is not intended as a criticism, just a comment.

Constructs like this should carry a safety warning, as the risk to production code is of making the whole thing "write-only". Pity the poor maintenance engineer, 5 years down the line, dealing on a daily basis with JavaScript (and its fleet of frameworks), Python, Java and legacy PHP, with limited experience of but responsibility for all of these and much more, who comes across such a construct and has to make sense of it. It's essentially an undocumented feature, in that few know about it and clear explanations of how it works are hard to find.

JavaScript probably has more unusual, powerful and arcane constructs than any other language, including many that are unintended side-effects of other features. They're great for the classroom and for coding challenges, so let's keep them there.

Collapse
 
uriel_hedz profile image
Uriel

This is a pretty popular line of code that until ES6 allowed you to manipulate array like objects as arrays so, it's not just an academic example, it's a real use case of the flexibility of the language.

It's also important that as the language evolves, there are now more readable alternatives.

I believe that understanding JavaScript it's important because it allows you to embrace the way it works.

Collapse
 
gtanyware profile image
Graham Trott • Edited

Well I have to allow you that. Perhaps I came over as being a bit hostile, but I had no wish to. Just because I personally have a negative reaction to certain constructs doesn't mean they should be banned. I can't tell if others look at [].slice.apply(arguments) and experience the same feeling I do of my brain freezing over, but I operate on the principle that if something needs explaining in detail then I will avoid it if my code is to be read by people at or below my own level of ability.

The benefit to me of articles like this are they help me benchmark myself and establish an eclectic style that suits me and the likely readers of my code.

As for "more readable alternatives" - that has a thumbs-up from me, though the designers of JS are finding it increasingly harder to come up with ways to achieve this when constrained by a restricted syntax. It's not like in English, where we seamlessly add "laser" to the language to avoid saying "Light Amplification by Stimulated Emission of Radiation" every time. But don't get me started on linguistics.