Mindfire Technology

Why Mindfire Tech Favors a Blazor Future

Tue, 07 May 2024 09:00:00 -0600

Late last year, the long-anticipated version 8 of .NET was released, containing a slew of new functionality and polishing- especially within the realm of web development. One of the most talked about set of changes were the enhancements and additions of functionality given to Blazor, the ASP.NET team’s relatively new alternative to traditional web development frameworks- a potential alternative and even rival to the long reigning king, JavaScript.

It’s no secret that as Blazor and other web development frameworks (typically JavaScript ones) have developed, Blazor has remained somewhat behind due to lacking the overall functionality and flexibility that far older and more developed options possessed. Now, however, Blazor has finally been brought to a point where it is not just competitive, but many are wondering if it could be an all-out replacement for older frameworks- giving C# developers an edge in the web development sphere.

Despite this long-lasting argument and battle of comparisons, Mindfire Tech has for quite some time now (even before .NET 8) held Blazor in special esteem, valuing its more modern security and TypeScript-like functionality. Though, this opinion comes at the bias of Mindfire’s team mostly being made up of C# and .NET experts, who- while skilled with many languages including JavaScript- much prefer C# over other alternative languages. Blazor is simply a seamless switch and obvious choice for C# developers (or Razor Syntax devs) over JavaScript and its various web development frameworks (such as ReactJS, AngularJS, and so on).

I wanted to explain this bias from the start as I try to dive into the value Blazor presents both to the developers and to the clients or businesses investing in new or upgraded websites; by making it clear from the beginning that the most important and valuable aspect of Blazor is that it runs in the feature rich language of C#, and seamlessly integrates with the .NET ecosphere.

Before diving further into that point, though, I am going to first share some of what .NET 8 has brought to Blazor, and why it now stands on its own as a truly independent and extremely viable option for full-stack web development.

Full-stack web UI

In Microsoft or ASP.NET’s own words, Blazor is now a full-stack web development framework, partially thanks to its existing C# and .NET infrastructure, and also thanks to its new rendering options and hybrid methods of rendering web applications.

Before, Blazor developers were limited to choose, typically, between two primary methods of rendering web components: WebAssembly and Blazor Server. Each method had its advantages and its disadvantages, typically issues of network speeds and latency, and issues of download size and rendering speed. Developers had to choose what option would provide the best experience overall for their clients and visitors.

With .NET 8, however, developers have much more flexibility and can choose by component how they want them to render. Dividing up from the two original options, users now have the choices of Server-side Rendering, Streaming Rendering, Server Mode, or WebAssembly Mode. They also have a new automatic mode that combines the benefits of Blazor Server and WebAssembly, providing that hybridized mode that gives freedom to the developers in terms of how they want each component to render.

This is a massive enhancement to Blazor, and allows developers to refine their web applications significantly, improving performance and functionality via a case by case basis. Need one particular component to focus entirely on loading quickly? Set it to a Server-side setup and let it jump ahead, rendering as soon as the client opens the page. Need a component to be able to work offline? Blazor WebAssembly is the right pick- and there is no need to wait for it to finish loading and downloading to the client in order to display the rest of the website.

While JavaScript could do this with some effort, especially with the React framework, Blazor’s new ease of use method of choosing how you want to render your web application components removes any prior advantage JavaScript had over Blazor and C#. (This also includes mobile applications, working extremely well in mobile app/web development).

Streaming Rendering

Continuing with ways .NET 8 has improved how Blazor renders web applications, another feature or change which Microsoft was proud to announce was that of streaming rendering, wherein the client-side UI framework streams the user interface directly from the server.

This new function of Blazor helps to eliminate slow loading websites by allowing for content that can be immediately rendered and displayed to do so, while the rest of the content or application components finish their needed operations (similar to a progressive web app). In their place, simple placeholder content will be rendered and then seamlessly replaced as soon as they are finished loading. No page refresh, nor major visual changes- simple seamless patching that will give the user an impression of immediate response times.

It would definitely seem that this update to .NET was focused heavily on giving Blazor an edge when it comes to rendering content quickly and seamlessly, providing an easy way for developers to leave a positive impression on visiting users and clients.

Enhanced navigation and form handling

Another valuable aspect of Blazor, one which was majorly improved with .NET 8 (and in part a piece of streaming rendering) is the ability for it to handle changes without needing to refresh a page- this is core to a single page application (SPA).

