ASP.NET Core gives developers all the tools they need to build robust back-end systems that are secure, scalable, and maintainable. It integrates seamlessly with Microsoft Azure as well as other cloud technologies (such as AWS) allowing developers to leverage the power of the cloud.
When it comes to the web, it provides developers with a few options. These options make use of server-side rendering, which allows developers to interact with the domain and business logic on the back-end before server-side rendering takes place. This is powerful. No, the server has never gone away ;). The server-side rendering options provided by ASP.NET Core are 1) MVC and 2) Razor Pages.
MVC (Model-View-Controller) is an established pattern in the web development community (made famous by Ruby on Rails I believe). It is better suited for API development than for web development. With MVC, controllers have the potential to get very messy by serving multiple views and thus will have more than one reason to change.
Microsoft thus developed Razor Pages which is a page-based model where the code-behind file handles the HTTP requests only for that page/view. It is similar to Xamarin.Forms MVVM's use of XAML and C#. It provides a cleaner separation of concerns. Razor Pages is thus the preferred and superior technology to develop enterprise web-based applications.
The web development world though keeps fluctuating between thin clients and thick clients. Is it better if more code executes and renders on the client or on the server? What is the right balance? Can this ever be objectively answered? These are the types of question which arise from the thin-thick-client debate.
Today all the rage seems to be with thick clients, namely with Single Page Applications (SPA) and Progressive Web Applications (PWA). SPA apps feel fluid, slick and responsive like desktop apps, while PWA apps feel the same, but are also installable as self-contained apps on various operating systems. Both SPA and PWA apps are capable of working offline while PWA apps feel like the native apps of the platform (executing without a browser window). This opens up doors of possibility. Suddenly, though it is possible, and probably the recommended route, to submit PWA apps to the app stores, one has the option to bypass the app stores and target mobile devices with native-like apps using a simple link.
It is not all well and good with PWA technology though. As an example, unless things change dramatically in the future, I do not see any major bank using PWA technology to develop a consumer-facing banking app. Access to native underlying platform APIs are needed and PWA technology will get in the way in such a scenario. Granted that PWA technology, limited by the capabilities of the browser, will probably never be at the same parity level of native platform SDKs or cross-platform tools, such as Xamarin or Flutter, in terms of accessing the underlying platform APIs, PWA technology still affords development teams with a lot of power and flexibility. By strategising, at design time, to compensate for the shortcomings of PWA technology, development teams can target multiple devices using web technologies alone. Imagine using one tech stack and one language to develop high-quality web and mobile apps as well as back-end services without ever context-switching and without ever switching from one language to another? Would that not be rather convenient?
The big three web development frameworks, which make SPA and PWA development possible are React (by FaceBook), Angular (by Google) and Vue (by a community). While these frameworks are brilliant in different ways (off the top of my head: React's JSX and Hooks, Angular's comprehensive docs and support of DI, Vue's hybrid approach combining the best parts of Angular and React), they all compile to JavaScript (JS). What does this mean? Unless development teams use JS to develop their back-end services they would have to context-switch between the tech stack for the back-end and front-end. This means learning and using multiple languages, build tools and frameworks. While this is certainly advantageous from a career-development perspective, it is nice, efficient and even cost-effective to be able to develop in one tech stack if possible.
The following questions thus arise: Is it possible to develop SPA and PWA apps in .NET with the same efficiency, effectiveness and support as with any of the big three frameworks? And more than that, is it possible to develop such apps with back-end services to match in one solution, one language, and one tech stack without context switching?
The answer to both questions is a resounding 'YES'. And this is what I like about .NET and ASP.NET Core. More on this in a future post.
Comentarios