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

JavaScript should replace C

[Anonymous Coward]

JavaScript has greatly improved the internet. Unlike true hipster languages like Rust, it has stood the test of time and is widely supported. Security has greatly improved over the years. We should consider replacing much of the C code in existence with JavaScript to improve security and reliability.

Re:JavaScript should replace C

[Anonymous Coward]

i have a windows 10 inch cock

Re:JavaScript should replace C

[MightyMartian]

WTF does Rust have to do with Javascript? Rust is supposed to be a memory-safe compiled language meant for system development. It's like comparing Algol to Logo.

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]

Rust is actually a decent language that can be used for serious coding for one. Also, wake up grandpa, efforts are being made to bring http closer and closer to the system, even so far as pushing the websocket model so that the current realm of java and now javascript programming is more and more the system level.

It's a sad world, granted, but more and more it is the real world.

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.

Re:JavaScript should replace C

[Richard Dick Head]

We should consider replacing much of the C code in existence with JavaScript

Spoken like a true Javascript "programmer" :D People who can't program and those talentless late 90s scabs that seem to hang onto the market like a venereal disease are jumping into this craze like a methed up wannabe chef into a box of Velveeta Shells and Cheese

Re:JavaScript should replace C

[Anonymous Coward]

Java made cross platform networking, GUIs, and multi-threading trivial. I'll call C and C++ pieces of shit due to how poorly IDEs can automatically manipulate those languages.

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.

Re:JavaScript should replace C

[Anonymous Coward]

Corporations bought into JavaScript because it was the best choice available at the time when there really was no good choice. Early browser JavaScript support was the usually the deciding factor.

Re:JavaScript should replace C

[Zeromous]

LOLOL, I dunno for now it pays my bills, Im less principled on the matter.

Re:JavaScript should replace C

[Anonymous Coward]

Well, to be fair, vbscript was indeed a competitor in the early days of IE.

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

[Billly Gates]

Have her watch this video? Yes, it is from the same guy who did the hilarious nosql == webscale video that was popularly posted here.

Re:JavaScript should replace C

[Anonymous Coward]

I've been programming in javascript for 18 years and it's not nearly as slow or buggy as you think it is. It's one of the most dynamic and powerful languages ever made.

Re:JavaScript should replace C

[HornWumpus]

I don't think you understand the purpose of C.

It's only one step up from assembler. It doesn't do the things you list because it isn't _supposed_ to.

Languages can't be 'lean' without being a little 'mean', there are plenty that will hold your hand, C isn't one of them.

Re: JavaScript should replace C

[Anonymous Coward]

I could have sworn you said Lisp.

Re:JavaScript should replace C

[TheDarkMaster]

This. Javascript as a programming language is a piece of shit, but is installed by default on all browsers so everyone will use javascript for client-side code. Nobody uses javascript for being the best option, everyone uses javascript because they have no other choice for the job (code running in the browser)

Re:JavaScript should replace C

[tuffy]

That's pretty much what Rust is: a low-level language that can be slotted into the same places C is used now, but without all the undefined behavior and memory leaks. And since it's a new language, it can have features people expect in a new language these days (like type inference, an intelligent build system, etc.).

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.

Re:JavaScript should replace C

[vtcodger]

"JavaScript has greatly improved the internet. .... We should consider replacing much of the C code in existence with JavaScript to improve security and reliability."

Then our entire digital infrastructure will run like the Internet. And the end days will be upon us. And the deserving shall enter the kingdom of heaven While the sinners shall be condemned to an eternity of trying to get a constantly updating Windows to load an improperly signed printer driver that has to be downloaded over a Comcast internet connection.

Re:JavaScript should replace C

[HuguesT]

Why replace C/C++? Compilers do optional bounds checking it already, at least since 2012.

Come on, man, keep up with the times! check out Adress Sanitizer and all the other Sanitizer goodies. Enabled by default in recent versions of GCC/G++ (since 4.8) *and* Clang (with LLVM 3.1). Contributed by your friendly Google developers.

Re:JavaScript should replace C

[gweihir]

Rust may have some merit, but the community is utterly toxic. Sane people stay away from it.

Re:JavaScript should replace C

[gweihir]

Very much this.

Lets hope web-assembly makes it and languages for actual coders will become available in web-coding.

Re:JavaScript should replace C

[gweihir]

You know, -Wall already gives you much of this with GCC. You need to use it though.

Re:JavaScript should replace C

[gweihir]

And as soon as you do any heavy lifting, these advantages go away because you need to embed C. The promises of Rust are mostly lies because its proponents do not understand the problem they are trying to solve. There is a reason C is still around and going strong after all this time. The reason is that all attempts at replacing it for the roles where it shines have failed, because they made things worse.

Another nice thing is that C makes dumb coders write obviously broken code. That alone makes it worth using it.

Re:JavaScript should replace C

[mikael]

C is meant to be a cross-platform low-level language that can be translated to any type of processor (CPU, GPU, DSP). That's the one and only reason for it to be created by Bell Labs. A language that would allow the source for an OS and device drivers to be ported across different hardware, particularly telephone exchanges.

The main problem with C was that you end up rewriting boilerplate code for every new data structure you create as an ADT (Abstract Data Type). That was solved with C++ using templates and STL.

Python is more close to what you want, which allows functions and objects to be implemented as templates. As long as there is a function that matches the name in the python script it will get called. If there isn't a class member by the name requested, the script exits.

Re: JavaScript should replace C

[that this is not und]

I have a backyard full of hens, if your cock would care to visit.

Re:JavaScript should replace C

[K. S. Kyosuke]

Oberon is "extra lean". Is it "extra mean", too?

Re:JavaScript should replace C

[h33t l4x0r]

I don't think you've looked at ES2017. You're complaining about the javascript you remember from back in the day.

Re:JavaScript should replace C

[Anonymous Coward]

You don't know enough Javascript developers if you've never had someone tell you straight-faced that you should replace a native app with Javascript without being able to form a valid and coherent argument as to why.

Re:JavaScript should replace C

[HiThere]

Python is not a C replacement. Perhaps you meant Pascal? Pre-Delphi Pascal had many of the features that I think the C replacement should have, though it was missing lots of them that are present in C. C's scope rules, e.g., are superior to those of Pascal.

FWIW, no language with objects built in, and no language that requires an interpreter or a virtual machine is a viable C replacement.

Re:JavaScript should replace C

[Mr. Shotgun]

We should consider replacing much of the C code in existence with JavaScript to improve security and reliability.

I was wondering what it would be like to have an aneurysm, now I know. Thanks buddy!>/p>

Re:JavaScript should replace C

[tepples]

-Wall already gives you much of this with GCC

I agree; my standard practice is to use g++ -Wall -Wextra. What else can I turn on to enable runtime bounds checking, especially in the parts that can't use std::vector because they use or implement extern "C" header interfaces?

Re: JavaScript should replace C

[Anonymous Coward]

I took a dynamic and powerful shit today. Shall we compare notes?

Re: JavaScript should replace C

[tigersha]

Send your test to basenotes.com

Re: JavaScript should replace C

[tigersha]

No but it is not actually used for anything either

Re: JavaScript should replace C

[Anonymous Coward]

C is supposed to create all the backdoors NSA needs to fsck with your Computer.

Algol, Pascal, Ada - all much Note robust.

Re: JavaScript should replace C

[Anonymous Coward]

C is a Race to engineering bottom. Made by an NSA contractor for NSA.

Re: JavaScript should replace C

[K. S. Kyosuke]

Which is of course rather sad. :/

Re: JavaScript should replace C

[reanjr]

No language whose primary implementation is written in C is a a replacement language for C. Self-host or GTFO.

Re: JavaScript should replace C

[tonywestonuk]

Its windows.....probably full of viruses. Probably better to look elsewhere for your chickens sake.

Re: JavaScript should replace C

[HiThere]

If the original compiler is written in C, or, better, a C subset, then it MUST be possible to write a compiler for the language in itself. Demanding that the original compiler for the language be written in the language is just being silly. You'd need to have a compiler for the language to use the source code...and assembler is less portable than C.

N.B.: This is one of the standard ways that self-hosting compilers work. It is quite rare (almost unheard of) for the reference implementation to be in the language itself. Algol, IIRC, was implemented originally via an Algol subset that was written in assembler, and Forth. Probably LISP and Fortran. Possibly COBOL. But note that these languages all date back to the 1950's or quite early 1960's. (I've never heard how the original BASIC was written, but i believe it was an interpreter.) However, after C really took hold, nobody wanted to bother with that non-portable approach.

Re: JavaScript should replace C

[Anonymous Coward]

This is one of the standard ways that self-hoisting compilers work.

FTFY

Re:JavaScript should replace C

[Anonymous Coward]

Shame it's so ludicrously slow to compile and frictionful.

Re: JavaScript should replace C

[CRConrad]

That replacement language has been invented already. It was created by Nicholaus Wirth, and its name is Pascal.

Re: JavaScript should replace C

[Anonymous Coward]

Lol! Thanks for the laugh, I needed it today. ;)

Re:JavaScript should replace C

[Anonymous Coward]

Golang

Re: JavaScript should replace C

[gweihir]

You are obviously utterly clueless, but could not control your desire to say something negative. Fail on many levels.

Re:JavaScript should replace C

[modmans2ndcoming]

https://en.wikipedia.org/wiki/...

Re:JavaScript should replace C

[Anonymous Coward]

Nonsense.

C wasn't created for any of those things; it wasn't intended to be portable or to run on anything but a PDP. Its sole reason for existing was to do system programming in a high-level language instead of in assembly.

And yes, C is a high-level language in the original sense of the term.

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

[Anonymous Coward]

There's a huge difference between Ruby and node. Ruby is slow as fuck and writing async code with it is very difficult. Node is ridiculously fast and writing async code is easy. Ruby lasted me about 6 years. Node is already upto 5 years and I can easily see it lasting another 5. And if it does get replaced by soemthing better later on. So be it... that's the life of a programmer

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

[jellomizer]

JavaScript is the main programming language for the browser.

Normally making a Web Application you often need to program in many languages.
SQL for the Data Layer
PHP/Java/C# for the Business/Logic layer
JavaScript for the Interface Layer
HTML for the interface

NodeJS is JavaScript, so you can cut down on the number of languages you are using for a Multi-Tier Application. This can allowed shared libraries across both sides Say your complex data validation check that you put on the Browser Side (as the UI layer needs this to keep people from keying in stupid stuff) then use the same code on the Logic Side, to double validate the data in case someone disables javascript on their browser.

Re: Ruby

[Anonymous Coward]

I think most companies DO need webscale tech now that they run everything on shitty cloud servers. Those systems are so performance flaky, you are driven to build scale out systems to take advantage, rather than 90s era scale up solutions.

Re:Ruby

[HornWumpus]

By the same argument, butt sex is better because everybody can participate...

Javascript is a shitty language that only exists because it is (was anyhow) the only somewhat safe game in the browser.

The only parts of your list not needed by Javascript purist is the business logic code. Using Javascript to access data still requires SQL (for reasonable efficiency) and the DOM is still a reflection of HTML.

Languages are easy, libraries are hard.

Re:Ruby

[93 Escort Wagon]

NodeJS is JavaScript, so you can cut down on the number of languages you are using for a Multi-Tier Application. This can allowed shared libraries across both sides Say your complex data validation check that you put on the Browser Side (as the UI layer needs this to keep people from keying in stupid stuff) then use the same code on the Logic Side, to double validate the data in case someone disables javascript on their browser.

If you use a different language on the server side, then you are probably more likely to catch errors in your logic - you're forced to think twice about the problem, and come at it from a slightly different perspective each time.

Regardless... if you're using the exact same code on both the client and the server, you are not "double validating" anything - you're just running a single check, either one or two times.

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

[Anonymous Coward]

Using Javascript to access data still requires SQL

Haven't you heard? MongoDB is webscale! /sarcasm

Re:Ruby

[Gr8Apes]

I wonder how many now legacy ruby apps people regret writing.

All of them?

Re: Ruby

[Gr8Apes]

Node is a clusterfuck waiting for the maintenance window to take its toll. It's not old nor widely used enough yet to have the pains of maintainability really rear its ugly head.

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.

Re:Ruby

[squiggleslash]

GWT was supposed to solve the same problem (by replacing JS with Java at the Interface Layer.) Was it too limited or was it just people don't like Java very much?

Still amazed, unfortunately, at the popularity of PHP. I hope the article's right, at least in that some of the PHP is slowly being replaced with JS.

Re:Ruby

[Wycliffe]

NodeJS is JavaScript, so you can cut down on the number of languages you are using for a Multi-Tier Application. This can allowed shared libraries across both sides Say your complex data validation check that you put on the Browser Side (as the UI layer needs this to keep people from keying in stupid stuff) then use the same code on the Logic Side, to double validate the data in case someone disables javascript on their browser.

This might have made sense 5 years ago but this doesn't seem very useful today. You could use the same argument for java and android phones. As most places now have to develop for web(js) and android(java) and ios(obj c), I don't see what the advantage is for having the same language on the server as the web. I'm assuming that most companies developing for web,android, and ios use a single language on their server to serve endpoints to the 3 current main platforms.

Re:Ruby

[DuckDodgers]

I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

Granted, you can get that with Perl, Python, and Ruby too and if you restrict yourself to certain Java and C# features you can also have it there. But in practice I think a lot of server side programmers first saw the instant feedback loop of Node.js first, and fell in love with it.

Re: Ruby

[drinkypoo]

if mod_perl didn't suck then perl would be a lot more popular, and php a lot less so.

Re:Ruby

[Anonymous Coward]

The people doing the regretting are whoever the poor saps are that have to janitor the apps after they're written, not whoever wrote them.

Re:Ruby

[nedlohs]

