About javascript libraries

Too many choices
eventually leads to

ambiguity and blurring
use case boundaries.

Often one library is
compared with other.

Comparing a jQuery library
with Backbone or Angular is
JavaScript libraries
work at different level
of abstraction.

meaningless. It is like

comparing a processor with
motherboard. You can
compare two processors or
two motherboards but not
both…

So exactly, how does

different libraries and
tools fit into front-end
stack?

Web Application
Widget (UI)
toolkits

Build tools
Full stack
frameworks
Package
managers

Web app
libraries
(MV*)

Graphics
libraries

Base / DOM libraries

Core JavaScript

Web browser

Module
loaders

Web Application
Widget (UI)
toolkits

Build tools
Full stack
frameworks
Package
managers

Web app
libraries
(MV*)

Graphics
libraries

Module
loaders


Core JavaScript

Web browser

JavaScript

engine provided
by the browser

Core JavaScript engine
• Every browser vendor provides

JavaScript engine
• Varying degree of JavaScript support
by engines
• Sometimes some APIs are buggy or
incomplete

• Major engines are Chakra, V8,
SpiderMonkey, Nitro, Carakan, etc.

Web Application
Widget (UI)
toolkits

Build tools
Full stack
frameworks
Package
managers

Web app
libraries
(MV*)

Graphics
libraries


Module
loaders

Hide browser
differences &
provide
consistent cross

Core JavaScript

Web browser

browser API.

Base/DOM manipulation libraries
• Provide abstraction over Core JavaScript
APIs and functions
• Mask browser differences to a larger
extent
• Ideal for basic operations like DOM, CSS,
events, animations & Ajax manipulation
• Provide little help for code organization

Few popular libraries are:

UI/Widget libraries(toolkits)
• Provide out of box reusable UI
widgets/components for rapidly building

web applications
• Some libraries provide features for
building desktop user experience
• Often called toolkits rather than libraries
as utility part is often miniature as
compared to component part


Web application libraries (MV*)
• Provide features for writing maintainable
& organized JavaScript code
• Client heavy applications usually suffer
from code maintenance as JavaScript
leaves modularization to programmers
• Few libraries heavily influence the design
of application while other libraries leave
design decisions to developers.


Graphics libraries
• Provide abstraction over raw Canvas, SVG
and WebGL APIs
• Used for online games, image editors and
data visualization
• Object oriented libraries but by no means
substitute for building web applications.
Do not even compare with web application
libraries


JavaScript module loaders
• Library dependencies and JavaScript code
gets very nasty as code base increases
• Module loaders provide solution to
address code dependency issues
• Loaders works seamlessly with modern
MV* libraries where everything is
organized as modules or components


JavaScript package managers
• Not really part of web application but part
of project development ecosystem
• Provide tools to install, upgrade, configure
& remove resources used by the project
• It also supports dependency management
and versioning

Few popular managers are:

JavaScript build tools
• What Ant and Maven to Java is what build
tools to JavaScript
• Build tools automates various JavaScript
tasks like concatenating, minifying, JSHint
files and other resources. Also automates
Unit testing of code.
• They are not directly used by web
application but external to application just
like package managers.

Few popular tools are:

Full stack frameworks
• There are some that are more than simple
libraries or toolkits. Thus they are

frameworks
• They provide support for many front-end
tasks
• There is no such thing as perfect
framework that can cater to every type of
need

Few popular frameworks are:

Closer look at
other JavaScript

libraries

JavaScript polyfills
• Polyfills is basically a JavaScript code that
emulates standard API that is lacking in

some older browsers
• Some polyfills also try to fix broken API in
the web browsers
• There are polyfills for almost every
HTML5 feature and number is quite large

Modernizr is not a JavaScript polyfill. It is
very small library that detect native
implementation of new features. In
Progressive Enhancement technique,
developer tests for certain feature using
Modernizr and if absent loads the required
polyfill conditionally.

Functional programming
• Along with object oriented nature,
JavaScript also has rich heritage of

functional programming
• In certain cases, functional programming is
much more natural than OOP
• Functional reactive programming uses
functional programming as its basic
building block

Few popular reactive & functional
libraries are:

Unit testing libraries
• Almost half of the JavaScript code is never
unit tested by developers as JavaScript is

still considered as scripting only language
• In Test Driven Development (TDD), tests
are written before any functional code
• As TDD and client heavy application gets
more popular, need for unit testing of
JavaScript code will be ever higher

Few popular unit testing libraries are:

So how do you

choose the right
library?

Some libraries are natural fit

Principle of
Natural fit

for certain tasks. For

example, Backbone.js is
apparent choice for RESTful
JSON applications.

Frameworks like Angular,
Backbone, etc. are good
choice for building single
page applications.

Depending upon the
requirements, it makes sense
to use full stack solutions

Full stack
heavy
libraries

that also direct application
design; while in other cases
lightweight solutions are
much better where
architectural design is left
entirely to developers.

Bare minimum
lightweight
libraries

Especially in case of rapid
prototyping, it helps

development teams to select
libraries with less learning
curve & easier adaptation.

Library like knockout or
Kendo UI is easier to catch on
for WPF or Silverlight
developers as their
philosophy is based on same
MVVM pattern.

T
eam
adaptability &

learning curve

But these are just guidelines
and one should not treat
them like lines carved in
stone. They are meant to be
bent as required.

But before you do anything with JavaScript libraries, do yourself a favor by asking this
question that will save you from many troubles in future

Do you really need a third-party library?
Should you build your custom library?

1.

Libraries create code lock-ins. Not
possible to replace easily

2.

Future can never be anticipated
when choosing a certain library.
Sometimes libraries are forced to

solve the problems they were not
intended to solve in the beginning;
resulting in bloated code base
3.

Many library version upgrades are
not backward compatible. APIs
break easily

Some problems with

third-party libraries

4.

Abstractions provided by libraries
make developers ignore

performance issues
5.

For non-expert developers who
are not aware of JavaScript &

browser internals use library APIs
in not so optimal way.
6.

Writing clean, efficient &
maintainable code is the
responsibility of developers. In the
end, libraries are blamed for any
performance issues.

Some problems with

third-party libraries

In the end, the only
conclusion is choose wisely

Author:
Harshal Patil
@softHarsh
http://definitelysimple.com
http://www.linkedin.com/in/hapatil

About javascript libraries

Recommended

More Related Content

What's hot (20)

Similar to About javascript libraries (20)

Recently uploaded (20)

About javascript libraries