2015 will be remembered as the year of the Javascript Fatigue.

Saul: “How’s it going?”
Me: “Fatigued.”
Saul: “Family?”
Me: “No, Javascript.”

Eric Clemmons, Javascript Fatigue

History.js: where and when all started

When Brendan Eich developed JavaScript for Netscape in just 10 days, JavaScript was introduced as a simple scripting language which could essentially affect the layout of an html document and respond to user input.

Netscape wanted a lightweight interpreted language that would complement Java by appealing to nonprofessional programmers

From the Wikipedia page about JavaScript

… and some of the weird quirks of the language continues to stick today like the absence of real inheritance (instead, see “object delegation”), weird bugs like typeof null === “object” // true, the choice of going full IEEE 754 0.1 + 0.2 === 0.3 // false etc…

Hello, Node!

To some, the big game changer was Gmail in demonstrating the potentialities of the language and, of course, Node proceeded by a wise decision by Google to open-source its V8 engine (kudos). Once I/O blocking was solved (well… delegated and sent back to the event-loop), the doors were wide open for more serious consideration but, first, JavaScript had to evolve into something more mature. This is why ECMA’s work on the ECMAScript is becoming more intense with new releases of the standard expected almost every year.

The most important thing to notice here is that, although JavaScript has formally nothing to do with Java, it shares a common dream: the code-once, run-everywhere programming language (GWT, anyone?). While some didn’t even tried to do it (.NET) and some did become os-independent, the web and especially the rise of SPAs added a new requirement: running code in the browser. Here comes Node to the rescue. Prior to it, JavaScript could only run on the client but now that barrier had fallen down.

There is also another thing to keep in mind: JavaScript is not strictly a “project” nor a “programming language”. It is a specification of a standard and there are many implementationsof it. So, being a standard, it is open although not open-source. Some JS Engines are open-source, like Google’s V8, Mozilla’s SpiderMonkey and Microsoft’s Chakra-core. This is important, because JavaScript is not controlled by a single-corporation, instead it is “maintained” by an international committee.

although JavaScript has formally nothing to do with Java, it shares a common dream: the code-once, run-everywhere programming language

Back to the point. Node is not only “JavaScript on the server”. It brings a disruptive client-side single-threaded process to the server-side enabling non-blocking I/O calls.

The absence of a standard framework

Although extremely powerful, Node has a community problem: there’s not a Django-like or a Ruby-on-Rails-like framework that is considered standard. Some might say that Express is the de-facto web framework to use in Node, but it is highly unopinionated and doesn’t solve common boilerplate and repetitive tasks. Community-wise, Node looks much more like the PHP ecosystem with all its Laravel, Phalcon and Yii’s alike.

While some great efforts are put into opinionated frameworks like LoopBack, Sails and Kraken, the communities are quite sparse (although very much active).

JavaScript on the client-side is not less sparse. While Angular 1 was probably the de-facto standard for SPAs, the rise of other tools like React (which is a library, not a framework) and Meteor (which is a… hem, let’s call it an experiment) has brought new ideas to the community. Unfortunately, some feels (and I personally share this feeling) that we are in the middle of a pivoting period, where everything looks old, there are new things coming out, but nothing is really ready yet. I’m talking about Angular 2, React 1.0 and Meteor 1.3 (and beyond).

we are in the middle of a pivoting period, where everything looks old, there are new things coming out, but nothing is really ready yet

How long can it last?

The surface is already cracking: the recent blog posts about what went wrong with Meteor in the state of Meteor 1 by Sacha Greif and a forum thread by MDG’s CEO Geoff Schmidt are proof that developers do need an integrated solution, or at least a clear path of when, where and how a tool can integrate with existing libraries.

Said it before and will repeat it. Meteor forgets what made them big. Those ten (or even hundred) thousand developers that use Meteor for fun or in small projects.

MDG wants big companies to switch to Meteor as it needs to pay back the VC’s that huge money they invested. Us small chicken won’t help pay the debts back as all we use up is free hosting on Meteor.com instead of paying for Galaxy.

User a4xrbj1 on the Meteor Forum

I’m still really confused about the message being given by Geoff [Schmidt, MDG’s CEO].

Initially I thought it was a full 180, but the wording is too unsure. It sounds like he’s saying we’re recommending Blaze until we can write a better guide with React and/or Angular2. It says nothing about what they’re going to be working on.

User mordrax on the Meteor Forum

Also, as Sacha Greif states (note to self: when writing an honest piece about a project of mine, do not drop “what went wrong” at the end if I want folks to keep using it):

I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.

Sacha Greif, The State Of Meteor Part 1: what went wrong

Basically, global-scoping almost everything and the problem with figuring out what the heck is happening inside that .meteor/folder. Some hard-core developers are worried too:

To be honest I’m having problems to understand MDG strategy for the future. I work with Meteor platform since mid 2014 and I’m pretty happy with what I have now.

[…] Is there a future in the platform? I’m worried, but I keep coding :)

User Massimo Sgrelli, The State Of Meteor Part 1: what went wrong

