If the code was buggy, fix the bugs. If the code was truly redundant, you could delete it. I suspect you meant more that it was repeated in several places, in

If the code was buggy, fix the bugs. If the code was truly redundant, you could delete it. I suspect you meant more that it was repeated in several places, in which case, of course refactor it to be more DRY. If you can write an abstraction that provides a consistent mental model and relieves programmer burden, then do it. None of that is in dispute. My point is rather one of interface design. This is about communication with other developers. Help them out! Give them affordances to make their lives easier. Leave clues so they know what's going on. A developer coming up to your template that just says {{ stockPrice }} has zero chance of knowing that this is going to secretly issue a network request. If it looks like a field reference, people are going to assume it has roughly the same characteristics as a normal field reference. That's an eminently reasonable assumption -- don't violate it. Everyone would be surprised to see that take several orders of magnitude longer because it needs to touch the network. Everyone would be surprised to find out that they can't include that field in a template that might possibly be rendered when the user has no network connection. When things do something different from what they look like they're doing, it's surprising. Don't surprise people. Make life easy for them.