you are not "double validating" anything - you're just running a single check, either one or two times.

Was it really that hard to read 10 more words?

You validate once on the browser do that you don't need to do a return trip to the server and can present the user with a validation error message at a conveniant time.

You validate again on the server because you assume the user is malicious.

You aren't trying to do anything more than use a single validation algorithm, you just do it twice (you know what the word double means) because it is more efficient to do it on the client side but it would be brain dead stupid to trust the client.

Re: Ruby

[Anonymous Coward]

JavaScript+Node seems like the opposite (e.g. a crappy language with a superior runtime engine).

It came a long way from a language designed to make blinking effects in web pages...

Re: Ruby

[Anonymous Coward]

I love Slashdot. Java is slow but Node is "ridiculously fast." lol!

Re: Ruby

[narcc]

JavaScript isn't even a real language.

What an odd thing to say. I'm guessing you're not very familiar with the language.

See, everyone hates JavaScript when they first use it. I suspect it's because they're trying to use the language like they'd use Java or C#. That's not a good idea. Once you learn the language, you'll find it's has very simple design that allows for a lot of depth. The biggest "warts" in the language come from where it's been unnaturally extended to make it look more like Java (the new keyword, for example).

It's unusual in that the language seems to get better the more you learn about it. Contrast this with Java, which seems to get worse the longer you use it.

At the moment, I'm wading through an unholy amalgam of C and Java that should never have been, so I might be a jaded today. Still, I'll stand by my comment. JavaScript isn't a bad language at all. Though if you're an inexperienced developer that tries to treat the language like Java or C#, it can certainly seem that way.

Re: Ruby

[HiThere]

I don't know Javascript, but Ruby is deficient in error checking. When I use it sometimes all I can be sure of is "somewhere in that program I didn't properly close a parenthesis, or left out an 'end'". This can be annoying when the program is several pages long. Recently I ran into a problem with some code I had written in Ruby a month ago, and the easiest way to solve it was to translate the code into Python...which didn't, in the end, turn out to be any longer than the original Ruby. (Well, the actual problem was the data format...I had gotten interrupted in the middle of changing the program into something that would scale better. But the error messages were hopelessly bad, so it looked like a program problem.)

P.S.: The Python program is easier to understand, but that may be because I've written it more recently.

Re:Ruby

[narcc]

PHP is and was popular, because it was better than the alternatives. Imagine a world where JSP or ColdFusion came out on top...

Whatever warts the language might have, it's trivial to write, debug, and deploy. Those three things are more important than ideological purity or whatever it is that informs your opinion on the language when it comes to adoption and longevity.

To replace PHP, you need a language that is at least as trivial to write, debug, and deploy.

NodeJS, while it's the hot new trend, isn't likely to replace PHP as it's more difficult to write, debug, and deploy. Whatever benefits it might have, without those three factors, it's not likely to knock PHP out of it's little niche.

Re: Ruby

[HornWumpus]

Come here and see the Stockholm syndrome...

What you are experiencing is 'my pigfuck', it's just human nature. Once you know a mess, it becomes your mess, you've invested the time.

Re:Ruby

[HornWumpus]

How's that debugging working for you?

Javascript is hardly the first interpreted language. When will Javascript catch up with pre .net VB?

Re: Ruby

[Jaime2]

JavaScript is only a good language if you know which 60% of it is horrible and never use that part. It also helps to know that it's not a variant of Java; it's a variant of Forth made to resemble Java. That help to reduce the temptation to try to use it like Java.

If you're wondering what the horrible parts are, my personal top five are; variable scope, type coersion, undefined, this, and global.

Back to what you said - so much of it is horrible that it really is worth hating. Sure, it can be used effectively, but only with a huge degree of self control. People who barely know the language and are learning by Googling are in for a world of hurt.

Re: Ruby

[narcc]

"Stockholm syndrome"? Ridiculous.

I've used Java for more than 20 years. I loved it at first, I even advocated it. I can't stand it today, and hate it more the longer I use it.

Javascript, I've used for a little over 10 years or so. I hated it at first, but now I think it's a pretty nice language. The exact opposite of my experience with Java.

C, which I've used longer than either language, I'm still pretty neutral about. I feel about the same way about it now that I did when I first started using it.

If what you're saying was true, I'd love C more than life itself and prefer Java over JavaScript.

Now, had you bothered learning the language before declaring it unsuitable for any purpose then you'd be able to offer legitimate insight in to the languages design, rather than pointless platitudes and allusions to amorous pigs.

Re: Ruby

[TheDarkMaster]

These people usually do not understand because they have never known anything different in life. I seriously doubt they have ever had to ensure that the application works even in adverse situations (check your inputs! expects failures!) and where it can cost lives if it fails in an unexpected way.

Re:Ruby

[Luthair]

I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

Java has had hot code swapping for as long as I can remember. Since C# was meant to compete with Java I would assume they did too. C/C++ didn't

Re:Ruby

[TheDarkMaster]

You do not want to run your critical server-side business/logic system in a language (javascript) where you do not even have guarantees if the variable you are dealing with is an integer or a string or something entirely else.

Re:Ruby

[rholtzjr]

GWT had a lot to be desired. WAY too slow. (IMO). While it did remove some of the burden from writing code to run on the client, to me, it seems like it was just a server side applet framework. I think Wicket does a better job than GWT. Once you get used to it's behavior, it does seems to run faster than any GWT code I have had to write to perform the same functionality.

What I would be curious about, "Does Node.js have a security model?" Since it is Javascript, I am only guessing, but JS never really put much emphasis on security. This is the reason I avoid it like the plague.

With Wicket, you at least inherit Java's security model and integrates with other security frameworks like Spring, JAAS, etc....

I think I will pass on this one, it seems more a fad to me than a serious industry direction. Plus I got WAY too many languages running around in my head right now, It seems lately I have very little room to add another.

Re: Ruby

[HornWumpus]

Javascript has it's place...the browser, until something better is built.

If you know a single other language and still seriously consider server side javascript, there is something wrong with you. The only argument (not a good one) for server side javascript is 'don't need to learn anything else'.

Java also had a _bad_ case of 'good for everything'. I'd rate Javascript on the server as about as good as Java that involved Swing.

C doesn't bring the massive volume of mess with it. It's simplicity is it's beauty. But the world's biggest C advocate wouldn't use it to implement server side web code, unless the only other choice was Javascript (then the smart move would be to quit your job).

Re:Ruby

[squiggleslash]

NodeJS, while it's the hot new trend, isn't likely to replace PHP as it's more difficult to write, debug, and deploy

I gotta tell you, I find that hard to believe. What about JS is harder to write, debug, and deploy? JS is easier to write, it still has the same free form nature but has far fewer gotchas, and virtually all PHP programmers are already familiar with it. It's easier to debug, again, with fewer gotchas; and deployment seems to be more or less identical, just copy the file where you need it.

JS is the most obvious language to knock PHP off its perch. Ruby, Python, and Perl all are "foreign" as far as the average PHP programmer goes, and are unusual in some major way. Java and C# require a completely different type of environment, and are much stricter as languages.

Javascript is similar enough to PHP, without having the bone headed "Zero is "" is empty is null" type decisions that make PHP such a dangerous language to develop in.

Re: Ruby

[s_p_oneil]

When I first tried both Ruby and Python, to me they seemed damn close to 100% equivalent in terms of features and ease-of-use, but to me the minor differences feel more elegant in Ruby and more irksome in Python. Maybe I'm just a bit more more old-school, maybe I just like the {} more than indentation for code blocks, or maybe it's just that I tried Ruby first.

Anyway, most of the languages I've worked with in the past 25 years have used C-style curly braces for code blocks, and once you get used to the {}, I find statements like this to be extremely elegant, simple, and self-explanatory (without even needing to know much about Ruby):

['a', 'b', 'c', 'd', 'e', 'f'].sort {|a,b| b <=> a } # It's intuitive to me that this will sort the list backwards

10.times {|i| puts("Iteration #{i}") } # I love how even constant literal values are instances of classes

7.days.ago # Base classes like Integer are extendable, and while it allows devs to shoot themselves in the foot, I can't imagine a more readable way to deal with datetime values

do_something() if x # I like the option to have leading or trailing if/while/etc.

x = case y # Like a C-style switch statement on steroids
    when Integer then 0
    when Array then 1
    when /regex/ then 2
    when "fixed string" then 3
end

Would the code to implement these in Python be all that different? Not really. But I find the extra hoops you have to jump through to do these things (again and again) to be annoying. Why can't Python add a switch/case statement? Why can't you call string.length or string.size (it's supposed to be an object-oriented language after all)?

Re: Ruby

[Tablizer]

So they need duck-wire and chicken-tape to patch the duck-tape and chicken-wire. I'm a vendor for Duck-Wire++ Cloud Premium, so I'll make a killing!

Re: Ruby

[Anonymous Coward]

The biggest problem with javascript, and all scripting languages in it is you can only find syntax errors at run time. Yes, there are external tools one can run to catch that, but how effed up is it that in this day and age you have languages that won't catch syntax errors until run time. And I've seen pros who have been doing web dev for 20 years get hit by this repeatedly.

Re:Ruby

[angel'o'sphere]

Or you double the amount of bugs.
In the browser the social security number check does not work correctly and on the backend my email gets rejected ...

Re: Ruby

[Anonymous Coward]

Jsp is as easy to deploy as php and it is way faster

Re:Ruby

[angel'o'sphere]

GWT is doing just fine, but meanwhile we have about 4 variations of it, vaadin, ext GWT, Sencha ... probbaly more.

While one group basically puts Java into the browser the other group puts JS on the backend ...

And except for brain dead casting rules, JS is a superb language. If you don't like its original syntax use CoffeeScript or TypeScript.

Re:Ruby

[Anonymous Coward]

Hey but what about this whole hype that made us write same code twice anyway, and call the first (but more often the second) attempt a "unit test"?

Re: Ruby

[Anonymous Coward]

It's just different from other languages/platforms. Most of the cluster people experience is the lack of established practices - and those that are established tend to make it harder. Attempting to develop in JavaScript using traditional styles you'd see with J2EE or .Net are destined for failure in a loosely typed functional language like JavaScript. I've been doing high volume production development with node since 2011, but I've been an enterprise level JavaScript developer since 2004. One of the biggest strengths the language has for maintenance is the small codebase footprint. The high-level constructs help, the simplified type system helps, and if you learn to use closure-scope instead of binding to "this" with class-based constructs you'll knock out half of the boilerplate you see in modern strategies. No single aspect of language or platform design will improve maintainability than cutting your codebase in half.

Re:Ruby

[angel'o'sphere]

For C++ we had hot code swapping 20 years ago, long before Java.
Unfortunately only in selected IDEs or OS platforms.

However I don't know how the status quo is right now, perhaps no one does it anymore.

Re:Ruby

[Darinbob]

Ruby is a real language (ignoring the "rails" thing). JavaScript is a hack. Using it on the server seems bizarre, unless your only devs only know javascript?

Re: Ruby

[markhb]

C doesn't bring the massive volume of mess with it. It's simplicity is it's beauty. But the world's biggest C advocate wouldn't use it to implement server side web code, unless the only other choice was Javascript (then the smart move would be to quit your job).

What do you think Apache modules are? :) And before application servers existed the only ways to do anything with a web server besides serve static files were to do CGI, probably in Perl 4, or to write to the server API, both in C (at least back then). So server-side C code still exists, and even has its use cases (chiefly maximum performance).

Meanwhile, I wonder if all this server-side Javascript is stepping on the toes of the SSJS Netscape introduced on its server; there must be some patents lying around that someone owns....

Re: Ruby

[K. S. Kyosuke]

7.days.ago # Base classes like Integer are extendable, and while it allows devs to shoot themselves in the foot, I can't imagine a more readable way to deal with datetime values

Wouldn't that be just "7 days ago" in Smalltalk? ;)

Re: Ruby

[K. S. Kyosuke]

If you know a single other language and still seriously consider server side javascript, there is something wrong with you. The only argument (not a good one) for server side javascript is 'don't need to learn anything else'.

What about mobile code? Although it is the case that JS doesn't have very good provisions for it.

Re:Ruby

[Anonymous Coward]

> Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

In Erlang (and Elixir) you don't even have to hit F5. Edit, save, and (if you're running something like "rebar3 auto" or rustyio's "sync") your changes are compiled and reloaded automatically.

Super, _super_ sweet.

Re: Ruby

[s_p_oneil]

I have no idea. I know Ruby was heavily influenced by smalltalk, but even after playing around with 25+ different programming languages (I even tried squirrel for a bit), somehow I never got around to looking at smalltalk. ;-)

Re:Ruby

[Anonymous Coward]

You don't need to press F5

Re: Ruby

[Anonymous Coward]

What you are experiencing is 'my pigfuck', it's just human nature. Once you know a mess, it becomes your mess, you've invested the time.

You have just summed up my workplace...

Re: Ruby

[bzipitidoo]

You think that array declaration is elegant? Tell me which snippet of code you think is easier to work with:

['a', 'b', 'c', 'd', 'e', 'f']

or

"a b c d e f".split(' ')

Re: Ruby

[Anonymous Coward]

What non-sense.

I have used many languages over the decades. More than I ever wanted to.

JavaScript on the server side under node.js is a wonderful thing and my weapon of choice in many situations. It makes development so much easier and quicker than many other systems. It's far easier to read after the event. It's performance is up there with Java and even C++ for server side data juggling.

As usual, choose your tools to suit the job at hand. To right off JS out of blind ignorance does not show you in the best light.

Re: Ruby

[Anonymous Coward]

Yet another poster criticising JavaScript for all the wrong reasons out of ignorance.

Yes JS has it's bad parts. Or at least annoying. All languages do. JS has a lot less annoying features than other commonly used languages.