To summarize: something is rotten in the state of Meteor. Will it recover? It’s too soon to know but it ain’t going anywhere in the near future: the project has a great traction on GitHub and was backed by some very smart people down at Andreessen Horowitz so I guess that they are addressing those issues as we write.

The State of Meteor is the state of JavaScript?

Back to the point. I’m seeing a lot of similarities between the “state” of Meteor and the “state” of the rest of the JavaScript community. There is just no clear path right now.

Ultimately, the problem is that by choosing React [or any JS framework, NDR] (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.

When a generator is good solution for repetitious code, a better solution is to abstract it into a simpler API.

Eric Clemmons, Javascript Fatigue

Being a JS developer right now is like being one of the suitors waiting for Penelope to finish weaving Odysseus’s shroud, being constantly reminded that yes, 1.x is indeed limited and 1.y will change everything so please stick with us a little bit longer.

I mean, there is no framework right now that is really production-ready (except for React, but, again… React 1.x is coming soon, is it?). Change is good, change is healthy, although having to re-learn everything from scratch again (yes, Angular, I’m talking to you) can be difficult for big projects that would like to stay up-to-date.

What framework to use for, like, NOW?

My feeling right now between what framework to use for a huge project is somewhat mixed.

Meteor has unanswered questions that will hopefully be answered with the 1.3 release (although I’m not ready to bet on it). A lot of the packages (oh, by the way, it seems that Atmosphere will be dropped for npm) are written for Blaze and not even the core-community is certain whether or not to drop everything for React or continue to support multiple view-frameworks. My advice is to skip the turn and see what’s coming.

Angular 2 is almost there although not there yet. It’s in beta and there is no release date for the final version. Still, whether or not the old 1.x crowd that has switched to React will come back for 2.0 is not clear yet. My guess is, they will. Angular 2 is written with all JS flaws and problems in mind. Case and point: TypeScript addresses the quirks of ES5 vs ES6 vs browser compatibility, RxJS gives a structure to data-streams, its whole structure gives a solid foundation to code on etc…

React sits in between, and, as they writes:

React makes no assumptions about the rest of your technology stack, it’s easy to try it out on a small feature in an existing project.

Basically, it’s something that can be applied to an existent solution. It uses its own syntax for building html components (JSX) and relies on pure vanilla JavaScript (for ES6 or ES7 compatibility, see Babel).

Kent C. Dodds wrote on July 2015:

Here’s the real kicker: If I had the freedom and leisure to build a major product from ground zero (like if I were to do a startup or something), I would probably go with React. Seriously.

I think some people in the Angular community are going to come at me with pitchforks right now. But as much as I like Angular 1, I think React is better.

Will Angular 2 be better than React? I think it might, but that remains to be seen. But it’s the principles and concepts behind React that I really like.

User kentcdodds on a GitHub AMA discussion

By the way, Kent is that Kent that hosts the Angular-Air podcast, so I feel that his views have somewhat more weight (see reputation) than other’s. Moreover:

A long time angular user but I’d agree and go React.

The way I look at it is that you can use React today.

Angular 2 is a work in progress. Angular 2 is adopting learnings from React which is great but it must impact development as plans have changed.

User jsteenkamp on a GitHub AMA discussion

But, keep in mind that in July 2015 the dust that ng-europecreated back in October 2014 had not yet settled, Angular2 was still in pre-alpha and no release date was announced (not even at the Angular Connect conference in London back in October 2015). Although now Angular2 is in a solid beta (again, sarcasm) I agree with Jeff Whelpley when he writes:

[…] as soon as Angular 2 is closer to full release I will use Angular 2 for every nearly every new project.

That doesn’t mean Angular 2 will be definitively “better”. It’s more like leveling the playing field and the choice between the two will end up being one much more of personal taste and specific project requirements (assuming the performance characteristics and features will be nearly the same which it appears will be true).

[…] So, the stuff typically associated with React is likely going to appeal more to devs that have their foundation in functional programming languages while Angular 2 is likely going to appeal to more to devs that have their foundation in OOP-based languages like Java and .NET.

User jeffwhelpley on a GitHub AMA discussion

Kent recently added:

So I actually talked about my feelings about Angular 2 […].

Basically, Angular 2 is amazing. There’s no denying that. And I know that there are some things we don’t know about Angular 2 yet that are going to be even more incredible. The challenge is time.

I just don’t have time to do everything under the sun I’d like to do. So I’ve decided to go pretty much all React.

User kentcdodds on a GitHub AMA discussion

And, as always, keep in mind this great piece of advice:

[…] it is a never ending battle if you want to try and work on the “best” and hottest framework.

It is much better IMO (and more productive) if you instead just pick one that makes sense (Angular 2, React and Aurelia are all fine choices) and then bring the ideas from other frameworks into what you are working on.

I think in general people tend to think they need to drop what they are doing and move on when in reality all they need to do is innovate where they are already at. So, just choose one and make it work.

User jeffwhelpley on a GitHub AMA discussion

Right, choose one, make it work, and may the code be with you. Personally, I’ve always been drawn to the Angular side of the force and I think that I’ll stick with it for big projects. For small projects I’ll experiment other frameworks.