'.get_bloginfo('name').'

Andrew Hall

0 comments

Future of Web Apps 2014 – Day 2 Session 1 – Scaling Front End Web Apps – James Turner

What is large scale?

Addy Osmani said that large scale Javascript apps are non trivial applications reuwiring significant developer effort to maintain.
In a web dashboard, with controls and graphs and options and grids and all of these have to work together and talk to back end systems. Gmail is another example of a complex web app.
We have taken the old C++ apps and now we run them in the browser but these apps now need to be long lived – if someone has invested 10 million poiuns into a solution, they want to use it for a long time. Features will be changed, added and removed.
When you are writing your app, people will come and go buty also its likely that you will have a large team build of QA, BA, tech authors etc etc
Its not just about how many lines of code it contains.

Architerctural SDolutions

So how do we solve these challenges? We need structure, we need to work together and we need to be adaptable to change.
Developers like developing, but theres no point in developing your own date formatter in javavscript – So code less.

You can also make it modular. Break things down into the smallest chunk and make the functionality available via APIs. Its more important to make sure the different piecesof your application work together, not what features your part of the application has.

For example, GMail has the tabs, menus and lists and searchboxes – so lets split those down into these small chunks.

You can have each part of the application talk using a message bus and this gives us loose coupling between components and allows us to remove a component without breaking the whole app.

Organising features into small parts and putting all of the code into that folder in the filesystem makes it really easy for new developer to know which part of the code to update.
It also allows us to reuse a components across teams.

Also consider abstracting certain features (like rendering). This means you can swap in and out front end libraries of necessary. Don’t tie your application in.

With these small segmented parts of our app, we can know who broke the app and that bug shouldn’t break the rest of the app.

When communicating between different parts of your app, use a known format and use services to communicate. Using services also allows us to test easier, by using mocks and stubs.

To help with this modular system, we can use things like lint and concat and etc etc. But this should be a minimum. Not the end point. We should help developers as much as possible.

Leave a comment or tweet me