Echo JS 0.11.0

While I don't agree with every point he hits on; I think his overall conclusion is correct.  Angular 2 is a terrible framework and should be avoided.  It's by far the most complex JavaScript framework I have spent time with and I've used many others (Knockout, Ember, Angular 1, Sammy, etc...).


The learning curve is way to steep, and saying it "isn't a framework for beginners" doesn't justify it.  I've been working with JavaScript for 15 years and programming for the past 20 years and the ramp up time on Angular 2 is ridiculous.  With Angular 1 I understood enough of the framework within a week that I could feel confident building out a product.  In a month's time with Angular 2 I still hadn't reached that level of confidence.  In my opinion this alone should be a deal breaker for projects.  Most teams are not going to be made up of all "senior" developers; if I don't feel some level of comfort in the framework within a short period of time how can I have confidence that junior developers are going to grok this?

I'm concerned that this creates fragmentation when the community would be better served working together.  As Node and IO diverge eventually they become incompatible module maintainers have to support both, or possibly they choose just one or the other; either way both of these are a loss for the community since one takes up valuable time supporting two platforms and the other option leaves us with a less healthy module eco-system for each platform.

Compare this with the Ruby community.  MRI is the reference implementation and more people than not continue to use it.  Rubinius and JRuby try to achieve performance gains through various means, but the attempt there is not to diverge from MRI, but rather to stay in lock step.  Even there, where the intention is not to diverge, there end up being some incompatibilities.  Now JRuby 9000 is falling even further behind MRI (https://github.com/jruby/jruby/wiki/Roadmap).  The end result is that more often than not people just choose MRI.

I think especially right now as Node.js is still an up and comer that this division could be toxic to the community as a whole.

This makes me think of the "State of JavaScript in 2015" article that showed up on Hacker News recently.

http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/

To me this seems like a fork without purpose that will mostly serve only to divide the community and lower overall adoption of Node.js.  Now I will not only have to know X^Infinite front-end frameworks, but also how many forks of Node.js will I need to keep up with.  I feel like these efforts would be better served bettering Node.js rather than creating a divide.

I have no vested interest in Ramda/LoDash/Underscore, but this isn't the first time I've seen articles from the author of Ramda comparing it to LoDash and/or Underscore and it is always in this sort of, "see how Ramda" is better sort of way.

I'm all for simplicity and fully aware of YAGNI, however throwing that around when we are talking about APIs for public consumption vs a specialized application are two totally different beasts. He essentially claims negative stepping through a range is so uncommon that there is no need to support it directly.

Underscore's implementation isn't difficult to figure out and it's flexible. And in my opinion at least, _.range(3,0,-1); is easier to read and type than R.reverse(R.range(1, 4)); as well as being more versatile.

Unerscore is small, flexible, well documented and easy to understand.  Additionally there is a good chance other JavaScript developers I encounter already know how to use it.

Sigh; YATE(Yet Another Text Editor)?

This is not going to get people to leave Vim or Emacs.  They are used because of their maturity, ubiquity, and massive ecosystems.

I read that part as well, but given that TJ is saying he is leaving the community and Koa hasn't seen the strong adoption of Express.js yet I wouldn't be putting any of my eggs in that basket either.

JavaScript: The New Parts would be more accurate. I'm not sure all of these changes are for the better; or will help make things any easier.

Class : 

This one is a mixed bag. The way prototype inheritance works in JavaScript today is non-trivial and many people do not understand it.  The new implementation makes creating objects and using inheritance easier at the implementation level, but it masquerades the fact that it is STILL prototypal inheritance.  It's good that it's easier to implement; bad that we end up with a bunch of confused programmers that will think JavaScript has something akin to traditional OOP.

Arrow functions:

Less typing; more confusion. The fact that it does lexical this binding is going to lead to more confusion as developers are left wondering why this is one thing when creating a function in the old style, and something else in the new style. It's no substitute for understanding how "this" really works in JavaScript.

While fictional; it is still both highly entertaining and thought provoking.

This looks pretty cool. I would love to see some kind of road map on this project in terms of where they want to go; what tools they would like to see covered, etc... This would help potential contributors know what they could be working on as well.

It's definitely a cool idea; just more curious what happens if CouchDB were to change significantly.  I'm personally using couchapp for some stuff, and that doesn't seem to get much attention anymore either.