My thoughts on the JavaScript ecosystem
(AKA why I think all web developers should learn JavaScript)
I have been learning JavaScript for a year now, and recently got into Node.js. By no means am I professional JavaScript developer but there are some things that I have noticed about the language, or more specifically, the community around it. This article may be stating the obvious for many people, but perhaps this may be quite helpful for JavaScript beginners. Nevertheless, here are my thoughts on the JavaScript ecosystem.
You do not have to reinvent the wheel.
This is true for most other languages that have their own package managers but what I have noticed is that for JavaScript is that there is a library, framework, or package for (pretty much) everything. The tool that really makes this true is NPM. As can be seen, by this graph, NPM has surpassed all package managers for other languages by hundreds of thousands of modules created. What this all means is that instead of writing some code that is just boilerplate or spending valuable time figuring out how to do something chances are you can find it on NPM. As well, it provides an easy way to find what you are looking for, look at the documentation, and install the library.
NOTE: I do understand that NPM does have modules written in many other languages than JavaScript, however, due to the sheer amount of game changing JavaScript libraries and frameworks that are hosted there (ie. express.js), I believe all of my previous statements are true.
Used in a wide variety of circumstances
JavaScript has become a very powerful language to know. Not only can it be used for client side animations and effects but also it has become very popular as a server-side language with Node.js. Thus, whether you want to become a front end designer/developer or server-side, JavaScript can do both. This also proves useful in the case that someone wants to be a full stack developer: The same language can be used client and server-side with a few added dependencies.
One language, multiple platforms
One of the major distinguishing features of JavaScript is the one language, many platforms ideology, meaning HTML, and CSS in addition to JavaScript. This has resulted in the creation of some very remarkable platforms such as Electron or the Ionic framework. This makes this language even more powerful being able to create apps that not only exist on the web, but also on app stores or even as a desktop app! All with just JavaScript, HTML and CSS.
Used on pretty much all browsers
I will keep this section short. JavaScript runs natively on most modern browsers. Internet Explorer is not a modern browser.
Despite all that...
Despite the fact that JavaScript is an awesome language, it is important to remember to have a diverse skill set, just like a person should have a diverse investment portfolio. This is important because even though JavaScript has become powerful, that doesn't mean it can do everything. JavaScript serves many purposes on the web, however, depending on the circumstance, a different language may be better. On top of that, a company might not even be using JavaScript for everything (or anything at all). A company's desktop app may be written in Java, and something like GoLang could be used server side. The point of this article is NOT to tell beginners to learn only JavaScript, and use it for everything but rather to highlight some of my observations about JavaScript as I begin to reach the intermediate level. I maintain the view that a person can specialize in one language but also should diversify their skill set.
I hope you learned something from this article. Many people may already know a lot of this, so I hope that this helps some beginners understand the JavaScript ecosystem a bit more and as well learn why it is a great language with many uses.
Please leave any feedback about this article that you have for me in the comments, I will try to respond to everyone! This is my opinion, and if you think I am wrong, tell me about it in the comments!
-Matt Silverman | Silverman.io
Top comments (6)
I would never use Javascript. It's not a good language. Let's take a look at your arguments:
You do not have to reinvent the wheel
Every language has libraries, and while a package manager makes it easier to use, it's not neccesary at all. But as said, more languages have package managers (which are better integrated with the language, i.e. Haskell or Rust)
Used in a variety of use cases
Just because something can be used for something does not mean it should be used. You can also write software in Assembly, but you dont do it. Nodejs is not a good platform for servers. Is only singlethreaded, so it can't use the full potential of modern PCs. Javascript is not designed for system use, thats why you have problems like nodejs giving same inodes to folders, because 64 bit floats cannot hold as many values as 64 bit integers that inodes are.
One language, multiple platforms
Also not true. You still need a javascript interpreter for the target platform. If there is one, you can also compile your own code to that platform. No javascript needed. Also bundling a browser with your website does not make it a native application.
Used by all browsers
Well yes, because the HTML standard says so. Hopefully WebAssembly enables us to finally get rid Javascript forever
First, thank you very much for your comment, you have highlighted several interesting points. In response to your first argument, I do understand that, of course, other languages have package managers, libraries, and frameworks. My response to this is that while it is that even if package managers are better-integrated none of them can really compare to the number of modules/packages NPM has to offer. If the issue with NPM is speed, Yarn can fix that. With your next group of points I do admit that you are correct that NodeJS that it is single-threaded, however, I will counter with the fact that it is non-io blocking (meaning multiple actions can be going at once on a single thread). It is true that many other languages have dependencies available for this functionality, however, that in most cases make other dependencies not work. As well, I would like to mention that I do agree that JavaScript shouldn't be used for everything which is why I included my last paragraph (ex. JavaScript would be a real cruddy choice for machine learning). As far as interpreter go, #1, if you want to make one for a language that doesn't have one the learning curve is very steep. #2, even if a compiler for that language did exist, at the current time, javascript does appear to be the only language that can deploy to Android, iOS, Windows, Mac, and the web without modifying too much code, and I never mentioned anything about native running apps. Often times this option would be better as it allows small teams to easily be able to get fully functional, albeit, not native apps, based off technologies that many web developers already know. Many companies including Discord, Slack, Atom, and even Microsoft with Visual Studio Code. agree with this view as they do use non-native Electron to power their desktop apps (source). While you can do this with interpreters, it is much easier and more efficient for small teams to use Electron in many use cases. As far as your view of WebAssembly, I do agree it would be awesome to use languages other than JS for client side scripting, however, JavaScript is here to stay. With the sheer community behind it, not to mention libraries and frameworks like React.js, Vue.js, and jQuery (an old library, but very useful). These all help to make it easier and easier to make epic web apps with JavaScript. With all this in mind, I believe it is unlikely that will change.
I do apologize for the long response, however, I wanted to make sure I addressed everything that you had mentioned. Thank you again for the comment.
-Matt
I'm always open for critique, as long I can give it back :)
Yes, npm has a lot of modules, but the count is not really the metric that is valuable. There are several reasons why javascript has so many packages. First of all, JS does not have a standard library. This means, features that come bundled with Haskell/C/C++/and almost every other language have to come from an external (untrusted) source. The second reason is that many modules are basicly oneliners that you would normally not put in an external dependency (left-pad?). Speed is not so much an issue, especially with npm v5.
Even with blocking IO, a server written in C++ is still faster than an async node server (This is about websockets, but a similar comparison is also available for general HTTP connections with similar result, TL;DR only Ruby on Rails is slower than Node). Also that async dependencies don't work with others is not true, I worked with Asio (async IO for C++) and it is just another library that you use, it's not something that changes the language.
The single threaded callback model of nodejs makes programming harder actually, because you can make the same synchronization related programming errors normally happening only in a multithreaded environment also in a single threaded one. Additionally, closures in Javascript are very inefficient, so having a bunch of nested callbacks using the outer scopes can cripple performance. There are two ways how you can make your life easier. First, you could use blocking IO with something like C++. You also dont have concurrency, but you also dont have callbacks everywhere. Performance should be even if not better than node. The second way is using one thread per connection, this is what you would with languages like Haskell or Erlang implementing green threads. You simply write your code per client, and the runtime system scales it across as many cores as you want without using costly system threads.
With the interpreter, I meant that you first need a C++ compiler for your target platform, so you can compile V8 on it. Then you can use Javascript. But if you already have a C++ compiler, you can also use C++ directly. In fact, you can write Cross-platform apps (natively) with C++ and libraries like Qt.
The main reason for Javascript is the community not wanting to learn one or two new languages and try to put everything in their own. Everyone hypes about functional programming in Javascript, but just using lamda expressions or array map/reduce does not make your code "functional". In fact it is impossible to do real functional programming in Javascript, because the APIs are imperative. Also not having a strong type system lessens the benefit of functional programming. This and more are all symptoms of Javscripts own core weaknesses that you just can't fix, no matter how many new ESX versions you develop or how many libraries you publish on npm.
Node js, in my option has only one valid use case: server side rendering for the browser. If I had to recommend a stack, I would use Haskell with servant for the server, as writing a server with Haskell is really easy. A lot easier than you might think. The type system and the compiler/REPL guides you very well and you end up having a lot less code than with any other language. For the browser, I would use Purescript (with purescript-bridge to share the types with the backend). For native (desktop/mobile) applications you can intially use your purescript website with electron and later on develop real native applications with C++ or Haskell.
Great points. I think Javascript will be the de facto programming language in the next few years.
Reminds me of what Jeff Atwood, founder of Stack Overflow, half jokingly said:
I totally agree. JavaScript is beggining to be used for almost everything on the web, for better or worse. As a result, people are making new libraries, and new frameworks to pave the way for new uses of the language. Jeff Atwood's statement may very well turn true quite soon, if it isn't already.
I've always felt rather happy with the state of the Javascript ecosystem. I can understand the 'Javascript fatigue' feeling but I see it as the consequence of a very very healthy ecosystem. A lot of people are trying to figure things out, and those tools are available to all of us. Seems like a small price to pay to me.