Why TypeScript, why MEAN?

July 2017

To understand how we came to this point in 2017, where it's a good idea to use the tsmean stack, we first need to unfold a bit of history.

Different languages

Have you ever wondered, why backends are written in Java or Python and frontends are written in Javascript? Doesn't that seem inefficient to you, to use different languages across one and the same project? Especially in smaller teams, this language barrier often builds a wall between backend and frontend developers and artificially pushes people into one of those categories. Compare it to real languages, isn't it useful that English is the de facto standard in the development community? Wouldn't it also be useful if everyone would speak the same programming language?

Or imagine having written a routine for your Java server, but now you think you'd rather run it on the client. You'll have to rewrite the entire code. It would be much easier to migrate code between client and server if they both would speak the same language.

The problems don't end with the code itself. Everything around the code is different as well with different languages. From code editors, to build tools, to dependency management, to community resources, to frameworks.

All of those points together can make it quite frustrating for developers to work full stack. Is there an alternative?

First steps towards compatibility

For the frontend we basically don't have any other choice than to use Javascript, since this is the only language that the browser understands. For a long time only browsers would speak Javascript, meaning you didn't even have the possibility to write Javascript for the backend.

Along came Node.js in 2009, finally making it possible to write JS on the server. Not only did it make it possible, but it provided some real advantages compared to other languages. Due to the non-blocking nature of Javascript, web-servers written in Node.js could be more resource efficient than their Java or Python counterparts.

However, since Javascript doesn't have the best reputation in terms of scalability (no types, callback hell, ....), the cost of maintenance drastically increased for larger projects. Developers were glad that they could write in a different language server-side and so full stack-Javascript only gained adoption for some few projects.

A new star on the horizon

Remember how I said you don't have another choice for the frontend than Javascript? Well, that was a lie. You just need something that compiles to Javascript. In 2012 Microsoft released TypeScript, an optionally-typed language that does exactly this. The promise was better scalability and maintainability for larger projects.

At first, TypeScript was full of bugs and you needed to be a compiler yourself to spot all the places where TypeScript would fail. Since then a lot has changed and nowadays you can trust TypeScript to do good work. This has led to a strong TypeScript-trend in the frontend world. Here's the Google-Trends chart for TypeScript from mid 2012 to mid 2017:

But TypeScript isn't just a better alternative to JavaScript. It is actually a good programming language overall! Roughly 20 years after the internet hit mainstream, it finally makes sense to talk one language back to front. Now developers can talk to each other. And projects can share code between backend and frontend. And you don't have to switch context anymore. And you can use the same package management solutions. Apply the same knowledge to build libraries. And finally this all comes in a sane and scalable language.

The journey ahead

The bad news is, that we are still at the very beginning of this journey. The developments are still very recent and there are only few good resources on server-side TypeScript development. While it could make sense to write full stack TypeScript, you would be an early adopter with this. This makes it really tough to get started. Which frameworks and libraries should you use? What are best practices? How could you build something that's modular with TypeScript?

This is where tsmean tries to alleviate some of the pain. Basically tsmean provides two things:

One thing we haven't looked at so far, is why the MEAN stack is a good choice. Mongodb is good for prototyping and MySQL is one of the best relational databases. Express is a pretty standard choice for backends in the Javascript world. There are typings available (like for most popular libraries), so it integrates well with TypeScript. Next, the "A", Angular. Angular has for sure the biggest TypeScript community. You could think about not using a framework at all, but the benefits that Angular provides justify it's steep learning curve and will make your application more scalable and reusable. Finally the "N", Node.js, doesn't even have to be discussed, since it's the only viable option to run JavaScript on the server. So that's it, that's why the MEAN stack is the best choice for fullstack TypeScript.

A final word of caution. While I tried to paint a picture in this article that's favourable for full stack TypeScript, as with anything in life there are pros and cons. There are many reasons that speak against full stack TypeScript, such as worse support in IDEs, TypeScript being a superset of JavaScript and thus inheriting many of it's problems, the asynchronous nature of Node.js which is more hard to deal with oftentimes and many more. So of course, you shouldn't make such a decision too hastily. Just know that it's one of your options nowadays.

Interested in web development?