Enough with the JavaScript Already!

Yeah, so I am not Nicholas Zakas. Here is his video "Enough with the JavaScript Already". This video prompts a lot of strong reactions from web developers. I believe that was the intent. When I first heard it I strongly disagreed, but as I have gone further into the world of JavaScript applications I think looking at this has a lot of value.

The history of web applications, while not long, should be understood. Initially people did everything on the server. The browser was a stupid thin client. Some frameworks had it so that changing a drop down would cause the entire page to be loaded in order to have dynamic content on a page. This sucked so people began to use JavaScript to manipulate the page. This was often hard, but as libraries gained popular acceptance it became much easier. Using XmlHttpRequests also made the user experience of a page much better and much faster. Advances in the speed browsers executed JavaScript also made client programming more viable.

So from a time of everything on the server we did some stuff on the server and some stuff on the client. It turned out that a lot of times this was difficult. Different controls wanted to use different systems of client server communication and client server communication was often difficult and took many forms with REST services living alongside page redraws from POSTs. You had code on the client and code on the server interacting in weird ways that made maintenance very difficult. A lot of frameworks did so much for you communication wise that it became hard to understand what was really going on.

A reaction to this was the single page application. They seemed incredibly easy because the server communication was called out and controlled instead of being hidden. There was no code interactions between the server and the client. With frameworks helping out it became easier to write code this way.

But as I travel down this path I see people view the web server as something that should serve static content and expose CRUD like REST services. But it is inefficient. It doesn't work well. I strongly believe that client server applications that use the browser as a client VM need to use both the server and the client in a sensible way. Here are some real world examples:

TRANSLATIONS

SHITTY: A single page web application starts up. It does a request to figure out what language to use. It does another request to get language resources. Then it translates tags that exist in a whole bunch of templates. One of the reasons for this is because you can't accurately determine what language to use on the client.

LESS SHITTY: A single web page application starts up. The server embeds language inform into the page. The page then translates tags in templates into the right language.

CORRECT: A single web page application starts up. Templates are requested. The server receives template requests with language info in the request. The templates are sent to the client already translated. The server very nicely caches these results allowing large number of clients to avoid the work of translating templates with a very simple caching mechanism. A server framework built with this in mind would be crazy easy to use.

----------------------------------------------------------------

CONDITIONAL TEMPLATES (for mobile or differentiated feature sets for different users)

SHITTY: A page requests everything, all the markup and logic, so that it can figure out what template to display. It loads a lot of resources it doesn't need. You have wasted bandwidth and made your page slow.

LESS SHITTY: You build intelligent code on the client around the loading of templates that either chooses a better template or strips out unneeded parts of the template (Google's Doubleclick uses this approach).

CORRECT: You request a template. The server knows the context of the browser, mobile versus non-mobile, and it knows who you are so it know what templates to serve.

--------------------------------------------------------------------

PAGE CONSTRUCTION

SHITTY: Your basic page is constructed by JavaScript. Maybe your index.html has a bunch of references to other templates. Your page then loads them. All that infrastructure to combine your JavaScript is undone because now you can split up you HTML really well!

LESS SHITTY: You build a system that loads all the templates in one file.

CORRECT: Your initial page is built on the server in terms of simple construction. Then you do more active stuff on the client.

-------------------------------------------------------------------

CACHE CONTROL

SHITTY: You rely on browser caching that is completely out of your control and has been shown to be largely ineffective due to growth of disk size and content amount versus browser cache sizes.

CORRECT: You rely on local storage to do your custom caching using cookies to indicate what parts of your application the server should load. Note that this allows you to serve content in single big files making your application faster.

So while I don't really agree with Nicholas Zakas in all regards I think it is useful to use the server and to think about how the server can make your application work better without increasing the complexity of your application.