Gluing it all together: How teams can build enterprise JavaScript applications

Michael Labriola

Digital Primates@mlabriola

Who am I?

Michael LabriolaClient Side Architect w/ Digital Primates

Apache ComitterApache Flex PMC MemberCo-Author of a few books on Internet technologiesAuthor of and Contributor to Multiple Open Source ProjectsFan of Working Apps / Testing GeekArchitect of really, really big single page apps

My Goal

My goal for this session is quite simple:

Make you reconsider _everything_ about developing JavaScript applications.

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.

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

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

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.

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.

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.

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?

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.

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.

Application

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

Σ

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?

Application

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

Application

And actually the problem is much worse:

Application

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

Application

That addresses part of the problem, but ignores something very fundamental.

Not all development is the same. Not all developers are the same.

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.

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

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.

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

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

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?

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.

History Repeats

What if applications could instead look like this:

Well, that’s what a few of us have been working on

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.

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

For more information follow:Me - @mlabriolaRandori - @randorijs

Michael Labriola

Digital Primates@mlabriola