Rebuilding the Shopify Admin: Deleting 28k lines of JavaScript
shopify.com
shopify.com
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...
[3] http://51elliot.blogspot.com/2012/08/a-simple-intro-to-mvc-p...
Too true. I find that the gating factor for development for me is the number of things I have to keep in my head at one time while working with a codebase. So simpler and cleaner abstractions mean that development goes faster with a lower defect rate. Maybe it's because I do have a background in music that I prefer to write minimalist code but I think there are a lot of objective advantages in it.
It also makes me wonder, how we've all decided that HTML is the way to go for this class of application, how hacking a document display format to ape a native UI is a good idea.
I have to think that at some point people think that there has to be a better way to deliver a network transparent, portable UI without worrying about strange things like a Shadow DOM, the hack that is CSS, and all of the other weird shit web developers have to put up with to create something that mimics (usually poorly) a desktop app.
Like is there a breaking point where people are like "fuck it" and come up with an alternative browser that is specific to this and similar kinds of applications? I guess not because the gray line between what HTML is good at and what people need to HTML to do despite itself is a pretty big fat line.
> I have to think that at some point people think that there has to be a better way to deliver a network transparent, portable UI without worrying about strange things like a Shadow DOM, the hack that is CSS, and all of the other weird shit web developers have to put up with to create something that mimics (usually poorly) a desktop app
It already exists : GWT,or you can use something like C++ and the emscripten toolchain,and whatever C++ gui framework. So if you dislike all the js/html/css you can definetly avoid it.And users dont care,provided it runs in their browser without plugin.
Most webdevs wont use these because they already know javascript and there are good frameworks out there.
And at the end of the day it is still a webpage,it's not a desktop app.
The fact of the matter—whether we like it or not—is that these are the tools we have for web development. It's hacks on hacks on hacks, as one might expect in a suite of technologies originally intended for X but arguably powerful enough to perform Y, Z, and Z(2014). Take ECMAScript: the first draft was written up retroactively, quirks and all. Many of the oddities and edgecases were written into the official language spec and vendors were encouraged to implement them as written (thus, intentionally writing engines with quirks).
But the fact remains that no single, "fuck it" has been able to take hold. The technologies we have at our disposal have proven themselves "good enough" to keep that from happening to date. At this point, we've invested ~20 years into these technologies.
And, for what it's worth, there are ways to cut through the cruft. These things can be done moderately cleanly. It is possible to write a web-based application that doesn't make one want to blow their brains out (I'd make the argument that, in a lot of cases if you're trying to write a "desktop app" in the browser, you're focusing on the wrong thing but that's neither here nor there[0]). It's simply that legacy and twisting the language to do what we want and not what it was intended for has caused that to not be terribly straightforward.
I understand you're being hyperbolic but it's been my experience that this mindset ("this is so bad I'm never going to touch it") generally comes from folks who take one look and turn in disgust. That's fine—and I'm not going to argue it's not without it's warts because that would be insanity—but it isn't so bad that you'd need to off yourself, and I think the staying power it has had regardless of quirks, poor design choices, etc., proves that.
[0] - with the right team and the right reasons, it can be done. The Slack desktop app is a pretty good example of when it makes sense and is done quite well.
Browsers were said to render the OS irrelevant and in a way Chromebooks come close to that.
We were also supposed to not owned & store any software locally and rent & download everything. Office Online, Creative clood are there.
But things are rarely that radical and the web was there and opened. I prefer desktop apps (and I'm a web developer !) but how can you beat the ability to login to any of your web tool from any computer ?
Honestly, I challenge anyone to write a simple UI (lets say draw a circle and put some text on the screen) that just works across ALL major operating systems, screen sizes, versions, etc.
If do actually end up doing it in anything besides "web" languages, its going to be more complicated and take longer as well....
To make a car analogy, The Chevy small block V8 engine was/is never the best, fastest, most efficient engine. It's just that for the past 40+ years they've put the damn thing in every vehicle imaginable. It's pretty ubiquitous in the auto world....It just works and everyone still uses it. Sort of like how you will find a HTML, CSS, Javscript rendering engine in everything today...
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.
The new admin would make a return to more classic architecture with some modernizations. Our approach would be ERB views and server-side rendering, with the use of Turbolinks, and a lightweight custom JavaScript binding system. This allowed us to tackle problems of code duplication and developer productivity in a single blow.
As always, the devil is in the details and I'm looking forward to seeing what their JS binding system looks like, but the pendulum appears to be swinging back towards server-side rendering and models, even amongst the cool kids.
I have been working on a small library for doing HTML partial AJAX programming, using fairly straight-forward HTML attributes and traditional server side rendering (plus some goodies like custom HTTP header support, timers, etc.):
I'm using it successfully in a few projects and very much enjoy the simplicity of the whole approach when contrasted with full MVC systems.
Clearly at this point both architectures work, it's childish to see this as an argument for server-side rendering. Obviously it works, so do client MVC systems.
The value in this article is the humble detailing of their mistakes that many of us also experience in our careers.
I've had to deal with more than my fair share of crappy, hacked-together Ember apps that were developed like this. There have been too many breaking changes to upgrade, performance is bad, an they're full of hacks to work around deficiencies that existed back then.
Even though we actually have production-ready frameworks now, that sort of thing can leave a bad taste in your mouth. Especially when you see the same mistakes made by people jumping onto the Meteor bandwagon, for example. But it's defintiely something to try and get over :)
In many ways this is the same as Rails Apps have traditionally been very much tied to Rails.
Having worked on many Rails Apps that have grown beyond the scope of the framework, the apps I build today are as decoupled as possible from the framework.
I hope that the Ember community can grow in that direction too, and at a distant look, it feels like Web Components will be that method of decoupling.
Right now I tell everyone that I'd never render HTML (or JS) on the server, and I hope that JS frameworks will keep maturing with my clients' needs, so I don't have to renege on that approach.
Worse, 'cool kids' implies doing something because someone else is doing it rather than because it's the right thing to do in your organisation. It smacks of cargo cult behaviour - copying actions and hoping to get the same end result without understanding why.
>and a lightweight custom JavaScript binding system
Most frameworks weren't even at 1.0 stable yet. I initially wrote a fairly extensive prototype with Ember, but there were breaking changes so frequently I couldn't keep up with the learning curve. In the end I chose Angular because it had the best documentation, Google dogfooding, and testing was an obvious priority. Worked out so well we're on our 4th major Angular app now.
It's a really tough call. I've been wrong (and right ;-) multiple times going down either path.
The last time I had to make that sort of choice we went the set-based design / real options path and developed both in parallel for as long as we could. More expensive, but lower risk. I'm glad we did coz the decision we made four months in on which one to drop wasn't the one we would have made at the start.
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 don't see a SPA vs Server side rendering debate in the article. Building your own framework was the problem, is not a core competence of Shopify to build JS frameworks. Maybe they could choose other route, like going with React or Angular there.
https://github.com/gigablah/generator-dashing-go/blob/master...
I've been toying with the idea of replacing the whole frontend with something much more lightweight. Perhaps a good time for me to play with Mithril or React...
The problem with this is that it makes client and server tightly coupled.One cannot update the client app without touching the server code.
I understand that's a tradeoff but I think a restful architecture serving only json/xml data is better. And you dont have to duplicate logic that much.If any validation needs to happen clientside,create some validation resource for each model and do it entirely serverside for instance. Even SPAs dont need fat clientside models or a complex service layer on the client.
"These frameworks work well for highly interactive apps with complex user interface requirements. We only needed a small piece of what a full framework would offer."
As you say its a tradeoff...