What's in a tech stack?

What's in a tech stack? We always talk about MEAN, MERN, MEVN, LAMP, but honestly I've never understood the point of these acronyms.

I've been a dedicated front end engineer for 5 of my 8 years of professional development. So I've really only ever cared about one letter of these acronyms (and for LAMP I actually have zero investment). Do I care what language the backend is written in or what database we're using? I really don't! I'm using angular/react/vue/etc. and as long as I get a well formatted response from the backend I don't care.

As a full stack developer, or when working on personal projects, I might have more cause to describe the stack. But I've never described myself as working on a SAC stack (SQL Server, Angular, C#), or a JERN stack (Java, Express, React, Node) (I don't even know what database we used for that one, I was so far removed from the backend it just didn't affect me), or a JRPK stack (figure that out if you can).

The other problem with these acronyms is they don't tell the full story of the stack. Why do we explicitly call out Express in the MEAN stack? Is it because it's more fundamental than any other library/framework we're using? I think it's more likely that MAN is just less catchy than MEAN.

So on that note, what stack am I using for my application? I'm actually owning the entire stack, so for once the entire tech stack actually does matter to me. Rather than try to create a pointless acronym I'll just list out some of the technologies/frameworks/libraries I'm using and why:

react

I've used Angular.js, Vue, and React over the years. And although I've always had a soft spot for Vue, the more I use both Vue and React, the more I find React to be the more complete/powerful option.

tailwind

I've used many languages in the past; sass, less, react-css, linaria, I even wrote plain css one time. But in all honestly, I hate writing css - which is probably a weird thing for a front ent dev to say. There's just something really cumbersome and unmaintainable about it for me. Tailwind offers just the right amount of abstraction between writing css and using something like bootstrap.

It's quite a divisive library, but almost every complaint I see about tailwind is solved by writing small components that remove the classes from my main application code. The components themselves give elements semantic meaning, not the class names - that's the secret.

Most importantly for me, tailwind makes prototyping and rapid development so easy.

react-hook-form

I've not been using this for long but it does the job nicely and it certainly feels like it performs better than formik and redux-form.

I felt its inclusion in this list was necessary because forms are like 80% of almost every front end application.

jpex

I can't write an article without plugging jpex of course, so here it is. Dependency injection is a pretty fundamental part of my architecture which I'll cover another time. I use jpex in both the frontend and the backend applications and it is essentially the glue that ties everything together.

respite

This is a state management solution I built myself. It's similar to react-query, I could have used react-query, and I have used it extensively in the past. But there were a lot of inconveniences and strange decisions that would constantly irritate me.

I also wanted a way to do global state that didn't involve adding another large library, as well as a way to decouple cache invalidation from the mutations.

I don't expect anyone else to use respite, but the more I work with it the more I'm pleased I wrote it! I'll probably cover some of it at a later point.

vite

Worth covering because 99% of apps are built with webpack. Webpack just owns the world of ui building. But I've always felt there are better ways of doing things. I originally played with snowpack when it was still in beta, but when vite came out by the guys behind Vue, I knew it would have the same super-simple api and great docs so I took the plunge.

I love it and I won't be willingly going back to webpack in the future!

node

Node was an obvious choice as it means my entire app is written in the same language. I'm always surprised just how fast it runs too. I've used node for all sorts of cli tools and bits and pieces for many years, so it's always my go-to for most tools and apis.

express

I actually tried out a few alternatives to express but nothing really beats it. It baffles me how a library can just "get it right" first time! Express has been the defacto server library for... ever!

mongo

To be honest, I haven't 100% settled on a database for production. But during development mongo is an obvious choice. It's so simple to set up and use. And you can just start throwing data in it without having to spec out an entire schema or relational mappings.

typescript

Typescript is another absolute fundamental part of the stack. I don't think I could go back to plain javascript at this point in my career. If I ever have to write javascript I immediately feel uncomfortable "What type is this variable meant to be? What parameters am I meant to pass into this function?!" - so stressful.

So there you have it. And of course this doesn't tell the full story. I've tried to include the fundamentals, but there are so many baselines that we just take for granted. Babel, jest, testing-library, these are all just as important as, say, express.

I'm sure you're wondering where next.js is in this list, everybody uses next.js now right? Well not me! I'm a rebel and I will probably cover my reasons why in a future post!

Okay so officially this is the MERN stack I'm using. But that tells you nothing about my actual application at all. Personally I prefer to call this the MERRVJNTT stack.