Date post: | 13-Dec-2014 |
Category: |
Technology |
Upload: | codemotion |
View: | 284 times |
Download: | 4 times |
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