Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
Although I was being sarcastic when I wrote that Javascript is a very nice language, I do actually stand behind this. Yeah you're right, it's getting there but so is everything else. I am very satisfied with the (not so) recent (anymore) developments of the language we have come to love and implement and the people responsible for it have done a great job adjusting to the requirements of modern browsers and even completely other realms Javascript was not expected to ever appear.
Javascript is universal. There are small context specific implementations sure but overall nearly everything can be ported from one realm to the other. Javascript can be typed procedurally and static as well as the most absurd high level abstraction design patterns because it is a script language without a lot of 'rules' on how to approach something. This freedom we have created a lot of 'styles' over time which I like to personally refer to as dialects. Which dialect you prefer and choose to use is up to you.
A good example of this is that a few years ago people started writing their event handler register function as on(). In stead of object.addEventListener('click', function() { }) we started doing object.on('click', ...). To some people this is blashphemy, to me it is beauty. Where else do you find code that is this semantic?
Another thing to love about Javascript is the collaborative effort. It is by far the most 'social' language in the sense that we are all constantly influencing its direction by the code we write and share with the world daily and the proposals we make for future syntax. I have my own preferences and dialect and sometimes I see other people copying my methods in often completely different contexts. There is no other language where you can see the origin, cause and effect so clearly.
We can use Javascript to write low level backends and interactive frontends using the same interpreter. Besides, even though there are multiple interpreters out there (V8, NiL, etc) they all do their best to have identical implementations rather than competing who gets to be right.
Then there is Electron/NW.js/app.js, the various crap like React and Express and don't get me started on super sets like TypeScript.
And yes, like you said even without acknowledging all this, the NPM ecosystem is still the largest one in the world and that has a reason.
OK. I will stop here I can go on for hours I think I might have a problem. Thanks for commenting on my post, it is really motivating to communicate with somebody about stuff like this.
Besides familiarity with the language if you've been on web dev before, I think the main "selling point" of NodeJS for devs is that it was able to greatly simplify the problem of concurrency. You have only one thread available so you forget to deal with threads and all that stuff.
Of course you now have to deal with other problems, i.e.: callback hell and async thinking.
Resource efficiency (hence lower costs) and scalability is the other one.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
I would like you to elaborate on the problem of concurrency. What practical problem did this solve for you? What were you struggling with every day that Node solved by being single threaded? Do you even know why it is single threaded? I am very curious because the majority of web developers that are considered competent have zero understanding of this.
I mean, you don't have to deal with multiple threads like you do if you're working with other server-side languages.
Multi-threading is hard, like sharing data between threads. If you are working with server-side web programming in PHP, Java, Python, etc you will have to deal with it unless you have very low traffic APIs or services.
I think Go's approach to concurrency with "light threads" and goroutines is better than the async model though, but Node's was quite clever.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
I think I have never reached any point where I needed to deal with multi-threading when I was writing something in for instance PHP. I suspect that I do this all the time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Although I was being sarcastic when I wrote that Javascript is a very nice language, I do actually stand behind this. Yeah you're right, it's getting there but so is everything else. I am very satisfied with the (not so) recent (anymore) developments of the language we have come to love and implement and the people responsible for it have done a great job adjusting to the requirements of modern browsers and even completely other realms Javascript was not expected to ever appear.
Javascript is universal. There are small context specific implementations sure but overall nearly everything can be ported from one realm to the other. Javascript can be typed procedurally and static as well as the most absurd high level abstraction design patterns because it is a script language without a lot of 'rules' on how to approach something. This freedom we have created a lot of 'styles' over time which I like to personally refer to as dialects. Which dialect you prefer and choose to use is up to you.
A good example of this is that a few years ago people started writing their event handler register function as on(). In stead of object.addEventListener('click', function() { }) we started doing object.on('click', ...). To some people this is blashphemy, to me it is beauty. Where else do you find code that is this semantic?
Another thing to love about Javascript is the collaborative effort. It is by far the most 'social' language in the sense that we are all constantly influencing its direction by the code we write and share with the world daily and the proposals we make for future syntax. I have my own preferences and dialect and sometimes I see other people copying my methods in often completely different contexts. There is no other language where you can see the origin, cause and effect so clearly.
We can use Javascript to write low level backends and interactive frontends using the same interpreter. Besides, even though there are multiple interpreters out there (V8, NiL, etc) they all do their best to have identical implementations rather than competing who gets to be right.
Then there is Electron/NW.js/app.js, the various crap like React and Express and don't get me started on super sets like TypeScript.
And yes, like you said even without acknowledging all this, the NPM ecosystem is still the largest one in the world and that has a reason.
OK. I will stop here I can go on for hours I think I might have a problem. Thanks for commenting on my post, it is really motivating to communicate with somebody about stuff like this.
Besides familiarity with the language if you've been on web dev before, I think the main "selling point" of NodeJS for devs is that it was able to greatly simplify the problem of concurrency. You have only one thread available so you forget to deal with threads and all that stuff.
Of course you now have to deal with other problems, i.e.: callback hell and async thinking.
Resource efficiency (hence lower costs) and scalability is the other one.
I would like you to elaborate on the problem of concurrency. What practical problem did this solve for you? What were you struggling with every day that Node solved by being single threaded? Do you even know why it is single threaded? I am very curious because the majority of web developers that are considered competent have zero understanding of this.
I mean, you don't have to deal with multiple threads like you do if you're working with other server-side languages.
Multi-threading is hard, like sharing data between threads. If you are working with server-side web programming in PHP, Java, Python, etc you will have to deal with it unless you have very low traffic APIs or services.
I think Go's approach to concurrency with "light threads" and goroutines is better than the async model though, but Node's was quite clever.
I think I have never reached any point where I needed to deal with multi-threading when I was writing something in for instance PHP. I suspect that I do this all the time.