5 ms·
It’s interesting to think about and tinker with maybe, but I don’t see the merit to using this for real life projects. In fact I’d recommend against it, consid
by WhitneyLand 6y ago
It’s interesting to think about and tinker with maybe, but I don’t see the merit to using this for real life projects.
In fact I’d recommend against it, considering the better alternatives and the fact that this is yet another thing that can break and has to be maintained.
I often hear people argue that XYZ is simple so it’s no big deal to use it. But the reality is that code changes hands often and every person who touches code incurs the extra bit of cognitive load.
Just use Typescript.
- depmann 6y agoI would make the exact same argument but with completely the opposite conclusion. Just use type casting which is self documenting and easily maintained. How can using Typescript be considered somehow less complex?
- WhitneyLand 6y agoI think there’s more to it than this but let’s pursue your point for a moment. What you’re not taking into consideration is that de facto standards matter. What if you invented a language tomorrow called XYZ and it was 20% better than a popular language today? Would you language eventually take over and become popular? Maybe. After how many years? Who knows. But until that happens far more JS developers are de facto making an investment in learning at least the basics of typescript vs your mechanism. The practical reality of that is if I start putting together a team to build something it’s much less likely that people will have to take time to learn typescript basics then they will to learn your tool. Are there times to throw out the old and go with what’s better or simpler? Sure. But that equation is not as simple as X > Y even if that were the case which I’m not convinced it is.