On Large JS Apps

large.md

A few points:

The article really only talks about static vs dynamic languages:

Not everybody is as smart as Gilad Bracha or John Resig and those that aren’t – like this author – are probably better off with writing their code in a statically typed language.

There's no other reason than this on why JS isn't suitable for large web apps.

His article seems to imply that all dynamic languages are not suitable for large apps of any kind (he only talks web apps, but a safe assumption). There are many examples of large apps written in a variety of languages (take anything written in php or ruby).

His only example is inconsistent return types and a claim that unless you are as smart as John Resig, we shouldn't expect people to know to avoid them. If you don't know good architecture, you shouldn't be building a complex UI. Nothing will help you except for experience, deep thought, and maybe a good book and tools (CanJS).

He could have done the same break-up with JS

There was nothing preventing him from breaking up his app from 10 to 100 files in the same way with JS as he did with action script. My guess is he had more experience with best practices using ActionScript which lead him to design the app better.

On what's large and complex

I should not have resorted to using files to talk about an application's complexity. They are only minimally related. A vast website/system could have tens of thousands of JavaScript files operating on as many pages. However, each page could have relatively simple and straightforward functionality, easily implemented in JavaScript that doesn't interface with JavaScript that runs on other pages.

Conversely, the 200 files in the app I referenced almost all interface with each other. Take a look at the filemanager in connect. It can

• do everything a desktop filemangaer can do (drag&drop/ribbon/permissions/etc)
• bookmark your state via the hash
• is live (meaning someone else can make changes and you see them)

In my opinion, a complex JS app is much more complex than a backend system. Why? because of state. A JS app has to deal with much more state and state that can come from multiple directions.

For example, in connect, if a user clicks a folder, it shows the folder's sub folders in the folder tree, and it's files in the file list, it also updates the hash. How do you write the file list and folder tree so they can work independently but not make multiple Ajax requests? Also, lets say you have opened a deep folder and click refresh, how do you load all the parent folder contents and populate the right widgets with as few Ajax requests as possible, but making everything independent? How do you also let the live connection know what you want updates to? How do you keep this memory safe?

The secret: A very powerful model layer that stores model instances and knows which lists have been retrieved (and are currently active by event handlers).

A server has mostly one entry point - a http request. And, it has one exit point - an http response.

So ... the amount of code is only somewhat related to complexity. Complexity is all about how much stuff needs to talk to other stuff.

On upper limits

What I meant by this is that there's an upper limit to the amount of active functionality presented to a user at one time. This puts another upper limit on how much stuff can talk to other stuff at one time in an application. There's complexity in building stuff like a tooltip, or a folder tree. But there's even more complexity in wiring up the tooltip to the folder tree.

Fortunately, the amount of wiring up has a limit because UI designed is constrained by what people can understand.

For connect, every action is felt by almost everything and everything can cause a change somewhere else. If I drew a state machine it would look like spaghetti and meatballs.

So when you say 10ks of files there's no way those are all operating at the same time. Instead, the application will be broken down into parts. The complexity is in wiring up those parts. But, the complexity of wiring up those parts also falls under the same limit of how much stuff can talk to other stuff.

For example, if google was considered one big app, at some point the communication between parts is a simple url - reader, gmail, calendar, docs, etc.

This is typically as simple as a hashchange in a JS app that loads that code into the main part of the page (and tears down what's there).

Conclusion

I'm positive that I can write any existing UI code in JavaScript and make it maintainable. Do you have an example of an application that would be difficult to build in JS? I'd love to do a screen cast on how I would break it down, showing how it can be built piece by piece and assembled modularly.

What's the most complex UI in the world?