A mriyad of libraries and the art of selection

[meenakshi sundar]

Its becoming more and more difficult to narrow down to a particular tool/Library ,there are so many out there in the open,the so called popular JS template libraries are becoming obsolete already and new set of libraries are popping up
Why this peculiar scenario with JavaScript Land?

Thanks
Sundar

[Bear Bibeault]

Of all the ecosystems I've worked in, the JavaScript landscape is the fastest changing one I've ever had to deal with. And yes, it can seem overwhelming.

When it all comes down to it, a firm understanding of the JavaScript language and its principles will help you adopt whatever's the latest and greatest.

But perhaps the most important thing I've learned is that you can't do it all -- there's just too much going on to be able to grok everything. So if you are beating yourself up because you can't seem to keep on top of everything, like I used to do, you can stop. Again, learn the fundamentals that can be applied anywhere, and learn how to judge what's important and what's a passing fad. (Easier said than done.) Keep an eye on what is taking root in the industry, and what's important for your career.

[Michael Matola]

So, right now, what's important and what's a passing fad?

[Bear Bibeault]

I can't tell you how many times I've been asked "So what do you think about FredsFabulousFramework", where it's some new-fangled thingie that's creating buzz.

My standard answer is that I'll pay attention to it when it starts appearing on job descriptions.

So for me, right now, that's AngularJS on the client, where I've been focusing. I do see NodeJS starting to show up a lot, but I'll admit to ignoring that for now due to my client-side focus.

[Michael Matola]

Bear Bibeault wrote:I do see NodeJS starting to show up a lot, but I'll admit to ignoring that for now due to my client-side focus.

Heh. Just yesterday I avoided clicking a link in my feed "Why companies are switching from Node to Go on the server."

And remember last year when I was joking about everyone being all "Grunt is so last year, now it's Gulp"? Now everyone is all "Gulp is so last year, now it's npm scripts."

[Michael Matola]

And today it was "Should I learn Express.js or Sails.js?"

[Bear Bibeault]

And tomorrow it will be...

[meenakshi sundar]

For a long time the web platform or the technology stack or the web stack were most fundamentally built on HTML+CSS+JS,And there was a whole lot of inconsistency between browsers and we had to write frameworks to paper over them. The problem was that there was disagreement even on the fundamental issues among browsers, like how events propagate, or what tags to support...

So every framework not only papered over the cracks,in doing so they designed their own model of how the browser should work. Actually their own models, A model for how events propagate, A model for how to interact with the DOM ...,the likes of jQuery and Dojo and MochiKit,AngularJS and Backbone,React were born.For the past several years we’ve been churning out a steady parade of JS frameworks.

In the meantime ,browsers got better,their support for standards improved, more capable and standards compliant than the previous versions,so there's no need to invent yet another framework to do something, even with plain old HTML+CSS+JS you can do much of every thing for which you dont need a framework.

So why are we still writing JS frameworks? I think a large part of it is inertia,Some times it scares away people ,What do you think about that?

[Bear Bibeault]

I disagree. Even with modern advances in HTML5 and JS, there's a lot of value that frameworks like jQuery, AngularJS, and the like bring to reducing the amount of code that one needs to write and maintain.

[Peer Reynders]

It is often helpful to distinguish between libraries and frameworks.

Martin Fowler: Inversion of Control

A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

Typically it is much easier to write small libraries than it is to write small (successful) frameworks - frameworks have the tendency to meander into the-whole-kit-and-caboodle/swiss-army-knife territory.

For the longest time there was something attractive about Swiss-army-knife products because "just one thing" could be helpful in so many ways and it could become more helpful with time as one becomes more and more proficient with "it" - even though one would never "know all of it". However these Swiss-army-knife products do tend affect how code is implemented and organized - and not always in a good way.

It is my impression that some of the drive behind the "micro-service craze" is the desire to move away from products where we have to accept the gorilla with the jungle when we just need the banana*. So there is a genuine desire for small libraries and "micro-"frameworks that do one thing very well (Single Responsibility Principle) and stay out of one another's way (Separation of Concerns) while having relatively few dependencies. Also these small products can tend much less toward "vendor lock-in" so you can start out with something that is "merely adequate" and replace it later without too much agony with something superior (or finally having figured out what you really need, simply write your own based on the knowledge that you gleaned by looking at existing products). When building an application that is "sufficiently different" some people end up using pre-existing libraries but write their own framework.

