This week there is a lot of noise in the JS ecosystem, on various trends. But the most noticeable is about Yarn. Yet another package manager for js, that states it opens a war against NPM (in soft terms but clearly enough). The long post from Facebook about it demonstrates a clear effort to push things forward about NPM shortcomings. The reaction on hacker news is pretty verbose.

It provoked a public response from NPM to try to explain that, nop, it’s not a war. But I keep feeling that Facebook is slowly taking over another piece of the javascript world. For now, it doesn’t seem harmful at all, but my instinct lights a various number of warning bonfires.

But for real, it was more than time that the supremacy of NPM was questioned. It has a lot of flaws and the number of posts about this event proves that the community was kind of waiting for something like this to happen. Like this cheatsheet, various articles like this one, this enthusiastic post from Yehuda Kats. But not everybody is happy about how things are done.

Personally, I like the technical direction it takes. But I hope that like io.js went back to node.js, it will eventually merge back to NPM, really. But I have the feeling it is not going to happen.

This week I laughed a lot while reading How it feels to learn JavaScript in 2016. That article had a pretty good response, like it hits a nerve.

But seriously it’s clear that we are at a transition time in Javascript evolution, and there is a huge chaos of possible alternatives to everything. It feels like an ecosystem where the natural selection didn’t operate its magic yet. It’s like there are things in suspension that are going to fall in order at some point eventually.

My personal bet is that things like elm will win the race, because with its embrace of functional programming it seems like it opens the door to interpretation with yet-to-be-written faster and more direct compilers (rather than transpiling to js). But that’s just a hunch.

In the while, front-end craft is now a wizard arcane art. It can’t be acquired by pure reasoning and logic, or reading a doc. You need the map of the landscape for knowing the possible choices and alternative intermediary solutions. For part-time front-end people, it’s just hell. For now.

There have been some noise last week about npm, coming from that article. It merely revealed that various open source organization are privately held by some individuals and they can either be pressured or take weird decisions. Honestly I consider this incident anecdotal. It’s not the first time such thing happens. One guy just happened to be very vocal and pissed off about it.

And it carried various threads of discussion on Twitter and elsewhere, in a huge controversy. There were many points raised. NPM has thousands and thousands of packages, and many of them are just a few lines of utility library, so it was a good occasion for some to point out that you should reduce your number of dependencies. Others pointed out that namespacing could help prevent such situation, like it’s done in docker or in go (having username/somelib instead of somelib) following the github convention.

All in all, it appears that open source is gaining its traction from being free of any legal duty. Or at least there is no formal contracting, no by-laws, on committees or advisors. People do how they feel in the limits of some very simple basic licensing rules. Some organization provide a more structured legal asset but they usually are on the side and purposed for channeling money management, not necessarily patents and intellectual property.

My opinion is that this kind of friction between businesses and open source is going to happen more and more. But I wonder how it’s going to turn out.

Recently I’ve been playing with Hubot plugins code in coffeescript for our company. That’s a while I didn’t do much js but I used it for a long time and I didn’t find it too difficult to catch up. But for some reason, it brought me the same feeling I have each time I get back to that language. I feel dirty. Still I can do what I need to do, for sure, but I don’t feel like a builder, more like an acrobat. And I’m far from a purist.

Some people talk about javascript taking over the world. But that language imho just was there at the right place at the right time. By having a runtime embedded in browsers and browsers libraries, it has been used to hijack the most used software on our computers and mobile devices, to transform them into richer clients. Along the way various layers were added to fulfill the need of software design, because javascript initial goal was merely DOM manipulation.

The thing that always stroke me the most with javascript is that despite the efforts from ecmascript, it has no formal standard or documentation. It is pretty extensively documented, of course, but because the language is pushed forward by the implementations rather than from a standard body, it gets a bit messy.

I saw a drawing this week that illustrates the mess quite well. It feels like Javascript is waiting for something to come replace it.

But there is hope with ES6. Seems like in recent years the normative effort on the ecmascript standard got some more traction and some more press coverage. But I personally don’t think it’s going to bring the solution. I enjoyed reading the thoughts of Eric Elliot on that topic but I’m not sure he’s right on everything. But what he’s right about, is that there will be an after-javascript.

Unless that after javascript doesn’t arrive fast enough and gets useless by some new programming paradigm that may appear one day soon. I mean, in the next 10 years. At some point, like big data is too complex to be handled by human, programming will also get too complex and will be handled by algorithms. We already see it coming. And all programmers will then become high end workflow designers or just play with antiquities.

In this perspective, I think javascript is a great intermediary technology for the time being, given its pervasive aspect. It’s far from satisfying, but it does the job. But the younger generation should keep an eye on higher level abstract approaches, like systems architectures, workflow logics, organization patterns, because imho that will drive software design in the next 10-20 years.