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.

Comments

Ruby

[Luthair]

Ruby was in the same position not that long ago, I wonder how many now legacy ruby apps people regret writing.

Re:Ruby

[Tablizer]

Ruby was in the same position not that long ago, I wonder how many now legacy ruby apps people regret writing.

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.

Re: Ruby

[s_p_oneil]

Very true. Ruby was (and still is) an awesome language at a conceptual level. Even though Ruby's runtime engine is slower and behind more established/popular scripting language engines like Python, I still strongly prefer using Ruby over any other language for writing utility scripts. It never made much sense for web server logic though (unless it's a small internal web server intended for very light traffic). IMO Rails was the worst thing to come from Ruby, but most developers using it were too wrapped up in the hype to notice.

JavaScript+Node seems like the opposite (e.g. a crappy language with a superior runtime engine). I like the async nature of it, though it drove me nuts when I needed to chain together multiple queries to respond to a single page request. That probably means I was "doing it wrong", but I was just getting my feet wet with it. ;-) It also bugged me how easy it was to make the Node.js engine lock up and crash. Maybe it's just the specific version I tried (which was about a year ago), or maybe it's only when Node.js is compiled for Windows, but a single Ruby script with 20-30 threads performing a speed test on a Node.js "Hello World" page brought it down in 30-60 seconds (though it did run impressively fast until it crashed ;-).

Re: Ruby

[shaitand]

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.

Re: Ruby

[Anonymous Coward]

It's comical to see JavaScript fanatics go on about how great JavaScript is because it supports limited support for asynchronous programming.

They really don't have any idea how limited JavaScript is in this respect compared to pretty much every other modern and quasi-modern programming language out there.

Ask them what "multithreading" is and they'll give you a blank stare!

C, C++, Java, C#, Python, Perl and even Ruby programmers can't believe how naive and ignorant JavaScript programmers are about this matter. It's like these JavaScript fanatics really don't understand how limited their preferred language is.

And then.........

[phantomfive]

When Webassembly gets access to the dom, the Javascript craze will begin its decline.
There are some aspects of Node that are really nice though, mainly the ease of use of the CLI. If that were combined with a better security system and less feature churn, it would be great.

Crystal ball: Defective

[Kjella]

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?"

Prominent Rubyists moved to Rust.

[Anonymous Coward]

This is a good point. Ruby, and especially Ruby on Rails, did fall out of favor quite quickly. I think that many people and organizations regret falling for the hype. Ruby and Ruby on Rails both gained a pretty bad reputation for being slow and bloated, and software written using them was often found to be difficult to maintain. Dynamically typed scripting languages might work well for quickly throwing together a prototype, but they often aren't so good for writing large software systems that must be maintained for many years or even decades.

It is also important to note that some prominent members of the Ruby and/or Ruby on Rails communities jumped ship to Rust when it started to become obvious that the Ruby and Ruby on Rails hype was wearing very thin, and the Rust hype was just starting to build.

For example, look at the Rust Core Team. We see Yehuda Katz listed, who is apparently a former member of the Ruby on Rails Core Team. We also see Steve Klabnik listed. He apparently wrote a book about Ruby on Rails with Katz. Alex Crichton appears to maintain some Ruby gems.

So over 30% of Rust's Core Team was involved with Ruby at some point. It might even be more than that. This has made me very suspicious and weary of Rust. I personally have had bad experiences with Ruby and Ruby on Rails, and I fear that I might be subjected to the same hype-driven nonsense if I get anywhere near Rust, due to the same people being involved with both.

Re:JavaScript should replace C

[matushorvath]

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.

Re:JavaScript should replace C

[shaitand]

It was a troll, surely you must have caught that when he suggested replacing C code with JavaScript... It's bad enough that people have wedged Java code into the domain of C. A scripted language like Perl or Ruby can actually be used to achieve similar performance for some use cases by someone who has a little understanding of how those languages are actually implemented and gain some advantages in terms of development speed and easier integration with the systems side scripting and applications that tend to be developed in house. Java is just a POS that corporations bought into because it was backed by a large commercial effort and JavaScript is just nasty.

Is it just because it's easy?

[ErichTheRed]

Doing systems integration work, my recent experience with web applications has mostly supported this point. javaScript, wrapped in FrameworkOfTheMonth, is slowly replacing client-side applications for better or worse. If we're not allowed to have rich client applications anymore, JavaScript is pretty much the only tool to make a browser act like a rich client -- but it's a good example of shoehorning a technology in just to save complexity. I'm not saying we should go back to Java applets or Flash or ActiveX, but JS is really being extended way beyond what it was ever meant to do.

I think its rise comes from a few factors -- massive amounts of cheap CPU and memory being available on clients, and a billion web frameworks to make using it easy for beginners. This latest dotcom bubble has spawned a bunch of "coder bootcamps" that teach basic front-end web development in a JS framework. It really is easy to throw something together that functions. However, you can definitely tell when either the framework and/or the programmer isn't doing something efficiently...just look at client side UIs that totally freeze up when a database call is taking longer than it should, or websites that slow quad-core systems with 16 GB of RAM to a crawl while they load 11,304,283 snippets of code from different hosted libraries.

Re:JavaScript should replace C

[ShanghaiBill]

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.

So fastly, you can hardly fathomy the bigliness

[Krakadoom]

Fastly? Since when is Trump writing summaries for Slashdot?

I'm a long time C programmer

[OrangeTide]

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

Re:JavaScript should replace C

[HiThere]

Javascript *is* the wrong way to go, but C really needs to be replaced with a language that can check for fence-post errors, and where you can tell when a value is a pointer rather than an integer. (Note I said "can'. This should be a compiler switch so that you can optimze the check away after everything is debugged.)

Somehow every new language seems to try to be an improved C++ rather than an improved C. This is a mistake. And improved C is just as needed as an improved C++...and would be a lot easier to do. You could even have it be almost the same as C, with most programs being identical between the two, and with the same meaning. But you can't call it C, because it would severely break many standard C idioms. And D's been used for a reasonable C++ replacement. Perhaps concentrate on making it easily debuggable and call it "ecstaCy". (That should be searchable for on the web.)

Re:JavaScript should replace C

[ShanghaiBill]

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.