We were fortunate to play a role in supporting this transformation, helping to implement solutions that align security with a better user experience. It was a collaborative effort, ensuring that compliance processes remain robust while minimizing disruptions for employees. Seeing the positive impact firsthand has been truly rewarding.

Companies often overlook user experience when trying to give their employees access to the secure systems they need to do their job. Our focus is on bringing tools together, making them easy to find, streamlining workflows, and reducing friction so employees spend less time looking for the right place to go, and more time getting things done.

Jason Rapps
Senior Manager II, IT Systems Engineering, Motorola Solutions
LinkedIn

Managing compliance at scale often leads to rigid processes, additional overhead, and a less-than-ideal employee experience. Striking the right balance between control and usability is critical—because when employees struggle with cumbersome compliance processes, productivity might take a hit.

The Problematic Compliance Burden on Employee Experience

Strict security rules can slow employees down. They have to reset passwords often, use multi-factor authentication, and connect through VPNs that can be frustrating. Gaining access to the right tools and systems takes extra steps, making simple tasks take longer. These security rules are important, but they can make work feel harder than it should be.

Additionally, workspace management can become a challenge. Secure environments enforce strict access controls, limiting seamless collaboration. Managing permissions, access, and approvals can create bottlenecks that slow down workflows. Even routine IT requests, like provisioning new devices or gaining access to certain applications, can be delayed due to compliance reviews.

Another common challenge is remote work. Compliance controls often require employees to navigate secure connections, restrictive access policies, and constant monitoring. This can hinder efficiency, particularly for global teams operating across different time zones.

Motorola Solutions’ Solution

Motorola Solutions took a bold and commendable approach. By integrating new tools that streamline compliance workflows without compromising control, they’ve improved both security and usability. Employees now spend less time navigating regulatory requirements and more time focusing on meaningful work.

For example, automation in identity and access management has significantly reduced the friction associated with password resets and account recovery. More intuitive VPN solutions have enhanced remote access security without adding unnecessary hurdles. Workspace management tools have enabled smoother collaboration without weakening compliance controls.

These improvements have not only made life easier for employees but also for IT and support teams. With fewer password reset requests, smoother access management, and reduced manual interventions, IT staff can focus on strategic initiatives rather than constantly troubleshooting compliance-related issues. Support teams can now provide faster resolutions, leading to a better overall work environment for everyone.

The Result is a Better Work Experience

Now, employees can work more smoothly without being slowed down by security steps. They can focus on their jobs instead of dealing with frustrating login issues or access problems. Motorola Solutions has found the right balance between keeping things secure and making work easier, creating a happier and more productive workplace.

Beyond just improving efficiency, these changes contribute to a healthier work environment where employees feel empowered rather than restricted by compliance processes. When security measures become seamless rather than obstructive, employees can fully engage with their work, collaborate effortlessly, and drive innovation without unnecessary slowdowns.

Moreover, IT and support teams also harvest the benefits. With fewer recurring issues related to access management and security compliance, they can dedicate more time to strategic improvements rather than constantly firefighting operational inefficiencies. This shift enhances not only the day-to-day experience for employees but also strengthens the overall resilience of the company’s IT infrastructure.

We were proud to contribute to this transformation by helping implement workplace management tools that improved the employee experience. By streamlining how employees interact with their digital workspace, it is easier to access the resources they need without unnecessary delays. Motorola Solutions was able to reduce frustration, enhance collaboration, and create a more seamless work environment.

This case proves the power of smart workplace management in driving real impact. When organizations take a proactive approach to improving employee experience, the benefits extend beyond convenience—they foster a culture of efficiency, engagement, and innovation. Motorola Solutions has shown that with the right investments, large enterprises can turn workplace complexity into an advantage rather than a challenge.

The post Motorola Solutions: Perfect Balance Between Compliance and Employee Experience – A Case Study appeared first on Codenteam.

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.

Imagine you’re tasked with assessing the structural integrity of a building that has already been built or is still in the process of construction. The challenge is to ensure that the building is safe, the materials are reliable, and the construction process follows safety regulations, all while minimizing the risk of disruption. This analogy is quite similar to the world of technical assessment and due diligence, where different types of security tests play crucial roles in ensuring the safety and robustness of a product or system, just like inspecting a building is important to ensure tenants’ safety, understanding application security is crucial in modern software development as ensuring application security helps protect sensitive data and systems.

What is application security (AppSec)?

Application security—commonly called AppSec—is the discipline of building and maintaining software so that it can withstand misuse, tampering, and data‑exfiltration attempts throughout its entire life‑cycle. It blends:

• Preventive practices such as secure design, threat modeling, and coding standards,
• Protective controls like strong authentication, input validation, and encryption, and
• Verification activities—SCA, SAST, the two flavors of DAST, penetration testing, and more

