4 ms·
For APIs the lack of typing hurts; only that is now no argument because it is fixed by TypeScript / Babel. Performance? That is a good reason, but again if you
by radicalbyte 10y ago
For APIs the lack of typing hurts; only that is now no argument because it is fixed by TypeScript / Babel.
Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints.
Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).
- Sanddancer 10y agoI would not call TypeScript/Babel making it a non-argument, because those two are separate languages that are compiled to Javascript. The language itself still has those limitations, you're just hiding it under the rug. Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge? With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation. Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
- flor1s 10y agoProgramming languages in general hide the limitations of machine code under the rug. Regarding performance, why don't we write our web applications in C++, Rust or Go? There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS). If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.