The .NET landscape continues to evolve at a blistering pace as it released its latest update — .NET 8.0.1 on January 11th, 2024; thanks to LTS policy.
It’s more than just a patch update; it’s a powerhouse packed with performance improvements, developer-friendly tools, and exciting cross-platform capabilities.
Performance is no longer just a buzzword in .NET, rather it’s a tangible reality. The latest release shows reductions in garbage collection times. This is possible with its optimized algorithms and improved memory management. JIT compilation has also received a major overhaul, leading to faster application startup and smoother execution.
These enhancements translate to real-world improvements, with many applications experiencing up to 20% faster execution times compared to previous versions.
.NET 8.0.1 understands that developers are time-pressed beings. To ease their burdens, the platform introduces a list of productivity-boosting tools and features. Minimal APIs let you design lightweight web APIs with minimal code and boilerplate, reducing development time and maintenance headaches.
Hot Reload for ASP.NET Core eliminates the dreaded server restart cycle, allowing you to see code changes reflected instantly. This leads to a more fluid development workflow. Improved tooling for code analysis and debugging further adds to the efficiency mix, helping you identify and fix issues faster.
Gone are the days of juggling separate codebases for iOS, Android, Windows, and macOS. .NET MAUI (Multi-platform App UI) empowers you to build beautiful native mobile and desktop applications using a single codebase. This translates to massive savings in development time and effort, allowing you to focus on your app’s core functionality instead of platform-specific intricacies.
Imagine crafting a stunning mobile game or a feature-rich desktop application, all powered by the magic of .NET MAUI and your shared codebase.
.NET 8.0.1 simplifies the deployment process, making it easier than ever to get your creations onto various environments, including cloud platforms and containers. Improved container image support and smaller footprints allow for smoother deployments and efficient resource utilization. Whether you’re targeting Azure, AWS, or any other cloud platform, .NET 8.0.1 has your back.
.NET 8.0.1 offers a range of features to protect your applications from vulnerabilities. Enhanced cryptography libraries ensure secure data transmission and storage, while deprecation of insecure protocols and APIs minimizes potential attack vectors. Improved logging and auditing capabilities provide better visibility into your application’s security posture, allowing you to proactively identify and address potential threats.
In today’s digital landscape, security is paramount. And .NET 8.0.1 has got everything you need.
The list of innovations in .NET 8.0.1 goes beyond these highlights. Hardware allows modern CPUs and GPUs in boosting performance in areas like scientific computing and image processing. WPF hardware acceleration in RDP enhances remote application experiences, making them smoother and more responsive. And the improvements continue, from modernized asynchronous programming primitives to enhanced Blazor capabilities, offering developers a richer and more versatile platform.
.NET 8.0.1 is an invitation to build faster, more secure, and truly cross-platform applications with increased developer productivity. The future of application development is bright with .NET and this latest release proves it right.
For more information, please head over to our Hire .NET Developer page and to develop your dream project using ASP.NET, Hire .NET Developer at HK Infosoft – we are destined to provide you with an innovative solution using the latest technology stacks. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
Content Source:
Angular has recently rolled out its latest update – Angular 17 which is more than just an incremental update. Angular 17 has taken a bold leap forward by refactoring the narrative with lightning-fast performance, developer-centric features, and a fresh new identity. Let’s dive into its amazing updates:
Angular 17 isn’t messing around when it comes to speed. Say goodbye to laggy loading times and unresponsive UI. With the help of Deferrable Views, Angular now allows dynamic loading of components, saving around 90% off runtime! This means smoother animations, instant responsiveness, and a user experience that will leave your audience with a smile.
And the speed boost doesn’t stop there. The new built-in control flow syntax in Angular 17, eliminates the need for third-party libraries, resulting in up to 87% faster builds for hybrid rendering and 67% for client-side rendering. Developers now can spend less time waiting and more time creating.
Control flow just got optimized. Forget clunky directives and leverage the elegance of native-like if, else, and for loops within your templates. This long-awaited feature in Angular 17 enhances readability, simplifies logic, and makes your code organized.
Angular 17 doesn’t just speed things up; it also cleans things up. The newly revamped website, Angular.dev, reflects the framework’s modern spirit with a sleek design and intuitive navigation. It’s your one-stop shop for documentation, learning resources, and a thriving community.
Angular 17 brings in inclusivity with an interactive learning journey tailored for diverse learning styles. Whether you’re a seasoned pro or a curious beginner, this personalized path ensures you level up your Angular skills at your own pace.
The list of updates doesn’t end there. View transitions API support unlocks stunning animation possibilities, while improved SSR (Server-side Rendering) boosts SEO and first-load performance. The cherry on top? A plethora of smaller enhancements and bug fixes polish the overall experience.
Angular 17 isn’t just about the present; it’s a stepping stone towards a brighter future. The team’s commitment to performance optimizations, developer experience, and accessibility paves the way for even more exciting iterations to come.
Angular 17 is a proof to the Angular framework’s unwavering commitment to pushing boundaries. It’s not just a technology upgrade; it’s a tech revolution. It’s about building faster, building smarter, and building with developer delight at the core.
So, should you upgrade to Angular 17? The answer is a resounding yes! Whether you’re building a new project or breathing life into an existing one, v17 offers undeniable advantages. Experience the speed, the finesse, the joy of development – experience the all new Angular 17.
For more information & to develop Web Application using Angular, visit our Hire Angular Developer page. At HK Infosoft, we are destined to provide you with an innovative solution using the latest technology stacks. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
Content Source:
Node.js 21 was released on October 17, 2023 and came with a number of new features and improvements. This includes experimental support for the WebSocket API, a new –experimental-default-type flag, and a number of updates to the test runner and llhttp parser.
Node.js 21 introduces experimental support for the WebSocket API, which allows you to connect to a WebSocket server from a Node.js application without resorting to third-party packages. This is an important innovation, as it allows real-time, two-way interactive communication between the client and server.
const WebSocket = require('ws');
const ws = new WebSocket('ws://localhost:8080');
ws.on('open', () => {
console.log('WebSocket connection open');
});
ws.on('message', (message) => {
console.log('Received message:', message);
});
ws.on('close', () => {
console.log('WebSocket connection closed');
});
By default, Node.js will interpret any code you enter or send it as an ES module if you do not specify otherwise, and if the package.json file is not present. The new –experimental-default-type flag allows you to override this behavior and specify that code should be interpreted as CommonJS instead.
To use the –experimental-default-type flag, you can use the following command:
node --experimental-default-type=commonjs my-script.js
This will cause the my-script.js file to be interpreted as CommonJS, even if it does not have an .extensions file extension.
Node.js 21 introduces a new –test-concurrency flag that allows you to specify the number of parallel processes that the test runner should use. This can be useful for improving performance on machines with multiple cores.
To use the –test-concurrency flag, you can use the following command:
node --test-concurrency=4 test
This will cause the test runner to execute tests in parallel using four processes.
Node.js 21 now supports passing globs as arguments to the test runner. This allows you to specify which test files to run based on patterns, rather than having to specify each file individually.
To run all test files that match the *.test.js pattern, you can use the following command:
node test *.test.js
Node.js 21 uses llhttp version 9.1.2, which introduces a number of new features and bug fixes. One of the most important changes is that llhttp 9.1.2 now has a strict mode that is enabled by default. This means that llhttp will now reject requests that are not formatted correctly.
If you are using a third-party library that sends malformed requests, you may need to disable strict mode in order to use it. To do this, you can use the following command:
node --insecure-http-parser my-script.js
Node.js 21 is a significant release that includes a number of new features and improvements. The experimental support for the WebSocket API is particularly exciting, as it opens up new possibilities for real-time applications.
For more information, please head over to our Hire Node Developer page and to develop a web application using Node JS, Hire Node Developer at HK Infosoft – we are destined to provide you with an innovative solution using the latest technology stacks. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
To develop Android Mobile Apps, please visit our technology page.
Content Source:
NET 7 is the successor to .NET 6 and focuses on being unified, modern, simple, and fast. .NET 7 will be supported for 18 months as a standard-term support (STS) release. .NET 7 was released on November 8, 2022 and is the latest version of the .NET platform. It includes a number of new features and improvements, including:
C# 11 includes a number of new features, such as:
.NET 7 includes a number of performance improvements, such as:
.NET 7 includes a number of new features for cloud-native development, such as:
.NET 7 includes a number of new features for desktop development, such as:
.NET 7 includes a number of new features for mobile development, such as:
For more information, please head over to our Hire .NET Developer page and to develop a website using ASP.NET, Hire .NET Developer at HK Infosoft – we are destined to provide you with an innovative solution using the latest technology stacks. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
Content Source:
In the rapidly evolving world of web development, developers are constantly on the lookout for frameworks that can provide both speed and efficiency. Enter Fastify, a lightweight and lightning-fast web framework for Node.js that has taken the development community by storm. If you’re a developer looking to create high-performance, scalable, and secure web applications, Fastify may be the game-changer you’ve been waiting for.
Fastify, developed by Matteo Collina and Tomas Della Vedova, is an open-source web framework for Node.js designed with a primary focus on speed and low overhead. Launched in 2016, Fastify has quickly gained popularity in the Node.js ecosystem due to its impressive performance, simplicity, and extensibility. It is built on top of Node.js’s HTTP module and takes full advantage of the latest JavaScript features to maximize its speed and efficiency.
// Require the framework and instantiate it
const fastify = require("fastify")({ logger: true });
// Declare a rout
fastify.get("/", async (request, reply) => {
return { hello: "world" };
});
// Start the server
fastify.listen(3000);
One of the primary reasons developers are flocking to Fastify is its exceptional performance. Thanks to its powerful and highly optimized core, Fastify boasts some of the fastest request/response times among Node.js frameworks. It leverages features like request validation, which is automatically generated from JSON schemas, to ensure that data is processed swiftly and accurately. Additionally, Fastify supports asynchronous programming and handles requests concurrently, making it ideal for handling heavy workloads and high traffic.
Fastify follows a minimalist approach, focusing on providing only the essential components needed to build web applications efficiently. Developers can opt-in to use various plugins to extend Fastify’s functionality as per their requirements. This approach not only keeps the core lightweight but also gives developers the flexibility to customize their stack with the specific tools they need. Furthermore, the ecosystem around Fastify is growing rapidly, with a wide array of plugins and middleware available, making it easy to integrate third-party tools seamlessly.
Fastify’s API is designed to be intuitive and easy to use, reducing the learning curve for developers. Its well-documented and expressive API allows developers to write clean, maintainable, and organized code. The framework’s emphasis on proper error handling and logging also contributes to its ease of use, helping developers quickly identify and rectify issues during development and production.
Data validation is a crucial aspect of web application development to ensure data integrity and security. Fastify utilizes JSON Schema for data validation, enabling developers to define the expected shape of incoming requests and responses. This not only simplifies the validation process but also automatically generates detailed and helpful error messages, making debugging a breeze.
Fastify is designed with security in mind. It encourages best practices such as using the latest cryptographic libraries and secure authentication mechanisms. Additionally, Fastify has a built-in protection mechanism against common web application attacks like Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). With Fastify, developers can rest assured that their applications are less prone to security vulnerabilities.
Fastify’s emergence as a top-tier web framework for Node.js is no coincidence. Its commitment to speed, minimalism, and extensibility sets it apart from the competition. Whether you’re building a small-scale API or a large-scale application, Fastify’s performance, easy-to-use API, and emphasis on security make it an excellent choice.
In the fast-paced world of web development, having a framework that can boost productivity and deliver top-notch performance is essential. Fastify has proven itself as a reliable and efficient framework, providing developers with the tools they need to create high-performance applications without compromising on code quality and security.
So, if you’re ready to take your Node.js projects to the next level, give Fastify a try, and experience the speed and power it brings to your development workflow.
For more information and to develop web applications using Node.js, Hire Node.js Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
To develop custom web apps using Node.js, please visit our technology page.
Content Source:
This transition is intended to ease the maintenance burden on the community and challenge our development team to ship amazing, powerful new features without introducing breaking changes. Therefore, we have shipped a variety of robust features to Laravel 9 without breaking backwards compatibility.
Therefore, this commitment to ship great new features during the current release will likely lead to future “major” releases being primarily used for “maintenance” tasks such as upgrading upstream dependencies, which can be seen in these release notes.
Laravel 10 continues the improvements made in Laravel 9.x by introducing argument and return types to all application skeleton methods, as well as all stub files used to generate classes throughout the framework. In addition, a new, developer-friendly abstraction layer has been introduced for starting and interacting with external processes.
PHP 8.1 is the minimum-required PHP version in Laravel 10. Some PHP 8.1 features, such as readonly properties and array_is_list, are used in Laravel 10.
Not only is the framework professionally maintained and updated on a regular basis, but so are all of the official packages and the ecosystem.
The following is a list of the most recent official Laravel packages that have been updated to support Laravel 10:
Predis is a robust Redis client for PHP that may help you get the most out of caching to provide a fantastic user experience. Laravel formerly supported both versions 1 and 2, but as of Laravel 10, the framework no longer supports Predis 1.
Although Laravel documentation mentions Predis as the package for interacting with Redis, you may also use the official PHP extension. This extension provides an API for communicating with Redis servers.
If you were to make an invokable validation rule in Laravel 9, you would need to add an –invokable flag after the Artisan command. This is no longer necessary because all Laravel 10 rules are invokable by default. So, you may run the following command to create a new invokable rule in Laravel 10:
php artisan make:rule CustomRule
On its initial release, Laravel utilized all of the type-hinting features available in PHP at the time. However, many new features have been added to PHP in the subsequent years, including additional primitive type-hints, return types, and union types.
Laravel 10.x thoroughly updates the application skeleton and all stubs utilized by the framework to introduce argument and return types to all method signatures. In addition, extraneous “doc block” type-hint information has been deleted.
This change is entirely backwards compatible with existing applications. Therefore, existing applications that do not have these type-hints will continue to function normally.
The Artisan test command has received a new –profile option that allows you to easily identify the slowest tests in your application:
php artisan test --profile
To improve the framework’s developer experience, all of Laravel’s built-in make commands no longer require any input. If the commands are invoked without input, you will be prompted for the required arguments:
php artisan make:controller
Laravel 10 can create a random and secure password with a given length:
$password = Str::password(12);
A new first-party package, Laravel Pennant, has been released. Laravel Pennant offers a light-weight, streamlined approach to managing your application’s feature flags. Out of the box, Pennant includes an in-memory array driver and a database driver for persistent feature storage.
Features can be easily defined via the Feature::define method:
use Laravel\Pennant\Feature;
use Illuminate\Support\Lottery;
Feature::define('new-onboarding-flow', function () {
return Lottery::odds(1, 10);
});
Once a feature has been defined, you may easily determine if the current user has access to the given feature:
if (Feature::active('new-onboarding-flow')) {
// ...
}
Of course, for convenience, Blade directives are also available:
@feature('new-onboarding-flow')
<div>
<!-- ... -->
</div>
@endfeature
Laravel 10.x introduces a beautiful abstraction layer for starting and interacting with external processes via a new Process facade:
use Illuminate\Support\Facades\Process;
$result = Process::run('ls -la');
return $result->output();
Processes may even be started in pools, allowing for the convenient execution and management of concurrent processes:
use Illuminate\Process\Pool;
use Illuminate\Support\Facades\Process;
[$first, $second, $third] = Process::concurrently(function (Pool $pool) {
$pool->command('cat first.txt');
$pool->command('cat second.txt');
$pool->command('cat third.txt');
});
return $first->output();
Horizon and Telescope have been updated with a fresh, modern look including improved typography, spacing, and design
Pest test scaffolding is now enabled by default when creating new Laravel projects. To enable this feature, use the –pest flag when building a new app with the Laravel installer:
laravel new example-application --pest
Laravel 10 is a significant release for the Laravel framework, and it comes with several new features and improvements that will help developers create more robust and efficient web applications. The introduction of BladeX, model event hooks, and improved routing features make it easier for developers to build modular and scalable applications. The dropping of PHP 8.0 support is also a significant decision that ensures that developers are using the latest version of PHP, which is more secure and efficient. As always, Laravel continues to evolve and innovate, making it an excellent choice for web development projects.
For more information and to develop web applications using Laravel, Hire Laravel Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
To develop custom web apps using Laravel, please visit our technology page.
Content Source:
Pair programming is an agile software development technique in which two developers work together on the same computer to write code. One developer, called the driver, is responsible for typing the code while the other, called the observer, review the code and makes suggestions. The two developers then switch roles, with the observer becoming the driver and the driver becoming the observer.
The story of pair programming originates from a software development company called Chrysler. In the late 1990s, Chrysler was tasked with developing a new software system for its payroll operations. The project was behind schedule and the team was struggling to make progress. In desperation, the lead programmer, Xitij Kothi, suggested an unconventional solution: pair programming. He proposed that two programmers work together on each task, with one writing code while the other reviews and offers suggestions.
The strategy worked. The project was completed on time and the quality of the software was far superior to what had been expected. Since then, pair programming has become a widely accepted practice in software development.
Pair programming can reduce the time it takes to complete a task by allowing two developers to work together more effectively. By having two developers work side-by-side, they can quickly identify and resolve problems as they occur. The navigator can also provide insights into potential issues before they become problems, helping to reduce the amount of debugging and testing that needs to be done. Additionally, pair programming enables developers to learn from each other, which can help reduce the amount of time it takes to complete a task.
Pair programming also helps to spread knowledge and skills among the team members, as each programmer learns from the other. This can be especially useful in distributed software projects, where team members may be geographically dispersed.
John and Jane had been classmates for the past couple of months, but never really got to know each other very well. They had been assigned a project in their programming class and had decided to work together.
John was very knowledgeable in the subject and had a good understanding of what was expected. Jane, on the other hand, had little to no experience with programming but was eager to learn. Together, they decided to use the pair programming technique.
John and Jane sat down together and discussed their project. John explained the concept of pair programming, how it works, and what their roles would be. Jane was very willing to learn and was excited to get started.
John and Jane began writing the code for their project. John took the lead and wrote most of the code while Jane watched and asked questions. Whenever Jane found a mistake or had an idea, she would suggest it to John, who would then incorporate it into the code.
In this way, John and Jane worked together to complete their project. By the end of it, both of them had gained a better understanding of programming and had come to know each other better.
“Pair programming had become a regular part of John and Jane’s programming class ever since.”
One type of problem that programmers can face during pair programming is communication breakdown. This is when two programmers are unable to effectively communicate with each other due to a lack of understanding or different working styles. To overcome this issue, it is important to ensure that both programmers are on the same page before starting to program. This can be done by discussing the problem, breaking it down into small manageable parts, and discussing how to approach it. It is also important to ensure that there is an equal amount of speaking and listening between the two programmers. It is also important to be aware of any language or cultural differences that may be present and to adjust your communication accordingly.
Different abilities can be a problem during pair programming because one programmer may be more knowledgeable or experienced in a certain area than the other. This can lead to the more experienced programmer taking on a larger share of the work, leaving the less experienced programmer feeling frustrated or left out.
To overcome this, the two partners should agree on a division of tasks based on their respective strengths. For example, if one partner is more experienced with databases, they can take the lead on designing and setting up the database structure, while the other partner focuses on developing the business logic. Both partners should aim to challenge each other and provide feedback and support to ensure that the project is completed to the highest standard. Additionally, the partners should regularly rotate tasks so that both have the opportunity to learn from each other and gain a more comprehensive understanding of the project.
Task division can be a problem during pair programming if one person takes on more responsibility than the other, leaving the other feeling like they’re not contributing as much to the project. This can lead to frustration and resentment, and can ultimately undermine the collaborative nature of pair programming. To overcome this, the two people should agree on how they will divide the tasks before they begin.
For example, they can decide that one person will take the lead on the coding while the other focuses on debugging and testing, or that each person will take turns writing sections of code. They should also make sure to have regular check-ins to discuss progress, address any issues, and ensure that both parties are on the same page. This will help ensure that both parties feel like they’re contributing equally to the project.
Distractions can be a major problem during pair programming, as they can prevent the pair from focusing on their task and completing it in a timely manner. Distractions could include anything from phones, emails, instant messages, or conversations with other people in the same room. To overcome distractions during pair programming, both partners should agree to have their phones on silent and out of sight. If possible, they should also try to find a quiet space where they can work without interruption. Additionally, they should set aside specific times to check emails and other messages and then get back to their task. They should also set specific goals and deadlines for the task ahead of time to help keep them on track.
one person may be more accustomed to writing code with fewer lines and using terse abbreviations, while the other person may prefer longer and more descriptive lines of code. This can lead to a lot of back and forth, which can slow down the programming process. To overcome this problem, it is important to have open communication and be respectful of each other’s coding styles. The pair should discuss their preferences and try to come to an agreement on which style they should use. They should also discuss the types of coding conventions they want to follow and agree on a coding style guide. Additionally, they should take time to explain their code to each other, as this can help them better understand each other’s coding styles. Finally, they should be open to feedback and criticism and be willing to compromise.
The importance of pair programming lies in its ability to improve the quality of code while also reducing the time it takes to develop software.
Next.js 13 has landed in a somewhat confusing way. Many remarkable things have been added; however, a good part is still Beta. Nevertheless, the Beta features give us important signals on how the future of Next.js will be shaped, so there are good reasons to keep a close eye on them, even if you’re going to wait to adopt them.
This article is part of a series of experiences about the Beta features. Let’s play with Server Components today.
Making server components the default option is arguably the boldest change made in Next.js 13. The goal of server component is to reduce the size of JS shipped to the client by keeping component code only on the server side. I.e., the rendering happens and only happens on the server side, even if the loading of the component is triggered on the client side (via client-side routing). It’s quite a big paradigm shift.
It feels quite “reasearch-y” by then, so it was shocking when seeing that Next.js is already betting its future on it now. Time flies and the fantastic engineers from React must have done some really great work.
npx create-next-app@latest --experimental-app --ts --eslint next13-server-components
Let’s have some fun playing with the project.
The first difference noticed is that a new app folder now sits along with old friend page. They’ll save the routing changes to another article, but what’s worth mentioning for now is that every component under the app folder is, by default, a server component, meaning that it’s rendered on the server side, and its code stays on the server side.
Let’s create our very first server component now:
// app/server/page.tsx
export default function Server() {
console.log('Server page rendering: this should only be printed on the server');
return (
<div>
<h1>Server Page</h1>
<p>My secret key: {process.env.MY_SECRET_ENV}</p>
</div>
);
}
If you access the /server route, whether by a fresh browser load or client-side routing, you’ll only see the line of log printed in your server console but never in the browser console. The environment variable value is fetched from the server side as well.
Looking at network traffic in the browser, you’ll see the content of the Server component is loaded via a remote call which returns an octet stream of JSON data of the render result:
Pic courtesy: medium.com
{
...
"childProp": {
"current": [
[
"$",
"div",
null,
{
"children": [
["$", "h1", null, { "children": "Server Page" }],
[
"$",
"p",
null,
{
"children": ["My secret key: ", "abc123"]
}
]
]
}
]
]
}
}
Rendering a server component is literally an API call to get serialized virtual DOM and then materialize it in the browser.
The most important thing to remember is that server components are for rendering non-interactive content, so there are no event handlers, no React hooks, and no browser-only APIs.
The most significant benefit is you can freely access any backend resource and secrets in server components. It’s safer (data don’t leak) and faster (code doesn’t leak).
To make a client component, you’ll need to mark it so explicitly with use client:
// app/client/page.tsx
'use client';
import { useEffect } from 'react';
export default function Client() {
console.log(
'Client page rendering: this should only be printed on the server during ssr, and client when routing'
);
useEffect(() => {
console.log('Client component rendered');
});
return (
<div>
<h1>Client Page</h1>
{/* Uncommenting this will result in an error complaining about inconsistent
rendering between client and server, which is very true */}
{/* <p>My secret env: {process.env.MY_SECRET_ENV}</p> */}
</div>
);
}
As you may already anticipate, this gives you a similar behavior to the previous Next.js versions.
When the page is first loaded, it’s rendered by SSR, so you should see the first log in the server console; during client-side routing, both log messages will appear in the browser console.
One of the biggest differences between Server Component and SSR is that SSR is at page level, while Server Component, as its name says, is at component level. This means you can mix and match server and client components in a render tree as you wish.
// A server page containing client component and nested server component
// app/mixmatch/page.tsx
import Client from './client';
import NestedServer from './nested-server';
export default function MixMatchPage() {
console.log('MixMatchPage rendering');
return (
<div>
<h1>Server Page</h1>
<div className="box">
<Client message="A message from server">
<NestedServer />
</Client>
</div>
</div>
);
}
// app/mixmatch/client.tsx
'use client';
import { useEffect } from 'react';
export default function Client({
message,
children,
}: {
message: string;
children: React.ReactNode;
}) {
console.log('Client component rendering');
return (
<div>
<h2>Client Child</h2>
<p>Message from parent: {message}</p>
<div className="box-red">{children}</div>
</div>
);
}
// app/mixmatch/nested-server.tsx
export default function NestedServer() {
console.log('Nested server component rendering');
return (
<div>
<h3>Nested Server</h3>
<p>Nested server content</p>
</div>
);
}
Pic courtesy: medium.com
In a mixed scenario like this, server and client components get rendered independently, and the results are assembled by React runtime. Props passed from server components to client ones are serialized across the network (and need to be serializable).
One caution you need to take is that if a server component is directly imported into a client one, it silently degenerates into a client component.
Let’s revise the previous example slightly to observe it:
// app/degenerate/page.tsx
import Client from './client';
export default function DegeneratePage() {
console.log('Degenerated page rendering');
return (
<div>
<h1>Degenerated Page</h1>
<div className="box-blue">
<Client message="A message from server" />
</div>
</div>
);
}
// app/degenerate/client.tsx
'use client';
import NestedServer from './nested-server';
export default function Client({ message }: { message: string }) {
console.log('Client component rendering');
return (
<div>
<h2>Client Child</h2>
<p>Message from parent: {message}</p>
<div className="box-blue">
<NestedServer />
</div>
</div>
);
}
// app/degenerated/nested-server.tsx
export default function NestedServer() {
console.log('Nested server component rendering');
return (
<div>
<h3>Degenerated Server</h3>
<p>Degenerated server content</p>
</div>
);
}
If you check out the log, you’ll see NestedServer has “degenerated” and is now rendered by the browser.
For more information and to develop web applications using React JS, Hire React Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
To develop custom web apps using React JS, please visit our technology page.
Content Source:
If you’re not familiar with TypeScript, it’s a language that builds on JavaScript by adding types and type-checking. Types can describe things like the shapes of our objects, how functions can be called, and whether a property can be null or undefined. TypeScript can check these types to make sure you’re not making mistakes in your programs so you can code with confidence. It can also power other tooling like auto-completion, go-to-definition, and refactorings in the editor. In fact, if you’ve used an editor like Visual Studio or VS Code for JavaScript, that same experience is already powered by TypeScript!
To get started with TypeScript 4.9, you can get it through NuGet, or use npm with the following command:
npm install -D typescript
You can also get editor support by
Here’s a quick list of what’s new in TypeScript 4.9!
Since the Release Candidate, no changes have been made to TypeScript 4.9.
TypeScript 4.9 beta originally included auto-accessors in classes, along with the performance improvements described below; however, these did not get documented in the 4.9 beta blog post.
Not originally shipped in the 4.9 beta were the new “Remove Unused Imports” and “Sort Imports” commands for editors, and new go-to-definition functionality on return keywords.
TypeScript developers are often faced with a dilemma: they want to ensure that some expression matches some type, but also want to keep the most specific type of that expression for inference purposes.
For example:
// Each property can be a string or an RGB tuple.
const palette = {
red: [255, 0, 0],
green: "#00ff00",
bleu: [0, 0, 255]
// ^^^^ sacrebleu - we've made a typo!
};
// We want to be able to use array methods on 'red'...
const redComponent = palette.red.at(0);
// or string methods on 'green'...
const greenNormalized = palette.green.toUpperCase();
Notice that they’ve written bleu, whereas they probably should have written blue. They could try to catch that bleu typo by using a type annotation on palette, but they’d lose the information about each property.
type Colors = "red" | "green" | "blue";
type RGB = [red: number, green: number, blue: number];
const palette: Record<Colors, string | RGB> = {
red: [255, 0, 0],
green: "#00ff00",
bleu: [0, 0, 255]
// ~~~~ The typo is now correctly detected
};
// But we now have an undesirable error here - 'palette.red' "could" be a string.
const redComponent = palette.red.at(0);
The new satisfies operator lets us validate that the type of an expression matches some type, without changing the resulting type of that expression. As an example, you could use satisfies to validate that all the properties of palette are compatible with string | number[]:
type Colors = "red" | "green" | "blue";
type RGB = [red: number, green: number, blue: number];
const palette = {
red: [255, 0, 0],
green: "#00ff00",
bleu: [0, 0, 255]
// ~~~~ The typo is now caught!
} satisfies Record<Colors, string | RGB>;
// Both of these methods are still accessible!
const redComponent = palette.red.at(0);
const greenNormalized = palette.green.toUpperCase();
satisfies can be used to catch lots of possible errors. For example, they could ensure that an object has all the keys of some type, but no more:
type Colors = "red" | "green" | "blue";
// Ensure that we have exactly the keys from 'Colors'.
const favoriteColors = {
"red": "yes",
"green": false,
"blue": "kinda",
"platypus": false
// ~~~~~~~~~~ error - "platypus" was never listed in 'Colors'.
} satisfies Record<Colors, unknown>;
// All the information about the 'red', 'green', and 'blue' properties are retained.
const g: boolean = favoriteColors.green;
Maybe they don’t care about if the property names match up somehow, but they do care about the types of each property. In that case, they can also ensure that all of an object’s property values conform to some type.
type RGB = [red: number, green: number, blue: number];
const palette = {
red: [255, 0, 0],
green: "#00ff00",
blue: [0, 0]
// ~~~~~~ error!
} satisfies Record<string, string | RGB>;
// Information about each property is still maintained.
const redComponent = palette.red.at(0);
const greenNormalized = palette.green.toUpperCase();
As developers, they often need to deal with values that aren’t fully known at runtime. In fact, they often don’t know if properties exist, whether they’re getting a response from a server or reading a configuration file. JavaScript’s in operator can check whether a property exists on an object.
Previously, TypeScript allowed us to narrow away any types that don’t explicitly list a property.
interface RGB {
red: number;
green: number;
blue: number;
}
interface HSV {
hue: number;
saturation: number;
value: number;
}
function setColor(color: RGB | HSV) {
if ("hue" in color) {
// 'color' now has the type HSV
}
// ...
}
Here, the type RGB didn’t list the hue and got narrowed away, and leaving us with the type HSV.
But what about examples where no type listed a given property? In those cases, the language didn’t help us much. Let’s take the following example in JavaScript:
function tryGetPackageName(context) {
const packageJSON = context.packageJSON;
// Check to see if we have an object.
if (packageJSON && typeof packageJSON === "object") {
// Check to see if it has a string name property.
if ("name" in packageJSON && typeof packageJSON.name === "string") {
return packageJSON.name;
}
}
return undefined;
}
Rewriting this to canonical TypeScript would just be a matter of defining and using a type for context; however, picking a safe type like unknown for the packageJSON property would cause issues in older versions of TypeScript.
interface Context {
packageJSON: unknown;
}
function tryGetPackageName(context: Context) {
const packageJSON = context.packageJSON;
// Check to see if we have an object.
if (packageJSON && typeof packageJSON === "object") {
// Check to see if it has a string name property.
if ("name" in packageJSON && typeof packageJSON.name === "string") {
// ~~~~
// error! Property 'name' does not exist on type 'object.
return packageJSON.name;
// ~~~~
// error! Property 'name' does not exist on type 'object.
}
}
return undefined;
}
This is because while the type of packageJSON was narrowed from unknown to object, the in operator strictly narrowed to types that actually defined the property being checked. As a result, the type of packageJSON remained object.
TypeScript 4.9 makes the in operator a little bit more powerful when narrowing types that don’t list the property at all. Instead of leaving them as-is, the language will intersect their types with Record<“property-key-being-checked”, unknown>.
So in our example, packageJSON will have its type narrowed from unknown to object to object & Record<“name”, unknown> That allows us to access packageJSON.name directly and narrow that independently.
interface Context {
packageJSON: unknown;
}
function tryGetPackageName(context: Context): string | undefined {
const packageJSON = context.packageJSON;
// Check to see if we have an object.
if (packageJSON && typeof packageJSON === "object") {
// Check to see if it has a string name property.
if ("name" in packageJSON && typeof packageJSON.name === "string") {
// Just works!
return packageJSON.name;
}
}
return undefined;
}
TypeScript 4.9 also tightens up a few checks around how in is used, ensuring that the left side is assignable to the type string | number | symbol, and the right side is assignable to object. This helps check that we’re using valid property keys, and not accidentally checking primitives.
TypeScript 4.9 supports an upcoming feature in ECMAScript called auto-accessors. Auto-accessors are declared just like properties on classes, except that they’re declared with the accessor keyword.
class Person {
accessor name: string;
constructor(name: string) {
this.name = name;
}
}
Under the covers, these auto-accessors “de-sugar” to a get and set accessor with an unreachable private property.
class Person {
#__name: string;
get name() {
return this.#__name;
}
set name(value: string) {
this.#__name = name;
}
constructor(name: string) {
this.name = name;
}
}
A major gotcha for JavaScript developers is checking against the value NaN using the built-in equality operators.
For some background, NaN is a special numeric value that stands for “Not a Number”. Nothing is ever equal to NaN – even NaN!
console.log(NaN == 0) // false console.log(NaN === 0) // false console.log(NaN == NaN) // false console.log(NaN === NaN) // false
But at least symmetrically everything is always not-equal to NaN.
console.log(NaN != 0) // true console.log(NaN !== 0) // true console.log(NaN != NaN) // true console.log(NaN !== NaN) // true
This technically isn’t a JavaScript-specific problem, since any language that contains IEEE-754 floats has the same behavior; but JavaScript’s primary numeric type is a floating point number, and number parsing in JavaScript can often result in NaN. In turn, checking against NaN ends up being fairly common, and the correct way to do so is to use Number.isNaN – but as we mentioned, lots of people accidentally end up checking with someValue === NaN instead.
TypeScript now errors on direct comparisons against NaN, and will suggest using some variation of Number.isNaN instead.
function validate(someValue: number) {
return someValue !== NaN;
// ~~~~~~~~~~~~~~~~~
// error: This condition will always return 'true'.
// Did you mean '!Number.isNaN(someValue)'?
}
They believe that this change should strictly help catch beginner errors, similar to how TypeScript currently issues errors on comparisons against object and array literals.
In earlier versions, TypeScript leaned heavily on polling for watching individual files. Using a polling strategy meant checking the state of a file periodically for updates. On Node.js, fs.watchFile is the built-in way to get a polling file-watcher. While polling tends to be more predictable across platforms and file systems, it means that your CPU has to periodically get interrupted and check for updates to the file, even when nothing’s changed. For a few dozen files, this might not be noticeable; but on a bigger project with lots of files – or lots of files in node_modules – this can become a resource hog.
Generally speaking, a better approach is to use file system events. Instead of polling, they can announce that they’re interested in updates of specific files and provide a callback for when those files actually do change. Most modern platforms in use provide facilities and APIs like CreateIoCompletionPort, kqueue, epoll, and inotify. Node.js mostly abstracts these away by providing fs.watch. File system events usually work great, but there are lots of caveats to using them, and in turn, to using the fs.watch API. A watcher needs to be careful to consider inode watching, unavailability on certain file systems (e.g.networked file systems), whether recursive file watching is available, whether directory renames trigger events, and even file watcher exhaustion! In other words, it’s not quite a free lunch, especially if you’re looking for something cross-platform.
As a result, their default was to pick the lowest common denominator: polling. Not always, but most of the time.
Over time, they’ve provided the means to choose other file-watching strategies. This allowed us to get feedback and harden our file-watching implementation against most of these platform-specific gotchas. As TypeScript has needed to scale to larger codebases, and has improved in this area, we felt swapping to file system events as the default would be a worthwhile investment.
In TypeScript 4.9, file watching is powered by file system events by default, only falling back to polling if we fail to set up event-based watchers. For most developers, this should provide a much less resource-intensive experience when running in –watch mode, or running with a TypeScript-powered editor like Visual Studio or VS Code.
The way file-watching works can still be configured through environment variables and watchOptions – and some editors like VS Code can support watchOptions independently. Developers using more exotic set-ups where source code resides on a networked file systems (like NFS and SMB) may need to opt back into the older behavior; though if a server has reasonable processing power, it might just be better to enable SSH and run TypeScript remotely so that it has direct local file access. VS Code has plenty of remote extensions to make this easier.
Previously, TypeScript only supported two editor commands to manage imports. For our examples, take the following code:
import { Zebra, Moose, HoneyBadger } from "./zoo";
import { foo, bar } from "./helper";
let x: Moose | HoneyBadger = foo();
The first was called “Organize Imports” which would remove unused imports, and then sort the remaining ones. It would rewrite that file to look like this one:
import { foo } from "./helper";
import { HoneyBadger, Moose } from "./zoo";
let x: Moose | HoneyBadger = foo();
In TypeScript 4.3, they introduced a command called “Sort Imports” which would only sort imports in the file, but not remove them – and would rewrite the file like this.
import { bar, foo } from "./helper";
import { HoneyBadger, Moose, Zebra } from "./zoo";
let x: Moose | HoneyBadger = foo();
The caveat with “Sort Imports” was that in Visual Studio Code, this feature was only available as an on-save command – not as a manually triggerable command.
TypeScript 4.9 adds the other half, and now provides “Remove Unused Imports”. TypeScript will now remove unused import names and statements, but will otherwise leave the relative ordering alone.
import { Moose, HoneyBadger } from "./zoo";
import { foo } from "./helper";
let x: Moose | HoneyBadger = foo();
This feature is available to all editors that wish to use either command; but notably, Visual Studio Code (1.73 and later) will have support built in and will surface these commands via its Command Palette. Users who prefer to use the more granular “Remove Unused Imports” or “Sort Imports” commands should be able to reassign the “Organize Imports” key combination to them if desired.
In the editor, when running a go-to-definition on the return keyword, TypeScript will now jump you to the top of the corresponding function. This can be helpful to get a quick sense of which function a return belongs to.
They expect TypeScript will expand this functionality to more keywords such as await and yield or switch, case, and default.
For more information and to develop web applications using TypeScript, Hire TypeScript Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
To develop custom web apps using TypeScript, please visit our technology page.
Content Source:
Over the past year, the team has removed Angular’s legacy compiler and rendering pipeline which enabled the development of a series of developer experience improvements in the past couple of months. Angular v15 is the culmination of this with dozens of refinements that lead to better developer experience and performance.
In v14 they introduced new standalone APIs which enable developers to build applications without using NgModules. they’re happy to share that these APIs graduated from developer preview and are now part of the stable API surface. From here on they will evolve them gradually following semantic versioning.
As part of making sure standalone APIs were ready to graduate they have ensured that standalone components work across Angular, and they now fully work in HttpClient, Angular Elements, router and more.
The standalone APIs allow you to bootstrap an application using a single component:
import {bootstrapApplication} from '@angular/platform-browser';
import {ImageGridComponent} from'./image-grid';
@Component({
standalone: true,
selector: 'photo-gallery',
imports: [ImageGridComponent],
template: `
… &lt;image-grid [images]=&quot;imageList&quot;&gt;&lt;/image-grid&gt;
`,
})
export class PhotoGalleryComponent {
// component logic
}
bootstrapApplication(PhotoGalleryComponent);
You can build a multi-route application using the new router standalone APIs! To declare the root route you can use the following:
export const appRoutes: Routes = [{
path: 'lazy',
loadChildren: () =&gt; import('./lazy/lazy.routes')
.then(routes =&gt; routes.lazyRoutes)
}];
Where lazyRoutes are declared in:
import {Routes} from '@angular/router';
import {LazyComponent} from './lazy.component';
export const lazyRoutes: Routes = [{path: '', component: LazyComponent}];
and finally, register the appRoutes in the bootstrapApplication call:
bootstrapApplication(AppComponent, {
providers: [
provideRouter(appRoutes)
]
});
Another benefit of the provideRouter API is that it’s tree-shakable! Bundlers can remove unused features of the router at build-time. In their testing with the new API, they found that removing these unused features from the bundle resulted in an 11% reduction in the size of the router code in the application bundle.
The directive composition API brings code reuse to another level! This feature was inspired by the most popular feature request on GitHub asking for the functionality to add directives to a host element.
The directive composition API enables developers to enhance host elements with directives and equips Angular with a powerful code reuse strategy, that’s only possible thanks to their compiler. The directive composition API only works with standalone directives.
Let’s look at a quick example:
@Component({
selector: 'mat-menu',
hostDirectives: [HasColor, {
directive: CdkMenu,
inputs: ['cdkMenuDisabled: disabled'],
outputs: ['cdkMenuClosed: closed']
}]
})
class MatMenu {}
In the code snippet above they enhanced MatMenu with two directives: HasColor and CdkMenu. MatMenu reuses all the inputs, outputs, and associated logic with HasColors and only the logic and the selected inputs from CdkMenu.
This technique may remind you of multiple inheritance or traits in some programming languages, with the difference that they have a mechanism for resolution of name conflicts and it’s applicable to user interface primitives.
They announced developer preview of the Angular image directive that they developed in collaboration with Chrome Aurora in v14.2.
Pic courtesy: medium.com
Before and after of a demo application
The’re excited to share that it is now stable! Land’s End experimented with this feature and observed 75% improvement in LCP in a lighthouse lab test.
The v15 release also includes a few new features for the image directive:
You can use the standalone NgOptimizedImage directive directly in your component or NgModule:
import { NgOptimizedImage } from '@angular/common';
// Include it into the necessary NgModule
@NgModule({
imports: [NgOptimizedImage],
})
class AppModule {}
// ... or a standalone Component
@Component({
standalone: true
imports: [NgOptimizedImage],
})
class MyStandaloneComponent {}
To use it within a component just replace the image’s src attribute with ngSrc and make sure you specify the priority attribute for your LCP images.
Together with the tree-shakable standalone router APIs they worked on reducing boilerplate in guards. Let’s look at an example where they define a guard which verifies if the user is logged in:
@Injectable({ providedIn: 'root' })
export class MyGuardWithDependency implements CanActivate {
constructor(private loginService: LoginService) {}
canActivate() {
return this.loginService.isLoggedIn();
}
}
const route = {
path: 'somePath',
canActivate: [MyGuardWithDependency]
};
LoginService implements most of the logic and in the guard we only invoke isLoggedIn(). Even though the guard is pretty simple, they have lots of boilerplate code.
With the new functional router guards, you can refactor this code down to:
const route = {
path: 'admin',
canActivate: [() =&gt; inject(LoginService).isLoggedIn()]
};
They expressed the entire guard within the guard declaration. Functional guards are also composable — you can create factory-like functions that accept a configuration and return a guard or resolver function.
To make the router simpler and reduce boilerplate further, the router now auto-unwraps default exports when lazy loading.
Let’s suppose you have the following LazyComponent:
@Component({
standalone: true,
template: '...'
})
export default class LazyComponent { ... }
Before this change, to lazy load a standalone component you had to:
{
path: 'lazy',
loadComponent: () =&gt; import('./lazy-file').then(m =&gt; m.LazyComponent),
}
Now the router will look for a default export and if it finds it, use it automatically, which simplifies the route declaration to:
{
path: 'lazy',
loadComponent: () =&gt; import('./lazy-file'),
}
The team gets lots of insights from their annual developer surveys so they want to thank you for taking the time to share your thoughts! Digging deeper into the struggles with debugging experience developers face they found that error messages could use some improvement.
Pic courtesy: medium.com
Debugging struggles for Angular developers
They partnered with Chrome DevTools to fix this! Let’s look at a sample stack trace that you may get working on an Angular app:
ERROR Error: Uncaught (in promise): Error Error at app.component.ts:18:11 at Generator.next (<anonymous>) at asyncGeneratorStep (asyncToGenerator.js:3:1) at _next (asyncToGenerator.js:25:1) at _ZoneDelegate.invoke (zone.js:372:26) at Object.onInvoke (core.mjs:26378:33) at _ZoneDelegate.invoke (zone.js:371:52) at Zone.run (zone.js:134:43) at zone.js:1275:36 at _ZoneDelegate.invokeTask (zone.js:406:31) at resolvePromise (zone.js:1211:31) at zone.js:1118:17 at zone.js:1134:33
This snippet suffers from two main problems:
The Chrome DevTools team created a mechanism to ignore scripts coming from node_modules by annotating source maps via the Angular CLI. They also collaborated on an async stack tagging API which allowed them to concatenate independent, scheduled async tasks into a single stack trace. Jia Li integrated Zone.js with the async stack tagging API, which allowed them to provide linked stack traces.
These two changes dramatically improve the stack traces developers see in Chrome DevTools:
ERROR Error: Uncaught (in promise): Error Error at app.component.ts:18:11 at fetch (async) at (anonymous) (app.component.ts:4) at request (app.component.ts:4) at (anonymous) (app.component.ts:17) at submit (app.component.ts:15) at AppComponent_click_3_listener (app.component.html:4)
Here you can follow the execution from the button press in the AppComponent all the way to the error.
They’re happy to announce the refactoring of the Angular material components based on Material Design Components for Web (MDC) is now done! This change allows Angular to align even closer to the Material Design specification, reuse code from primitives developed by the Material Design team, and enable us to adopt Material 3 once they finalize the style tokens.
For many of the components they’ve updated the styles and the DOM structure and others they rewrote from scratch. They kept most of the TypeScript APIs and component/directive selectors for the new components identical to the old implementation.
They migrated thousands of Google projects which allowed us to make the external migration path smooth and document a comprehensive list of the changes in all the components.
Due to the new DOM and CSS, you will likely find that some styles in your application need to be adjusted, particularly if your CSS is overriding styles on internal elements on any of the migrated components.
The old implementation of each new component is now deprecated, but still available from a “legacy” import. For example, you can import the old mat-button implementation by importing the legacy button module.
import {MatLegacyButtonModule} from '@angular/material/legacy-button';
Visit the migration guide for more information.
They moved many of the components to use design tokens and CSS variables under the hood, which will provide a smooth path for applications to adopt Material 3 component styles.
They resolved the 4th most upvoted issue — range selection support in the slider.
To get a range input use:
&lt;mat-slider&gt; &lt;input matSliderStartThumb&gt; &lt;input matSliderEndThumb&gt; &lt;/mat-slider&gt;
Additionally, all components now have an API to customize density which resolved another popular GitHub issue.
You can now specify the default density across all of your components by customizing your theme:
@use '@angular/material' as mat; $theme: mat.define-light-theme(( color: ( primary: mat.define-palette(mat.$red-palette), accent: mat.define-palette(mat.$blue-palette), ), typography: mat.define-typography-config(), density: -2, )); @include mat.all-component-themes($theme);
The new versions of the components include a wide range of accessibility improvements, including better contrast ratios, increased touch target sizes, and refined ARIA semantics.
The Component Dev Kit (CDK) offers a set of behavior primitives for building UI components. In v15 they introduced another primitive that you can customize for your use case — the CDK listbox:
Pic courtesy: medium.com
The @angular/cdk/listbox module provides directives to help create custom listbox interactions based on the WAI ARIA listbox pattern.
By using @angular/cdk/listbox you get all the expected behaviors for an accessible experience, including bidi layout support, keyboard interaction, and focus management. All directives apply their associated ARIA roles to their host element.
Pic courtesy: medium.com
In v14 they announced the experimental support for esbuild in ng build to enable faster build times and simplify our pipeline.
In v15 they now have experimental Sass, SVG template, file replacement , and ng build –watchsupport! Please give esbuild a try by updating your builders angular.json from:
"builder": "@angular-devkit/build-angular:browser"
to:
"builder": "@angular-devkit/build-angular:browser-esbuild"
If you encounter any issues with your production builds, let us know by filing an issue on GitHub.
The language service now can automatically import components that you’re using in a template but haven’t added to a standalone component or an NgModule.
Pic courtesy: medium.com
In the Angular CLI they introduced support for standalone stable APIs. Now you can generate a new standalone component via ng g component –standalone.
They’re also on a mission to simplify the output of ng new. As a first step they reduced the configuration by removing test.ts, polyfills.ts, and environments. You can now specify your polyfills directly in angular.json in the polyfills section:
"polyfills": [ "zone.js" ]
To reduce configuration overhead further, they now use .browserlist to allow you define the target ECMAScript version.
For more information and to develop web applications using Angular, Hire Angular Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”.
To develop your custom web app using Angular, please visit our technology page.
Content Source:
606, Suvas Scala,
Nr. Parikh Hospitals, S P Ring Road,
Nikol, Ahmedabad – 380049, Gujarat, India.
57 Sherway St,
Stoney Creek, ON
L8J 0J3
57 Sherway St,
Stoney Creek, ON
L8J 0J3
606, Suvas Scala,
S P Ring Road, Nikol,
Ahmedabad 380049
1131 Baycrest Drive,
Wesley Chapel,
FL 33544
57 Sherway St,
Stoney Creek, ON
L8J 0J3
606, Suvas Scala,
S P Ring Road, Nikol,
Ahmedabad 380049
1131 Baycrest Drive,
Wesley Chapel,
FL 33544
606, Suvas Scala,
Nr. Parikh Hospitals, S P Ring Road,
Nikol, Ahmedabad - 380049, Gujarat, India.
With a client-centric approach, we provide cutting-edge Web & App Development Services to businesses across the globe, ensuring successful project delivery that drive growth and innovation.
© 2024 — HK Infosoft. All Rights Reserved.
© 2023 — HK Infosoft. All Rights Reserved.
T&C | Privacy Policy | Sitemap