Typically, or originally, static server-side rendered pages would need to be fully refreshed whenever a user navigated to a new page or submitted a form. Blazor, however, can intercept such requests and instead perform a fetch request, patching the rendered content rather than simply refreshing everything to match the new content.

The value of this feature is obvious, as it allows for more seamless usage of websites and other web applications, giving users a more fluid and comfortable experience. As companies and their various teams try to find ways to modernize their websites and applications- giving them the feeling of the future which customers and users constantly seem to thirst for- this seamless functionality certainly is one way to give you an edge over competitors.

Seamless interoperability

Technically already a feature of Blazor, but one that has remained a key selling point and was also improved with .NET, is how easy Blazor is to integrate with existing content from different languages and frameworks.

One of the downsides to using a new framework like Blazor (and in my opinion really the only proper downside) is that older frameworks will have had years and years of useful and functional content developed and shared across their respective ecosystems. JavaScript and frameworks such as React have countless resources and libraries available for immediate implementation, much if not most being open source and free to use.

JavaScript’s community is absolutely massive and constantly evolving, giving way for new and old developers to immediately find new ways of doing things and resolving issues they couldn’t solve on their own. It is simply a resource far too valuable to ignore or to abandon.

That is why it is fantastic that Blazor doesn’t do so, but instead has extremely robust methods of allowing interoperability with existing JavaScript solutions and components. You’re not restricted to just C# and .NET features but can blend and weld different existing methods of doing things (via JavaScript) together to allow for web applications to run exactly how you want.

This is especially useful as clients want to update or upgrade old websites and other web applications to run in Blazor. The likelihood is that much of the code the original site was made on is still useful or functioning fine, and instead of needing to fully re-create all that content, it can simply be adapted to integrate directly into your Blazor web application. Certainly, you should strip off and re-create severely crippled, unsupported, or insecure components- but for those pieces which still work great and may even be a critical aspect of the web application, no worries, it will likely work just fine alongside your brand new Blazor components.

Blazor is also compatible with many other technologies including SignalR and MassTransit, allowing super easy interoperability with whatever old web app you’re updating or connecting.

Conclusion

My purpose in writing this article was not to argue why Blazor is better than JavaScript and related frameworks (or other languages such as Python, Swift, or Dart), but simply to elaborate on why Blazor is causing such an uproar in the web development community- and why Mindfire prefers it over older and more established alternatives for web development.

The truth is that everything C# can do on the web, JavaScript can also do- and has likely done, considering its massive seniority in the field of web development. There is a reason that over 90% of all websites on the global internet utilize JavaScript as a core aspect of their web applications. However, my point is that any arguments that JavaScript was superior to C# and Blazor have now been made moot or no longer relevant. Blazor is now just as full-stack and viable for web development as any JavaScript framework, and even contains some of its own aces up its sleeve such as a superior programming model. The best part is that it’s still under major development, and Microsoft’s ASP.NET team doesn’t appear to be slowing down on development anytime soon (meaning continuing security enhancements, feature upgrades, and more).

So, what framework should you as a respective business owner or developer choose for your web application or website? Well, whichever fits your team’s expertise the best. Have a team of ReactJS experts? Keep on going with JavaScript. Have a team of C# and .NET developers? Blazor will be a seamless transition for them (if they aren’t already experts on it).

As for Mindfire Tech, we will continue to recommend Blazor to our clients, as it will always prove the best fit for any future web application projects given to our team. Not because we think it is necessarily better than JavaScript, but because it fits our model best and we can do anything with it that any JavaScript developer can do with their respective frameworks.

If you are interested in having a website or web application built from scratch or upgraded/updated, we here at Mindfire Tech are ready to tackle any project sent our way, no matter how challenging or unique. Whether you want it made in C# or JavaScript, our team of experienced software engineers will find solutions to your needs and will work to make your dreams become a reality.

Just reach out over our contact-us page, and we will start a proper conversation ASAP.

Native Isn't Really Better

Fri, 25 Aug 2023 12:00:00 -0600

Old Rivalries

Mobile Application development is one of the most popular software specializations in the world, with an estimated 224,000 developers located in the United States alone. Nearly every major app or program has some mobile variant. You could probably think of a dozen mobile apps that you use regularly that are also present on your computer or tablet. Moreover, these apps are usually not exclusive to one type of mobile device, whether that means tablets and smartphones, or iOS and Android.

