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. For example with Java, you'll have to learn about ant or some other package manager, while with Javascript your package manager will be npm or yarn.

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 it 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 young and there are only few good resources on server-side TypeScript development. It totally makes sense to write full stack TypeScript, but you are 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. One thing that has to be said, if you're the ORM kind of guy, then you probably should think about fullstack typescript twice, since there isn't a stable ORM solution for typescript yet. Express is a pretty standard choice for routing in the Javascript world. There are typings available (like most popular libraries), so it integrates well with typescript. Next, the "A", Angular. Angular has for sure the biggest typescript community. The most notable competitors ReactJS and VueJS have almost non-existent typescript communities. So for fullstack ts, Angular is basically the only viable option. 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 in the end. 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. The biggest point of debate is probably which database to use.

Interested in TypeScript?