First off, let’s get our terms straight. What do I mean by Language Stack? Is that the same as a Tech Stack, or is it more like a Software Stack? Then again, what’s the difference between a Tech Stack and a Software Stack?
Full Stack
A stack is a handy metaphor for the way in which we build platforms and applications in layers, with each layer building on abstracted functionality exposed by the layer below and providing abstracted functionality for the layer above. A full stack web application looks something like this.
You have front end clients that work with back end services. Each is implemented using a stack of technology starting with physical hardware in the base layers, possibly with abstractions of the hardware as VMs or Containers.
On top of the hardware we have layers of general software, such as databases and operating systems, that we almost always run off the shelf.
Finally, we get to our software. There will be some kind of hosting app that runs as a process on the operating system. We could write this ourselves but in most cases we’ll use something off the shelf, like a web server in the backend or a web browser in the front end. The hosting app includes the runtime for the programming language(s) we write our software in. We could write the whole thing ourselves, but in most cases we’ll use common libraries and frameworks to make our life easier. Finally, at the top of the stack is the code we actually write in the programming language determined by the hosting app and frameworks we’re using.
The way I think of this is that the Tech Stack is the whole thing (hardware included), the Software Stack is all the software layers and finally the Language Stack is the programming language dependent layers.
As I’ve discussed previously, when using a truly serverless back end, the only meaningful choices you have to make are what Language Stack to use.
My History with Language Stacks
I first started programming as a kid, in Basic on a ZX81, soon followed by a BBC Micro. I moved on to trying to write games for the BBC Micro in 6502 assembly. The BBC micro was followed by an Atari ST. For some reason I don’t remember, I had a Modula-2 development environment for it, as well as trying to write a 3D graphics engine in Motorola 68000 assembly.
During my computer science degree at Cambridge, I was introduced to a weird and wonderful array of languages. In some cases, languages that the lecturer or their predecessor had created. I remember attending a lecture by the man who invented the subroutine. I was briefly exposed to ML, Scheme, BCPL, Fortran, Prolog and C.
My first encounter with the real world was a summer vacation job writing compression routines for IBM System 360 mainframes in IBM Basic Assembly Language. Throughout my postgraduate work in computer graphics I used C.
When I moved to the Martin Centre, I started using the newly fashionable C++. During one of my early projects, I added support for a high level scripting language to an interactive solid modeller that I’d developed. At the time there were two open source scripting languages suitable for embedding into a C++ application: TCL and Python.
After careful consideration, I decided that TCL was the clear winner. Python’s weird significant indentation syntax would never catch on. At the time of writing, 20 years later, Python is the world’s most popular language. TCL is … not.
Navisworks was originally built entirely in C++ using the MFC UI framework. Later on, we exposed the Navisworks core to Microsoft .Net using C++/CLI and implemented newer application features using C#, first with the WinForms framework and then later with WPF.
Into the Cloud
I first got involved with language stacks for the cloud when Autodesk acquired Horizontal Glue (rebranded as BIM 360 Glue) and Vela (rebranded as BIM 360 Field). Glue was built on a .Net stack while Field used a Ruby on Rails stack. Rails was very much the exciting new technology that all the cool kids were using. The VP that ended up running the BIM 360 group was part of the Vela acquisition, so naturally there was a drive to standardize on Rails. Meanwhile, the rest of Autodesk was gravitating around a JVM stack (mostly Java but with some teams using cooler JVM compatible languages like Scala). Other acquisitions, reorgs and skunkworks projects added Python and NodeJS to the mix.
As BIM 360 Chief Architect, I was asked to come up with one or two recommended stacks to consolidate future development around. I decided that two stacks was the minimum number we could get away with.
First, .Net. A statically typed, high performance, do anything, swiss army knife of a stack. All our desktop technology was either written directly in .Net or in C++ exposed to .Net. Supporting .Net as a cloud stack would make it easy to repurpose existing technology and development teams for use in the cloud. It was also a great fallback for anything that couldn’t be implemented using our second stack. The downside is that development with .Net can be slow. Complex tooling, verbose code, heavyweight runtime, multiple choices to make at every step.
The second stack was NodeJS. A cloud native, dynamically typed, low ceremony, fast development stack. I could have gone for any of Rails, Python or NodeJS. All were already in use, all addressed the same niche. The clear differentiator for me is that NodeJS uses an asynchronous IO, event-driven programming model from the ground up. Idiomatic NodeJS code scales surprisingly well without additional effort. A simple NodeJS server can handle many thousands of simultaneous requests. Using NodeJS also makes it easy to share code between front end and back end.
In contrast, Rails and Python both come from a single threaded, synchronous blocking IO heritage. Idiomatic Rails and Python code can handle one request at a time. More recent releases have added support for multi-threading and asynchronous IO but it’s off the easy path. It takes care and effort to get decent performance. It’s also surprisingly easy to fall off the fast path. Are you sure that there’s no blocking IO calls in any of the third party components you use?
The Choice
The project I’m working on will have a serverless backend with a thick front end client. The initial front end target is a web browser. It’s highly likely that I’ll want to share code between the front end and back end.
There’s only me working on this. I expect I will be iterating rapidly with multiple prototypes, so I want a stack focused on rapid development.
I recommended NodeJS as the BIM 360 preferred dynamic stack. However, I’ve never written a line of JavaScript that made it into production. By the time I became Chief Architect, I had little time to write code myself. The little time I had was spent where it would be most productive, in the Navisworks code base. It’s high time to eat my own dog food and follow my recommendation.
I’m old school. I like to fully understand each layer of a stack before using abstractions built on top. JavaScript is the native language for web development. I want to experience that directly before considering some higher level cross-platform thing that compiles down to JavaScript (like Flutter or Kotlin).
I do want some additional control over the potential chaos, so I’ll be using TypeScript rather than vanilla JavaScript. After 30 years writing in C++ and C#, I’ve come to like and depend on static typing. TypeScript is the lowest impact way of adding types to JavaScript. TypeScript still looks and feels like JavaScript, with types added as optional annotations.
Of course, choosing NodeJS/TypeScript is just the starting point. There’s a huge selection of frameworks available for both front end and back end. That’s a discussion that will have to wait for another day.