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

Building Webgames

In the recent years, WebGL became stronger than ever. With a number of great frameworks to support you. We recommend taking a look at ThreeJS and BabylonJS.

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 startup maturity, maybe when the company reaches phase II or phase III and there is more budget and a need for a better app, you can proceed 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!

The post 8 areas of Typescript: VR, IaC, Extensions, Robots, Games, WebAssembly, runners and cross-platform. appeared first on Codenteam.

Typescript is a popular programming language that was developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, meaning that any valid JavaScript code is also valid Typescript code. So, why would you want to use Typescript instead of just sticking with JavaScript? Here are a few reasons:

Strong Typing and Type Safety

One of TypeScript’s core strengths is its static typing. In JavaScript, variable types are inferred during runtime, which means you might only discover certain bugs after deploying the code. TypeScript’s type system, on the other hand, introduces types at compile time, allowing you to define the expected types of variables, function parameters, and return values. For instance, if you define a function parameter as a string but accidentally pass a number, TypeScript will throw an error before you even run the code. This proactive approach to error-checking reduces the likelihood of runtime bugs and enhances overall code quality, making applications more resilient.

One of TypeScript’s core strengths is its static typing. In JavaScript, variable types are inferred during runtime, which means you might only discover certain bugs after deploying the code. TypeScript’s type system, on the other hand, introduces types at compile time, allowing you to define the expected types of variables, function parameters, and return values. For instance, if you define a function parameter as a string but accidentally pass a number, TypeScript will throw an error before you even run the code. This proactive approach to error-checking reduces the likelihood of runtime bugs and enhances overall code quality, making applications more resilient.

Furthermore, the benefits of strong typing extend to improving developer productivity. TypeScript’s type definitions serve as a guide for what each variable, function, or object is meant to represent. This self-documenting nature is invaluable in complex projects where different parts of the codebase interact frequently. Developers can understand, at a glance, the data expected in each section, which is particularly useful for onboarding new team members or revisiting code after a long break. By adding this extra layer of clarity, TypeScript makes collaboration easier and reduces the learning curve for understanding someone else’s code.

Enhanced Code Editor Support and Developer Experience

TypeScript also benefits from exceptional editor support. Code editors like Visual Studio Code, WebStorm, and Atom offer a rich TypeScript experience with features like intelligent code completion, real-time error highlighting, and advanced refactoring tools. Unlike JavaScript, where the editor may only guess what a variable might represent, TypeScript’s static types provide concrete information, enabling the editor to offer more accurate and useful suggestions. This means that you can spend more time coding and less time correcting minor errors, as the editor catches them in real-time.

In addition to reducing errors, these editor features significantly boost productivity. For instance, autocomplete allows developers to write code faster, while refactoring tools help reorganize code seamlessly, making TypeScript a developer-friendly language. TypeScript’s editor support extends beyond just syntax—it helps developers explore the structure of their code with features like jump-to-definition, parameter hints, and quick info, which provide helpful popups on variable types, function arguments, and more. This rich ecosystem makes TypeScript an appealing choice, particularly for large projects or when working in team environments where seamless code navigation is essential.

Reduced Debugging Time and More Reliable Code

A primary advantage of using TypeScript is its ability to catch bugs at compile-time, reducing the time spent on debugging. JavaScript’s dynamic typing can make complex bugs challenging to locate, especially when they involve incorrect data types or unexpected function arguments. TypeScript minimizes this risk by catching these issues early in the development process.

For example, if you attempt to call a function with an incompatible argument type, TypeScript will flag this before the code is executed, preventing errors that might otherwise appear in production.

The reduced need for debugging contributes to TypeScript’s reputation as a language for building more reliable and maintainable code. By highlighting potential issues during development, TypeScript allows developers to address problems before they escalate, resulting in cleaner, more stable applications. This reliability is particularly beneficial for applications that require high uptime and resilience, such as e-commerce websites, financial applications, and other mission-critical systems. In these cases, TypeScript can serve as a safeguard, reducing the likelihood of type-related issues reaching production and impacting users.

