E.g. maybe you had a class 'Box' with a field 'area'. Later you added fields 'width' and 'height'. What are you going to do? Change 'area' to 'getArea()' and break the API? Write extra code to ensure that you update area every time you change width or height? Or write a getter that returns width*height?
I'd say getter is the cleanest option in many cases.
And yeah, if you radically rework how you make your boxes work, that's a good time to do a refactor. But there's no reason to anticipatorily add in a bunch of complexity so that you don't have to convert a value to a property at some hypothetical future point.
(I mean, among other things, if you put your area property behind get/set methods, you still have to go and change all the setters anyway, since in your brave new width 'n' height world, setting area is nonsensical. So your API still breaks, and you still need to change your consuming code. What was the benefit of the getters/setters then?)
And the area example use-case holds if it was a read-only property.
* Given a reference to a data entity, invoking a getter on the data should always return the same result, no matter how many times it is invoked, no matter how the rest of the program or world state evolve.
There are others situations. In those situations explicit code is preferable:
* Change an attribute of a data. Do not use a setter, period. Create a data copy with the attribute changed instead. Even GUI toolkits nowadays are using immutable data patterns with great success, see React.
* Use a data entity as a facade for reading data from a 3rd party API. Instead of using an object that pretends to be data but isn't via a heavy getter, use the 3rd party API explicitly to instantiate your immutable data graph.
* Use a data entity as a facade for updating a 3rd party API. Don't use a setter, instead create an updated copy of your data, then explicitly invoke the 3rd party API with the updated data copy.
Not breaking an API is one of the few cases where they make sense, but it's sort of a hack that you have to settle for because of back-compatibility. But even then, you've already broken the API in a lot of cases. In your example, 'area' was a field you could read and potentially set. But by changing it to a derived value, code that sets it no longer makes any sense - what do you do with width and height if somebody sets the area? The underlying model changed in a way that broke the old API either way. So yeah, just change 'area' to 'getArea()'.
Unless I change width and height all the time, but only read the area very rarely: of course, and gladly so, since I much prefer that to fetching two values and making a multiplication for what could be a simple fetch instead. And don't get me started on code that uses a getter on a value that doesn't change in a loop. I don't find that stuff "clean" at all. Don't just ask how it looks in the editor, ask what it makes the machine do.
In JavaScript, there's no assurance that the object you've got even means 'area' to be a number. It could be a string indicating which warehouse the Box is in.
So yes, you bloody well bump the major version number and the consumer needs to check the errata. Pretending to maintain compatibility when you're actually messing with the meaning of things is not something which should be done silently. What happens when someone calls the 'area' setter? Does it trust the width or the height...?
Firstly objects in JavaScript are not classes, they are just your good old dictionary value store, to an JavaScript object it doesn't matter if u put a function or a value under its property, under the hood its just a pointer pointing to a memory location. infact you can dynamically change it!
Also if this code is running in the browser you get ZERO security benefits, i can still read your values through the debugger.
But it does impart some very significant slow down, especially if you are calling the getter a LOT.
With Box.area; it literally has to resolve the BOX variable name and jump 1 pointer. with BOX.getArea(); it has to create a new scope and stack for the function call and there is SO MUCH MORE going on behind the scenes.
The right solution here is absolutely to update your area as the width and height change.
please learn functional event driven programming if you are going to give advice on javascript. most of the stuff you learned and got tested on in your HS and College courses about how to properly write object oriented code does not apply to javaScript. ESPECIALLY if performance is vital, which it often is since you interact with user input.
I use strict FP languages every day and could not figure out what your point was, and your condescending intro and outro makes it hard to continue the discussion with you.