This is a great question.
Every framework is a product. It can be free to use, it can be open source, but it is still a product and authors want their products to be popular, so most design-wise decisions are made based on the “ease of use” basis. Just like you suggested - framework should be easy to use. So I would argue that they decided to keep it simple and using the same name would cause a lot of problems for developers, let me explain why.
When it comes to frameworks that operate simultaneously in more than one language - like Angular (JS & HTML), we have to pay attention to the specification of both languages. We often come to some sort of cardinality problem. JS is case sensitive, HTML is case insensitive.
So JavaScript and the additional tools (for example linters) allow you to create two variables named appinfo
and appInfo
. It might be a bad practice (as it makes the code less readable) but you are allowed to do that. And now, what happens on the HTML side of things?
In Angular names of those two variables will be transformed respectively to app-info
and appinfo
, two different names, great. So every valid name in JS results in the unique name on the HTML side, awesome.
Let’s take a look at your proposition, in that case, those names would not be transformed and developers would use appInfo
and appinfo
in HTML, but as we stated earlier - HTML is case insensitive so those names are actually equal. And that’s the problem. To make it all work you would need to create a rule that variables defined in JavaScript must be unique in a case insensitive system. But the language itself and tools created for JS (not Angular) would still allow this. You would have to create your language that would be compiled to JS, not an easy task.
Ok, but let’s assume that you don’t create your own language, you just state the rule that developers have to use unique names in a case insensitive sense. As programmes we make errors and then we fix them, that’s our job. I am sure that someone would forget about this rule (as it’s not enforced by the language and tooling) - what happens now? Someone notices that there is a bug in the system and you are assigned to fix it. Trust me, bugs that occur without any error logs or problems reported by the linter are the worst.
That’s why I believe that they went for the easier path, for them as authors of the product and for the developers as the users of the framework.