Should everyone write code in one language? Would you hire a team to build a house with only hammers? Companies, large ones, are trying to port huge systems to the browser. Is one language really the perfect tool for presentation and business logic? This session disagrees with the single tool premise and discusses an approach to help companies integrate existing skills, web standards, and resources with different skills together, and still target the browser.

1. Gluing it all together: How teams can build
enterprise JavaScript applications
Michael Labriola
Digital Primates
@mlabriola

2. Who am I?
Michael Labriola
Client Side Architect w/ Digital Primates
Apache Comitter
Apache Flex PMC Member
Co-Author of a few books on Internet technologies
Author of and Contributor to Multiple Open Source Projects
Fan of Working Apps / Testing Geek
Architect of really, really big single page apps

3. My Goal
My goal for this session is quite simple:
Make you reconsider _everything_ about developing
JavaScript applications.

4. Today’s Goal
We might not have time for that, so I will settle for:
Make you reconsider how teams should work when
developing large enterprise JavaScript applications.

5. Enterprise Applications
Why enterprise applications?
Sometimes its easier to make a point when you look at
the extremes
These types of applications have unique properties
which cause small changes to be noticed in large ways

6. Enterprise Applications
What do I mean by enterprise applications?
Very large systems that are developed over multiple
years. Once deployed they often need to be maintained
for 10 to 15 years.
Dozens or hundreds of developers - new developers
arrive and others depart routinely

7. Enterprise Applications
The applications have many users and roles.
There are multiple pathways through the application
and it is too big to download all at once.
Millions of lines of code, broken into hundreds of
thousands of objects and functions.

8. Enterprise Applications
Often intended to be reconfigured for every customer.
Often customers have the ability to extend and change
the functionality of the system after deployment.

9. Costs
There are many issues with this sort of system.
Maintainability, Scalability, Performance, etc.
One thing that also makes it unique is cost multiplication.
At one of my larger clients, if each developer spends a few
extra minutes per day trying to identify a typo, it will cost
only 500.000 € per year.

10. One size fits all?
How similar are these applications to a twitter client?
Does it make sense to use the same techniques, frameworks
or approaches to develop all applications?
The same paradigms and languages?
Why must people feel that there _is_ an answer to the
question: which framework?

11. Teams
When building a house, I want my architect to be an expert
and to work with the tools he or she knows.
I want my electrician to be an expert with his or her tools
and techniques.
I expect no less from my carpenter, plumber, etc.
I would be a fool to make them all use the same tools. What
I need to do is make them all work together.

12. Teams
An application of any significant size requires a team. The
team usually gets larger as the application gets bigger.
“Coming together is a beginning. Keeping together is progress.
Working together is success.” -Henry Ford
Team members have different skills.
Team members have different levels of expertise.
To be successful, one must recognize and work with these
facts.

13. Application
Any single-page web application consists of a few pieces,
this is how I name them:
Σ

14. Application
There are many ways that these applications are built today,
one of the more popular is this:
This doesn’t work, in my opinion, why?

15. Application
At the very least, this is like having a carpenter work under
the advice of an electrician:

16. Application
And actually the problem is much worse:

17. Application
I believe that, to be successful, we need a process where
designers and developers can work (nearly) independently.

18. Application
That addresses part of the problem, but ignores something
very fundamental.
Not all development is the same. Not all developers are the
same.

19. Teams
Even if you haven’t already, at some point every developer
begins to identify their specialty.
Rarely do you find someone very good at development and
very good at visual design
Rarely do you find someone very good at implementing
business requirements and very good at performance and
low-level techniques.

20. Teams
Why?
Because being good at one of these things also means
learning the tools and techniques associated with that craft.
Often, they also require a different way of thinking and
usually involve different training.
And, especially with large teams, re-training or cross
training is expensive and does not happen often

21. Teams
I believe the way to solve this problem is to choose the right
tool for each job.
I believe we need to let developers in these types of
applications work in different source languages and
paradigms.
This isn’t a new idea. It has all been argued before.

22. History Repeats
In embedded systems, the lowest level code and any code
that needs close integration with the hardware and extreme
performance is written in Assembly.
Most other code in the device is compiled to Assembly.
This is a fact of life and a successful approach for these
developers

23. History Repeats
It doesn’t mean everyone is happy with that solution. In
Software Engineering, history repeats often:
“C is a crutch. If you can’t write it in Assembly, it’s not worth
writing”
“Everything is basically a form of assembly in the end, why not write
it that way to begin with?” ~ Daryl H. circa 1997
“He who hasn't hacked assembly language as a youth has no heart.
He who does so as an adult has no brain.” ~John Moore

24. History Repeats
The use case should determine the technology choice. Not
the opposite.
Which brings me to JavaScript. Its an excellent language,
but is it the right choice for every use case?
More specifically, must we make every developer learn
JavaScript to participate in this type of application
development?

25. History Repeats
I believe a more effective strategy is to use JavaScript where
it is the appropriate choice.
Use it where it makes sense. Certainly use it for the lowest
level portions of the system or where we need that control.
However, do we need to force our business developers to re-
implement their ideas in JavaScript.
At least for large applications, I say no.

26. History Repeats
What if applications could instead look like this:
Well, that’s what a few of us have been working on

27. History Repeats
We call the idea Randori - @randorijs
Randori is a Japanese word which translates most often as
‘Seizing Chaos’
It’s about blending various elements and redirecting.
Not opposing but influencing.

28. HTML/CSSHTML/CSS Cross Compiled LanguageCross Compiled LanguageJavaScriptJavaScript
History Repeats
In Randori, our applications look like this:
View
CSS Document
Mediator
Behavior
Behavior
Behavior
Business Logic
Business Logic
Business Logic
Business Logic

29. For more information follow:
Me - @mlabriola
Randori - @randorijs
Michael Labriola
Digital Primates
@mlabriola