You literally restrict yourself to one of the worst languages ever designed. What could be solved with elegance and without demoralizing your staff in 5 minutes in some other language, in JavaScript it might require "sailing to Africa and back" to achieve the same (though I must say it has improved a bit recently from the insanity it used to be). On paper it might look good to you, but the reality is very different and you are making yourself seriously restricted in competing with other companies using more sane languages.
Not to mention the web stack changes every single year completely, node has scalability and versioning issues, and you end up relying on quickly changing pieces of code you have zero control about.
1. Can you give me an exam of something that is trivial in another lang, but requires "sailing to Africa and back" in JS?
2. What sort of scalability issues related to Node.js are you talking about? Isn't node.js (thanks to V8, and async IO) much more performance friendly than other scripting langs?
3. Regarding web-stack changing quickly, this hasn't effected me on server side yet. It has effected me on the mobile apps and web app side of things where I am using react 15.x, but it'll make sense to tackle that after raising meeting the next few business milestones.
"Can you give me an exam of something that is trivial in another lang, but requires "sailing to Africa and back" in JS?"
Packages and imports. First-class entities, built in to every other modern language. A mishmash of different "standards" and proprietary implementations in Javascript. Even K&R-era C had a better solution than Javascript (until ES6, anyway).
And do not tell me that ECMAScript 6 fixes this -- as long as there are multiple implementations in use in legacy code (there are) JS will have to live with a rat's nest of horrors at this incredibly fundamental level (not to mention the fact that ES6 imports aren't yet universally supported!)
2. Compare some well-designed async framework on JVM like Netty (used by most game studios for their high-throughput servers) with node.js. See the benchmarks. Still wanna use node.js? Do you think you can cost-compete with any company that needs 4x less servers than you do for the same functionality? Show me something close to zeromq capable of reaching over 1M messages/s on a single computer?
3. No comment. Plenty of posts about it over here every year
On 2. If you have that requirement, I don't think you can use any scripting language. If you have to use one, JS is probably the best option out there.
english is similarly a terrible language in many ways. Its only benefit is it is fairly easy to learn and start speaking with in a “broken” way but still gets its point across.
Which has led to a meta advantage which is it being used everywhere.
So while Esperanto speakers bemoan this, the rest of the world doesnt care too much.
The rest is disagremeent or agreement on the quote “If it’s stupid and works, it’s not stupid”
Emulating classes hierarchy using prototypes while always keeping on mind what "this" means right here right now at this very call stack/context, without async/await basically any resource loading (unless you use some lib that is hiding nasty pieces from you), no enforced object structure/properties and passing them arbitrarily and then in the next version needing to add/remove some property everywhere, and many more.
Dunno, wrote games in JavaScript that left people gasping for air it was possible in a browser, wrote most algorithms in some image/vector processing tool you might be using in your business right now where I had to interleave JVM, JavaScript, WebGL and GLSL in areas nobody tried before; wrote facial/emotion tracking system with advanced computer vision in a browser etc. Maybe I am not a noob you think you are talking to?
I wrote code in way better and more productive languages than JavaScript. I can somehow tolerate JavaScript when I write code alone, but once I have to deal with the fart-mess that most JavaScript developers write, I have to eject. There are very few JavaScript projects that are well designed and I always need to debug and fix them as I put most of them into their knees when they aren't working anymore. You have no idea how far "the best JavaScript" libraries are quality-wise from what you'd expect from a well-designed C++, Java or Scala library.
My bad. By the way, I didn't think of you as a noob, I just wanted to see if you have explored JS to the point of being able to use it predictable while managing a few developers.
In my defence:
I haven't worked on webGL or facial/emotion tracking system with CV in a browser yet. My experience has been more towards apps that tend to be very heavy in functionality, and are written with a specific personas of users in mind.
I have been using JS in a functional manner for quite a few years. And I have found that JS works best when you don't have to deal in classes when writing domain-specific code. Using "functions-as-first-class-citizens" is what I have found works in scalable way. And I generally get any new junior dev up to speed on basics of functional programming before working with them.
EDIT: By the way, I mentioned tensofrlow.js because with it, if you have a dataset, you can prototype the emotional recognition thing in a week or two. Just don't have the need/time to spend that effort at the moment. Needed to share that information in order to see if i'm correctly gauging the complexity of the type of work you mentioned.
No problem. I usually learn a new language by picking a very challenging idea and then implementing it; that way I can see how the language performs "under stress", though I might have skewed view for normal use cases. Still, companies seem to be more interested in the weird cases I am forced to explore (much to detriment of my happiness), and JavaScript was making me quite grumpy at times.
Right, with TensorFlow.js (or even better Keras.js) you can write a simple CNN in a few hours that given a good dataset of facial keypoints can allow you to build a fairly accurate (80-90%) emotion detection framework, and it's pretty fast. I am past this stage though; right now I have e.g. a working state-of-art model for detecting offensive visual content on the web based on very deep DenseNet, which might be difficult to fit into a browser implementation and the more Titan Vs you throw at it, the better; Python only then.
I agree, with functional approach, especially with the recent additions to ES, it seems like JS is becoming a quite OK language, though the issue of having somebody using ugly old hacks is not going away, unfortunately.
Usually in teams I worked before for anything more complex we used transpilers from one language to JavaScript and relied heavily on our IDEs to allow us debugging. Kotlin seems to be pretty popular in that space right now; if I haven't had some personal gripe with its authors I'd have probably used it as well ;-)
Good luck with your company, keep your eyes open for things to come! :)
And by the way, using python for training is a must right now(though JS is going to become an alternate for this in a few months, as tensorflow.js is being ported to node with bindings to actual tensorflow's C++ layer). Using tensorflow.js, I'd have been able to use saved models in the browser.
Not to mention the web stack changes every single year completely, node has scalability and versioning issues, and you end up relying on quickly changing pieces of code you have zero control about.