4 ms·
I understand there are some runtime implications but the vast majority of the "classes" created in my applications are instantiated once or only at startup. The
by andrewstuart2 10y ago
I understand there are some runtime implications but the vast majority of the "classes" created in my applications are instantiated once or only at startup. The memory usage and speed implications are negligible compared to the added maintainability.
In the grand scheme of all the allocation and computation taking place in my applications, these concerns are very far down the line.
Now, if you happen to be creating an application or framework that for some reason has to do a whole lot of allocating and might be meaningfully and measurably affected by such issues, then by all means use prototype "methods" when it will make a difference.
Personally, code clarity is much more important than making sure my application starts microseconds faster and allocates several bytes fewer per instance when there are only going to be ~10s of instances ever created.
- vmasto 10y agoAs long as we are extremely clear of the implications it's a good enough reasoning. Many people, especially newcomers, believe that just because their code initializes a class only N times it's being instanced exactly N times. This is false more often than not, especially in server environments.
- acjohnson55 10y agoI'd argue that adhering workaround for things that have language-level solutions nowadays hurts code clarity, if other people have to work with your code. Sure, the non-functional noise fades to the background when you're used to the pattern, but ES6 has been out for a while now, and it provides reasonable solutions.
- andrewstuart2 10y agoUnless javascript removes alternate meanings of `this`, which will never happen, it does not have a language-level solution. In fact, I think it's easily as reasonable a solution as lambdas. I may be biased because I think ES6 is a hot mess, but the lack of `this` binding of lambdas is a serious misstep IMO. If anything, ES6 lambdas add yet another way of interpreting `this` because while it is a function, it's not functionally scoped. Even better, a lambda is a function but `call` and `apply` are interpreted differently [1] since `this` is not bound. If you ever need to use `call` or `apply`, you'll have to know exactly how the called code is implemented to avoid bugs. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Invoked_through_call_or_apply https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- orf 10y ago> code clarity This makes sense if it's only you working on a project, but it would be pretty confusing and weird for someone new to join.
- andrewstuart2 10y agoWhat would be confusing and weird?
- orf 10y agoIt being done nowhere else? Muscle memory? It looking non-standard and harder to parse?