For those of us who are not overly familiar with the software development process for mobile apps, the lines between iOS and Android or even Windows and MacOS may seem blurred or unimportant. Yet, as those who have worked in the industry for many years know very well, the differences between these operating systems are drastic when it comes to software development and can completely reshape the way an engineer must design their code.

Operating systems, such as Android and iOS, run on entirely different languages known as native languages. This is similar to different countries with different cultures and languages, each with entirely different ways of accomplishing more-or-less the same tasks or end-goals. These coding languages can also be the defining aspect of a software engineer and their career, especially if they choose to specialize in a particular language rather than spread their talent across multiple languages.

Because of this, there has grown a divide between software engineers, each deciding for themselves which languages and tools are best to accomplish different tasks, or which languages and tools they are more comfortable using. For the last couple decades, since the rivalry between Microsoft and Apple began with their unique and yet similarly popular operating systems, the argument has mostly been between which native languages or tools to use, that of Microsoft’s .NET with C#, Google’s Java and Kotlin, or Apple’s Objective-C (or more recently, Swift). Moreover, there is also the argument of which preferred IDE (integrated development environment) to use, that of either Microsoft’s Visual Studio or Apple’s Xcode.

However, in the last decade another debate has enflamed: cross-platform tools, which build a bridge between different operating systems. The debate being less about which native language is best, and more about whether to go native and write unique code for each mobile operating system , or to use cross-platform tools which apply the written code to both iOS and Android simultaneously.

The Future: Cross-platform Frameworks

The idea is relatively simple in concept: a framework or tool that can translate code written from a single language to various other languages or platforms.

The upsides to something like this are easily understood, as now a software engineer who is specialized in only one type of language can now develop applications for multiple operating systems without having to learn an entirely new language. In opposition, however, there used to be many valid arguments against cross-platform such as issues with compatibility, latency, and build size- yet, in recent years that is no longer the case. In fact, it’s gotten to the point that cross-platform frameworks have started to make developing across multiple operating systems individually look downright wasteful and short sighted.

“.NET, that is Xamarin and MAUI, now compile down to pure native code, and they’ve been optimized to the point that once you’ve compiled your app and built it for the final target platform of Android or iOS, it’s going to run as fast- and sometimes faster- than native code would.” Says Tony Pitman, a software engineer with over 40 years of experience, who has watched this progression closely and has become an expert in the use of Xamarin and .NET MAUI. “Because, when you write native code, you’re the one doing all the work figuring out how to optimize it, and the .NET team has done a great job optimizing their code to produce extremely performant native code on Android and iOS.”

It would seem, then, that all the old arguments against cross-platform frameworks may no longer be relevant. It might, in rare cases, be more efficient for software developers to still use native code to write their apps, but only if they intend to release it for just the one OS and if their engineer is already specialized or trained in that native language. Otherwise, if you need to run your code/app on multiple operating systems, it may genuinely be a waste of money and time to write native code for each individual use case when the tools used for cross-platform development are near perfect replacements.

Consider the amount of time and resources wasted, all being spent on developing applications for different devices and operating systems. Not only are you doubling the time it takes to write the code, as you have to write it entirely from scratch per native language, but you are also, most likely, are paying an entirely different team of software developers trained on that particular language.

To make it even more difficult to justify, having code written in two different languages means you’ll end up with entirely different and separate codebases that will need to be maintained simultaneously. This means that if you have an app which is both on iOS and Android, and you need to make an update to the app, you’ll have to make the needed changes individually. The complication with this is not just twice the time and effort needed, but also the potential of complications with one OS/device causing a delay for both deployments. You might have that update ready to go on Android but be forced to delay its launch all because of an issue which is unique to iOS.

Just Like Mother Used to Make It

Now, to further elaborate on the point regarding how close cross platform frameworks get their code to native: these tools have been meticulously refined over the years to grapple into every part of a native application. For example, native components such as entry boxes (i.e., a fillable text form) can be very unique between operating systems, having their own special style that is reflective of that OS’ theme. In light of this, Xamarin and MAUI have been designed to cross-compile into those native components, meaning the same entry box will look as if it was written in native code on each device.

