3 ms·
Certainly you didn't go through the entire pro con list of Node over other languages and go "it must be developer laziness!" Easy to reason about, great perfor
by vorpalhex 6y ago
Certainly you didn't go through the entire pro con list of Node over other languages and go "it must be developer laziness!"
Easy to reason about, great performance for most cases, simple to debug and write code for, a plethora of libraries, easy to ship, no need to have different teams for backend/frontend, and minimal tooling needed.
- kbenson 6y agoThe only really unique thing JS is bringing to the table is that it also has a privileged position in the front end. Your list of benefits it provides boils down to stuff multiple large languages all have, and the one thing that means you can learn just JS. GP comment was presented somewhat snarkily, but I'm not sure they're all that wrong.
- vorpalhex 6y agoSure other languages have some pieces of the puzzle - python has tons of libraries and is easy to understand, golang has great performance and is easy to write, etc. But I have yet to find a language that has the same set of features except JS. If you want to offer up an alternative, please do so.
- BiteCode_dev 6y agoJS has zero unique set of feature. There is not a single feature in JS you can't find elsewhere, often better implemented. If anything, the vast majority of scripting languages (Python, Ruby, PHP...) have more features than JS. JS is so lacking in features that half of its ecosystem is dedicated to compensate for that (typescript, babel, webpack, undersacore...).
- vorpalhex 6y agoSure and julia has the best matrices, python has the most flexible threading models, erlang has the best distributed runtime.. Yet one feature does not a language make. A language is the whole of it's behavior, and JS is a perfectly fine solution with a wide mix of good features. Is it the fastest? No. The most performant? Not close. Does it have the best ability to write language parsers? No! But it's not supposed to. It's a general purpose language that's well suited for a wide swath of cases. Most languages have transpilers and utility libraries - and those are useful tools but also not meant to be part of a language. Even python has dozens of compilation tools depending on how you intend to distribute your code. It's the mark of a poor intelligence that buys on pros only without considering cons. We must weigh not only our features but how well the average engineer can use it, how quickly we can produce features and how safe our code is, and how easily we can actually hire and train engineers. JS is one of the most popular languages in the world. My 10 year old nephew can write it and do a decent job of it.
- kbenson 6y agoYou're missing the point here, which is not that each of these languages has something JS does, it's that Perl, Python, Ruby etc all support all the same features, have large ecosystems of modules, are easy to use, etc. JS is a fine language. It doesn't really bring anything new/different to the table (other than prototype inheritance, but that doesn't amount to much IMO), so the real differentiating factor is that it has a privileged position because of browsers.
- hombre_fatal 6y agoJS has a great future: first class ubiquitous promise + async-everything. Can't find that in Ruby/Python/PHP, you have to use something like Twisted/asyncio which limits you to a bolted on subset of the ecosystem, unlike in JS. Very dishonest take btw. Here's a forum of people who could tell you why they use JS instead of your $favelang, yet instead of trying to figure it out, you just assume everyone is lazy or a junior dev except for you. You should be a little more suspicious of convenient little truths like that where you're the cool elite engineer protagonist and everyone else is a bumbling idiot. I use JS on the server. Any questions for me?
- NicoJuicy 6y agoNo, I'm experienced with node and other programming languages. I never said NodeJS is a bad language, that is not related to the statement i made. I also didn't say everyone is lazy. I said a lot of developers. Most people here do not belong to that use-case. As they are mostly here by interest and are willing to learn. But most people, after work, don't do anything with their knowledge. And are more willing to learn node as it's the same on the backend + frontend. Or keep using what they already know, with no interest for other languages.
- BiteCode_dev 6y agoGo and Erlang (or Elixir) both have a better async model, and are pretty much better designed on all points. So for the rare cases where async does matter (and they are a niche, given even big names like facebook code behind async proxy and do long polling), there are still little reason to choose JS. I can't think of a single mission where, if I were not being forced to use it, I would chose it over something else. And I say that while coding a LOT of JS all year long. Even training people regularly in the language. I double down on my initial statement, if tomorrow JS is removed from the browser, it would die in a few years. It's a badly designed language that has been accumulated fixes over the years to make it acceptable while never removing what's bad. It was so initially bad that half the ecosystem of JS exists to not code in JS (typescript, coffeescript, babel, jsx, webpack...). And it has received that much of attention because we had no choice. Google spent millions to make a technical marvel of a JIT to run it at decent speed. Any tech that would have had half the resources poured into it would today be the incarnation of skynet. It's a language surviving on artificial life support than can do so because it has the best blackmail game of all time.
- hombre_fatal 6y agoYikes to see people assume so little about others. Why not ask people why they use Node instead of assuming the worst about them? You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem. Btw, what's lazy is making convenient uncharitable assumptions about others than just... asking. This forum is full of people who could tell you why they still use JS after they analyze pros/cons of other languages.
- NicoJuicy 6y agoI believe people here don't belong to the situation I mentioned. You are here because you are interested and want to learn. You probably know more than 1 language. But that is not the general developer. Most developers are lazy and at the end of the day, want to go back to their wife and kids ( for example).
- yawaramin 6y agoYeah, and there's absolutely nothing wrong with that. It's the sign of a healthy work-life balance. The real problem is that businesses don't want to train devs in the right tools for the jobs at hand, and are instead looking for the shortcut that will let them 'ship it'.
- NicoJuicy 6y ago> Yeah, and there's absolutely nothing wrong with that. It's the sign of a healthy work-life balance. I agree, never claimed otherwise.
- kbenson 6y agoI'm not entirely sure what you think I was saying. You refer to me assuming and being uncharitable in those assumptions, but I was responding to a specific list of items pointed out, and my own experience. I think you're actually assuming quite a bit about my comment. > You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem. A fraction like nodejs or whatever subset of NPM you decide to use? Core JS is what you get in a browser. That includes async/await, but it's hardly ubiquitous in usage in the core. The main distinction JS has over Perl, Python, Ruby etc is that it's in the browser, so you can assume almost everyone has it and it's accessible in some manner if they access a web property you are responsible for.
- eitland 6y ago> Easy to reason about, I'd like to know what language you use as a baseline for this? I made my first "real" Javascript code back in 2005 (a vector map system that worked in realtime) and I've been working mostly with frontend for the last 3 years so it is not lack of familiarity. In between that however I have programmed a lot of other languages, worked in a number of different teams, written new code, maintained old code and generally gotten some perspective on life. That perspective has sent Javascript down my list of languages that are easy to reason about.
- vorpalhex 6y agoEvent threading pulls out a huge amount of difficulty with semaphores, locks, thread safety, etc. The lack of OO means no typecasting, inheritance models, interfaces, etc. Arrays are fully dynamic, not type restricted and operate strictly by reference. No memory mapping, manual garbage collection or even GC adjustments. Suddenly the list of things someone has to understand to be a competent JS engineer is way smaller than a language like C or Java. There are other languages that have a similar level of being easy to understand such as Python and Ruby, and they're good languages too but have a different set of tradeoffs.
- eitland 6y agoHave my upvote for the serious answer. Let's just say we have different opinions. Here's my attempt to create something similar from my perspective: - Being able to know to at any point what a variable can contain is very liberating. (Ok, you can define a list of Object that behaves just like a list in JS: "fully dynamic, not type restricted", but thankfully for people like me that is not common in Java anymore.) - Knowing that the compiler has my back allows me to work faster. - My preferred languages (Java, C#, TypeScript) together with version control allows me to refactor fearlessly.
- vorpalhex 6y agoIt's a tradeoff. Dynamic isn't "better" than typesafety, but it's generally easier to comprehend and reason about. Just yesterday, I was working on a C# script and encountered the following problem: + An engineer had written a script with a Dictionary of type <Transform, Material>. If you've touched Unity, you immediately caught the flaw: Transform's aren't unique enough keys and it's really easy to end up trying to add Duplicate keys, even though you really mean different objects. + So, since we don't care about uniqueness, shift from a Dictionary to a List. Except we have a problem, because we need to keep that Key->Value relation so we know what transforms get what materials. Well, we have a solution to that, it's yet-another-type called a KeyValuePair. + Well we're now nesting a generic KeyValuePair that needs type information inside of a list that is holding <KeyValuePair> objects, which also changes how we iterate through that list and add items to it. + In a language like JS, everything I just said doesn't matter at all because instead of using a Dictionary (Map in JS), we would of just said "Use a Set instead". Done.