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

[matushorvath]

The only reason everyone uses JavaScript in the browser is that it is the only language supported by major browsers. If browsers supported Visual Basic instead, everyone would be using Visual Basic. There is no choice. The popularity of JavaScript under these circumstances is no measure of the quality of the language. There was no "test of time", since there was no competition.

Re:JavaScript should replace C

[shaitand]

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

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

[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

[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

[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

[that this is not und]

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

Re: JavaScript should replace C

[tonywestonuk]

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

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

[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

[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

[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

[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

[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

[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

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

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

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

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

[avandesande]

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

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

[davecb]

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

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.

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.

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

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.

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

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.

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.

So fastly, you can hardly fathomy the bigliness

[Krakadoom]

Fastly? Since when is Trump writing summaries for Slashdot?

I'm a long time C programmer

[OrangeTide]

I'm primarily an embedded/kernel developer, and I've been using C for decades. Normally I'm pretty strongly in favor of using C. But I readily admit that you can throw together a project in NodeJS very quickly. There isn't much revolutionary about NodeJS, other than it is packaged nicely and is easy to use. When the primary purpose of writing software is to solve problems, getting something going in short order has value.

I grew up on BASIC, but JavaScript is so ubiquitous and is not terribly hard to learn that I would recommend it as a first language over anything else. (Ideally you should learn multiple languages as you advance, as they each have their own advantages and quirks)

PS - I have a fondness for FORTH that may never go away, even if I will likely never again get to use it in a professional project. R.I.P. OpenFirmware

Re:JavaScript should 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.

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

[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: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: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)?

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.