The value in this is that developers don’t have to spend extra effort ensuring that their apps fit the unique feeling of each operating system. The downside is that if you wanted the theme to be identical between devices and operating systems, then you have some additional work to do. The upside in turn, however, is that these cross-platform frameworks have tools and functionality to allow just that, including the ability to overwrite and/or adjust how those native components will appear after cross-compiling.

For example, on Android many text entry boxes (especially on websites) contain a magenta or purple underline rather than a box outline, while iOS usually has a recessed box with an outline. With Xamarin, you can choose to have your text entry element displayed how Android or iOS would natively display such a box as if you had written said app in their native language. Or, if you wanted both to simply show as an empty outlined box, you could adjust the custom properties to force it to display identically as such. Either way it is a one-time effort that can be executed using a language the developer knows, and the cross-platform framework will do the heavy lifting of compiling to both operating systems, seamlessly creating the desired component.

Options for every Developer

The majority of the arguments made to this point are specific to Xamarin and MAUI. Meaning, the ability to cross-compile into native components is (mostly) a unique feature to their platforms. Other solutions such as Flutter or ReactNative get around this by having their own unique components, which can be customized or adjusted according to the desires and needs of the developer.

This presents another interesting selling point of getting into the cross-platform framework arena, that there are multiple frameworks a developer can choose from. So, every developer has the opportunity to choose a platform that best suits their coding preferences.

“When it comes to choosing a cross-platform development tool, a lot of that decision is going to depend on the developer’s experience and what they’re used to. If you have a developer who is used to using Microsoft tools and writing Windows desktop apps and similar mobile apps, they’re more likely to use Xamarin or MAUI just because they’re used to .NET and they have a lot of experience with C#.” Says Tony, thinking back on his own experience with .NET and C#, which led him to Xamarin. “On the other hand, if you have a developer who is more web based, so they do websites and web pages, and a lot of JavaScript, they’ll probably gravitate more towards ReactNative or Flutter.”

He continues, elaborating on the flexibility of these tools, and how all that really matters is what you are comfortable with and what you are willing to learn, stating “Now that doesn’t mean that either one of those people couldn’t learn the other tool- in fact, I know a lot of developers who are Microsoft .NET people and yet use Flutter, and also people who are more web-based who really like .NET and C#.”

Conclusion

Ten years ago there could’ve been arguments made about the superiority of writing in native code with native tools due to the rather primitive cross-platform tools of the time. However, that is no longer the case, not even in the slightest. Not only can these tools compile applications to near identical replications of a natively written app but can even supersede them in terms of quality and performance. Most importantly, however, they can cut down development time significantly, reducing costs and allowing your developers to spend more time innovating rather than duplicating work and maintaining multiple codebases. It’s just plain better

What are your thoughts on the state and use of cross-platform development systems? Do you still prefer to use native languages and tools? Let us know your thoughts in the comment section below.

An Introduction to Mocking Frameworks

Fri, 05 May 2017 15:52:45 -0600

Introduction

A mocking framework is used to create replacement objects. These objects can be Fakes, Stubs, and Mocks. In unit testing scenarios, developers use mocking frameworks to isolate dependencies. This allows for a quick, concise, and reliable way to ensure that the testing goes smoothly.

More Background on Using Mocking Frameworks

Like discussed above, mock frameworks are extensions testing techniques for object oriented programming. So what problem does it solve? Let’s find out.

Say that you are testing your code that is still in development. In order to achieve the right results, you need to test its interactions with system resources, outside applications, and other dependencies. Unfortunately, you learn early on that that is not possible. Utilizing a mock framework allows for realistic emulations of the required interactions.

Creating a Mock

When you are running a test, they have to be set up. Oftentimes, dependencies are still under development and can require a set response, ie., a specific time of day, or error code. Even when you feel good that the code is interacting with external program or different system components, the tests can cannot be counted on.

With mock, they interact with the code as interfaces, meaning that you must write a fully-interface compliant test. When this is done properly, the code will not be able to tell the difference between the mock and the actual object.

Need a visual? Check out this Pluralsight video on how to Create mock objects with .NET

So, should you start mocking frameworks for testing? The answer to that is totally up to you. It matters what you are testing and how in depth of an interaction you are looking to get. Mindfire Technology loves looking at different ways to make writing and testing code more efficiently. Ask us what cool new tech we are working on, and we will answer!