To ensure that every line of code and every third‑party component meets today’s security expectations. Just as building engineers must follow structural codes and schedule site inspections to keep occupants safe, AppSec professionals embed checks and controls at each stage of development and operations so the application remains resilient to evolving threats and regulatory requirements long after it first goes live.

One way to categorize all test types is by intrusive level. Would you send inspectors to just look at the building and the plans? Or you will send workers with them to put the walls under real test?

Intrusive vs. Non-Intrusive Testing

The difference between intrusive and non-intrusive testing is like deciding whether your building inspectors should only observe or actively make changes.

• Non-Intrusive Testing (SCA, SAST, Passive DAST) doesn’t interfere with the operations of the system—just like inspectors who check blueprints or monitor the building without touching anything.
• Intrusive Testing (Active DAST) goes further by probing the system aggressively, potentially disrupting services to uncover vulnerabilities, much like an inspector knocking down a wall to see if it was built properly.

While riskier, intrusive testing often provides deeper insights into potential structural weaknesses and can be used to verify potential threats or to mark them as false positives.

Software Composition Analysis (SCA): Building Material Inspection

The first step is to assess the raw materials being used in the construction—this is where Software Composition Analysis (SCA) comes in. SCA tests are like inspecting the materials being used in a building:

• Are the bricks sturdy?
• Is the cement high quality?

This type of testing looks at the open-source components and third-party libraries within your software. It ensures that none of the materials (i.e., external dependencies) have vulnerabilities or are outdated, which could compromise the security of the entire structure.

Just as bad building materials can result in a weak structure, outdated or insecure libraries in a codebase can introduce significant risks, making SCA essential for verifying that the foundation of your software is sound and up to modern security standards.

Static Application Security Testing (SAST): Reviewing the Blueprint and Construction Procedures

Next, we take a look at the blueprints and the plans behind the construction, inspecting them before or during the building process. This is similar to Static Application Security Testing (SAST).

In SAST, the source code of the application is analyzed—it’s like reviewing the architect’s plans or watching over the construction techniques being used. SAST aims to identify potential weaknesses in the code structure, like:

• Poor coding practices
• Insecure design patterns
• Areas where errors might creep in unnoticed

By catching issues early in the blueprint (or code) review, SAST ensures that potential weaknesses are addressed before they are built into the system, much like ensuring that construction workers aren’t cutting corners with structural supports or ignoring fire safety measures.

Passive Dynamic Application Security Testing (DAST): Semi-Intrusive Inspection

Now imagine the building is nearly complete, and you want inspectors to come in and assess the structure—but without causing disruption. These inspectors walk through the building, looking for cracks in the walls, faulty wiring, or areas where security might be at risk, all without actively altering the building. You need a completed building though (running system) but you don’t need access to blueprints and plans (source code).

This is how Passive Dynamic Application Security Testing (DAST) works. Passive DAST assesses the live application while it’s running but doesn’t interact with it in ways that could disrupt services. It observes and detects issues like:

• Weak configurations
• Exposed entry points

All without directly influencing the system. It’s like sending someone to observe the building under normal operations, identifying potential flaws without changing the state of the system.

Worst case scenario in a real-world software situation is, those inspectors can cause the system to run slower, as they take some of the server’s resources.

Active Dynamic Application Security Testing (DAST): Intrusive Inspection

Sometimes, you need to send in a more assertive inspector, one who will check not just how the building looks but might even knock down a weak wall or intentionally short-circuit a wire to see how the building reacts. Active DAST is a more hands-on approach.

Sometimes, you need to send in a more assertive inspector, one who will check not just how the building looks but might even knock down a weak wall or intentionally short-circuit a wire to see how the building reacts. Active DAST is a more hands-on approach.

Unlike passive DAST, it actively interacts with the system, probing for vulnerabilities by executing tests and scenarios that mimic real-world attacks. This could involve making changes to the system, introducing intentional stress, or even causing damage—just to see if and where the building (or system) breaks.

To run an active DAST, you need a completed building either the real one or a version identical to it (Staging environment) but you can allow external testers to run it for you, as you don’t need to give them access to the source code.

Summary

Each of these tests plays an essential role in assessing and securing a product or system during technical assessments and due diligence. Together, they ensure that both the materials and the final structure are robust, secure, and capable of withstanding external pressures, much like a well-built building.

Did you know?

Codenteam AI gives you all needed information around risks in SCA, SAST, DAST in the report page, you can discuss with the AI bot why it has marked each.

The post Types of AppSec Security Testing in Technical Assessment and Due Diligence: SCA vs SAST vs DAST appeared first on Codenteam.