1.
ON SELECTING
JAVASCRIPT
FRAMEWORKS

2.
I'm Zoe Landon.
(aka @hupfen)

3.
I'VE DONE THIS A BIT BEFORE.
◇ I'm a web developer with a fair bit of
front-end experience.
◇ My last two jobs both involved some
degree of picking a JavaScript
framework.
◇ In fact, I've only had one job where it
didn't come up.
◇ Not to mention personal projects.
◇ It's getting kinda old, honestly.

4.
So, if we're going to pick
a JavaScript framework,
we should look at our
options, right?

5.
THERE'S A FEW.

6.
BY THE WAY...
These were all active within the last two
weeks, when I made this presentation
(Oct. 7).
Some are hobbyists, some are big
companies, but all are active projects.
You could maybe double this with "slow"
projects (updates in the last 6 months).

7.
LET'S CLEAN
THIS UP A BIT.

8.
BETTER.

9.
EXCEPT...
Those lines are blurry.
An MVC framework can use components
to drive its structure.
A component-driven architecture may or
may not be modular.
There's overlap. It's not clear-cut.

10.
So, how do you pick the
right JavaScript
framework out of all that
ambiguity?

11.
ANSWER:

12.
Choosing a framework
shouldn't be the first
thing you do on a
project, but the last.
Before writing code, of course.

13.
LET'S TALK ABOUT
CODE SCHOOLS.

14.
CODE SCHOOLS
◇ Code schools, and many college CS
programs, advertise that they'll teach
you how to code.
◇ Broader PR language talks about how
everyone should learn to code.
◇ That's all true. And that's all useful.
◇ But coding is not making software.

15.
Learning to write code,
but not learning to make
software, causes
problems.

16.
CS VERSUS SE
Software is more than the code you write.
It's all of the context that goes into it.
Writing code is a vital step in
implementing software, but so is the
process of finding that context.
Too often, that process is skipped over by
programmers who just want to code.

17.
CODING IS NOT
SOFTWARE
ENGINEERING

18.
Selecting a JavaScript
framework is a software
engineering challenge,
not a coding challenge.

19.
THE PROCESS
Sorry, but this is a software engineering
talk in disguise.
But if you ask the right questions, you'll
end up understanding the project and its
context so well that picking a framework
takes hardly any effort.
So let's ask those questions.

20.
SOFTWARE
QUESTIONS

21.
WHY?

22.
WHY?
Why does the problem you're trying to
solve exist?
Was performance never considered?
Is the code poorly built?
Are you just goofing around and learning?
There's no wrong answer, besides having
no answer.

23.
WHY?
Sometimes, you'll get requirements that
propose a solution to what they describe.
Asking "why?" offers a gut-check, to make
sure that solution really is the best one.
Also consider why a framework you're
evaluating exists. What problems are its
authors trying to solve? Do they know?

24.
The context of the
problem matters more
than the problem itself.

25.
WHAT?

26.
WHAT?
Working out why the problem exists helps
to define what the problem really is.
That helps define the features and
capabilities that are going to be
necessary.
Those become your priority.

27.
WHAT?
Some tools and frameworks do certain
features really well, and really easily. But
other features may take some work.
Don't discard a framework just because it
doesn't have exactly what you want. You
can build it. Or it may have something
different that achieves the goal instead.

28.
Any feature is possible,
but with the wrong tools
some will be difficult.

29.
WHO?

30.
WHO?
You go to war with the army you have.
You, your customer, your users, your
teammates, your company… Everyone
brings perspectives. Expectations. Skills.
Experiences. Ideas.
Politics.

31.
WHO?
If your boss says "we're using this
framework", and it's not the best one, you
either have to fight or concede.
If your team already knows a framework
that's not empirically the best, but is still
kinda close, that may be your wisest pick.
Merit rarely wins. Account for this.

32.
The people on a project
ultimately determine
what's practical.

33.
HOW?

34.
HOW?
Every framework has a philosophy behind
it. Based on the context you've gathered,
you'll have a philosophy on how the
project should be done.
Now you're just looking for a match.
You'll make better code that way.

35.
HOW?
Beyond a certain level of competence-
based best practices, it's not worth
worrying about how pundits write their
code.
If you don't like a popular approach, don't
use it. If you do like it, use it.
You're the one writing the code, after all.

36.
Pick the tools that
encourage the kind of
code you can enjoy.

37.
REPEAT

38.
REPEAT
You'll hopefully only choose a framework
once, but you should be asking those
questions routinely.
Every quarter, or at the beginning of every
sprint, whatever pace helps keep you
confident you're on the right track and
making the right software.

39.
REPEAT
But now, the hard work is done!
All you have to do is implement the ideas
you decided on. But since you did all that
work, the programming will be easier.
You've made the software, you just need
to write the code that powers it.

40.
LAST THOUGHTS

41.
LAST THOUGHTS
I always like to end
on some little
summarizing
thoughts.
Some oblique
strategies for
software
engineering, if you
will.
And I will.

42.
Immediately why,
Eventually how

43.
When faced with a
problem, ask why
the problem exists
before jumping to
solve it.

44.
Pick the boring option

45.
Practicality is a valid
argument. When
working with many
others, a less
interesting option
may be the best.

46.
Software is human

47.
Software has a
personality. It's
more than just
code, it's all the
decisions and
context that went
into it. Understand
those, understand
software.

48.
Also:
Software has a life.
It will grow up.
It will grow old.
You can give it the
best chance of
success, but
ultimately, it's out
of your hands.
Accept this.
Embrace this.

49.
TWEET AT ME: @HUPFEN
YELL AT ME: ZOE@HUPFEN.COM
Presentation template by SlidesCarnival
Photographs by Death to the Stock Photo