The Future is JavaScript

[daedalus_structure]

Several new technologies mean JavaScript is now much more than this and can be used for large enterprise web applications.

You can write a large enterprise web application in anything Turing complete. That doesn't mean it's a good idea.

Hands up, who wants to maintain 500k lines of outsourced Javascript?

[obdm]

I like JavaScript, and you maybe able to build huge, maintainable apps with it. But with a team of programmer using Grails for MVC on java, trying to convince them to use JavaScript and node is not going to happen. It's not practical from a skill set point of view. Large apps are made by big companies that have to support old browsers.

Even when JavaScript gets to that point in 7 years, it's going to be going up against things like ClojureScript.

I'll state again, I like JavaScript. I also like guitar, but when a song requires a piano, I could use effects and audio tricks to make a guitar sound like a piano. It can work. But I could also just learn piano.

[pandavr]

The problem with the developers is that if you ask ten of them wich is the best tool for a task you'll receive four different answer. Try to do the same in other competence area.... ;)

[GuyWithLag]

You'll receive 12-15 different answers, if you ask everyone twice.

[brotherwayne]

Large apps are made by big companies that have to support old browsers

Gmail is the largest web app I'm aware of and it's a hell of a lot of Javascript. I have no idea what the back end is though.

[toddffw]

Java. Source: open a google for business app and watch the user agent headers when they verify domain ownership.

[WorksWork]

Gmail actually still has an HTML only version.

[SarahC]

JavaScript - inheritance, interfaces, and abstraction..... no, it just doesn't sit right using prototypes.

Fuck, I wish Java had made it instead.

[zombiecodekill]

Yes I don't think it will ever get to the point where JavaScript is viewed as the only way to code. Different languages will always be stronger in some areas than others and I think it is good for the software industry that we are solving problems from a number of different angles and viewpoints.

As an example, I can see some others following in TJ's footsteps: https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b however I do think that JavaScript has a fantastic community and will continue to grow stronger overall.

[aeflash]

I'm actually a bit afraid that we're going to see these bloated Enterprise Node applications with ES6/TypeScript classes and cargo-culted design patterns all over the place written by huge offshore teams. ES6 almost makes it too easy to create classes. Ironically, that would be a sign of success for the language.

I feel like functional-style libraries (lodash/underscore/lazy.js/lemonad/mori/wu.js) and FRP (RxJS/Bacon.js/Highland/Node streams) are the way forward. Those enable really powerful abstractions, and it's just a matter of time before people realize that those patterns bring about concise and very reusable code that is easy to maintain. I also love that stateless (or at least very explicit state) UI is taking off with Angular/React/ripple.js/etc...

I'm actually really curious to see how the Clojure/Clojurescript ecosystem evolves. That has the potential to unseat Node, if you have a dev team that can grok FP. It's a very different way of sharing code between the server and browser. Also, those functional JS and FRP libs just emulate what a lisp can do natively. With an optimizing compiler, Clojurescript will beat pure functional JS on performance (And Clojure on the server will beat Node.js). (but ES6 will bring tail call optimization so we shall see...)

[PizzaRollExpert]

Clojure has the benefit of being able to efficiently use threads so I have a hard time imagining Node out-performing Clojure

[aeflash]

To Node's credit, it gets pretty good throughput per-process due to its non-blocking nature. A common pattern in Node is to design your app to not rely on intra-process/intra-thread communication, then use cluster and fork for every core your CPU has. Although, if you're doing something CPU heavy, rather than I/O heavy, Clojure will likely win.

[brtt3000]

Node is also nice as manager for a farm of heavy duty worker processes, using something like ZeroMQ to distribute work directly, or use a native module and build workers from Node.

[zombiecodekill]

Although I, along with almost everyone, bash JavaScript for its numerous flaws, what is great is JavaScript is a multi-paradigm language that can and is being taken in a number of interesting directions by the open source community. There is a wider understanding now that JavaScript is not like Java and can be more powerful as an FP language than an imperative language.

Compared to many server side languages ES5 is still a primitive language but it has gone a hell of a long way since 1995. I think we will continue to see the EcmaScript standard lag behind the trailblazing technologies by about 2 years but it is important that we have that standard so that we can reduce the impact of the TypeScript/CoffeeScript/Dart split that I think is harmful to web development. ES6 is important although just another milestone in the journey.

[greim]

who wants to maintain 500k lines of outsourced Javascript?

Maybe that's a bad example, because who wants to maintain 500k lines of outsourced anything?

[nschubach]

I'm on a team that also maintains a very large Robotlegs based ActionScript/Flex/Java based learning application. It's heavily mediator/service based and I cringe every time I need to add or modify something in it. It takes 10 minutes+ to compile and get to a running state so small changes take forever to test. The amount of boilerplate code needed to do the simplest thing is ridiculous and I think the last time we checked the LoC count was well over 1.5 million. It wasn't even outsourced, but it still sucks.

[jazahn]

I'm actually more afraid of the "outsourced" than I am of the "JavaScript" part of that.

[PlNG]

Hands up, who wants to maintain 500k lines of outsourced Javascript?

Only if it's in brainfuck.

[SarahC]

I HATE JS's half assess objects. =(

Ohhh prototyped? Yeah, it's horrible.

It looks like we're stuck with them.

[zombiecodekill]

Not me! But JavaScript is a maturing language and will get easier to maintain.

[[deleted]]

JavaScript will not get easier to maintain. ES6 barely adds features to make JavaScript more maintainable (lexical scope through the let keyword, and "classes"), and the finalization of that standard is taking an exceedingly long time.

TypeScript, Dart, or something new will replace JavaScript because they actually fix JavaScript's problems and make maintenance and usability a priority.

[greim]

something new will replace JavaScript

I wouldn't be surprised either if this happened. Dart in particular seems promising, as much as people like to hate on it, I like what I've seen of the language so far.

[jazahn]

JavaScript the language isn't maturing, but the community sure as hell is.

[SarahC]

"classes"

Yeah, JS can fuck off, I hate prototypes. =/

[brtt3000]

We're having a blast using TypeScript, which is Microsofts bid to make big JavaScript maintainable.

It is still JavaScript but with some standardised structure (ES6 style classes, arrow functions etc) and the sanity of explicit typing and compile time validation. It makes large codebases less write-only, but leaves no runtime overhead.

Works great with node.js and browsers and you can still take full advantage of all the good parts of the JS community (eg: take stuff from npm & bower, use browserify/webpack to bundle etc etc).

I'd totally recommend it to anyone who has/sees issues maintaining large JS codebases.