JS most certainly is not a variant of Forth. That shows your total ignorance of JS or Forth or both. JS was inspired by Self. As such it has always had advanced features that languages like C++, Java, C# have only recently adopted.

The variable scope issue is history. I won't explain it. You can google it.

"this" works perfectly well. Especialy with the lambda syntax that comes with the latest standard.

I have no globals in my JS code under node.js. Node has modules. Modules are comming to JS in browsers very soon. All by browser side code is already using modules wih the help of a module bundler. No globals there either.

Re: Ruby

[Anonymous Coward]

We know what "multi-threading" is. I have been writing multi-threaded, multi-processor code since 1980.

The JS event driven model is a different approach to do many of the things one would normally use threads for. The event model results in code that is easier to reason about and is very efficient.

If you must knock on a language you should be able to do better than that feeble attempt.

Re: Ruby

[h33t l4x0r]

I've been using Node lately for IO-bound projects that I used to do with Ruby (multithreading, but not really). I really am seeing better performance from Node.

Re: Ruby

[K. S. Kyosuke]

The biggest problem with javascript, and all scripting languages in it is you can only find syntax errors at run time.

Bullshit, in all languages with fixed grammars are syntax errors found at read time (in Lisp lingo, that's before compilation).

Re: Ruby

[doom]

> I don't know Javascript, but Ruby is deficient in error checking. Client-side javascript is even better: you never need to worry about error messages because you never see them.

Re: Ruby

[DCFusor]

Wouldn't know. Like many, I never really used Apache. NGINX doesn't use mod_perl...I use perl here with NGINX on all sorts of things - even RPis, and it's plenty good enough. The big boys don't use Apache at all...

Re:Ruby

[tepples]

Javascript is similar enough to PHP, without having the bone headed "Zero is "" is empty is null" type decisions that make PHP such a dangerous language to develop in.

Those who think ECMAScript lacks the brain-deadness of PHP have another think coming. Appendix B of Douglas Crockford's JavaScript: The Good Parts lists a few examples.

• == is as brain-dead as PHP: 0 == '0' and 0 == '' but '' != '0'
• The hard-to-predict with statement (which thankfully got cut from later versions of ECMAScript)
• Any use of eval or new Function other than detection of ECMAScript 6+ syntax, which is prone to even more serious errors than the SQL injection endemic in beginners' PHP code
• Boxed types such as new Boolean(false)

However, Crockford is known for holding idiosyncratic opinions. In appendix B, he continues that the following elements are bad:

• Early exit from an iteration of a loop using continue; Crockford considers it preferable to refactor the loop's body into a function that exits early with return
• Fall-through in switch if break is missing; Crockford considers it preferable to refactor the repeated portion into a function
• The if, while, do, and for statements allow a form without braces
• The ++ and -- operators
• The presence of bitwise operators &amp | ^ ~ << <<< >>, which Crockford deems more likely to be typos for && || Math.pow() ! < < > respectively than actual bit manipulation because ECMAScript lacks a distinct integer type and "is rarely used for doing bit manipulation."
• Declaring a function using a function statement rather than a function lambda expression
• Operator new rather than factory functions

Re: Ruby

[stephenmac7]

"abcdef".chars

Re: Ruby

[Anonymous Coward]

%w{a b c d e f}

Re: Ruby

[narcc]

it's a variant of Forth

!

People who barely know the language and are learning by Googling are in for a world of hurt.

Indeed. Look at what that did to you.

Re:Ruby

[narcc]

What about JS is harder to write, debug, and deploy?

This is the only point with any detail:

deployment seems to be more or less identical, just copy the file where you need it.

That's not how it works. Try this: Set up two different php applications on the same server, then do the same for node. You'll see what I mean.

Re: Ruby

[Anonymous Coward]

it's a variant of Forth

Now hold on--I liked Forth. Javascript, not so much.

If you're wondering what the horrible parts are, my personal top five are; variable scope, type coersion, undefined, this, and global.

The worst part is how those strange behaviors can bite you in surprising ways. The language was designed for beginners, yet you have to be an expert in it to use it competently. It is not a safe language.

Re:Ruby

[Anonymous Coward]

By the same argument, butt sex is better because everybody can participate...

I got a big laugh out of this. After all, Javascript was designed by a guy who disapproves of butt sex.

Re:Ruby

[Anonymous Coward]

but has far fewer gotchas

What the hell are you smoking? I'll grant that PHP's treatment of equalities can be a bit funky, but I sure take it over what Javascript offers. PHP has actual classes. It has scoping rules that are not batshit crazy like Javascript's. Concatenation has a different operator than addition--an attribute you'd damn better have in a language with dynamic types. Debugging in PHP is much less painful than in Javascript. PHP's arrays function as ordered maps--while sometimes causing undue overhead, this attribute of PHP arrays is often very handy in practice.

I've done tons of programming in both PHP and Javascript, not to mention a range of other languages also. Using C, I'm in my happy place. PHP is usable and fast for developing. Javascript always seems like the penalty box.

Re:Ruby

[bmarkovic]

Just did. Copy the folder (including the node_modules tree). Run `node .` (the dot is not a typo). Done

Re:Ruby

[narcc]

Good for you. Now try to do what I said you should try to do.

Re: Ruby

[Anonymous Coward]

A lot of people think mod_perl is the Perl equivalent of what mod_php is. I did at first too. It isn't.

It's made to extend Apache with Perl. Write filters and handlers and stuff for HTTP requests. Not for serving simple HTML pages. If you tried to read its documentation, you'd realise that.

You were apparently always supposed to use Perl with FastCGI or (in the modern times) Plack/PSGI.

See CGI::Alternatives for a bunch of popular modern web frameworks. None of them need mod_perl.

Re: Ruby

[Anonymous Coward]

Don't forget about AOLServer and embedded TCL. Remember that Sun first hired in John Ousterhout and bought into TCL thinking it would be their platform of choice but when Ousterhout wouldn't let Sun "own" it they basically stopped supporting him and went with Oak (aka Java) because they could claim ownership of it, so Ousterhout left Sun and started Scriptics. AOLServer has some pretty impressive performance capabilities.

Re: Ruby

[Anonymous Coward]

Considering V8 and JVM are both written in C or C++, then it is safe to say that event driven, asynchronous coding is available in C, C++ and Java, and has been for some time. And it gets used quite a bit. But it isn't considered the be-all end-all solution to software development and multi-threading that can take better advantage of multi-processor affinity has the potential for much higher scalability than a single thread handling all communications with clients.

Re: Ruby

[Jaime2]

Yet another poster criticising JavaScript for all the wrong reasons out of ignorance.

Yes JS has it's bad parts. Or at least annoying. All languages do. JS has a lot less annoying features than other commonly used languages.

Not ignorant, I use JS a lot and know it better than most. Most other languages have old libraries or syntax elements that have been superseded by something better. Very few languages have core feature that should almost never be used, but JS does (e.g. eval).

JS most certainly is not a variant of Forth. That shows your total ignorance of JS or Forth or both. JS was inspired by Self. As such it has always had advanced features that languages like C++, Java, C# have only recently adopted.

My central point was that JS was not "Java for web browsers". I got the language wrong, it was Scheme with a bit of Self, rather than Forth. But, that's still the reason things go wrong when a developer thinks of it as a variant of Java. Sure, it acquired some features earlier than Java and C#, but at least C# was originally designed with a sane variable scope system. Missing features can be added easily - broken fundamentals will haunt you forever.

The variable scope issue is history. I won't explain it. You can google it.

Fixed last year... it will still be years before it can be assumed to be available on a given browser.

"this" works perfectly well. Especialy with the lambda syntax that comes with the latest standard.

Now you're showing ignorance of JS. "this" is a disaster. Most languages that have an equivalent of "this" have a semantic meaning for it that makes sense. In JS, it's up to the caller. Sure, sometimes it's sensible, but when it's not, it's a problem. You gave an example of a good use of this. But, for every good use, there's code out there that abuses "this". If you ever write a callback that gets called by someone else's code - the only way to know what will be in "this" is to read the documentation (or the code).

I have no globals in my JS code under node.js. Node has modules. Modules are comming to JS in browsers very soon. All by browser side code is already using modules wih the help of a module bundler. No globals there either.

Congratulations. But, the fact that you write good code by using a subset of JS doesn't make JS a good language. It means that it's a language filled with land mines that every newcomer has to navigate. That's what makes it a bad language. Also, the things you can take for granted server-side are more bigger problems when you go client-side. The fact that you have a module system "on the way" after more than twenty years is pretty good evidence that JS is still immature.

Re: Ruby

[Rutulian]

It also helps to know that it's not a variant of Java;

If you think that, you are just ignorant. It was never true, and while it may have been an understandable mistake 15 years ago due to the similarity in naming and the push to use Java applets in the browser, it isn't anymore.

it's a variant of Forth made to resemble Java

Also not true.

That help to reduce the temptation to try to use it like Java.

I don't even know how you would do that. They are so different it seems like you would notice within the first 10 seconds. Go ahead and try to use closures in Java.

variable scope

Variable scope is pretty straightforward if you understand how it works (hint: don't do everything in one monolithic function). And if you're smart, you use strict mode, which will stop you from making 99% of scoping mistakes.
https://developer.mozilla.org/...

type coersion

First, you can prevent type coercion where it matters if you don't want to use it.
Second, type coercion is very useful in certain situations, especially involving HTML forms.

undefined

Why? Distinguishing between null and undefined seems pretty basic to me. If you want a test for null that includes undefined, this is an example of a situation where type coercion can be handy.

this

"this" is perfectly fine as long as you know what it does. Use prototypical inheritance properly and it will never be a problem for you.

global

Many scripting languages support them (ex: Perl), and most recommend the same thing, don't use globals.

Now, if you had said Array-Like Objects, there we could agree about some stupidness in JavaScript that is unnecessary and annoying.

Re: Ruby

[Rutulian]

I seriously doubt they have ever had to ensure that the application works even in adverse situations

You do realize that most JavaScript runs in the most untrusted client ever known, the web browser, right? I'm sure you can find plenty of examples of people making stupid mistakes, but there are also plenty of people who know what they are doing, thank you very much.

Re: Ruby

[Jaime2]

It also helps to know that it's not a variant of Java;

If you think that, you are just ignorant. It was never true, and while it may have been an understandable mistake 15 years ago due to the similarity in naming and the push to use Java applets in the browser, it isn't anymore.

You do realize that I said that JS is not a variant of Java, right?

The rest of your post is simply you saying how to work around the badness of JS. You are simply listing all of the skills that need to be acquired to be a competent JS programmer and that is a longer list than most other languages. That's precisely why it's a bad language.

Also, if you think "this" is perfectly well defined, you are wrong. A caller can passes literally anything for "this". That means that, by language spec, "this" is completely undefined. The caller will have a definition, but it may or may not be sane and it may or may not be consistent.

Go ahead and try to use closures in Java.

That's a great example of why something who thinks JS is a variant of Java would write bad JS. Of course, they wouldn't write any closures, meaning they are almost certainly writing bad JS that looks like it was written in 1998.

Re: Ruby

[Anonymous Coward]

JavaScript gives you the tools to do what needs to be done. If you don't know what needs to be done, then that's on you. If you don't like how this works, then don't fucking use it. But don't pretend this is designed poorly just because it doesn't work like it does in Java. JavaScript is a multi-paradigm language. If you can't pull yourself out of the OOP ghetto, you're gonna have a bad time.

Re: Ruby

[Anonymous Coward]

Funny, my editor of choice and every editor I've tried (with the exception of nano) seem to find syntax errors just fine.

Stop being a dipshit.

Re: Ruby

[Anonymous Coward]

The limited form of async in JS is a feature. The concurrency model allows for high parallelization while offering a programming model where the parallelization can be handwaved. No mutexes, thread local storage, etc. If you need more control, IPC is built in (at least in Node).

It's not that JS async is so great, it's that async isn't tacked on to a language that was designed for procedural code.

Re: Ruby

[Anonymous Coward]

For algorithmic computation, JS beats Java in performance. For highter level abstractions, Java outperforms JS. It depends highly on what you're doing. JS engine performance draws the most money and the best engineers, due to its prominent position on the web. When's the last time Google and MS got into a performance war over Java?

Re: Ruby

[K. S. Kyosuke]

I'd personally still prefer Lua over Javascript. It's funny how both languages were inspired by Scheme to some extent and still both made some crucial choices in a different way, with Lua being much saner and JS being much dumber.

Re: Ruby

[Anonymous Coward]

That doesn't happen in JS. That type of shit happens in highly object oriented systems which have become so convoluted people keep trying to automate DI instead of just doing it by hand. When you get to testing, your DI automation pushes you into duplicating your entire DI environment, which in turn pushes you to write a bunch of duplicate code.

Unit tests for decent JS rarely take you down that ugly path that is endemic to most heavily OOP languages.

Re: Ruby

[reanjr]

They are both equally bad at type coercion, and they both have a brain-dead simple silver bullet to fix the issue (===), but JS developers tend to be higher quality, so they actually use the "===" operator.

Re: Ruby

[reanjr]

I am not a fan of PHP, but it's one of the best templating languages available. It never ceases to amaze me how many templating languages have been written in PHP, when the language provides those facilities already, and the new languages inevitably introduce all sorts of headaches not present in straight-up PHP.

If your app mostly takes form inputs and renders the data into HTML templates, PHP is a fine language. That's just not what the focus on the web is anymore. Now, it's all REST-y micro-services, which PHP is abysmal at, but JS excels.

Re: Ruby

[reanjr]

if (typeof x === "string") {
        console.log(x, "guaranteed to be a string");
}

Re:Ruby

[swilver]

...hit F5, and error. Fix some syntax/naming/style problem and swap to browser again, F5, another error... rinse repeat until you fixed everything that a compiler would catch right away.

Re: Ruby

[Rutulian]

You do realize that I said that JS is not a variant of Java, right?

Yes, you did. The point is, nobody should ever think that, so I don't know why you even mentioned it.

The rest of your post is simply you saying how to work around the badness of JS.

What badness? You have not mentioned any badness aside from the fact that you don't like it. JavaScript is a different language, so it will behave differently from other languages. JavaScript does not have block-level scope, it has function-level scope. That is not inherently bad. It's just different, and as long as you are aware of it, it works just fine. Same with prototype-based inheritance vs class-based inheritance. Not bad, just different.

You are simply listing all of the skills that need to be acquired to be a competent JS programmer

I'm listing language features. Newsflash: you have to know a language and be aware of its features to use it effectively. There are quite a few differences between C and C++ as well.

and that is a longer list than most other languages. That's precisely why it's a bad language.

Nonsense. The ease with which you can pick up a language based on its similarity to other languages has nothing to do with goodness or badness.

Also, if you think "this" is perfectly well defined, you are wrong. A caller can passes literally anything for "this". That means that, by language spec, "this" is completely undefined. The caller will have a definition, but it may or may not be sane and it may or may not be consistent.

Again, you are basing your complaint on similarity to other languages. If you don't do that, you won't have problems. "this", by definition in JavaScript, refers to the current execution context of your function. The execution context, naturally, is not fixed and can change. That is the whole point and there are very good uses for it (ex: event handlers). If you need static arguments, use static arguments. Don't use "this" as a static argument, because that is not what it is. For object methods, "this" behaves 99% like implementations in other languages (ie: it refers to the current object instance). The 1% difference is that you can change the object instance, which is useful because, among other uses, it is the JavaScript way of implementing super inheritance. Not bad, just different.

Re: Ruby

[Jaime2]

I'm listing language features. Newsflash: you have to know a language and be aware of its features to use it effectively. There are quite a few differences between C and C++ as well.

A good language allows you to discover features and is enjoyable to use and allows you to be productive quickly. JavaScript's nuances constantly stab the inexperienced developer in the eyeball. Any language is learnable - but the fact that you can eventually get to the point of building software isn't enough to make a language good.

Again, you are basing your complaint on similarity to other languages. If you don't do that, you won't have problems. "this", by definition in JavaScript, refers to the current execution context of your function. The execution context, naturally, is not fixed and can change. That is the whole point and there are very good uses for it (ex: event handlers). If you need static arguments, use static arguments. Don't use "this" as a static argument, because that is not what it is. For object methods, "this" behaves 99% like implementations in other languages (ie: it refers to the current object instance). The 1% difference is that you can change the object instance, which is useful because, among other uses, it is the JavaScript way of implementing super inheritance.

I can call any function you write and pass it anything I want for "this". Most languages have a much more straightforward concept of "this". For example, in C#, "this" always refers to the current class instance. Always. I'm not saying C# is better because I know it. I know both the C# and the JS implementation. C#'s implementation is better because one look at a line of C# that has "this" in in tells me what it does. In JS, I have to read documentation and/or experiment if I didn't write the code that makes the call (and even if I wrote it, assuming I still remember). This is a major source of errors.

Not bad, just different.

It breaks the "principal of least surprise" and is considered bad by many people with better reputations in this field than you or I.

Re: Ruby

[fluffynuts]

I don't have a beef with Ruby (other than that it looks like someone wanted Perl but realised that Python was saner). Javascript is accessible. It's also targetable, so you can use "superior" (my choice of discriminator) languages like Typescript to "get there". Node.js offers a low-hanging branch for people to "get shit done" -- and it does so well, imo.
Ruby just never grabbed me. It's esoteric, strangely unmalleable, and breaks from version to version -- which may be a good thing (in that the maintainers aren't bound by backward compat) -- but it's a negative as a noob.

Speed isn't everything. Maintainability, "grokkability" -- these are king. Code isn't for compilers -- it's for co-workers. What JS lacks in "super-awesomeness" (and it does have flaws, no arguments there), it makes up in readability and accessibility.

Node all things! (:

Re: Ruby

[Rutulian]

A good language allows you to discover features and is enjoyable to use and allows you to be productive quickly. JavaScript's nuances constantly stab the inexperienced developer in the eyeball. Any language is learnable - but the fact that you can eventually get to the point of building software isn't enough to make a language good.

It's just my opinion, but I don't find JS nuances to be any more numerous or onerous than those found in other languages.

I can call [mozilla.org] any function you write and pass it anything I want for "this".

Yes you can do that, but there are only a handful of common cases where you should do that. If you are deviating from known best practices and design patterns, then you are probably not writing good code. If your point is that JS is not good for writing abstract interfaces, I agree with that. That is not the purpose for which it was intended, though.

C#'s implementation is better because one look at a line of C# that has "this" in in tells me what it does. In JS, I have to read documentation and/or experiment if I didn't write the code that makes the call (and even if I wrote it, assuming I still remember). This is a major source of errors.

You should not. You should know that 1) You are working on an object method, and therefore "this" is the current object instance OR 2) You are working in an event handler, in which case "this" is the DOM element that triggered the event OR 3) You are working with a bare function, in which case "this" is the global/window/call() context. #3 is very rare and should not be done in common practice, so you are really only needing to consider #1 or #2 the vast majority of the time, and in both cases the meaning of "this" is straightforward and intuitive. The most common "this" errors come from not realizing that you have changed context when entering a closure, but that is just elementary JS and is easy to learn.

