Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript

Complexity can hurt on the server just as much as the client. The same thing that Shopify experienced with Batman.JS had affected our server-side codebase: uncontrolled complexity stemming from ad hoc design and frameworkophilia. We achieved incredible performance improvements by moving away from server side rendering to a lightweight, in house micro framework [1] and making improvements in our server side API code, going from many tens of thousands SLOC down to one-tenth of that, and from 0% test coverage to ~85%.

AFAICT its very rare to find developers with that unique ability to write truly minimalist code. The natural tendency of almost all of the developers I've worked with seems to be to add complexity and to revel in their ability to navigate that complexity. That's why, given the choice, I try to hire or recommend developers who also have a background in music composition and/or visual arts - people who are motivated more by producing an end product that evokes beauty, not by the intricacies of the medium used to produce the work.

Batman was led by someone who previously worked on the Cappuccinno web framework, which is based on its own programming language (Objective-J) and an attempt to port most of the Cocoa framework over to the web environment. Batman was different, but it might say something about its tolerance for complexity. Cross-compilation from 3rd generation language X to 3rd generation language Y has always been a bad idea imho, and seems to be based on a desire to mitigate the effort of learning, much like the tendency to reach for a framework with the most bells and whistles instead of understanding the simplest way to solve a problem. Trying to counter that tendency towards complexity has motivated a few talks I've done at our local JavaScript meetup [2][3][4] (apologies for being overly self-referential).

[1] https://github.com/darrenderidder/talks/tree/master/jswidget...

[2] http://ottawajs.org

[3] http://51elliot.blogspot.com/2012/08/a-simple-intro-to-mvc-p...

[4] http://darrenderidder.github.io/talks/ModulePatterns/#/

Well, its not often I say I wish I lived closer to Ottawa, but I fully agree with this post, and it was quite nice to see it written down elsewhere.

    >and a lightweight custom JavaScript binding system

I wonder what the reason was for not using a smaller binding library like Knockout vs rolling their own.

Sometimes I wish I can do more server-side rendering etc.

I have been working on single page applications for awhile now; I miss the ease that is afforded by just capturing state through server-side page transitions.

Specifically, with SPAs (existing codebases now mostly), I run in bugs a lot that involve Backbone events: when are they firing, what part of the codebase is firing them, who is ignoring the global state and firing anyway. Sometimes, looking through a call stack is not even helpful. Every project that I worked on had these problems. The last big bug I dealt with involved, for me, an unfamiliar codebase and about a week-and-a-half of sitting with the debugger tracing every line.

While for new projects, you can work very hard to ensure that firing events is hygienic, existing projects might not be so hygienic.

With a server-centric approach, each page load limits the mental load with state. On page-transition, the page state is clean.

While I think frameworks like Angular is very interesting, I tend to question my own ambition personally. Something like the approach that Turbolinks takes might actually be more appealing.

I've just started getting into Cocoa dev after doing iOS for a while and it has more than its own share of warts. KVO is a clunky API that's very inconsistently available and easy to misuse. Interfaces built using auto layout in xibs are very tricky to debug and maintain. There's all kinds of string typing in the APIs which defeats many of the benefits of static typing. And there seem to be a lot of quirks and bugs in the API overall which I'm guessing are a result of Apple shifting its focus to iOS, where the money is.

All in all I'll take the web stack, particularly with the changes coming down the pipe. Javascript with ES6 is a much better language. And if web components really take off then component-based UI development on the web will be pretty competitive with Cocoa.