The Stack

By: Gil Pinheiro

Sitting down to start a new project, as a software guy, always feels like a tremendous opportunity. You want to try out the newest and latest greatest things that will fix the all the problems of the last project. You spend a few days reading and writing stub implementations of new-fangled ideas, but in the end you just discover new problems.

Of course, this also happened here at Pushrate. I set out to survey the state of web service development and try and pick up the new ideas that would help save time and effort.

For the first time, though, I found a landscape made much more complex but not more efficient. It isn’t like I've been away from the cutting edge for very long, our last project used ember and was largely api driven. I had kept up with developments like react, angular, web components so there was not expecting any surprises.

And I guess there wasn’t any new paradigms or techniques. The surprise is how tall of the stacks have become.

When you choose a toolkit now you are choosing a whole ecosystem. If you want to react, you are doing it on the server and on the client. If you use ember you are steered toward their build tools and compatible libraries.

This is happening because we have stretched the standard abstractions past their breaking point. The assumption that client and server are disparate that is implied by rendering html on the server is not dependable. Libraries are forced to build abstractions on top of the standards to implement the paradigm that they want, but because there is no ‘standard’ interface they each library is completely on their own. Everything in that stack that layers on top is incompatible with all the other libraries out there.

Blue sky time

It is a kind of disease to think that a better abstraction can solve all the problems. No developer is immune. I can only hope to be self aware.

10 years ago it was best practice to have a site that worked with or without javascript, and heck, even looked good/worked in a browser like lynx. I don’t mention it because I’m focused on backward-compatibility or would want to prevent innovation/evolution. The point I want to make is more subtle than that.

Our mantra has been standardization. We advocate and promote web standards in the hope that open technology will allow competition. We hope that competing implementations will result in innovation. The fear is that they cause fragmentation. Both are the case, and the balance and cost vary with each revision but such is life.

So we continue to build and enforce standards to pay service to the idea that competition brings innovation. What people seem to forget (or at least neglect), is that standards are not enough. Simple standards are what drive innovation.

The depth of our stack

We’ve seen things like CORBA and SOAP and heck even XHTML come and go. Complex standards are not worth the tremendous stacks of paper they are printed on. Standards are meant to be building blocks. If a standard is too complex, it will become resistant to innovation.

If I could fix the web, it would be by enabling smaller layers of standardization that can then cope with the applications that people are actually building today.

The best I can imagine is by dismantling our current standards. Converting the browser into more modular and extensible application platform. The stack is too damn thick. The logic contained in the browser would be broken down into small and simple apis, tied together by the web assembly standard.

More like the way NeWS or postscript itself worked. Providing a simple api for screen rendering, fonts and sounds porting distributable versions of html rendering, etc. on top of that. Browsers can focus on a well specified API footprint, and web standards then become libraries that run on top of our common virtual machines. Layers are the important abstraction, and can be shared by many different stacks.

I know what I’m saying has grave implications. What we lose might be more than we gain, to be honest. ‘Inspectability’ becomes much more of an option than a certainty. It much more closely mirrors traditional software development. At least we’d stop playing dressing up a document-oriented language as a viable application framework.


So this time around I’ve decided to avoid doing anything radical, and to use tried & tested technologies that match the existing medium whenever possible. I see that using react or one of its variations could have benefits, but I think it is one step too far down that path of abstraction - it increases the depth of the stack to the point that I can’t fully intuit what happens during the lifecycle of the application. Over the next weeks I’ll be talking more about each piece of our particular technology stack. I just needed to rant a bit first.

Back to Post