Improved Code Maintainability and Refactoring

TypeScript’s type system and strong editor support make it easier to maintain and refactor code over time. In traditional JavaScript projects, refactoring—changing the structure or design of the code without altering its behavior—can be risky, as there’s no built-in safety net to prevent type-related errors. With TypeScript, however, developers have the assurance of knowing that the compiler will flag any inconsistencies introduced during refactoring. This confidence enables more frequent and reliable refactoring, which is essential for keeping the codebase clean, organized, and easy to understand.

In team settings, TypeScript’s type safety allows multiple developers to work on different parts of the codebase without introducing compatibility issues. When one part of the code changes, TypeScript can automatically highlight any affected areas elsewhere in the project, ensuring that all components remain compatible. This interdependency awareness reduces the risk of breaking code in other parts of the project, making it easier to scale applications without accumulating technical debt.

Built-In Documentation and Better Code Readability

TypeScript’s type annotations serve as implicit documentation for your code, improving code readability and making it easier for others to understand how your application is meant to function. When developers encounter a function, they can instantly see the types of its parameters and return value, which helps them understand its purpose and limitations without needing additional documentation. This is especially valuable for new team members or external contributors who need to familiarize themselves with the codebase. Type annotations provide a clearer understanding of expected inputs and outputs, reducing misunderstandings and making collaboration smoother.

Moreover, with TypeScript, your code is inherently more readable. By defining types explicitly, you make the code easier to follow, even for those who didn’t write it. This increased readability helps teams work more cohesively, as everyone has a shared understanding of the data structures and operations involved. Type annotations reduce the cognitive load on developers, freeing them to focus on the actual functionality rather than deciphering what each variable represents.

TypeScript’s Growing Ecosystem and Community Support

TypeScript’s popularity has led to a robust ecosystem of tools, libraries, and frameworks designed to work seamlessly with it. Many major JavaScript libraries now offer type definitions, which means you can use TypeScript with minimal configuration. Libraries like React, Vue, and Express have TypeScript-compatible versions or support, allowing developers to bring TypeScript’s benefits into any part of the stack, from the frontend UI layer to backend APIs. The TypeScript community is also active and supportive, with a wealth of resources, tutorials, and forums that make it easier for newcomers to learn and adopt the language.

Beyond individual libraries, TypeScript also works well in various architectural patterns, like monorepos. For example, TypeScript is frequently used in monorepo setups, where multiple projects—such as libraries and applications—are managed within the same repository. This organization method benefits from TypeScript’s type-checking and modularity, as it allows for shared types and interfaces across projects, reducing redundancy and ensuring consistent data structures throughout the codebase.

But is TypeScript a frontend or backend language?

The short answer is that TypeScript can be used for both frontend and backend development.

On the frontend, TypeScript can be used to build web applications using JavaScript frameworks such as Angular, React, or Vue.js. TypeScript can provide a number of benefits when building frontend applications, including improved code readability and maintainability, as well as catching errors early in the development process.

On the backend, TypeScript can be used to build server-side applications using Node.js. Just like on the frontend, TypeScript can help improve the quality and reliability of the code by adding type checking and other features.

So, to summarize, TypeScript is not exclusively a frontend or backend language, but can be used for both types of development. Its primary purpose is to add additional features and type checking to JavaScript, and it can be used in a variety of contexts, including frontend web development, backend server-side development, and even mobile app development.

How to organize code written in Typescript?

All the benefits we listed above about why to use Typescript, makes a perfect language for big teams, we recommend reading this post about monorepos and release management, as Typescript is a great language to use in a monorepo structure that combines multiple libraries and apps in the same place

Can Typescript do more than that?

We have written an extensive post about using Typescript in multiple fields like VR, IaC, Extensions, Robots, Games, WebAssembly, runners and cross-platform.

The post Why Typescript? Is Typescript Frontend or Backend? appeared first on Codenteam.