|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "Orchestra - The Journey of a Javascript Framework Part 1" |
| 4 | +date: 2015-04-16 15:00:00 +0100 |
| 5 | +comments: true |
| 6 | +author: Andrew Humphreys |
| 7 | +categories: javascript |
| 8 | +--- |
| 9 | + |
| 10 | + |
| 11 | +Recently I've been excitedly talking to my colleagues about Orchestra, a "Super awesome framework" we have built in the Bede Games Studio, so I thought I'd give them all a break a write a blog post about it instead! |
| 12 | + |
| 13 | +<!-- more --> |
| 14 | + |
| 15 | +## What is Orchestra? |
| 16 | + |
| 17 | +The chances are, you're probably reading this wondering what on Earth Orchestra actually is. In a nutshell, it's a purpose built Javascript framework for large scale applications. Harnessing the flexibility of [MarionetteJS](http://marionettejs.com/) framework, it gives us the tools we need to enable us to implement some battle tested patterns for large scale Javascript applications. |
| 18 | + |
| 19 | +It was built with the modularity and flexibility of the Bede platform in mind. Apps are split into smaller reusable components: Chat, Tickets, Countdown etc for the Bingo Client, what this means is, should we decide we want a chat client in another game, we just include the orchestra-chat component and provide its config and 'it will just work'. It has built in support for theming and localisation, allowing us to easily skin up new designs based on existing components. Our Bingo client is a great example of this in action. All of the bingo clients use the same core codebase, with a different theme and language file. |
| 20 | + |
| 21 | +Even in its early days it was clear Orchestra was going to be a great fit for Bingo but now we have taken this a step further with a series of changes, and built our Slots Client using the same framework. The aim of this post is to explain the changes we made and the rationale behind them. |
| 22 | + |
| 23 | +## The battle of the Javascript Build Tools |
| 24 | + |
| 25 | +If I had a £ for every article I've read with this heading as the title I'd be an extremely rich man and would probably be writing this post from my yacht in the Bahamas. So, originally [Grunt](http://gruntjs.com) was the build tool used for all our JS projects at Bede, it was amazing - everyone loved it, but, then something changed... [Gulp](http://gulpjs.com) came along. |
| 26 | + |
| 27 | +Now before you all think this is another case of simply jumping on a bandwagon, let me provide some justification for converting our build from Grunt to Gulp. We know that Gulp provides two main benefits: |
| 28 | + |
| 29 | +1. Code over configuration |
| 30 | +2. Speed |
| 31 | + |
| 32 | +But what difference do these make to our apps? Code over configuration is something that is quite a difficult sell, however take a look at this snippet from our old Gruntfile: |
| 33 | + |
| 34 | +```js |
| 35 | +less: { |
| 36 | + development: { |
| 37 | + options: { |
| 38 | + sourceMap: true, |
| 39 | + ieCompat: true, |
| 40 | + customFunctions: { |
| 41 | + 'assets-path': function (less, path) { |
| 42 | + return '/assets/media/' + path.value; |
| 43 | + } |
| 44 | + } |
| 45 | + }, |
| 46 | + files: { |
| 47 | + 'assets/css/bingostars/desktop.css': ['assets/less/themes/bingostars/desktop/main.less'], |
| 48 | + 'assets/css/bingostars/mobile.css': ['assets/less/themes/bingostars/mobile/main.less'], |
| 49 | + 'assets/css/healthbingo/desktop.css': ['assets/less/themes/healthbingo/desktop/main.less'], |
| 50 | + 'assets/css/healthbingo/mobile.css': ['assets/less/themes/healthbingo/mobile/main.less'], |
| 51 | + 'assets/css/stv/desktop.css': ['assets/less/themes/stv/desktop/main.less'], |
| 52 | + 'assets/css/stv/mobile.css': ['assets/less/themes/stv/mobile/main.less'], |
| 53 | + 'assets/css/betvictor/desktop.css': ['assets/less/themes/betvictor/desktop/main.less'], |
| 54 | + 'assets/css/betvictor/mobile.css': ['assets/less/themes/betvictor/mobile/main.less'], |
| 55 | + 'assets/css/lovebingo/desktop.css': ['assets/less/themes/lovebingo/desktop/main.less'], |
| 56 | + 'assets/css/lovebingo/mobile.css': ['assets/less/themes/lovebingo/mobile/main.less'] |
| 57 | + } |
| 58 | + } |
| 59 | +} |
| 60 | +``` |
| 61 | + |
| 62 | +and compare it to: |
| 63 | + |
| 64 | +```js |
| 65 | +var lessTaskNames = ['cleanCSS'].concat(themeTaskGenerator('less', function (theme, platform) { |
| 66 | + return gulp.src('assets/less/themes/' + theme.name + '/' + platform + '/main.less') |
| 67 | + .pipe(less({ |
| 68 | + modifyVars: { |
| 69 | + 'asset-path': '"/assets"' |
| 70 | + } |
| 71 | + })) |
| 72 | + .pipe(rename(platform + '.css')) |
| 73 | + .pipe(gulp.dest('assets/css/' + theme.name + '/')); |
| 74 | +})); |
| 75 | + |
| 76 | +``` |
| 77 | + |
| 78 | +From our new Gulp task, straight away you can see the reduced lines of code, but perhaps hidden in here is what I would consider a bigger benefit. Notice the list of output files in the Grunt config? This grows with every new theme, but because Gulp is code based, we can simply iterate over a `themes` array. |
| 79 | + |
| 80 | +Something that is not such a difficult sell is the time shaved off our build task. Before Gulp we built 6 themes in a total time of 8 minutes, now, after the conversion, we are building 12 themes in 6 minutes - I think we can class that as a win. There are 2 main reasons for this speed benefit: |
| 81 | +* Tasks are ran concurrently by default, whereas Grunt will only run tasks asynchronously. |
| 82 | +* Gulp makes use of `pipe` which is native in node and most popular OS's. This means that whereas Grunt is required to create temporary files for its tasks, Gulp can pipe a file into its next task. |
| 83 | + |
| 84 | +## The battle of the Javascript Module Loaders |
| 85 | + |
| 86 | +I'm guessing you can see a theme appearing here, yet another well trodden path in the plethora of JavaScript blogs/articles is the comparison of the different module loaders available. |
| 87 | +For me there are 3 main contenders: |
| 88 | +* [RequireJS](http://requirejs.org) which will load in AMD modules |
| 89 | +* [Browserify](http://browserify.org) which will load in CommonJS modules and |
| 90 | +* [Webpack](http://webpack.github.io) which will load anything and everything. |
| 91 | + |
| 92 | +It should be noted that ES6 brings a new module pattern, which the community hopes will bring some unity. It is possible to start using these new ES6 features now with the help of [Babel](http://babeljs.io/) which, will transpile ES6 modules to either AMD or CommonJS until they are widely available. I've dabbled with Babel a bit and have some friends that work on the Babel project, it looks amazing, but we're not switching just yet! :smile: |
| 93 | + |
| 94 | +Originally Orchestra was setup to build using AMD modules with the RequireJS tool, this was something that hindered us for a couple of reasons: |
| 95 | + |
| 96 | +* The modules are loaded at the same time during development vs concatenated during a production build. |
| 97 | +* The build time was around 60 seconds per theme using RequireJS. |
| 98 | + |
| 99 | +Gulp is also unable to run these tasks concurrently, as that isn't supported by the RequireJS compiler. We needed to look at the alternatives. Browserify came up trumps - it allowed us to use the same module pattern across browser apps and Node.js apps and also solved the 2 problems I mentioned above: Your development version is the same as the production build, it compiles and provides sourcemaps (the overhead for the compile step when using [watchify](https://github.com/substack/watchify) is milliseconds) and the build time per theme was reduced to 18 seconds - when you add the benefit of building all themes concurrently, its easy to see why this was a wise move for us! |
| 100 | + |
| 101 | +That's it for part 1, in part 2 I'll cover changes that were made as more apps began to use the Orchestra framework. |
0 commit comments