It breaks the "principal of least surprise" and is considered bad by many people with better reputations in this field than you or I.

I disagree. Whether or not something is a "good" or "bad" language is mostly a matter of subjective and biased opinion regardless of reputation. There are plenty of people with good reputations who say C is a bad language. They might be right, but I think it depends more on what you intend to use it for. I would never use JS for backend code. There are much better languages to use for that (my personal favorite is Perl), but for DOM/event-driven GUI stuff, I think it is at least as respectable as other languages out there. I certainly would prefer it over something like Java/Swing.

Re: Ruby

[s_p_oneil]

If you're talking about Ruby + Rails, then I agree 100% (but the esoteric, unmalleable, broken parts are in the Rails framework/libraries).

If you're talking about the core Ruby language itself without Rails, I don't. I still have quite a few Ruby scripts that were quick and easy to write, are super-easy to read and maintain, and most didn't need any changes to run perfectly from Ruby 1.8 through 2.4 (a few needed some very minor changes). One was a multi-threaded crawler that built a SQlite database of responses (with complete headers and content) for classification. It replaced tens of thousands of lines of Java code with about 200 lines of Ruby code, and the resulting code was orders of magnitude more grokkable and maintainable. It also ran faster, but that was only because it was using SQLite (with all the safeties turned off) instead of an older DB2 server. ;-)

Unfortunately, Ruby is a bad choice for a web server unless you need something very small/simple (and you already happen to be using Ruby). I still see Python and Ruby as vastly superior alternatives to older languages used to write shell/utility/configuration scripts. Perhaps the biggest problems with these languages is that they give developers a false sense of security and make them think "I can (and am determined to) do ANYTHING with this language!"

Anyway, I do plan to re-evaluate Node.js at some point in the near future. I might already be using Node for something today if my first experience with it hadn't been:

"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" (easily repeatable, I tested the latest stable and TLS versions about a year ago)

Re: Ruby

[Anonymous Coward]

Javascript has its place...the browser, until something better is built.

If you know a single other language and still seriously consider server side javascript, there is something wrong with you. The only argument (not a good one) for server side javascript is 'don't need to learn anything else'.

Java also had a _bad_ case of 'good for everything'. I'd rate Javascript on the server as about as good as Java that involved Swing.

C doesn't bring the massive volume of mess with it. Its simplicity is its beauty. But the world's biggest C advocate wouldn't use it to implement server side web code, unless the only other choice was Javascript (then the smart move would be to quit your job).

FTFY

Re: Ruby

[Anonymous Coward]

It also helps to know that it's not a variant of Java;

If you think that, you are just ignorant.

So you're saying it *is* a variant of Java?

Fucking moron.

Re: Ruby

[Anonymous Coward]

JavaScript is a reincarnation of VisualBasic 5/6. It was an interesting system in the sense that designers could drag several components together, without understanding any CS concepts, they could make sufficiently decent apps that solve specific business needs. The problem is upper management sees this and assumes that those apps can be easily adapted to some other use case, and in 95% of cases, it just wasn't. Often, kludges were made that sort of worked, but very inefficiently. Always.

JavaScript seems to attract similar types of people, that are not very savy in CS, but creative and have simple to medium-complexity task that needs to be solved. Now it's worse, as web applications are being hammered out, so no concern for security or user privacy is an obvious outcome.

Re: Ruby

[Anonymous Coward]

No.

Did you actually bother to read the comment you're replying to?

Re:Ruby

[DuckDodgers]

Java has had hot code swapping that works in some cases, but not all. If one of the toolkits you use doesn't support it, or you're working in one of the library dependencies for your project at the same time you're working on the project (e.g. you're working in foo and bar at the same time, and bar uses foo.jar at runtime), you can't use it.

Maybe I'm just unlucky, but in all the places I worked Java hot code swapping covered such a tiny sliver of the work we did that none of the developers used it more than a few days per year.

Re:Ruby

[DuckDodgers]

And repeat 589 more times... in three hours and have something with an amazing set of working features considering all of the work involved.

At my job now, I work on Java code. "mvn install ; cp_to_tomcat.sh ; start_tomcat.sh ; loop_until_login.sh ; espeak 'build ready for manual check' " takes nine minutes on a core i7, even if I changed only one line of one Java file since the last build. If I do "mvn install -DskipTests" it takes five minutes.

So even though the Node.js/Python/Ruby/PHP/Perl developer loses all of the power of static types, he or she can iterate fifty times faster than I can. Once your application is complicated enough, you can make a very strong argument that even fifty times faster iteration doesn't offset the value of a good static type system. But there is definitely trade offs.

Re:Ruby

[DuckDodgers]

I specifically said at the end of my post that other languages offered this before Javascript and Node.js. I just said that for a lot of server side developers, Node.js was their first exposure to the concept.

And yes, debugging is much harder and the bizarre type system causes all kinds of headaches. I'm not saying Node.js is flat out better than Java (or C#, or C++, or Haskell, or Scala). I'm just saying that instant feedback on changes can be a wonderful break from "make change, grow beard, test change" iterative cycles.

Re: Ruby

[iMadeGhostzilla]

How much I love the language is decided by how much ooh yeah moments I have working with it and how much it feels like fuck this shit. For that reason I stand with your comment -- Javascript for me had a number of this is nifty! moments and a good number of this is just ridiculous moments. Java has far fewer moments of delight while it's often frustrating even if not as much. C feels like a well thought out minimalistic tool, like a sharp knife that you get used to working with, it's satisfying and gets the job done. C++ has for me the most moments of pure ecstasy, often in the place where the closing brace is, even if the template compile errors are dreadful -- but they are compile errors.

That said love for the language is different from appreciation for a robust system, where Java shines.

Re:Ruby

[swilver]

I am Java programmer, and I can tell you, you're doing it wrong. Fix whatever is the root cause of having to do a full deployment so you can use hot code replacement like everyone else for Tomcat stuff.

A maven build for every line changed would be ridiculous. In a well setup environment, you never need to run Maven locally. You commit stuff on a branch, build server runs the maven build. During development you use incremental builds and hot code replacement only.

If that is not possible, then make it possible, involve management if needed. I wouldn't even consider working in that kind of fashion. We're programmers after all, lazy by nature. Fix your process.

Re:Ruby

[DuckDodgers]

I have a cushy position, which is why I haven't jumped ship despite intense frustration over the slow build environment. What you're suggesting makes sense, but it's a huge amount of work. I've suggested it before and couldn't get any traction. But a friend just earned a promotion to developer lead and this is something he's always wanted to fix too, so I'll bring it up again to him.

What kind of hot reload do you use? Just in your IDE? JRebel? JHipster? DCEVM? SpringLoaded?

Re:Ruby

[Tablizer]

I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

So it's like PHP, Perl, and ASP-Classic: interpreted. New is old again and old is new again. I'm getting my bell-bottom jeans out...or did they already come-and-go again, I forgot.

Re:Ruby

[Tablizer]

Actually it shouldn't matter much except at the validation stage. Much of typical CRUD programming is just marshaling around rows and fields rather than computations on those fields. If each marshaling stage has to know the type, then you violate DRY by replicating schema info to check at each stage.

Re:Ruby

[DuckDodgers]

Right. I did say that other languages have offered the feature. I just think that many of the people wildly enthusiastic about Node.js probably come from Java, C#, and C++ shops where the edit-compile-run-test cycle was measured in minutes. So even though this is not a new thing, it was new to these developers.

Re: Ruby

[modmans2ndcoming]

Node is popular because: 1) Your client developers can do server side development (saves money!) 2) You can send your JSON data to it from the client and it can handle it without converting it. (saves thinking!)

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.

Re:And then.........

[Anonymous Coward]

Yeah, don't use a well supported tool with massive module library and crazy amounts of tooling support. Use this other language that will be ready in 3-5 years!

Re:And then.........

[phantomfive]

Yeah, don't use a well supported tool with massive module library and crazy amounts of tooling support.

You mean C? Oh, you mean Perl? Wait, you mean Python? Or is it Java? Or C#? Maybe you're talking about Go?

The reality is, there are plenty of options with massive libraries and crazy amounts of tooling support. Javascript is popular because it's the only option in the frontend.

As long as we're on it, while it's true that Node has a massive module library, the vast majority of everything in there is garbage.

Re:And then.........

[Anonymous Coward]

