After a while since I left JS, I decided to learn Typescript, React and to give it a go again… It’s all fun, until you have to hunt down bugs…
I’m working with an headless CMS, so you have like 4 layers of stuff: JS, TS, React, CMS.
My opinion is that debugging works for SIMPLE stuff, like if I have a static website generator, debugging and hunting the errors by hand to find what’s wrong it’s okay. But when you have to do really complex stuff, interact with APIs, working with promises, async requests and all, I do think that hunting bugs like that is the recipe for a disaster.
My project runs into a bug: I get 27 different errors messages from different tools, some of them are easy to misunderstand and not really pointing out the right problem. And I don’t want to imagine what’s like working with a big fullstack app where you have to manage backend as well, not just its APIs…
Once things starts to get complex the language MUST have a good compiler, MUST have a very good package manager, an included linter which is the SAME one for everyone, and API/libraries documentation tool which looks everywhere the same, and most importantly a carefully crafted error handling system. Once a language is very complex it needs to goes straight to the point and tells you where the issue is, what you are doing wrong, and it’s okay to have layers but you cannot use 5 different error detection mechanisms for one project.
Quite frankly, no this isn’t the case, largely because you’ve conflating language and framework.
Javascript is a language, Typescript is a language, React is a library for tracking and updating a component tree, React Web is a library for rendering React components to HTML, external services like a CMS are external services.
None of those are frameworks, and as such are not designed to give you a single easy point of failure as you develop with them. Something like Angular or Next.js is a framework, and does provide the development experience you’re looking for.
Similarly, C# is a language, .NET is framework. Java is a language, Spring is a framework. If you want a simple out of the box development experience, use a framework, if you have complex custom needs then combine the language and the various framework components that you need into your own framework.
.NET is more of a runtime and SDKs than a framework, despite the terrible naming of .NET Framework (which is now an obsolete runtime anyway, new naming is just .NET).
ASP.NET Core (which also is named after the now obsolete .NET Core runtime hilariously) would be closer to the other listed frameworks.