Maintainable Javascript carsonified

Maintainable JavaScript

Chris&an Heilmann
Carsonﬁed online conference, September 2010

Nowadays writing
JavaScript is
wonderfully easy.

Libraries patch the
support holes in
browsers.

Pure JavaScript
environments allow
us to really play
with the language.

JavaScript is dead
easy to learn and
the first steps are
already very
rewarding.

This is also the
problem of
JavaScript.

The web is not a
closed environment
where we can
dictate the
technologies people
use.

Some of the things I
will talk about
today will seem
outdated or overly
cautious.

The reason is that I
want to build a web
that works.

For far too long we
have built a mess
that barely
functions and is
hard to change.

So here are a few
ideas and concepts
you should follow if
you write
JavaScript.

★ Using, not abusing libraries
★ Separation of concerns
★ Building for extensibility
★ Documenting your work
★ Planning for performance
★ Avoiding double maintenance
★ Live code vs. development code

Libraries fix
browsers and make
the complex simple.

They make web
development
predictable.

Building without
libraries means
constant catch-up
with the browser
market.

Do not mix and
match libraries
though.

Stick with one and
use it to its
strengths.

If the library totally
re-invents JS as we
know it, this is fine.

But: writing in an
abstraction syntax
is not writing
JavaScript.

Quick two-liners do
not replace
architecting and
planning.

Professional
libraries come as a
pick and mix
solution.

Include what you
need and when you
need it - not the
kitchen sink
approach.

One big danger of
libraries is to tie the
markup and your
scripts far too close
to each other.

Small looking loops
can actually be very
slow.

Long CSS selectors
are dangerous.

Pick your plugins by
how well they are
documented, how
well supported and
how easy they are
to extend.

Take each
technology on the
web and use it for
what it was meant
to.

HTML that works
without JavaScript
should not be aded
using JavaScript.

HTML that only
makes sense when
JavaScript is
available should be
added with
JavaScript.

Instructions that
describe
functionality that is
dependent on JS
should also be
added by it.

Text, classes and ID
names are very
much prone to
change.

So don’t spread
them all over your
scripts but keep
them in one place
for maintenance.

Public configuration
objects are a great
idea.

Most underused
element:
<button>

Buttons by
definition are there
to trigger script
functionality - so
use them instead of
links.

Links should point
to a real resource -
a url, a server
endpoint or an
anchor.

Empty links, void(0)
# and other hacks
don’t make any
sense.

Styling should be
done in CSS, not in
your JavaScript.

Calculated positions
are of course the
exception to that
rule.

Adding and
removing classes
makes sure
designers have a
handle and you
don’t have to worry.

By adding a class to
a parent element
you can swiftly hide
a lot of elements
you’d otherwise
have to loop over.

Adding a “js” class
to the body means
CSS designers can
define two views
easily.

Make maintainers
not have to know JS
or change yours!

Using libraries
means using a lot of
anonymous
functions.

Most of the time at
the end of a
massive chain of
methods or for
every click().

Naming and calling
these methods
makes more sense
as you create a
single space to
maintain.

Never think your
script is done and
you thought of all
use cases.

This is why we have
dozens of lightbox
plugins in jQuery all
doing almost the
same thing.

Instead of building
a “one size fits all”
solution, split it up
into small solutions
that do one thing
and allow for mixing
and matching.

Think about firing
off custom events at
interesting
moments.

This allows people
who want to extend
your solution to do
so without having
to touch the main
code.

Don’t limit anything
to a fixed size or
amount. Instead
make it a variable in
the configuration
object.

Documentation is
what we rely on
when we get lost.

People think
documentation
replaces good code
examples.

The issue is that as
developers, we
almost never start
with the
documentation.

Instead we dive into
the code and mess
about with it.

We read the
documentation
when we get stuck.

Which is why code
comments and
descriptive variable
and function names
make your code
easy to maintain.

Comment the
special case, not the
obvious.

Keep function and
variable names
short and to the
point.

Your documentation
should explain
applying and
extending the code,
not the code itself.

Don’t worry about
the size of
comments - a good
process deals with
that.

GitHub and Google
Code is the new
View-Source, so add
value, not only
solutions.

You can find a lot of
great performance
tricks on the web
when it comes to
JS.

Read those with the
use case in mind.

Tricks necessary to
make Google Mail
on mobiles run
smooth are edge
cases.

Performance is a
specialist topic and
can be handled a lot
in build processes.

If a performance
change means re-
educating a whole
team of developers
it is probably not
worth it.

Scripts can convert
and change code
written in a
predictable fashion.

Hacks and shortcuts
need to be fixed by
humans.

The performance of
JS itself is not really
the issue you should
be concentrating
on.

Slowness of the
DOM and reflow of
the interface is
where users get
hurt.

Assemble HTML as
as string and use
innerHTML once
instead of adding to
it.

Use Event
Delegation instead
of hundreds of
event handlers.

Store information in
JS objects instead
of HTML attributes.

Make your code
easy to understand
and clean and add a
performance review
and refactoring step
at the end.

Double
maintenance of
code is a bad idea.

Validation rules
might get out of
sync.

This is always the
killer argument of
enemies of
progressive
enhancement.

“I spend a lot of time doing
form validation in JavaScript
- why should I repeat the
same on the server side?
“

Because there is no
security in
JavaScript!

If all you do is
validate in JS,
attackers will have a
field day with your
server.

Besides, there is no
need to repeat
validation rules.

That way you
validate on the
server and you can
use the same rules
for your JS...

Form validation
scripts are
annoying.

You need to access
the right parts, read
and write from the
DOM, change styles
and and and...

You can leave it all
to the server and
still save your users
a full page reload.

Request type
switching is the
answer.

Maintainable Javascript carsonified

More Related Content

What's hot

Similar to Maintainable Javascript carsonified

More from Christian Heilmann

Maintainable Javascript carsonified