Personally I hate both Java & JavaScript, but their utility, library support, and tooling are what keep them afloat.

I love me some C code, but the tooling is still stuck in the dark ages.

Re:And then.........

[Anonymous Coward]

your mom should be tried for crimes against humanity

Re:And then.........

[Anne Thwacks]

Snobol is the only answer.

(Depending on what our problem actually is).

Rust is never the only answer.

Re:And then.........

[Aaden42]

it can't be worse

Have you seen COBOL? FORTRAN? It can *always* be worse.

Re:And then.........

[Anonymous Coward]

I've been watching webassembly because I don't want to go back to the ancient days of basic where everything was floating point.

Re:And then.........

[Anonymous Coward]

As long as we're on it, while it's true that Node has a massive module library, the vast majority of everything in there is garbage.

Install grunt. Look at the packages that had to be downloaded that grunt depends on (and depends on, and depends on....). You're kidding me that there isn't some centralized library that's part of the language runtime that doesn't provide 75% of that stuff. Apparently, requiring a plethora of tiny random libraries to make up for the lack of central runtime functional support is a "feature" of this ecosystem. Make that a plethora of tiny random libraries your app will completely and utterly depend on. Sure, if one of them "goes away", you can replace it quite easily, but that's not going to stop your app from failing in the interim while your last planned update gets deployed.

Re:And then.........

[irrational_design]

Please no. In my opinion the best part of the WWW is that I can look at the source (even if it has been obfuscated) in plain text in my browser. Moving to binary formats is a terrible idea.

Re:And then.........

[doconnor]

WebAssembly isn't a language. It is a bytecode format that you compile other languages and libraries into.

Re:And then.........

[HornWumpus]

DataFlex...from the dawn of microcomputers. It was like a basic (classic w line numbers) programmer got shitfaced with a COBOL programmer. DataFlex was the unholy spawn.

Fast database engine (for it's day) though. Too bad it was stable like mySQL, routine reindex.

Re:And then.........

[MattSinger]

But Rust Never Sleeps

Re:And then.........

[rholtzjr]

Geez, I was hoping to get through the article WITHOUT any bad flashbacks. You forgot RPG in your list.

Re:And then.........

[maestroX]

Install grunt. Look at the packages that had to be downloaded that grunt depends on (and depends on, and depends on....).

I was just getting to that, because really, I don't want to spend too much time programming stack building scripts to get stuff running.
But, gulp was to be the next great thing, so I went for that only to find out yarn is the place to be.

Somehow, I find myself spending more and more time managing js libraries and compiling assets due to the ADHD nature of the js community.

Re:And then.........

[gweihir]

This was done before with JavaApplets. They mostly failed (and often cause significant problems were still used), but web-assembly is the only way to get good performance for non business-logic things.

Re:And then.........

[clintp]

Back in the day RPG was wonderful when it was used for its intended purpose. The concept of the program cycle was a fucking inspired piece of beauty. In a few minutes a competent programmer could create formatted output that would take days in any other language at the time.

Header, detail, break, total, and footer were just *breathing* in RPG. As a programmable text filter, unparalleled.

Nothing of its ilk would come along until AWK.

Re:And then.........

[Anonymous Coward]

Nah, that was Ada, the mouse made to government specs that was an elephant. Thank God the PC revolution put the stake through that one.

Re:And then.........

[toddestan]

What's wrong with Fortran? Granted, Fortran and Javascript are used for completely different things (well, at least they should be), but Fortran works pretty well for what it's generally used for nowadays - heavy duty number crunching where speed is important.

Based on my inexperienced observation...

[__aaclcg7560]

The Node Package Manager (NPM) is probably why Node.js is being used with every new JavaScript framework out there.

Re: Based on my inexperienced observation...

[Anonymous Coward]

6) Self-destruct in 5, 4, 3...

Re: Based on my inexperienced observation...

[avandesande]

I'm ready to swear allegiance, but could you change it to 'the motherland'? I think fatherland is a bit sexist.

Re: Based on my inexperienced observation...

[Anonymous Coward]

2) I think letting things enter the public domain is an acceptable, realistic alternative. Sorry, but people do need to make some money.

Re: Based on my inexperienced observation...

[Anonymous Coward]

There's actually some pretty good suggestions in there. There needs to be reform of H-1B and copyright law. We should get rid of patents all together. The TSA is complete bullshit and doesn't secure our transportation. All true.

Here's where you screw up: "Once we have created the master race that supports our principles"

You may not be aware, but the H-1B abuses, the "Intellectual Property" system, and even the TSA, are all for the benefit of the current "master race", all the liver-spotted white male billionaire assholes whose empire runs everything.

A very small, not-at-all-diverse group of people (about 100 of them) "own" all of the wealth in the entire world. If ever there was a "master race", it is these shitheads. What's needed is of course the opposite, true democratic rule, distributed wealth, etc.

Re:Based on my inexperienced observation...

[Anonymous Coward]

It's also one of the worst features of the Node ecosystem. There's nothing quite like seeing how even a small project ends up with five different versions of the same framework because dependencies are apparently too difficult to do properly. And then there's the ten frameworks that do the same thing, just slightly differently because NIH and buzzword compliance, and because abandoning something and starting over is sexier than fixing and maintaining things.

Node may have its uses but holy shit is everything around it terrible.

Re:Based on my inexperienced observation...

[avandesande]

Just keep everyone into one version with package-lock.json file

Re: Based on my inexperienced observation...

[Anonymous Coward]

If you have five different versions of a framework being pulled in, that strongly implies you are choosing packages with questionable architectures. Learning your ecosystem is an important step in taking on any new language.

Re: Based on my inexperienced observation...

[Anonymous Coward]

You never watch Hitler (History) Channel ? It is necessary to use "fatherland" ("Vaterland") for stylistic accuracy of this form of Godwin.

Re:Based on my inexperienced observation...

[Anonymous Coward]

The best part is when you develop something and then turn your back on it for a while. When you inevitably have to come back to it you find half of your dependencies are abandoned by their developers; they moved on to some other fad and what they offer now is not compatible. There is a mountain of abandoned AngularJS stuff because all the cool kids moved to React, for example.

An acronym emerged (complete with a web site, wikipedia page, conferences and everything) and examining it is instructive; MEAN: Mongo, Express, Angular and Node. Mongo isn't a given any longer, if it ever was; relational, cloud and other nosql solutions have been pushing it aside and selecting Mongo today isn't necessarily wise; people are openly hostile toward it for various reasons. Express is obsolete; Koa is the new hotness. Angular is on life support and fading; the user base has fragmented along with the code base (Angular 1, 2, 4...) or left for React. Node is the only part of MEAN stack that still deserves to be included.

Re: Based on my inexperienced observation...

[angel'o'sphere]

Motherland is the land you are born in.
Fatherland is the land you fight for.

A bit absurd, isn't it?

Don't Worry!

[Anonymous Coward]

Don't worry, AI will eat Javascript. nd hopefully, M'Smash too.

Software Is Eating the World, But AI Is Going To Eat Software, Nvidia CEO Says

Re: Don't Worry!

[Anonymous Coward]

Weak,
I was hoping for a goatse link.

Java is like corruption

[Anonymous Coward]

Java is like corruption. It is evil, it should be eradicated, but it won't be. Because the people that could make it disappear are the ones benefiting from it.

Re: Java is like corruption

[Anonymous Coward]

That may be true, but you know Java is not related to JavaScript, right?

Re: Java is like corruption

[tomhath]

You do know that Java was mentioned twice in the summary, right?

Trying to use Java for front-end development is absurd.

Re: Java is like corruption

[angel'o'sphere]

Unless you use Vaadin(GWT), assuming you meant a web frontend.
Or you have a heavy weight client and use Swing/JavaFX.

Re: Java is like corruption

[tepples]

Trying to use Java for front-end development is absurd.

In your opinion, in which language should Minecraft have been written?

Re: Java is like corruption

[bmarkovic]

Lua

It's a JS world now.

[Anonymous Coward]

Agreed. I've noticed a drastic increase in JS use across the web since Windows 10 was released. The problem with JS 10 years ago used to be that the browsers would interpret things differently breaking stuff almost on a monthly basis. The incentive back then to use primarily JS was low due to being high maintenance. Now the roles are reversed. PHP is starting to get out competed by JS frameworks and web sockets. JS can do more and faster in most cases. I remember hoping the world would eventually get to this point with JS 10 years ago. Seems we have arrived.

Node based on Edge?

[alexborges]

What a horrible thought, really. This is Microsoft saying Yup, we would prefer to try and fail to kill any innovation in the web, as per usual. It will be for nothing. Again, again, again.

Re: Node based on Edge?

[cyber-vandal]

Fortunately it's not 2005 when this would be a problem

Becoming John Hipster

[Anonymous Coward]

They really wanted to emphasize that this is a "hipster" language...it reads as if hipster walked into the door on the 7.5th floor, into itself.

Pointy-haired bosses love node.js

[davecb]

It's easier and cheaper to staff with relatively junior .js people than pay for so-called "back end" or "full stack" programmers who know C++/Java/whatever.

In a previous life it was very important that management could hire .js people, as the new budget required they get rid of anyone expensive. Like the chief architect (;-))

Re:Pointy-haired bosses love node.js

[aardvarkjoe]

In a previous life it was very important that management could hire .js people, as the new budget required they get rid of anyone expensive. Like the chief architect (;-))

Our management tells us that "Agile Development" means that anyone can develop anything. Why would we need expensive chief architects anymore?

Re:Pointy-haired bosses love node.js

[Anonymous Coward]

I've seen the work of some of those so-called 'back-end' or 'full-stack' programmers. Comparing C to JS, nowadays, I'll take the JS, even with the sometimes ridiculous debugging or packaging issues. They've remained insignificant compared to debugging some of the steaming piles full-stacks often enough tend to encourage.

Re:Pointy-haired bosses love node.js

[avandesande]

Javascript has been driving most of the functional programming and high level architectures in those languages. It's possible to create crappy/toy code in any language.

Re:Pointy-haired bosses love node.js

[davecb]

In part to say "No Dave, don't add to the main codebase, let's try a microservice instead for that component" (:-))

Re:Pointy-haired bosses love node.js

[Gr8Apes]

It certainly is easier to staff with junior js people. It'll wind up being really expensive down the road, when something major comes up, like changing data or service definitions, or, say, an npm package gets removed.

Re:Pointy-haired bosses love node.js

[HornWumpus]

Because some apps are steaming piles, you're choosing a library that's a steaming pile and expecting to build good, non-steaming pile applications?

I wish I could still muster such optimism.

Re:Pointy-haired bosses love node.js

[Anonymous Coward]

doesnt work yet? You need to FAIL MORE!

Re:Pointy-haired bosses love node.js

[Anonymous Coward]

It's possible to create crappy/toy code in any language.

Too true, just ask APK. He knows all about creating crappy/toy code with lots of bloat. He will even tell you why he thinks a file aggregator needs to be multi-threaded, have DB functionality, plus what ever other bloat is included.

Re:Pointy-haired bosses love node.js

[Anonymous Coward]

dunno man I've done C++ development for almost 2 decades, and Javascript is much harder to master IMO.

Re: Pointy-haired bosses love node.js

[Anonymous Coward]

I'm a bit confused. Aren't most Node.js devs working on "full-stack" or "back-end" development? In my experience, the other stuff gets pushed into the browser stack and is handled by front-end devs, while the Node devs focus on the back end.

Re:Pointy-haired bosses love node.js

[HiThere]

Depends on what you're doing. For some things JavaScript is the easy way to go, for other's it's damn near impossible. Sometimes I can even see *why* they made it so difficult. Would you want an ordinary web page to freely access your hard disk?

Re:Pointy-haired bosses love node.js

[Anonymous Coward]

One man's pile is another man's ticket to ride, I suppose. Apps don't seem to the issue at hand, but rather how they're built. It can be difficult to judge their steaminess while constructing them. I'm certain we could all write good, non-steaming pile applications with any number of languages. There's no rule that says an app written in C should be any more or less difficult to debug than in JS. At the end of the day, I'm putting faith in which ecosystem (pretty sure we're discussing a bit more than simply a library) I've estimated will bring the most happiness to stake holders with the least amount of work/time/etc. No optimism needed, just an iota of hubris.

Re:Pointy-haired bosses love node.js

[HornWumpus]

Nobody 'masters' Javascript until they swear it off. That's the sign of mastery of a pigfuck, running away.

The people that have mastered Javascript are behind 'Web Assembly'. Nobody that's 'mastered' javascript, would ever use it on the server.

Re: Pointy-haired bosses love node.js

[davecb]

They're hiring folks with front-end experience to do server programming, because they're cheaper than folks with back-end experience. The latter usually involves other languages.

Re:Pointy-haired bosses love node.js

[vtcodger]

"Our management tells us that "Agile Development" means that anyone can develop anything. Why would we need expensive chief architects anymore?"

Indeed, why do you need programmers? Management can do the code (agiley of course) in the time they used to spend managing development.