So if we are in fact moving away from the large Swiss-army-knife products towards the small and highly focused do-one-thing-really-well products then it would only be natural to see a proliferation in number as we are on average going to need a larger number of the do-one-thing-really-well products in any single application (and an even larger number to satisfy the needs of the whole spectrum of application types).

[meenakshi sundar]

Typically it is much easier to write small libraries than it is to write small (successful) frameworks - frameworks have the tendency to meander into the-whole-kit-and-caboodle/swiss-army-knife territory.

I agree to that ,Another selling point of frameworks is that you can get access to a library of widgets. But really, you shouldn't need to adopt a framework to get access to widgets, we use CodeMirror, a syntax highlighting
code editor You can use it anywhere, no framework needed.

it should come in the form of a Library not as Framework, problem with frameworks that i see is that they end up being silos, they proliferate the landscape, widgets built for one framework may not work in another framework.

[Kyle Simpson]

> So, right now, what's important and what's a passing fad?

Everything other than JS the language itself is probably in some sense or another, a passing fad. Some last longer than others (jQuery) and others are here and gone before you know it. I recommend investing first, heavily, in your deeper understanding of the core language. That is learning that pays off year after year and won't any time soon be "passing".

When picking a library, look for all the usual signs, like good community support, proper documentation, etc. But also, look for a library that constrains itself to a limited scope of behavior. Tools that claim to be "everything you need" usually aren't. Look for libraries that do one set of things really well.

For frameworks, look for real modularity. That means more than just "stuff in separate files". It means real attention has been given to keep pieces loosely coupled and easy to remove. That kind of thing won't seem to matter much in the early going, but it pays off exponentially more as your project moves into maturity and maintenance.

Lastly, I'd say, if you have a tool or framework but you're not completely happy with it, don't necessarily be looking around to jump to something else. Whatever tool you use is going to have flaws. React is not better-enough than Angular to mean you should switch. It just isn't. They both have pluses and minuses. You're far better served by learning the thing you're using -- and the language it's built in! -- better, and learning better patterns of use of that thing. Investing not in re-learning and moving to a whole new thing, but instead in trying to make your current code more understandable and cleaner, will mean that it's less likely that your code will eventually have to be re-written a few years from now when a new group of devs can't figure out your code and they just throw it away.

[Michael Matola]

I know the original question had to do with libraries and frameworks, but I'd also be interested in hearing thoughts about things like CoffeeScript and TypeScript, which were created to address perceived deficiencies in JavaScript. Is either still relevant in light of ES2015?

[Kyle Simpson]

> CoffeeScript

Nope, definitely dead. It had its impact though, and the best parts made it into ES6. Time to move on from coffee though.

> TypeScript

Yep, still very relevant. I don't recommend it as your general programming language, but I do recommend it if you're interoperating with a more strongly typed language in the back-end. It's great in the microsoft stack, for example.

[meenakshi sundar]

Everything other than JS the language itself is probably in some sense or another, a passing fad. Some last longer than others (jQuery) and others are here and gone before you know it. I recommend investing first, heavily, in your deeper understanding of the core language. That is learning that pays off year after year and won't any time soon be "passing".

When picking a library, look for all the usual signs, like good community support, proper documentation, etc. But also, look for a library that constrains itself to a limited scope of behavior. Tools that claim to be "everything you need" usually aren't. Look for libraries that do one set of things really well

Thanks for the insight Kyle

Plain JavaScript along with jQuery has been used for years to build complex web application but with lot more effort and complexity in code development
And maintenance.

In that sense ,JavaScript Frameworks give you space to focus on developing interactive aspects of the user interface without worrying too much about the
Non functional Aspects such as code structure and code maintenance, re-usability,scalability. Different frameworks offer different concepts and methodology
But attempt to solve the common Underlying problem of rendering complex user interfaces dynamically and making single page applications much more useful.

In the meanwhile with the advancement in the browser capabilities ,There are possibilities and use cases out there that you can still build application with a
Minimalist or light weight Javascrpit libraries or frameworks such as Meteor.JS,Here we are seriously looking in to this since it is a full stack framework for
Building end to end mobile and web applications completely in JavaScript and it is modular and the packages and libraries can be used on demand.

What do you suggest about Meteor.JS?