Gluing it all together: How teams can buildenterprise JavaScript applicationsMichael LabriolaDigital Primates@mlabriola
Who am I?Michael LabriolaClient Side Architect w/ Digital PrimatesApache ComitterApache Flex PMC MemberCo-Author of a few ...
My GoalMy goal for this session is quite simple:Make you reconsider _everything_ about developingJavaScript applications.
Today’s GoalWe might not have time for that, so I will settle for:Make you reconsider how teams should work whendeveloping...
Enterprise ApplicationsWhy enterprise applications?Sometimes its easier to make a point when you look atthe extremesThese ...
Enterprise ApplicationsWhat do I mean by enterprise applications?Very large systems that are developed over multipleyears....
Enterprise ApplicationsThe applications have many users and roles.There are multiple pathways through the applicationand i...
Enterprise ApplicationsOften intended to be reconfigured for every customer.Often customers have the ability to extend and...
CostsThere are many issues with this sort of system.Maintainability, Scalability, Performance, etc.One thing that also mak...
One size fits all?How similar are these applications to a twitter client?Does it make sense to use the same techniques, fr...
TeamsWhen building a house, I want my architect to be an expertand to work with the tools he or she knows.I want my electr...
TeamsAn application of any significant size requires a team. Theteam usually gets larger as the application gets bigger.“C...
ApplicationAny single-page web application consists of a few pieces,this is how I name them:Σ
ApplicationThere are many ways that these applications are built today,one of the more popular is this:This doesn’t work, ...
ApplicationAt the very least, this is like having a carpenter work underthe advice of an electrician:
ApplicationAnd actually the problem is much worse:
ApplicationI believe that, to be successful, we need a process wheredesigners and developers can work (nearly) independent...
ApplicationThat addresses part of the problem, but ignores somethingvery fundamental.Not all development is the same. Not ...
TeamsEven if you haven’t already, at some point every developerbegins to identify their specialty.Rarely do you find someo...
TeamsWhy?Because being good at one of these things also meanslearning the tools and techniques associated with that craft....
TeamsI believe the way to solve this problem is to choose the righttool for each job.I believe we need to let developers i...
History RepeatsIn embedded systems, the lowest level code and any codethat needs close integration with the hardware and e...
History RepeatsIt doesn’t mean everyone is happy with that solution. InSoftware Engineering, history repeats often:“C is a...
History RepeatsThe use case should determine the technology choice. Notthe opposite.Which brings me to JavaScript. Its an ...
History RepeatsI believe a more effective strategy is to use JavaScript whereit is the appropriate choice.Use it where it ...
History RepeatsWhat if applications could instead look like this:Well, that’s what a few of us have been working on
History RepeatsWe call the idea Randori - @randorijsRandori is a Japanese word which translates most often as‘Seizing Chao...
HTML/CSSHTML/CSS Cross Compiled LanguageCross Compiled LanguageJavaScriptJavaScriptHistory RepeatsIn Randori, our applicat...
For more information follow:Me - @mlabriolaRandori - @randorijsMichael LabriolaDigital Primates@mlabriola
Upcoming SlideShare
Loading in...5
×

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