(If it will make you any happier, next year's question is why do you need managers?)

Re:Pointy-haired bosses love node.js

[Darinbob]

Because they add more value than an expensive CEO or CTO?

Re:Pointy-haired bosses love node.js

[Tablizer]

Our management tells us that "Agile Development" means that anyone can develop anything. Why would we need expensive chief architects anymore?

Technically that's true as it can be "hacked into shape" over time. But maintainability likely will be kicked in the nuts. PHB's don't think long term, or else they wouldn't be PHB's.

I was once tasked with maintaining a mostly-CRUD app written in Excel VBA by a non-programmer. Ugly-city. Maintainability matters. The PHB's are either clueless about the cost of maintenance, or hope to get promoted away before their Live-For-Today projects need real maintenance.

Throwaway apps use throwaway platform

[Anonymous Coward]

It is noteable that some major services are using these JS platforms. Could be for several reasons including a glut of code campers who will work for cheap.

But the bulk of software being stamped out these days is not intended to be durable. As such, the tools being used to build it are not necessarily the "future" of anything.

Re:Throwaway apps use throwaway platform

[Anonymous Coward]

But the bulk of software being stamped out these days is not intended to be durable. As such, the tools being used to build it are not necessarily the "future" of anything.

I wish I had a buck for every "temporary solution" which turned out to be rather permanent. Experience tells us that there are LOTS of code out there running well past the time it was supposed to be replaced. All too frequently the problem is that you don't know from the beginning what will soon be replaced and what will live for ever, and not seldom the parts you really want to fix, those held together by duct tape and shoestrings, turns out to be marked "We have no idea how this works, but it's critical! DO NOT TOUCH!".

Re:Throwaway apps use throwaway platform

[infolation]

I thought that was the whole point of agile - that there is no 2.0, there's only 1.0 plus duct tape. Because if you're genuinely aiming for an MVP, the end-goal is just more durable duct tape?

If the requirement is 'throwaway platform' then the manager-deity-on-high didn't properly think through what they really wanted.

Re:Throwaway apps use throwaway platform

[Anonymous Coward]

But the bulk of software being stamped out these days is not intended to be durable. As such, the tools being used to build it are not necessarily the "future" of anything.

I wish I had a buck for every "temporary solution" which turned out to be rather permanent.

I wish I had a buck for every application that was built and then abandoned.

Re:Throwaway apps use throwaway platform

[Anonymous Coward]

If the requirement is 'throwaway platform' then the manager-deity-on-high didn't properly think through what they really wanted.

That isn't the requirement. The requirement is a platform with a ton of built in tools that allow inexperienced (low cost) coders to punch above their weight and reach a wide audience, quickly.

That was the PHP's world's bread-and-butter, but now the market has moved on to the even more stupid-user-friendly JS platforms.

Been developing in NodeJS for 3 years now

[L'Ange Oliver]

Its a great framework. Development is fast. Deployments are even faster. Testing is easy... Sure, Javascript is far from the fastest language, but in our context we delivered many more tools and services than we would have in Java, Php or .NET. Its not perfect of course, but for us the benefits far outweighs the disadvantages. Long live NodeJS.

Re:Been developing in NodeJS for 3 years now

[Billly Gates]

Absolutely easy with no problems at all when needing high performance.

Re:Been developing in NodeJS for 3 years now

[phantomfive]

In echoing your comment I would suggest that everyone try out Node.js to understand what all the hype is about: it's not the quality of the system itself (which is rather garbage), it's the quality of the developer UI. Nice and easy to get stuff done.

Re:Been developing in NodeJS for 3 years now

[Anonymous Coward]

Consider suicide.

Re:Been developing in NodeJS for 3 years now

[ilsaloving]

And this basically summarizes the whole javascript movement.

People don't use it cause it's good.
People use it cause it's easy and fast. You can crank out some shit sandwich of a product very quickly. And that's all that matters.

Javascript today is what Visual Basic was 15 years ago. And 15 years from now, javascript developers will be looked down upon with the same disdain that VB programmers are looked at now. And future people will be stuck picking up the god awful pieces of the resulting mess, having to rewrite/replace everything all over again, just like we had to do with VB applications.

Re:Been developing in NodeJS for 3 years now

[L'Ange Oliver]

So Much For Subtlety

Uhm...

[Casandro]

...there's probably still more electric toothbrushes than webservers. And those don't run Javscript but tiny Assembler programs.

If you use a programming language simply because it's popular, there is a big chance you are using one that's unsuitable to solve your problem.

Re:Uhm...

[Anne Thwacks]

Electric toothbrushes have processors? Next thing, you will tell me they run NetBSD!

Re:Uhm...

[drinkypoo]

No netbsd, but there's a bunch of electric toothbrushes with lcd displays for battery voltage these days, and it's probably cheaper to use a microcontroller than not in that case.

Re:Uhm...

[serviscope_minor]

The Braun ones with no display that just pulse the brush after 2 minutes use a 4 bit uC.

Re:Uhm...

[drinkypoo]

The Braun ones with no display that just pulse the brush after 2 minutes use a 4 bit uC.

That makes sense. If you compare the cost of a timer module and the discrete circuitry needed to implement that, charge cutoff, and also shutoff-during-charging, it's got to be cheaper to slap the microcontroller on there just because of the number of components it replaces.

Re:Uhm...

[serviscope_minor]

Yep. They also added a feature where it gives a small pulse every 30 seconds too. Presumably that was free. I believe it's this family:

http://www.emmicroelectronic.c...

Note that it runs down to 0.9v making it work of single cell NiMH and mask-ROM based.

Re:Uhm...

[vtcodger]

I don't know about you, but my electric toothbrush consists of a motor, some plastic gears, a switch, and a couple of AA batteries. I can't imagine how a processor, much less JS, could provide anything other than aggravation.

Re:Uhm...

[Hognoxious]

But it can't upload your brushing stats to your twitbook timeline so you can receive helpful reminders from targeted dentists!

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

Re:Crystal ball: Defective

[SendBot]

Ha! This is exactly how I feel about it too. Every time I start advocating how nicely it solves all my problems, I preface it by saying how surprised I am that this is the language doing it.

Re:Crystal ball: Defective

[Anonymous Coward]

No no, 90s person, the future we come from makes total sense! Microsoft doesn't want to do operating systems anymore, Apple's switched to making phones, and last year we elected Donald Trump.

P.S. Buy stock in that lame online book store!

Re:Crystal ball: Defective

[h33t l4x0r]

What you people don't understand is that it's not the Javascript you remember. Javascript has evolved more than any 3 programming languages combined. There are literally core language changes every year now. Meanwhile Python can't get users to move to Python 3 which came out 15 years ago or something.

Re:Crystal ball: Defective

[Anonymous Coward]

The world has gone completely fucking batshit.

At least TypeScript (thanks Microsoft - another fucking flip from the 90s there) is a godsend for dealing with the rolling nightmare of Javascript.

Cue all the squealing from limpdick millennial code monkeys about how dynamic types give them freedom. LULZ.

There once was a boy who wrote webCGI.

[Anonymous Coward]

he could output any style or form readable in the oldest webbrowsers and new.

htmlpost was customary intetaction.

and his extendability and portability was a shell call away.

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:Prominent Rubyists moved to Rust.

[s_p_oneil]

I've never had any problem with the Ruby language itself. If you look at what high-level scripting languages like Perl/Python/Ruby are good for (small-to-medium utility scripts, not large systems), I prefer Ruby over the others. The whole concept of the Rails framework was always more hype than substance. IMO Ruby's biggest problem was that most developers never considered it until the Rails hype (probably because there was a much bigger need for web development than for utility scripts).

Re:Prominent Rubyists moved to Rust.

[Anonymous Coward]

Ruby was slow because of the interpreter, dynamic typing, and GC. Rust is a compiled language with no GC, and performs well enough that Mozilla is rewriting parts of Firefox in Rust.

Re:Prominent Rubyists moved to Rust.

[angel'o'sphere]

RAILS, regardless of Groovy on RAILS or Ruby on RAILS has absolutely nothing to do with WEB!
It is about DB access, and automatic mapping of an OO language's objects into a relational data base.

Re:Prominent Rubyists moved to Rust.

[s_p_oneil]

BS. ActiveRecord is about mapping the OO language's objects to a relational database. Rails is a parent project that includes ActiveRecord along with SEVERAL OTHER projects to build a very large (and bloated) MVC web application framework. The part you're referring to is just the "M" of the "MVC" framework. The "V" and the "C" have everything to do with WEB!

WikiPedia's intro paragraph for Rails:

Ruby on Rails, or simply Rails, is a server-side web application framework written in Ruby under the MIT License. Rails is a model–view–controller (MVC) framework, providing default structures for a database, a web service, and web pages. It encourages and facilitates the use of web standards such as JSON or XML for data transfer, and HTML, CSS and JavaScript for display and user interfacing. In addition to MVC, Rails emphasizes the use of other well-known software engineering patterns and paradigms, including convention over configuration (CoC), don't repeat yourself (DRY), and the active record pattern.[4]

Re:Prominent Rubyists moved to Rust.

[angel'o'sphere]

I don't care what Wikipedia claims.
When Rails was invented it was all about DBs, and the web part came much later.

And when you want to throw MVC into the game, the C is on the server, not on the web frontend in the browser. So it has nothing to do with web at all.

Re: Prominent Rubyists moved to Rust.

[s_p_oneil]

Do you really not realize how that sounds? You're basically saying web servers have nothing to do with the web at all, that because it's server-side logic, it's not "web". That's asinine. It's a client-server model. You can't have clients without servers, and those servers need controller logic. Using that logic, you would have to say that node.js web servers have even less to do with the web than rails (since it skips the view logic and primarily serves json), which is also asinine. And it doesn't matter what Rails 0.x started out as, it's what it became.

Re:Prominent Rubyists moved to Rust.

[Darinbob]

Yes, the Ruby language is pretty decent. It's essentially Smalltalk in a textual form, with fewer pimples than a lot of other scripting languages. Ruby on Rails was the hype train, and when it comes to web programming there have been many hype trains.

Re:Prominent Rubyists moved to Rust.

[Tablizer]

It is about DB access, and automatic mapping of an OO language's objects into a relational data base.

And when they don't fit each other, it often creates a mess in performance and/or code. Relational is mostly set-based, and objects are mostly hierarchy-based: these two philosophies don't always jive well.

Sure, if you are skilled enough, you can manage the work-arounds well, but that's true of anything: If you know assembler well enough, you can potentially program circles around the high-level-language people. And I've seen some really productive COBOLers, for example because they knew the language and shop conventions like the back of their hands.

Re:Prominent Rubyists moved to Rust.

[angel'o'sphere]

That is a misconception.

OO models can be mapped 1:1 to relational ones. There are plenty of patterns to achieve that.

The problem comes if you already have an relational DB, which probably evolved and is no longer a pure design, and want to map that to oo.

If you know assembler well enough, you can potentially program circles around the high-level-language people.
In terms of development speed, no. The amount of lines of code you write per day is nearly irrelevant regarding to the language. While I might write 100 lines assembly (which would be quite an achievement) per day, 100 lines C++ or Java implement 10 times more functionality.

And I've seen some really productive COBOLers, for example because they knew the language and shop conventions like the back of their hands.
So do I with C++ and Java ... so what is the point? Accessing CICS systems with COBOL is cooler than using Java and JPA/Hibernate?

Re:Prominent Rubyists moved to Rust.

[Tablizer]

OO models can be mapped 1:1 to relational ones. There are plenty of patterns to achieve that.

Of course they can. It's why I used the word "mostly". Whether it's practical/useful is another matter. OOP is generally based on inheritance and/or composition, which are hierarchical concepts. While OOP can "model" sets, it's not their forte. (AKA, Turing Tarpit.)

The problem comes if you already have an relational DB, which probably evolved and is no longer a pure design, and want to map that to oo.

After several years, usually no design is "pure". Changes often come that don't fit our original abstractions and we have to fudge the design with kludges. True, you can refactor databases and OOP, but most places don't fully bother for various reasons I won't delve into here. Another problem I see is forcing the relational model to look like object models (or OO-centric frameworks), such as using surrogate keys on many-to-many tables and doing joins on the client side to avoid creating another class/object.

100 lines C++ or Java implement 10 times more functionality [than assembler].

Not necessarily. The assembler coder can use clever tricks to save code and use extensive existing libraries to reduce reinvention of the wheel.

So do I with C++ and Java

Maybe you're a whiz at them; that's my point. One can say that if OTHERS are slow in your favorite tool/paradigm that they are just not yet skilled at it and/or dumb. Tools that are otherwise awkward or have huge learning curves to normal/average coders can be "justified" that way. One person is not a good test.

ah

[matushorvath]

Ah, JavaScript. The Visual Basic of our time.
Using a language that everyone can program in just means you will have to deal with a lot of code written by people who don't completely understand how a 'while' cycle works.

Re:ah

[narcc]

Because being easy to use is a bad thing?

If harder is better, why don't we all switch to whitespace or brainfuck? All systems development will be in raw machine code and we'll use base 3 for added complexity.

We'll also start calling loops 'cycles' in honor of your great insight...

Re:ah

[Tablizer]

DLL-Hell aside, VB classic was great for "git'er done" non-critical internal applications. It just was lousy at building API's meant to be used or shared in multiple applications.

Homophobia!

[mi]

Incase you haven't heard the news, JavaScript and NodeJS are single handedly eating the world of software.

Creator of JavaScript is a homophobe, who opposed gay marriage. It is immoral to use it.

Similarly, because the US Constituion and the Pythagoras' Theorem were thought up by slave-owners, it is immoral (and should be illegal!) to use them too!

Re:Homophobia!

[Anonymous Coward]

They're all fornicators. Long live our future robot overlords.

Re:Homophobia!

[Anonymous Coward]

oh look a white male piece of shit who is scared and angry about his fading relevance. good riddance, dipshit!

Javascript responsible for memory hungry apps

[Anonymous Coward]

Web browsers and web based software like electron hoard memory like crazy. A gigabyte of RAM was once reserved for supercomputers, now even the cheapest netbooks have one. We need to force app developers like Mozilla (who rather design silly logos than work on RAM consumption) to document every byte of their usage. We will soon how much is wasted due to fad technologies like javascript and blockchains.

Re:Javascript responsible for memory hungry apps

[Anonymous Coward]

... We need to force app developers ... to document every byte of their usage.

Why?

The world has changed. Memory is now cheap and abundant. It's called progress. Get used to it. In related news, people now live in houses rather than caves.

The first language I learned was FORTRAN, running on a Univac mainframe. We wrote programs on punch cards, sent them to the data center, and got the results a few days later. I also spent a lot of time writing assembly code for Z80's -- I know what living in 16K or 32K of RAM is like. I'm extremely happy I don't have to do those things any more.

Across many fields, there are always groups of people who fetishize the "old school" ways of doing things. Real Programmers and all that. Fine. But be honest about it and recognize that it is just a fetish.

Re: Javascript responsible for memory hungry apps

[that this is not und]

Actually it's a refactoring and a cost reduction. A piece of software running in a sea of cheap memory has 10,000 more places and ways it can fail.

Re:Javascript responsible for memory hungry apps

[vtcodger]

Food. At least in the US, is also cheap and abundant. Doesn't mean that you need to eat 5600 calories a day and try a different candy covered breakfast cereal every morning.

I also started off in the days of FORTRAN and punched cards. Actually, the first computers I programmed used vacuum tubes and were programmed in assembler. I didn't encounter FORTRAN for a number of years.

Up until 2000 or 2005 I agree, I saw immense progress on many fronts. But I have to say that what I've seen for the past decade or so (except for cell phones) looks about as structured, directed, and organized as the Trump presidency..

"PROGRESS" implies a destination. Where on Earth are you folks going? You do have a destination, and hopefully a road map, right? Care to share any information on where this train is going and when it might get there?

When WebAssembly gets the DOM: We're fucked.

[Anonymous Coward]

When WebAssembly gets the DOM: We're fucked.

You thought malware was bad before?

Re:When WebAssembly gets the DOM: We're fucked.

[Luthair]

Why do you think it would be any different than javascript....

Re:When WebAssembly gets the DOM: We're fucked.

[phantomfive]

Webassembly is better than Javascript in terms of security, because the definition is more precise, simpler and clearer. It's easier to correctly sandbox Webassembly than Javascript. It wouldn't be surprising if someday, in order to improve security, the browser just compiled all Javascript to Webassembly because of security reasons.

Re:When WebAssembly gets the DOM: We're fucked.

[Anonymous Coward]

I've heard this argument before, back in the late 1990s. But back then it went something like:

Java applets are better than Javascript in terms of security, because the definition is more precise, simpler and clearer. It's easier to correctly sandbox Java applets than Javascript. It wouldn't be surprising if someday, in order to improve security, the browser just compiled all Javascript to Java applets because of security reasons.

Re:When WebAssembly gets the DOM: We're fucked.

[phantomfive]

I lived through the 1990s, and I don't remember anyone saying that applets were better than Javascript in terms of security.
What makes you think Javascript is so secure? It's not.

Re:When WebAssembly gets the DOM: We're fucked.

[bondsbw]

I lived through the 1990s, and I don't remember anyone saying much of anything about security.

Re:When WebAssembly gets the DOM: We're fucked.

[rholtzjr]

Now THAT is an accurate statement. It was however something we always took serious as it was an FDA and later HIPAA requirement for medical devices. But alas, reading about some the the vulnerabilities in today's devices, I think they have been asleep at the wheel. Plus, who in their right mind would want to change someone else's heart rate remotely other than for nefarious reasons.

Rendering engine?

[cgimusic]

> based on the V8 JS rendering engine found in Google Chrome What's a "JS rendering engine". You don't "render" JavaScript.

Re:Rendering engine?

[Anne Thwacks]

You don't "render" JavaScript.

So what is it called when the CIA illegally drag JS, kicking and screaming, into another country, in the middle of the night?

Re:Rendering engine?

[OrangeTide]

Maybe you want to render it so you can print out the source? Does a2ps do syntax highlighting for JavaScript, it'd be especially handy if it could do a little extra for jQuery-like APIs.

Why not Python?

[Anonymous Coward]

Python, with it's massive and robust package library, has a lot to offer on both the client and server side.

Re:Why not Python?

[Anonymous Coward]

Have they settled on the syntax for print statements yet? I heard Python had some nice features, but the reference books all say "This was done in a different way in version 2.0," and version pain is a real thing.

Re:Why not Python?

[HiThere]

You're being silly. That print statement thing was easy to be compatible between versions. (The 3.x versions make print a standard function, so you need to remember the parenthesis, but you can use them in 2.x.)

If you want to complain about something that really changed significantly, talk about string representation. That causes some real problems.

Re:Why not Python?

[vtcodger]

Close enough I guess. Sometimes you really want print to be a function rather than a language element so you can, for example, print using a list comprehension. To do that in Python 2, you actually have to define a function (e.g. "def prnt(x): print x", then print using a call to prnt("I wish I'd never heard of Javascript"). But you're right. It's not a big deal.

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:Is it just because it's easy?

[Anonymous Coward]

The reason "rich client applications" are falling out of favor is the shattering of the Microsoft monopoly. Windows desktops, Windows fondleslabs, MacOS, iOS, Android, Chromebooks, full GNU/Linux... the web is the only thing that even has a prayer of being deployed to all of these, across five CPU architectures (i386, amd64, armv7/32, armv8/64, MIPS Android phones). Ironically the other broad target is an open source ncurses or CLI application, especially with the Windows console getting VT100/ANSI support.

Re:Is it just because it's easy?

[Anonymous Coward]

JS is really being extended way beyond what it was ever meant to do.

is there a technology out there that you can't say this about?

did von braun intend for his rockets to be used for placing satellites for facebook?

do you think the inventors of TCP/IP were thinking about netflix and amazon?

Re:Is it just because it's easy?

[Anonymous Coward]

...while they load 11,304,283 snippets of code from different hosted libraries.

That, right there is why I still like using Firefox with NoScript. Granted, most the webpages I surf to look pretty terrible or only half function with this setup, I get the important information which is usually a news article. The pictures usually don't load, ads don't load unless locally hosted and all and all like is good.

Occasionally I am forced to use Chrome because some websites just don't like not being able to run cross scripts or some other feature that gets blocked. Citibank comes to mind as the #1 offender. I do love their site's functionality in Chrome though.

it's not the language

[qQ7eBMsfM5gs]

IMO it's not the language itself, it's the life time and complexity of applications: there is a a little value in developing a well designed and thought through application when its life time will be weeks and its doesn't do anything but parse a trivial request and fetch something simple from the storage.

Stitching together something that "just works" using the (almost) same set of tools as the UI is much easier.

The trend towards simplified stateless cloud-based backends is to blame.

Can't imagine javascript will survive

[Anonymous Coward]

Javascript is truly an awful language for developing an application of any real scale. If you depend on any of the third party modules, you better be ready to take over maintenance in future. Coupled with the awful design of major components like React, I really do wonder who is actually making the decisions to burden themselves with this nightmare. At least with web assembly, we will be able to use a sensible language that is not tainted by javascript semantics. I think when web assembly becomes more popular, javascript will sink pretty quickly. I just can't imagine why anyone would worth with such an unprofessional, and truly regressive toolchain and libraries.

Too funny

[Anonymous Coward]

I remember interviewing for jobs in the early 2000s and when given the choice of language to use, I'd often pick JavaScript, and the companies would be like "LOL WTF JavaScript?"

Fuckers!

Not the software world

[Anonymous Coward]

Why do people keep equating enterprise web stuff with "the world of software" sigh. It's not. After coding JS for a long long time I am happy to be back doing C again. Long live C!

Why JavaScript? Because optimization!

[Anonymous Coward]

I can't remember where I read this, but I agree 100%:

JavaScript is in every web browser, and the web browser is the way that most people interact with computers these days. Because of this, the industry has devoted, and will continue to devote, massive amounts of resources at optimizing JavaScript implementations. No other language, not even C/C++, is going to get that level of industry-wide effort.

It doesn't matter that JavaScript is a flawed language. It doesn't matter that some of it's features almost guarantee inefficient execution. The effort will be made to make it work.

So fastly, you can hardly fathomy the bigliness

[Krakadoom]

Fastly? Since when is Trump writing summaries for Slashdot?

Re:So fastly, you can hardly fathomy the bigliness

[Anonymous Coward]

I'm so glad I wasn't the only one that got caught up on that.

Re:So fastly, you can hardly fathomy the bigliness

[michael_wojcik]

Not to mention "incase" as a compound rather than a phrase, "JavaScript and NodeJS [sic] are single-handedly" (what, one hand between the two of them?), and assorted other infelicities. But then "dubious summary by a marginal writer" is pretty much par for the course.

Re:So fastly, you can hardly fathomy the bigliness

[Tablizer]

Fastly? Since when is Trump writing summaries for Slashdot?

Trump sets trends for good or bad because he's in the news so often. When W was in office, people often copied his style also:

"The trumpificationism of linguistical discussionificationism has increasified."

Whether trump-speak lasts or not is another matter. Imagine the speech of their offspring if the 2 mated:

"I'm the bestified at speakificationism, believify me! The ratingnizing people givefy me biglified top resultifications. Huuugitized! I know more wordations than losercated English teachifiers! So sadditudes. #MAGAFICATE!"

Re:So fastly, you can hardly fathomy the bigliness

[Anonymous Coward]

Imagine the speech of their offspring if [W & Trump] mated

He/she would invade a random country and make them pay for the wall.

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:I'm a long time C programmer

[Anonymous Coward]

When the primary purpose of writing software is to solve problems, getting something going in short order has value.

But then it grows. And has to be maintained.

Re:I'm a long time C programmer

[OrangeTide]

But then it grows. And has to be maintained.

It is inevitable that a project grows as requirements are added or changed. The ease or difficulty of maintenance has more to do with the author's organizational skills than with the programming language itself. Certainly there are tools that can help, but spaghetti C is no better or worse than spaghetti JavaScript.

Re:I'm a long time C programmer

[Anonymous Coward]

spaghetti C is no better or worse than spaghetti JavaScript.

True, but at least it's type safe. I can't take any language seriously that doesn't at least have type safety.

I can look at a piece of C code and figure out what it does. To fix or maintain anything in JavaScript involves stepping through with a debugger just to figure out what it does. And that can change entirely based on the context and the types of arguments (unchecked, of course).

I hate JavaScript. Of course, I'm basically a JavaScript developer now because that's all my clients want.

Re:I'm a long time C programmer

[OrangeTide]

True, but at least it's type safe. I can't take any language seriously that doesn't at least have type safety.

But JavaScript has run-time dynamic types, I can't take a language seriously that doesn't at least have compile-time static checking. I prefer to know in advance that my program is illegal instead of finding out at run-time. Turning many parser bugs into an exercise in run-time debugging is frustrating.

Ultimately these are just tools. You could argue that you would never use a hammer without a claw, but a ball-peen hammer is quite useful in some situations. I guess it depends on if you do a lot of building construction or if you install a lot of rivets in another craft.

Re:I'm a long time C programmer

[angel'o'sphere]

Dynamic typed languages have their benefits, too.
I also grew up with static typed languages, and preferred them because I make easy typos. However IDEs are getting better and flag typos in dynamic typed languages.
Consider that programming in assembly basically is untyped ... on the other hand dynamic typed languages only make sense if the runtime environment is solid, e.g. SmallTalk ... JS is ok, but everything below objects (ints, strings, booleans) is error prone.

Re:I'm a long time C programmer

[OrangeTide]

I also grew up with static typed languages, and preferred them because I make easy typos. However IDEs are getting better and flag typos in dynamic typed languages.

I use a lot of safety and static analysis for C in my job. So tools do compensate for the lack of type safety in C, just like tools compensate for the limitation of run time typing. That said, I think if I got to pick I'd prefer doing projects in ML-family or maybe SmallTalk over JavaScript or even C.

Re:I'm a long time C programmer

[Anonymous Coward]

True, but at least it's type safe. I can't take any language seriously that doesn't at least have type safety.

But JavaScript has run-time dynamic types, I can't take a language seriously that doesn't at least have compile-time static checking. I prefer to know in advance that my program is illegal instead of finding out at run-time. Turning many parser bugs into an exercise in run-time debugging is frustrating.

Ultimately these are just tools. You could argue that you would never use a hammer without a claw, but a ball-peen hammer is quite useful in some situations. I guess it depends on if you do a lot of building construction or if you install a lot of rivets in another craft.

Then use elm or typescript.

Re:I'm a long time C programmer

[hoggoth]

> I have a fondness for FORTH
FORTH for fondness I have

The only language written in Yoda's native tongue.

Logo is the better choice

[Anonymous Coward]

Algol syntax is cumbersome and limited. Where as Logo is based on LISP and has some very powerful built-in datatypes.

Re:Logo is the better choice

[HiThere]

You were never an Algol programmer, either that or you never used Logo. The syntax of Logo seems simple until you try to use it for something a bit complicated. The syntax of Algol *is* simple. OTOH it doesn't have many standard libraries, which make it so limited it's basically useless except for instruction. (It could have, but the designers intentionally stripped out basic features without moving them into standard libraries. Whoops! [They moved them into libraries, but didn't standardize them. So you got all sorts of dialect differences almost immediately.])

FWIW, I rather liked BC-Algol, but debugging was horrible. But when compared to Fortran it was lamentably lacking in libraries.

Re: Logo is the better choice

[tigersha]

Wow, a live one. Was Algol seriously ever implemented for real?

Re: Logo is the better choice

[Anonymous Coward]

Before Bell labs foisted their insecure-by-design Unix onto The Worldwide, ich, unisys and mcst Had entire mainframes programmed in algol.

Blame your mcEducation for your Lack of knowledge.

Re: Logo is the better choice

[CRConrad]

Hello, Ross!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:JavaScript should Flash

[Marxist Hacker 42]

Exactly right. It is the most bandwidth intensive way possible to do anything. If browsers had supported something more lightweight, say a compiled language instead of a cruddy interpreter, then perhaps we'd have something, but as it is, NO, I don't want to download 6 GB of javacript to my phone to see your cat video.

Clickbait alert

[InterBigs]

While I hate Javascript as much as the next guy and I love the title, this article is full of errors, misconceptions and spelling mistakes. Not worth your time.

Node.js sucks

[Billly Gates]

I maybe in the minority with the young hipsters, but this summarizes my thoughts on Node.js from the same guy who did nosql webscales video where he pointed out non SQL databases don't have data protection or integrity.

Basically the video states node.js has the complexities of assembler with the syntax of javascript. You have to write your own freaking threads with callback after callback loop. Why?? It makes no sense in 2017 where NGINX has async threading models built in. Javascript is bad language too and while node.js looks cool for simple things if you already know Javascript it gets sucky very very quickly when you need something complex.

So why build your own multitasking when you can use built in threads?

Re:Node.js sucks

[phantomfive]

How do you use NGINX? (Serious question, I'm trying to understand the uses people have for it).

Re:Node.js sucks

[Anonymous Coward]

Last time I checked there was NO need for more than one thread in Node.js to service thousands of concurrent clients. Thats why there is an asynchronous event loop and all global variables do not require locks

So why use multitasking when you do not need it?

Re:Node.js sucks

[avandesande]

just use typescript

Re:Node.js sucks

[ilsaloving]

nginx was a great low-footprint option for when apache was total overkill.

It was originally designed to act purely as a proxy server, and it does that function *fantastically* well with very low resources. This is because it used a strict event-based model that only spawned processes as requests came in.

Since it's inception, it's grown more powerful and you can also use it for serving sites and applications as well, so it can do a majority of what Apache is. You'd have to google for an actual comparison article if you want a really detailed analysis, but that's the jist of it.

That being said, Apache caught up and released their own event-driven processing engine that you can choose to use with a configuration setting. I haven't evaluated it myself, personally, cause I am satisfied with what nginx can do and don't see any point making an effort to switch back for proxy tasks.

AFAIK, Apache is still the king though when it comes to actually hosting sites that run non-java application code (ie: php, etc).

Re:Node.js sucks

[Anonymous Coward]

Easy, install it. Then notice a 50% increase in your web server speed.

That wasn't so hard was it?

advertisement or not?

[Anonymous Coward]

How much did Joyent pay for this advertisement?

Will always be a "hipster" framework

[Anonymous Coward]

FTFY. Javascript and NodeJS are terrible platforms. I write Javascript code quite regularly and hate quite a bit of it. jQuery, which seems to have fallen into disfavor with da hipsters, takes off some of the edge but browser vendors will never agree on anything. Vanilla JS is like running around having sex with everything that has a hole only to discover that you basically rewrote an inferior jQuery (but, hey, at least you didn't use jQuery, amiright?). The latest fad terminology is "feature detection" which just means "We suck at writing sane software so you and your users get to suffer. Also, we'll inexplicably break this feature in about 6 months so you'll have to work around it." Let's call the entire mess what it is: Broken software. My philosophy is to NOT use broken software unless I absolutely have to because maintaining sanity is a good idea. What a novel idea!

NodeJS is crap. It's a massive, bloated memory hog that is insecure, you can't do anything in it that you can already do in other languages, and it only becomes useful once you drag in enough libraries (aka packages) to power an entire OS. Put 5 NodeJS instances on a single virtual and the host OS will be begging you to have mercy. Also, just because Node is "cross-platform" doesn't mean that applications written in it are actually cross-platform (Hint: They aren't).

Grunt (Node) and SASS (Ruby) are the worst. Ignoring the fact that those tools run slower than molasses on a 6th generation i7, whoever came up with the idea to "compile" Javascript and CSS should be shot. Anyone making the decision to use those two technologies should also similarly be shot. Whoever runs the npm website should be shot, set on fire, and then nuked from orbit just to be sure. And, of course, never permitted to write software ever again.

Also, just because a company like Google uses something doesn't mean it is GOOD. After all, Google gave us Android. Unfortunately, to write Android apps requires writing Java. Java was pretty much on its deathbed until Google did that because Oracle was doing a fantastic job of killing it off after they bought out Sun Microsystems. That was the only good thing to ever happen to Java. Java abuses Exceptions in so many ways you pretty much have to wrap your entire Android application in a giant try-catch so it won't crash. Java lacks several critical object-oriented features from other languages that violates DRY in painful ways. Java is one of the worst languages out there to pick for the underpinnings of an entire OS. Maybe using the JVM allowed Google to get to market quickly, but now we are stuck with a terrible ecosystem just under the hood. And that's just one example of using something internally and it being a terrible long-term decision.

Re:Will always be a "hipster" framework

[TheDarkMaster]

You can do some good applications on Java if you bravely (and insistently) resist the idea of filling the code with abstractions, layers and more layers of classes, "factories" and so on. Why you would make your code with ten+ layers of classes between the user input and the object that actually does the job, when you can do the same work with two classes (or less)?

By Neruos

[Anonymous Coward]

NODEJS IS NOT EATING SHYT.

stop pushing these lame agendas. nodejs is dead. move on.

One Language For All? [Re:Ruby]

[Tablizer]

By the same argument, butt sex is better because everybody can participate...Javascript is a shitty language...

+5 analogy for "one language for entire stack" argument! Kudos & LOL.

While I do have many qualms about JavaScript (JS), a bigger problem is that different kinds of languages better fit different needs. JS is okay as a light-weight glue language, but should NOT be used to write lower-level API's and services that need a compiled/strong-typed (CST) language for performance and the safety of type-checking.

Low-level components/layers that higher levels such as app-specific logic rely on should generally be CST. If you think of applications as an onion with OS, compiler/interpreter and databases being the core, middle-ware libraries the middle layers, and application business logic the outer layers, then the closer to the core you are, the more "anal" the language you need for speed and reliability, thus CST. JS is best for the outer layers where too bureaucratic of a language slows progress, especially in-house apps for non-key tasks that wont kill anybody if they break. I doubt there will ever be a one-size-fits-all language.

(Although, others and I have kicked around the idea of a language that can be strong and weak typed based on configuration switches that can be applied to the entire application or a specific module, and specific parameters can be still be verified as requested. It's almost comparable to using the type "object" in C# by default if weak mode is on, but without the need to actually state "object". Another approach is "soft compilation", but that would take a long time to explain. Also, I realize there are existing interpreted strong-typed languages, but for various reasons that combo has not been successful.)

Not new

[HongoBelando]

Hardly new. Around 1998 I was using Netscape Enterprise Server with Server Side Javascript. It integrated easily with Oracle (and probably other RDBMS). Certainly the JS engine was a bit fragile and could bring the whole server down, but it was also 20 years ago.

Javascript ...

[Anonymous Coward]

for when you have no talent but want to be a silicon valley "bro".

No quicker way to lose respect that say you are a competent "javascript" coder

But you do you.

FUCK Javascript

[Anonymous Coward]

Kill it with fire

I'll stick with static typing...C# .NET Core, Java Spring.Boot, etc...if I had to do something front-end, I'd use TypeScript, but no way in hell that javascript shit we're forced to use on the front end is going on my backend.

Size of your world

[Anonymous Coward]

> eating the world of software

For anyone under 20 maybe.

That word, it does not mean...

[Anonymous Coward]

JavaScript and NodeJS are single handedly eating the world

<Inigo Montoya />

Well-designed libraries and easy to scale

[mveloso]

I've been using node for about a year. What's it good at? Glue. It's awesome at being glue. It's mind-numbingly easy to put something together that can handle 40k messages a minute on one thread.

The libraries are well-designed, are documented, have good error handling, and make sense. Most of the packages seem to be written by experienced developers who don't have retarded APIs or naming conventions. They're very task-oriented and don't have a lot of extra crap in them.

As an example, you can build an SNMP poller in about a day or two that could replace HPOV/NetView. That's pretty good. And you could do it using one xeon core.

Re:Well-designed libraries and easy to scale

[Anonymous Coward]

Handling 40k messages per minute is an achievement? Try millions or hundreds of thousands messages per seconds: http://zeromq.org/results:ib-tests-v206

Many here prefer "a return trip to the server"

[tepples]

It appears a lot of Slashdot users oppose script-in-the-browser to such an extent that they would prefer "a return trip to the server" to automatic execution of unvetted proprietary third-party code. And as for "a validation error message at a conveniant time", they consider the inconvenience of waiting for form submission to be worth the increased security arising from less third-party code on their machines.

Re:Many here prefer "a return trip to the server"

[nedlohs]

And they can turn off javascript and get the behavior they want, without affecting those who prefer less latency. So I'm not sure how that is an argument against benefiting the other users.

Re: Ruby perl

[Anonymous Coward]

too bad..

JS ???

[Tom]

Wasn't JavaScript this buggy hack that you can't use to run anything real (bad PNRG) and that was originally designed to make scrolling text before the devil replaced it with the marquee tag?

Maybe things have changed, but the last time I did work with JS, it still felt like a supersized tool that adults shouldn't be using. Did I miss some fundamental changes to the language, or has the other half of the world gone crazy?

C++ + Qt instead of JavaScript + HTML DOM

[tepples]

Windows desktops, Windows fondleslabs, MacOS, iOS, Android, Chromebooks, full GNU/Linux... the web is the only thing that even has a prayer of being deployed to all of these, across five CPU architectures (i386, amd64, armv7/32, armv8/64, MIPS Android phones).

That or a native application written with Qt and compiled for Win32, UWP, macOS, iOS, Android, NaCl, and GNU/Linux respectively, leaving out only Chromebooks. Even if you were developing a web application, you would need to buy the full set of hardware anyway in order to test it on all platforms, including the many quirks of the Mac and iOS versions of Safari.

XY problem much?

[tepples]

everyone uses javascript because they have no other choice for the job (code running in the browser)

The job is not "code running in the browser". The job is "code running on client computers". This can be done without JavaScript by producing a native app and building it for each of Windows, macOS, GNU/Linux, iOS, and Android.

Re:XY problem much?

[TheDarkMaster]

You understood what I meant. I I emphasized the part of the "code in the browser" exactly because if I wanted to do something that works outside of a browser I would have done that using a conventional desktop application.

Re:XY problem much?

[tepples]

My point is that some users choose not to run code in the browser in the first place. What makes this not a valid choice?

Re:XY problem much?

[suutar]

It's not invalid, but it's not the job in question. The job in question is specced as "something running in a browser". Sure, there's folks who won't use the product because of that, but they're not the target market. There's a proposal to put together a different group to address that market, but management's not sure it's big enough to be worth the investment, so it's not funded quite yet...

Re:XY problem much?

[TheDarkMaster]

I believe that the suutar answered your question well enough

Is 'rocketly' 'speedily' 'fastly' 'quickly'

[Anonymous Coward]

... in hipsterese? Given the writing, is it possible to take this article seriously?

WebScale guy is old news

[mveloso]

While amusing, that video is pretty out of date.

Today you can choose the level of data integrity and data protection that you want. If you don't understand why you would want to do that then you can come back in a few years.

Hi, Ross!

[CRConrad]

(No, I didn't forget to write my comment. It's in the headline above.)

Heard this story before

[jargonburn]

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

*Face contorted in a horrified grimace* Run! Run, you fools! RUNNN!!!!!!

Hi, Bryce!

[CRConrad]

"Re: Ruby", Yadda yadda.

"Designed by a guy who..."

[CRConrad]

Not necessarily; maybe only between men. We don't know what Brendan gets up to with the missus.

Ah, but then, "the Motherland"...

[CRConrad]

...is also a WW2 reference, namely to the country that actually beat the Nazis: the Rodina.

MVC origin [Re: Prominent Rubyists moved to Rust.]

[Tablizer]

MVC was "invented" for client/server systems, if I'm not mistaking, or at least used heavily for client/server before moving to web. Thus, its association with web-ness is weak at best.

GUI Rant [Re:Is it just because it's easy?]

[Tablizer]

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...

The browser has become a rich/fat-client, it just sucks at it because it wasn't originally designed for it, and hacked up over time to fake it.

For "productivity" applications (brochure-ware excluded), desktop UI idioms are still preferred. But we have to bend over backward to get HTML-browser/DOM to act like a (non-fucked-up) desktop, with lots of blood, sweat, tears. It's ugly compared to desktop/CRUD development in say Delphi, Powerbuilder, etc.

What's needed is a new GUI-friendly standard that works decently over HTTP/HTTPS. We should take the best lessons from Java applets, Flash, X-Windows etc., discard the worse parts, and try to get a real GUI standard for once.

Some suggestions:

* Do most of the positioning calculations on the server side to avoid complex "flow" calculations on the client (which end up varying too much per browser brand/version). Perhaps put the "flow engine" on the server and have the client merely render "dumb" vectors as coordinates (pixels or panel percents). The client sends its screen size preferences to the server rather than let the client-side do the "fit" calcs on the browser (client).

* Allow font sizing with a maximum containment box such that fonts are rendered smaller if necessary (at least on the X axis) in order to guarantee a fit in a designated containment box. Overlapping element errors are common in CSS/JS-centric frameworks, largely because testers don't test in a wide enough variety of clients/versions/OS-DPI settings.

* Don't make the client an OS or OS-like thing. This is largely Java's mistake: they bit off more than they could chew. Focus on GUI's and KISS. Most the app activity should be on the server.

* Allow flexible "skinning" to keep up with style Joneses. You have to keep up with the look styles to not get ignored, unfortunately. (I have some ideas for graphic (image) background skinning that are flexible but relatively simple that allow changing the visual styles without breaking the complexity bank.)

* Allow optional client-side scripting, but try not to over-do reliance on it. If a UI pattern(s) emerges, then build that pattern into the standard.