The State of JavaScript in 2015

added by Bob Senoff
12/1/2014 8:30:45 AM


The JavaScript world seems to be entering a crisis of churn rate. Frameworks and technologies are being pushed out and burned through at an unsustainable speed. But I think the community will adapt and adopt new practices in response.


Dom Barker
12/1/2014 9:33:10 AM
Can't stress point 3 enough, probably for software engineering generally but most especially for an ecosystem that's as unstable and immature as javascript.

Drew Peterson
12/1/2014 7:26:30 PM
Are you referring to the point about dedicated libraries? If so, I agree, but it doesn't solve the problem. We have *so many* libraries out there already that are tailor-made for a specific purpose, but what if you want to combine those libraries? What if I want to use selector library Foo with CSS polyfill Bar? I either have to fork the project and use Foo, or I have to use whatever library Bar chose. That brings us back to the Reddit comment that was quoted earlier in the article, you're at the mercy of whomever wrote that small library to either provide extensions points for you to swap out a dependency (good luck), or you have to go with a larger framework so that you don't have to worry about the author not updating their library because obscure dependency X just had a breaking change. We had that with jQuery, in a way. jQuery has enough built-in that you can write any number of purposeful libraries against it, each filling some niche. But since jQuery is a big monolithic project, doesn't that make it bad? I'm not convinced that's true. Just because Angular screwed the pooch and a whole bunch of work now has an end-of-life slated for 2015, doesn't mean that every large-ish framework will do the same. So what I propose is that we need more medium-sized libraries. We need some of these small projects to graduate. They need unit tests and documentation and pull requests from the community to fix bugs. This provides support so you can be confident in choosing the library, but not be at the whim of a corporation with things other than your productivity and happiness in mind. I'd love to hear what some others have to say on this article. @gingemonster @buzzdecafe @graham_kane @awgreenarrow08

Graham Kane
12/1/2014 11:12:10 PM
Cobbling together a bunch of micro-libraries feels like a bit of a backward step. I believe generally people are just looking for something that does most of things they should be doing, reasonably well. But it would be nice to have the option to optimise / swap out different components, if needed. The key thing here is making things easy to TEST. I really liked Durandal. As a framework, I think it struck the nicest balance with a few well implemented core building block concepts doing mostly everything I wanted. Being able to read through the source code and easily understand what was happening behind the scenes was great for learning, and being able to extend / override conventions as needed. It will be interesting to see what happens with v2, now Rob Eisenberg focusing his efforts there again.

Drew Peterson
12/2/2014 3:56:56 AM
I'm glad you brought up Durandal, it's sort of the benchmark I use when looking at other larger libraries these days. It's been an absolute joy to use; I feel *so much* more productive with it. What are your thoughts on extension points for Durandal vNext? One thing I'd love to see is the ability to swap out the view layer. I am a fan of knockout, but it would be nice to have the option to leverage something new and shiny when it inevitably comes along ;-)

Ofer Zelig
12/1/2014 10:59:28 PM
I agree for the most part, but not necessarily with the conclusion. Yes, there's a huge array of JS libraries, large and small. With more options comes more potential mess. My problem with micro libraries is - sometimes - their lack of maintenance or robustness. AngularJS was my best choice at the time I started learning it and at the time I decided to base my company's current big project on. Would I have started with AngularJS had I knew that version 2 is going to shuffle everything and render our code base virtually redundant? I don't think so. But what option did I have? not using ANY client side MVC framework? because the same can happen to Ember, Backbone, you name it. Frameworks need to evolve and that's it. You need to take the best decision you can at any given point in time and hope that it will last.

Drew Peterson
12/2/2014 4:01:37 AM
So I wonder then if the safe bet, regardless of the size of the MV* framework, is the one that allows you to separate your application code from the plumbing code as much as possible. I get the feeling that that isn't quite as easy to do in Angular 1.x as some people would like, and that may be what makes the shift to 2.0 that much more painful. This is mainly from what I've picked up in the blogosphere and my limited foray into Angular, I could be completely off base. However, bringing up Durandal again, I found that most of my plumbing code, while specific to knockout (due to ko.observable), was mainly limited to plumbing code. I was able to easily import my application/business logic as services into my viewmodels whenever I needed without having to put much thought into it at all. Nothing in my services depended on any part of Durandal.

Ofer Zelig
12/2/2014 4:20:43 AM
The separation you describe is an important factor but just one of them. AngularJS has several other advantages. But we're not arguing which MV* framework is better (or best). Everyone needs to choose what they're best at and/or what serves their goals better.