Back Story

I got into programming while I was in graduate school for sound design. There's this graphic programming language used by many experimental sound artists called Max. Back then it was called Max/MSP and now it's exploded to do video/image manipulate and has direct integration with a widely used audio app call Ableton Live.

As a sound designer and composer, there wasn't a tool for someone like me to create sound art for theatre. I had to come up with quite a few tricks to get close to what I wanted. So I decide to learn computer programming and build the ideal tool for me.

This lead me to build programs in Objective-C, C++, and Swift. Some fully fledged standalone applications, and some that were audio plugins.

Switching to Web

As I have very recently switched to web programming, mostly backend work, I've noticed a few major differences.

Micro Services

Most programs on platforms are entirely self contained. Sure there's the occasional program that does a web call, or uses a dynamic library on your computer. And of course there are projects that are modularly built, in a very SOLID principle kind of way. But for the most part, everything is right in front of you and usually in the same language.

This was difficult for me at first to wrap by brain around: micro services. Granted I'm very new to web programming and may be wrong about this, but it seems that all web sites are built this way. Separate parts are completely different projects, often in different languages, and even on different machines, all communicating via web calls.

You have your UI project(s), which calls a BFF, which calls a backend or backends, which may call other backend APIs and may call a database. These are all separate projects, some of which you may be consuming and not building yourself. For example, there are a ton of technologies you can use for styling so you don't have to write any css yourself.

Not only are sites separated this way, there are developers that strictly only work on that part of the tech stack (eg: backend, devops, frontend, etc). You can work exclusively on one of those parts and know absolutely nothing about the others.

Languages

In most platform programs, you write it in a single language. Granted there are many UI's built with XML and many IDE's have some graphic programming environment for building out the interface (eg: Xcode).

When it comes to web programming, the number of languages stacks up quickly. You have your backend in C#, frontend in typescript (which is just javascript with extra features), JSON for setting environment variables, yml for IaC/SaaS. Oh and don't forget: javascript, markdown, html, and css.

Data

In most desktop/mobile applications your data is generally in memory. Sometimes you access data via a file, but for the most part that's for loading/saving your data. There's also user preferences, which can be handled a few different ways, but ultimately it's a file somewhere on your hard-drive.

With web programming, I've found this to be very different. Your data is usually on some database (MongoDB, DynamoDB, SQL, etc) that is located on some server (depending on what solution you're using).

Using a simplistic example, you have an endpoint that you call to get data. Your endpoint becomes an abstraction for calling your database and returns the data. In a .NET API, you would get the data as a JSON, converted to a model class in C#, then converted back to JSON for the return.

Abstraction

This was the most difficult part for me. If you have a C++ program, you know exactly where the program starts and can follow the flow of execution fairly easily (granted game loops, callbacks, and the like can make this much more complex).

When I started learning .NET and C#, I kept getting tripped up with one question, "How/Where did [this method or class] get called?". In the platform world Singletons are frowned upon. But in the backend .NET world, they're a necessity.

You can have an API with multiple controllers that almost work like independent entities that have a selection of CRUD endpoints for a client to call. Depending on the API, you can think about the controllers in isolation.

Technologies/Options

After seven months of web programming, I've noticed that there are soooooo many tech options for doing any one thing. Many developers have very strong opinions about which of these technologies are better than the others.

I've spent much more time learning different libraries/frameworks/tools then learning different programming languages.

Conclusion

Web programming has been really daunting for me. I've been able to rely on my programming chops, problem solving, and eagerness to learn. Maybe it's no different than when I first wanted to learn programming and had to sift through the different languages then.

Ultimately, I find the difference to be with platform programming I'm focused on the how, while with web I'm focused on the what.

• How do I make X happen?
• What do I use to make X happen?