Slashdot Mirror
JavaScript Is Eating The World (dev.to)
An anonymous reader shares a report: In case you haven't heard the news, JavaScript and NodeJS are single handedly eating the world of software. NodeJS is an Open Source server-side JavaScript environment based on the V8 JS rendering engine found in Google Chrome. Once only thought of as a "hipster" framework, NodeJS is fastly becoming one of the most commonly used languages in building web applications and is beginning to find its way into the Enterprise. Netflix, Microsoft, PayPal, Uber, and IBM have adopted the popular "hipster" server-side JavaScript engine for use inside high traffic, high profile production projects. Java still powers the backend of Netflix, but all the stuff that the user sees comes from Node. In addition to Node, Netflix is also using ReactJS in their stack. PayPal too is moving away from Java and onto JavaScript and NodeJS for use in their web application platform. Uber has built its massive driver / rider matching system on Node.js Distributed Web Architecture. IBM has also embraced NodeJS as well. Even Microsoft has embraced NodeJS, offering direct integrations into their Azure Platform, releasing a wealth of tutorials targeted at Node and they have even announced plans to fork the project and build their own version of Node powered by their Edge Javascript engine instead of Chrome's V8.
Fad sniffers, that's why. I'm going into my get-off-my-lawn mode here, if you don't mind.
Tech companies and consultants profit off of change, and so encourage it, whether it's the right decision or not for a particular project. When technology stagnates (becomes stable), people figure everything out, and fixing and changing becomes routine and commoditized such that orgs no longer buy expensive new stuff and don't rent consultants for $100 an hour.
The vast majority of companies don't need "web scale", but many end up copying big-co stacks anyhow in fear of being left behind. They end up acquiring NFL-level equipment for little-league.
Sometimes these fads do actually either pay off or trigger similar good ideas elsewhere such that they do have a use in aggregate, but it's usually not good for a typical company to be the guinea-pig. Let some somebody else be the guinea-pig and benefit from THEIR lessons. You won't be hip, but you also won't be burned.
Table-ized A.I.
I worked with Javascript in the 90s... if you had come in a time machine and showed me this article from 2017, I'd say if you were bat shit crazy. If you gave me next week's lottery numbers and I won the jackpot I'd say "Well I believe you're from the future... but you're still pulling my leg about this Javascript thing, right?"
Live today, because you never know what tomorrow brings
The only reason everyone uses JavaScript in the browser is that it is the only language supported by major browsers. If browsers supported Visual Basic instead, everyone would be using Visual Basic. There is no choice. The popularity of JavaScript under these circumstances is no measure of the quality of the language. There was no "test of time", since there was no competition.
It's too bad Perl 5 has fallen on the popularity scale. Node was better for async code about five years ago but now Perl has some amazing modern async systems and if written properly is lightning fast. Every time one of these new upstart languages has a feature or advantage Perl just absorbs it. Sadly, most of the Perl code you actually see is written because it is the lowest common denominator which means not using any new functionality and sometimes not even having access to CPAN. Non-blocking async code with websockets scaling to tens or even hundreds of thousands of connections, no problem for actual modern perl. Perl has been around for so long though that someone trying to pick up Perl is going to find a lot of old cruft out there showing old ways. Hell there is even a book called "Modern Perl" that is hopelessly ridiculously outdated.
JavaScript isn't even a real language. Sounds like you've written in other languages... be honest, if written without a style convention Perl can look ugly but JavaScript actually IS ugly. You might get the job done in JS but you feel a little dirty afterwards.
WTF does Rust have to do with Javascript?
Everything, because people are using JavaScript in place of Rust and C++. When my wife writes an app, she does 1% in C, just enough to pop up a WebView, and then does the other 99% in embedded JavaScript. This makes it 10 times slower, and 100 times harder to debug. Now she wants me to switch the backend to Node.js. She has even started teaching our kids to write non-web code in JavaScript, since "That is what Khan Academy uses!" (which is true).
The only good thing about the JavaScript takeover is that we no longer have to worry about Judgement Day. If the T-1000 is running JavaScript it will be too slow and buggy to harm anyone.
Fastly? Since when is Trump writing summaries for Slashdot?
I'm primarily an embedded/kernel developer, and I've been using C for decades. Normally I'm pretty strongly in favor of using C. But I readily admit that you can throw together a project in NodeJS very quickly. There isn't much revolutionary about NodeJS, other than it is packaged nicely and is easy to use. When the primary purpose of writing software is to solve problems, getting something going in short order has value.
I grew up on BASIC, but JavaScript is so ubiquitous and is not terribly hard to learn that I would recommend it as a first language over anything else. (Ideally you should learn multiple languages as you advance, as they each have their own advantages and quirks)
PS - I have a fondness for FORTH that may never go away, even if I will likely never again get to use it in a professional project. R.I.P. OpenFirmware
“Common sense is not so common.” — Voltaire
I've been programming in javascript for 18 years and it's not nearly as slow or buggy as you think it is.
There are plenty of problems with JavaScript. Jshint can catch a lot of them, and Closure can catch even more, but those tools require a lot of self-discipline, and they still don't fix all the problems. Of course my wife refuses to use either.
But I wasn't talking about debugging JavaScript in a browser, which is bad enough, but debugging embedded JavaScript inside a WebView where there is no console and no debugger. Many of the problems are "Heisenbugs" that only occur in the WebView, but disappear when the same code is run in a browser (which has a console and debugger).
Then it gets even worse when she starts using one bloated framework on top of another. Many of them rely on tags in the HTML so I can't even see the problem by looking at just the JavaScript. So then she tells me if that I am sleeping on the couch until the bug is fixed ... ARRRRGGGGGHHH!!!
Lesson learned: Do a thorough code review before you marry someone. A pair programming session to test development style compatibility is also advisable.