Some depressions on the chaos of JavaScript

JavaScript is not a language, it’s a platform.

It’s becoming more and more tough to learn JavaScript. People are complaining. You probably have seen this post joking about how prosperous JavaScript is, meanwhile how overwhelming people feel about them. It’s popular.

People in China hate it too. We have Anguar and React, we also have small libraries like react-lite(React and light) and Avalon(MVVM but now virtual DOM like Vue). And this year Vue 2 is rising quickly and a lot people are talking about it. We also have Weex(React Native in Vue) and WeChat App(in JavaScript). It’s chaotic. Yesterday I saw someone complaining on it, so did I.

Well, I’m in Shanghai and I’m still building a front-end MVC library called Respo. Hopefully it will make the situation more chaotic. Personally I’ on the React side. But due to the doubts on React community I started learning ClojureScript even though it’s a bad choice for a job.

Clojure is a well designed language, much better compared to Babel. There’s immutability by default, no need of JSX to write HTML with the language, we don’t have to update the compiler to add new syntaxes thanks to macros, and it’s not controlled by Facebook. The language is also quite stable and platform agnostic. We were trying to do a lot in JavaScript in the React community to make JavaScript better, it was a lot of efforts. However, even with the efforts, ClojureScript is still superior in some aspects, without aggressively bumping the version numbers.

And in some degree, I don’t like Facebook’s tempers. In my last company we were using CoffeeScript and React is becoming more and more unfriendly to it. We used Flux at first to build a large app with more than 100 components, and it become hard to migrate. Then the React community prefers to use Redux, a lot of tools are built around Redux. react-router is incompatible with Redux so there’s redux-router. Then, Redux updates. Also react-hot-loader updated to something I can never use in CoffeeScript. It’s like we were abandoned.

That problem comes to Webpack 2 as well. One of my workmates used it as a dependency. Then it broke after an update. You could say Webpack is still in beta and we need to be careful from the beginning. Yeah, we should. But seems Vue 2 is using it somewhere, we thought it’s already stable enough. And Webpack 2 was said to be release by the end of August. How its October, there must be issues.

Surely Facebook is very kind to share lots of it tools to the community. Those tools saved us small companies and medium-sized companies a lot of time. We don’t have to stay in the jungle of jQuery and template engines. It’s great improvement to us when I can migrate our app from Backbone to React and gain benefits in developing and maintaining. The problem is, it updates.

While Facebook is large, there’s a lot of small ones doing different businesses. My previous company aims to provide realtime collaboration tools with HTML5 and native apps. It ends with a very large simple page app looks like combining the webpages of Trello, Sunrise, Dropbox and Asana. And my teams was working on a chat app(like Slack). Those works requires lots of skills on building single pages apps. To make it faster, we need code splitting, basic server side rendering, memory control and a lot of stuffs. And also there are companies integrating HTML5 pages into native apps in China, which requires techniques to make mobile pages loaded instantly. Some of them are different from large company, some are not.

Server side rendering is an old thing in React community. But as I was learning Vue’s SSR, I found SSR code for React is not even merged. Actually no updates for months. That’s strange when React is such a friendly and active community. After React updated to 15.x , suddenly we have no official solution for SSR. I don’t know what’s happening there.

Facebook evolves JavaScript. It was great. And slowly we have type system like Flow, we have more and more ES6 features to power up our apps. It takes long time to wait for Google and Microsoft finish supporting ES, with Facebook, it’s a lot faster. The part I don’t like is we still run into problems, and some of them are likely created by Facebook. Type system is very nice for making apps robust, however, does everyone need it? I was a big CoffeeScript fan since I was enjoying prototyping of small apps. Then one day people started talking “CoffeeScript is dead, use ES6”.

I don’t use CoffeeScript often now, since my new work prefers ES6. But you guess what, people are still downloading coffee-script every day. That number even succeeded babel-core at this moment, which can be confirmed on npm.

And somehow CoffeeScript isn’t dead, there will probably be CoffeeScript2, just not sure when.

But as said, CoffeeScript classes and Babel classes are not incompatible. And there can be more issues like this. JavaScript is always falling a part. There’s also TypeScript, a lot of languages, just like there are lots of frameworks. So it’s a problem how we can make the standard really work to make pieces together. Maybe it’s like people said, it’s too easy to publish npm packages. As I see, small companies like have their needs, which is a lot different compared to large ones like Facebook. Now I don’t believe we can follow the steps of Facebook all the way. Sharing knowledges is nice, but sharing code is more that that.

I forgot who but someone said, large company need to control the language or it will be controlled. Maybe it’s saying Google and Java. But how about CoffeeScript, will Facebook risk using a language that is controlled by the community? Seems not, and they have Babel now, and they also have Flow and Reason, maybe more. What if there are disagreements between Facebook and some small companies? It can be complicated, but React is on whose GitHub.

So here’s what I want to say, not all things from Facebook, Microsoft or Google fits our scenarios naturally as smaller companies. Once I heard that, there are ES4 before I was learning JavaScript. There was different opinions on type systems. Well…

我觉得这个问题的最大分歧在于,你做的是什么类型的产品,做web页面的强烈反对把js复杂化,但做web应用的恨不得自己在用c# ,也许google搞dart就是为了这个,我强烈觉得,再往后,这个矛盾更加不可调和,放弃es4应该就是web应用开发者话语权不够的体现,但从目前来看,页面开发者更不乐观。
by Xu Fei

So here’s the reality. JavaScript is a big platform, people are dragging it towards different directions. Static/dynamic types, curly braces/indentation based, observations/immutability, Rx/CSP, and a lot of.

Even more, the story never ends. There will be WebAssembly. By the way, it’s not bad for us Clojure enthusiasts. WebAssembly may push this platform to a new level where JavaScript is not the boundary of compilation of toolchains, and that may bring lots of possibilities. Then we may no longer see JavaScript as the language of the Web, and large companies may build their own tech stacks. Then we don’t have to complain that libraries from different companies don’t work with each other, because they use different languages, rather than sharing a JavaScript.

Now JavaScript community is still growing. It’s like there a bright future ahead, except for that it’s so far that I don’t know when we can get there. The situation now is mixed of enthusiasms and depressions. Yeah, I bet on JavaScript too, in the long term, but let me stay with Clojure for a while.


Sorry for my Chinese English. I just want you to hear my options on JavaScript.

Show your support

Clapping shows how much you appreciated JiyinYiyong’s story.