300

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
300
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Gluing it all together: How teams can buildenterprise JavaScript applicationsMichael LabriolaDigital Primates@mlabriola
  2. 2. Who am I?Michael LabriolaClient Side Architect w/ Digital PrimatesApache 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
  3. 3. My GoalMy goal for this session is quite simple:Make you reconsider _everything_ about developingJavaScript applications.
  4. 4. Today’s GoalWe might not have time for that, so I will settle for:Make you reconsider how teams should work whendeveloping large enterprise JavaScript applications.
  5. 5. Enterprise ApplicationsWhy enterprise applications?Sometimes its easier to make a point when you look atthe extremesThese types of applications have unique propertieswhich cause small changes to be noticed in large ways
  6. 6. Enterprise ApplicationsWhat do I mean by enterprise applications?Very large systems that are developed over multipleyears. Once deployed they often need to be maintainedfor 10 to 15 years.Dozens or hundreds of developers - new developersarrive and others depart routinely
  7. 7. Enterprise ApplicationsThe applications have many users and roles.There are multiple pathways through the applicationand it is too big to download all at once.Millions of lines of code, broken into hundreds ofthousands of objects and functions.
  8. 8. Enterprise ApplicationsOften intended to be reconfigured for every customer.Often customers have the ability to extend and changethe functionality of the system after deployment.
  9. 9. CostsThere 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 fewextra minutes per day trying to identify a typo, it will costonly 500.000 € per year.
  10. 10. One size fits all?How similar are these applications to a twitter client?Does it make sense to use the same techniques, frameworksor approaches to develop all applications?The same paradigms and languages?Why must people feel that there _is_ an answer to thequestion: which framework?
  11. 11. TeamsWhen building a house, I want my architect to be an expertand to work with the tools he or she knows.I want my electrician to be an expert with his or her toolsand techniques.I expect no less from my carpenter, plumber, etc.I would be a fool to make them all use the same tools. WhatI need to do is make them all work together.
  12. 12. TeamsAn application of any significant size requires a team. Theteam usually gets larger as the application gets bigger.“Coming together is a beginning. Keeping together is progress.Working together is success.” -Henry FordTeam members have different skills.Team members have different levels of expertise.To be successful, one must recognize and work with thesefacts.
  13. 13. ApplicationAny single-page web application consists of a few pieces,this is how I name them:Σ
  14. 14. ApplicationThere 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. 15. ApplicationAt the very least, this is like having a carpenter work underthe advice of an electrician:
  16. 16. ApplicationAnd actually the problem is much worse:
  17. 17. ApplicationI believe that, to be successful, we need a process wheredesigners and developers can work (nearly) independently.
  18. 18. ApplicationThat addresses part of the problem, but ignores somethingvery fundamental.Not all development is the same. Not all developers are thesame.
  19. 19. TeamsEven if you haven’t already, at some point every developerbegins to identify their specialty.Rarely do you find someone very good at development andvery good at visual designRarely do you find someone very good at implementingbusiness requirements and very good at performance andlow-level techniques.
  20. 20. TeamsWhy?Because being good at one of these things also meanslearning the tools and techniques associated with that craft.Often, they also require a different way of thinking andusually involve different training.And, especially with large teams, re-training or crosstraining is expensive and does not happen often
  21. 21. TeamsI believe the way to solve this problem is to choose the righttool for each job.I believe we need to let developers in these types ofapplications work in different source languages andparadigms.This isn’t a new idea. It has all been argued before.
  22. 22. History RepeatsIn embedded systems, the lowest level code and any codethat needs close integration with the hardware and extremeperformance 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 thesedevelopers
  23. 23. History RepeatsIt doesn’t mean everyone is happy with that solution. InSoftware Engineering, history repeats often:“C is a crutch. If you can’t write it in Assembly, it’s not worthwriting”“Everything is basically a form of assembly in the end, why not writeit that way to begin with?” ~ Daryl H. circa 1997“He who hasnt hacked assembly language as a youth has no heart.He who does so as an adult has no brain.” ~John Moore
  24. 24. History RepeatsThe use case should determine the technology choice. Notthe 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 learnJavaScript to participate in this type of applicationdevelopment?
  25. 25. History RepeatsI believe a more effective strategy is to use JavaScript whereit is the appropriate choice.Use it where it makes sense. Certainly use it for the lowestlevel 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. 26. History RepeatsWhat if applications could instead look like this:Well, that’s what a few of us have been working on
  27. 27. History RepeatsWe call the idea Randori - @randorijsRandori is a Japanese word which translates most often as‘Seizing Chaos’It’s about blending various elements and redirecting.Not opposing but influencing.
  28. 28. HTML/CSSHTML/CSS Cross Compiled LanguageCross Compiled LanguageJavaScriptJavaScriptHistory RepeatsIn Randori, our applications look like this:ViewCSS DocumentMediatorBehaviorBehaviorBehaviorBusiness LogicBusiness LogicBusiness LogicBusiness Logic
  29. 29. For more information follow:Me - @mlabriolaRandori - @randorijsMichael LabriolaDigital Primates@mlabriola
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×