We are actively using typescript for most of our development work nowadays. Mainly for backend and frontend. In this post, we will discuss 8 more areas where we think Typescript might be the best choice.
Building VR (Metaverse webapps)
Building your first VR WebXR app can be quite painful. Should you write the app in a game loop sequencing design pattern, or deal with it as a normal Web App and use something like MVVM? Should you use WebGL directly or stick to a framework?
Although for us using A-Frame/Angular combo is unparalleled so far for WebXR and even hybrid VR apps, we encourage the reader to test a POC first before taking a complete headfirst dive into this stack. It can have limitations and worse performance than native apps.
With that being said, A-Frame/Angular combo provides all the latest and greatest powers of both worlds. As well as very strong typing support to make sure you are always covered while developing. Being a Web system, you can share the setup between your VR to your development environment through a browser proxy and having HMR or hot reload to see everything in real time on the VR. Super practical and efficient!
Even if you aren’t developing a VR webapp, but a regular webgame game, Typescript has your back
The beauty of developing in Typescript is how great this would integrate easily with everything else. For example, if you need to create a websockets implementation for multiplayer communication, you can share all your business logic between the game, the backend and any publicly accessible dashboards or real-time players monitor.
You can then take your code and deploy it as a hybrid app on desktop or mobile, although we don’t recommend doing that for a performance demanding game as current WebGL frameworks are not as efficient as super powerful native game engines (Like Epic/Unreal Engine, Unity, etc)
Still, building non-game apps on desktop using typescript, is a breeze!
Hybrid cross-platform desktop apps
With Slack, Skype, VSCode, Loom and many more great apps using Electron. Node/Typescript is becoming our go to language for Desktop apps as well. Write your web app once, deploy it on desktops without hassles. Although this isn’t quite the case on mobile side. There is a lot to consider before you decide to use Typescript for a mobile app, more on that later.
A cool idea to consider here, is to couple your Electron GUI with your frontend code. And abstract your OS/Process bindings somewhere else. This way, you can easily inject whatever you want by just providing a different implementation in Electron, Backend, mobile, etc.
On Desktop, our only recommendation is to see if your app would need native performance. In that case, other options might be better. From our experience, most of the apps work great in electron. If specific tasks need native performance, you can spawn a process for those parts directly. That’s much easier than writing the whole app in native code.
Performance also means GUI layer, if you need a super fast and efficient GUI, maybe consider an alternative. For example a DirectX powered WPF app can be much faster on windows. So choose smartly.
With that being said, Electron is great, super mature, would do all you need and more if the performance difference wouldn’t be an issue for you. On the other side, packing hybrid cross-platform mobile app might not be as good.
Hybrid cross-platform mobile apps
Although using Electron on desktop now is a very viable option, and maybe the preferred option, to most companies now. Hybrid mobile apps, whether it’s Ionic, React Native or Cordova, is usually a step in your path of finally deciding to create a native mobile app. Or at least that’s what AirBnb eventually decided after being one of the leading companies that used React Native before sunsetting the usage in 2018. Not just Airbnb, but lots of other companies as well.
We encourage the reader to go through the post in detail to understand the current limitations and if those limitation would affect your next project or not. If not, a hybrid typescript approach will give you very quick a head start.
What we always recommend to our customers, is always going hybrid for your MVP, always! Specially if you have limited budget, as you can use the same code to build web, desktop and mobile.
And at some point of maturity, maybe when the company reaches Chasm I or Chasm II and there is more budget and a need for a better app, you can start with building the native mobile App.
“But I don’t want it as an app, I want to have more control in a browser, using Typescript!”
Well, You can try writing your next extension in Typescript.
Browser Extensions
Extensions are written in Javascript by default, so using Typescript for that is super straight forward.
You can easily share your Frontend code as-is in your extension script, and then go one more step and abstract your Browser API code to use in background.js, so you can easily replace this abstraction layer on and share it on mobile, desktop app.
A cool trick here, you can try hjson (Or any other json extended-languages) to write your manifest so you can comment parts of the file and even automate building multiple json out of the hjson.
An even higher level, is to use typescript to write your json files as well, your manifest generation logic kept somewhere in your monorepo as, again, typescript code. Much less re-writing, much higher level of control on json generation.
“But I want to write native code, not extension, using Typescript, to run fast, but in a browser!”
Well, Webassembly is here to the rescue.
Webassembly
Webassembly in short is running your code almost natively (more precisely in WebAssembly bytecode) outside the browser engine. This way your code can perform better than Javascript running in the browser’s JS engine (For example Google’s V8 engine).
TL;DR: If you need great webassembly support, don’t use typescript, or be very careful.
We wanted to start with the statement above before explaining what are the latest Typescript trends on that side so you don’t take that as a direction. It’s impossible to write WebAssembly in Javascript, as WebAssembly requires typed code to be compiled statically and ahead-of-time. Javascript doesn’t have any types in compile-time, so that isn’t possible. With Typescript, it’s possible but typescript support on webassembly side is not great yet (Although AssemblyScript is getting stronger by the day), but it’s not there yet. So I would recommend sticking to C++ or Go or whatever your preference is for now until Typescript is as powerful on Webassembly side.
The reason for that is WebAssembly nature, which is to run everything as native. To understand this, use C/C++ mentality, where if you missed deleting an initialized variable, it won’t be garbage-collected. If you casted something into a wrong type, you are doomed. If you tried to reach an illegal memory location, you will get segmentation fault, and so on. This whole compile-time/runtime mindset is essential to write a successful webassembly app.
All of those concerns aren’t usually in mind of a typescript mindset, as all of those don’t usually need a lot of attention in typescript. However for webassembly those are the core of your thinking if you want good webassembly code.
Because of that, you just can’t take a library you have written in typescript and use it in AssemblyScript, most probably you will need a lot of re-writing. AssemblyScript is a small subset of Typescript. So, it will be worth it to do a POC of your idea first and see if those limitation will affect you or not. Our recommendation is to go with C++ or Go for your next Webassembly project, but we think very soon AssemblyScript might take over on that side as well.
Now that you have your backend, web-app, game, desktop app and mobile app. You want to deploy and distribute, right? Well, use Typescript!
Writing task runners, IaC and Deployment scripts
Years ago, the usual practice was having your code somewhere, task runners somewhere else in another language because the code language doesn’t support good enough task runners, then writing IaC maybe in terraform, and finally some CI/CD using some yet another task runner or tool like Travis, Github actions and so on.
Although this is still a very acceptable setup, but you can write all of that in a typescript ecosystem. You can use Gulp/Grunt as Task runners, and they do really good job on that side. The beauty of that is you can integrate the task runner in code as well, for example image optimizations can run on passive/scheduled bases outside the app, or imported and used directly in app seamlessly without a single line of code re-written!
On IaC side, writing terraform or cloudformation can be really optimal for small projects, but once the project gets bigger, going one level lower and writing infrastructure as Typescript code, gives you much much more control on your infrastructure and allows you to again share specific parts (Like configurations) between your app code and IaC.
Finally, on deployment side, you can write platform independent typescript to do your deployment. This way, if you moved from Github to Gitlab you don’t need to rewrite Github actions in Gitlab CI/CD. Also if you want to move from Travis to Jenkins, you don’t need to rewrite complicated parts of the deployment script. You only the hooks and the initiators and that’s it!
But what if you want to deploy to, hmmm, maybe a robot instead, can I use Typescript? ABSOLUTELY!
Robotics
We aren’t specialized in Robotics or embedded systems, but we wanted to get this one extra level to show the areas Typescript explored that we find super amazing.
With CylonJs, you can write you next Arduino app in Javascript, if you are an expert, you can go one more level and write your code as typescript but be very careful as CylonJs typings support isn’t great, so splitting your business logic out, and abstracting your native code for connections and stuff, needs to be very sophisticated to be able to finally pack the app and deploy it.
We can’t recommend nor oppose CylonJs, we see this is a great way to jump into the world of robotics with nothing other than your usual Yarn and Typescript knowledge.
Conclusion
The future of typescript has never been that bright! Giving you the greatest of all worlds. Let it be apps, games, backend, frontends, VR or even embedded robotics! With the daily advances on ESM, code packers and transpilers for typescript, we think now might be the best time to do your research for a possible migration. In all cases, a quick POC of whatever you need to build is important to make sure you are doing the right decision.
Are you using Typescript now in even more areas? Let us know in the comments below!
