《最高人民检察院工作报告》全文公布

Transcript

Introduction [00:05]

Arthur Casals: Hello, everyone. Welcome to the InfoQ podcast Annual Trends Report in .NET. I'm Arthur Casals, the lead editor for .NET at InfoQ, and today I am joined by two external panelists, and we will talk about some of the recent innovations and developments happening in the .NET space. But before we jump into that, let’s start with the introduction of our guests. So, first, Irina, could you please introduce yourself?

Irina Scurtu: Hello everyone. My name is Irina Scurtu. I'm a software architect, Microsoft MVP, and I might say international speaker focusing around .NET and everything that moves around the.NET world. I'm from Romania and I enjoy working and keeping an eye on everything that happens inside this platform.

Arthur Casals: Thank you. Next up we have Francois. So François, can you please go ahead?

Francois Tanguay: Hi, my name is Francois Tanguay, I'm based in Montreal, Canada, and I'm the founder of the UNO platform, an open source project, as well as Inventive, our parent consulting agency out of Canada as well. I’ve been involved in the .NET space for over 20 years now.

Arthur Casals: Awesome, thank you. It’s great to have you joining this panel, thank you. Now, for everyone that’s listening, I’d like to quickly go through the scope of this podcast. Today we want to discuss some of the innovative technologies and trends in .NET that our readers may find interesting to learn or apply in their own organizations, now or in the near future. We know that there’s a lot happening today, so I’ll try to tackle different aspects of the recent .NET developments. I’d also like to mention that our other teams at InfoQ also publish trend reports on other topics like Architecture, Cloud and DevOps, and also Culture and Methods. So please check them out on the InfoQ website. 

Now, for this trend reports that we publish yearly, there are two major components or parts. The first one is this podcast, which is an opportunity for you to listen to the panel of expert practitioners from the industry on how those innovative technologies are disrupting the industry and the development workspace. And the second part of the trends report is a written article that will be available on the InfoQ website. This report will contain the trends graph that shows the different phases of technology adoption and provides more details on individual technologies that we have added or updated since last year's report. So, everything that's updated, everything that's new, everything that we are going to write about along the year it's in there. So, I recommend that you all check out the article as well when it's published later this month. 

Now there are a lot of excellent topics to discuss today, but in order to organize the discussion a little better, and also considering the expertise of our guests today, we will focus on the latest developments related to User Interface and Communication. François, the team at UNO has been exploring different areas on different fronts related to User Interface, which is good, because there's a lot of that happening at Microsoft right now. So, could you please talk a little bit about the current User Interface landscape for .NET developers and the industry at the moment?

User Interface [03:04]

Francois Tanguay: Yes, there are quite a few things happening and some confusion as well and the market as to like what's supposed to do what and what's available and what is actually ready in the market. So, cross-platform app development, and UI frameworks have been growing rapidly in the last decade or so. And to give you an example, we started UNO platform back in 2013 because there was nothing else in the market that we felt was good enough - I'll put it this way - to build apps for our customers, as a consulting agency. We eventually spun off UNO as its own thing, but it started as part of Inventive, and we used it as an internal tool for all these years. We open-sourced it in 2018 because we felt there was still a gap in the market and that we know we could fit in one of these gaps.

And there are basically three buckets of the way we look at it of cross-platform, UI frameworks out there. There's the hybrid approach that's been out there as a web-based technology for a long time, where you use web technologies to have a single UI experience across platforms, and then you wrap it into native shells in order to access native features. That's like the hybrid approach of using more basic technology. There's a second bucket, and that's where Microsoft would lie into what their Xamarin Forms and MAUI expertise, for example, where you're basically trying to create an abstraction across all the native UI frameworks that exist and try to figure out what intersects between all of these and create an abstraction that you can use from a single code base in order to create a cross-platform UI framework, right? We took a different route and we're part of that third bucket where Flutter, for example, fits as well, where you're creating a new UI framework that targets all the platforms available for the kind of ecosystem you live in. In .NET it obviously means web, desktop and mobile. And when you're in that bucket, you can either start creating your own framework, your own API design that you want your UI framework to live in. We decided to leverage some of Microsoft's own technology in UWP and WinUI as an API to make sure we're compatible with that and enable an existing ecosystem to live and be supported by the UI framework we're building. So, really, three buckets, hybrid abstraction base, or creating your own new layer on top and having a native UI framework that works everywhere would be the third bucket.

Arthur Casals: It makes sense. Thank you. Since you're dealing directly with that, how do you feel that these three buckets are in terms of maturity in terms of adoption? I mean, as you mentioned before, there are a lot of things that are confusing people. I know the whole discussion about Blazor and MAUI, for example, inside Blazor itself. I mean, people are still debating on the web, what they should use for what. How do you see this not so much in terms of organization, but in terms of maturity, in terms of adoption, where it's going?

Francois Tanguay: That's definitely a good question. And in terms of guidance, I think everybody could be better at providing exactly clarity as to where it fits. To answer your question on Blazor specifically, there's always a natural tendency to expand web-based technology onto native apps, because it makes sense just to try to wrap it and use it and allow the application developer to use native features. It comes with pros and cons. 

So in terms of maturity, it's been out there for a while. Obviously, Blazor is a new technology. Blazor Hybrid is even newer because it ships with MAUI now. If you ask us, that's why we're still investing, and we do believe that there's room for native cross-platform UI frameworks, which is at the other end of the spectrum. They're getting mature because we're building on top of native stacks, like .NET 6; there is support for iOS, Android, Mac, and all that. And it's been like this for years now, with Xamarin before that, right? So you're really building on mature technologies and platforms in the context of UNO because we're aligning with another mature API, which is WinUI coming from UWP, coming before that from WPF and Silverlight. It's been a well-known API that's been designed and battle-tested for years now. And that's why we decided to align with this in the first place. It gives us the opportunity to tap into a mature ecosystem. That's been out there for over a decade now.

Arthur Casals: I know there are some things happening on .NET 7 as well. So if you were to pick one of the most promising technologies related to UI regarding what’s being done at Microsoft right now, which would you say is the most prolific one?

Francois Tanguay: Well, clearly - and we're seeing it in terms of adoption - people are coming to, you know, primarily for our web support today. And our web support is enabled through the WebAssembly platform that we're building on top of, right? So it's been there on .NET 6, there're major announcements in .NET 7 now on the WebAssembly front with threading support, and exception handling as well in previous threading support. So it'll enable richer, faster, more performant applications to be developed and to sit on top of UNO for WebAssembly. So that's clearly where we're getting the most excitement and adoption, and we can see the innovators coming early to try to figure out how it's working and how they can leverage all those new capabilities that .NET 7 will enable, right? And some of them are coming in a few months already.

Arthur Casals: Thank you, Francois. Irina, how do you see this UI landscape from an architect’s perspective? Professionally and your company, I mean, François is inside the whole thing with UNO an all, but from the outside, how do you see this UI landscape?

Irina Scurtu: The UI landscape right now is very diverse. I mean, compared to, I don't know, five years ago, now you have so many options and it's sometimes very hard to actually take a decision. Okay, what should I pick for my UI? And should I go with UNO? Should I go with something else? Because in an enterprise environment, you really need to weigh all these available options. And for a specific business, Blazor might be just enough, even if it's not mature enough. I personally haven't seen real-life productions running with Blazor currently. And the safest decision to take from the architectural point of view is to go with something that is proven in the battle, as Francois said, is diverse. 

I mean, I remember when Blazor came up a few years ago, a lot of developers were hyped that, “oh right now I won't have to use JavaScript anymore.” And that's a lie, you'll have to use JavaScript. JavaScript is there to stay, but maybe, well, just use libraries and interrupt with JavaScript and so on. Not, right, front-end in like Angular or React or anything like that because it might be heavy, and it might be a steep learning curve for a backend developer, for example. So you need to work with what you have available in your team. If you have resources, if you have developers available and willing to learn something new, yeah, you might go for a full-set JavaScript framework. But if we're talking hybrid where we're talking UI in general, well, the decision is hard to take. If you ask me, it's nice to have options and not be stuck with one or two or three options that everybody uses.

Arthur Casals: Yes. To be honest, I'm very curious to see what's going to happen in the next two or three years because yes, there are a lot of things going on right now. And there is still some intersection. I mean, I don't know if you see that as well, but there are some things that you use for the same use cases, both different technologies. So I guess this causes a bit of confusion, especially for newcomers. I mean, developers that are just trying to develop their first application, their first UI in .NET.

Francois Tanguay: And especially as a newcomer, and that's something we're trying to tackle. So when you're looking at the curve of adoption, obviously at some point, you have something stable that can be adopted by a majority of people. And that's from UNO's perspective, and it's our core UI framework that targets all the platforms and runs everywhere .NET runs. But for newcomers, there're even more challenges from an architectural point of view, right? Once you have a UI framework and you're ready to build your first app that needs to connect to whatever communication layer, should it be like REST APIs or gRPC? And then, you need to start thinking about things like: How do you sterilize data? How do you navigate between your pages? How do you manage data in your application? There're so many different challenges. How do you make sure that your app - if you're targeting cross-platform or using a cross-platform, UI framework it is because you want to target a variety of platforms. With a variety of platforms, there're a variety of form factors. You need to take into consideration responsive design, for example, and how can your app flow across all those different breakpoints. And those are all challenges that are not necessarily supported or enabled by the UI frameworks themselves. So you need extra packages and third-party libraries and all that. And that's why now that we have a core stable UI framework, we start investing more and more in additional packages to enable and facilitate those scenarios for newcomers. So we have extensions to where you start, and we are already giving you all the guidance you need and hopefully answer all of your questions as to how an app should be built. It's more opinionated, so it obviously needs to be challenged depending on the architectural context that you have. But we're hoping that given the experience and because we've been builders first and foremost, we know those questions that are coming up.

So as newcomers, hopefully, you're getting more traction and there's so much waste in the industry from an app development standpoint. To us, it's crazy that in 2022, you're still trying to replicate all the great work that your designer did and your design spec document. You're looking at it, it's been validated, and now you need to start over and do it all in code in UI code from scratch. So that's why we're investing in what we call pragmatic low code solutions that maybe generate 90% of your UI code so that you're able to get all of this. And then, you can focus on the actual business challenges and get to your business layer, data, and business logic.

Irina Scurtu: I think currently, this year 2022 should be about reusing existing components, about building apps by putting together components and customizing those. You shouldn't need to reinvent the wheel and start from scratch with exactly as Francois said, okay, you get something from the designer and you should go ahead and implement it in pure HTML, CSS, and JavaScript. You shouldn't need to do that. I mean, there are so many tools and frameworks out there to help you with this, but I think people should need to understand that, okay, we have all these available options. How do you create a UI, a design from the user experience perspective and the interface perspective to be easy to be implemented? Why put a handful of people to create something from scratch? I'm not against creativity, don't get me wrong, but you have options out th,ere. We have frameworks that help you with a few clicks. You have the majority of codes that you need and you just go ahead and customize it.

Communication [13:41]

Arthur Casals: I completely agree. But interesting enough - I mean, we are talking here about UI and communication, but interesting enough, you still have that same confusion going on communication right here, because we don't actually have the same facility for .NET communication. I mean, I agree you don't have to reinvent the wheel in terms of UI components, but right now, for example, you have a lot of WCF orphans after the big split, let's call it. Because now you have gRPC, you have SignalR, you have a lot of things based on the ASP.NET Core middleware for communications. So we have kind of the same situation in terms of diversity of technologies, a plurality of technologies, but we can't really reuse anything from the past because most of these things kind of died with WCF. We also have to deal with that in terms of architecture, so Irina, how do you see this communication landscape confusion going on right now?

Irina Scurtu: Currently, in the backend also, there are so many options to move data from one side to another, especially with microservice architectures, or event-driven, or anything in between that requires back-and-forth requests and data transfer over the wire. Then it's hard for developers to choose if they were to be put in that situation. But to be honest, what I'm seeing is that REST or HTTP APIs are still the go-to option for implementing APIs. gRPC is starting to have some traction, but yet again, there is not enough maturity for it in .NET. And some people are very reluctant to use it to replace, for example, not WCF, because usually that's what gRPC would replace. But gRPC also would replace HTTP APIs because all developers say, "Hey, we're implementing REST APIs" when in fact they kind of aren't. They simply sent JSON over some endpoints and used HTTP methods, a few of them, not all of them, and not all of them as they should use.

I think on the backend side, the focus should be more on the business. Like, okay. What do we have to deliver? What data should we send out? And there is this confusion about, okay, I have two APIs that need to talk to each other. How do I get data from here to there? And the go-to option will still be, I think for a few years more, making an HTTP request, a simple one, doesn't matter. And that without abstraction, just using a simple HTTP call.

Arthur Casals: Yes. I mean, interesting enough - you mentioned gRPC a lot now - the thing is that part of what gRPC is supposed to replace is the whole inter-process communication. There’s a big part of the industry developing applications that are not web-native or don't use web communication at all. So I'm seeing a lot of them being confused about that, because right now you have a lot of examples, a lot of things happening on the API side, on the HTTP side of communication, but it's kind of like the local stuff was left aside. I mean, have you seen something like that going on in your company, or in your expertise?

Irina Scurtu: I'm more focused around the web part, but also if you have gRPC then you can also have WebSockets to communicate, so there is nothing stopping you there. But yes, the variety of all these tools in tech that are out there is confusing, and it's confusing from so many points of view. For example, if you were to talk about UI, that we just talked about, Yes, you're talking HTML, you're talking user experience and interface and so on and you need to tie that to a specific server that gets your data, let's say, but some of the development work pretty much stops there. There needs to be someone else taking the decisions. Okay. Why do we use gRPC? Why do we use WebSockets and when, or HTTP, or an abstraction over HTTP, or service boxes, or messaging or queues, there are so many scenarios.

Arthur Casals: Right, I mean, which would be also the same people should be on top of everything that's going on right now. Actually, I think that is also a problem for François, right? I mean, since you have a lot of WebAssembly going on with Uno, you're probably facing a lot of these new challenges or using a lot of these new technologies. How's it going from your side?

Francois Tanguay: Clearly, with the diversity of the types of endpoints that exist nowadays, you need to align with these patterns as well as to how data is returned and there're opportunities in there to grow in terms of maturity from the communications standpoint. When I started in the computer science industry, we were talking about CORBA and then we had DCOM with IL, that would be providing a format definition for what your service should behave like. And then we had [unaudible], right? And then you were measuring WCF as well. But with REST today, we have the Swagger API definition file that should be available for any endpoints being defined by developers, so that at least you're able to leverage the strongly-typed contract if you wish to generate code client-side, to consume it more easily in your apps, because yes, it's not directly tied to the UI, but it's tied to the client-side development experience. And it's the same thing with gRPC today. And there are so many different ways to build communication layers today, just in the Microsoft stack with web APIs. And then we add serverless considerations and Service Fabric and Dapper and everything else. They all provide their own interpretation of what an API layer should look like and how it should scale. So it creates additional challenges from a client-side story as to how can we consume that in a consistent manner.

Irina Scurtu: And since we're talking communication, I think we forgot GraphQL that - I think - has a lot of traction recently. It's very nice, it's a cool paradigm. It's meant to replace a lot of what HTTP APIs are doing, like back-and-forth requests to get some more data, and GraphQL puts everything pretty much in the hand of the front-end developer - or at least it gives more control to the front-end developer.

Francois Tanguay: Totally. And it also brings additional challenges. Especially if you're thinking about mobile apps, you always need to keep in mind that you're eventually connected to the Internet, meaning that in many cases you would enjoy an offline capability experience. And if that's the case, then you have cached or local data. And if you're able to edit that data, how do you sync back to the server once you reconnect, which is an entirely different set of challenges of being able to query local data versus remote data in terms of patterns and communication recipes, and how to sync back also. There's no one well-known prescriptive recipe as to how to do two-way synchronization of data between a client and a server.

Arthur Casals: Right, absolutely. I mean, that's a very, very important remark. On that remark: the technologies, how do you see them in terms of maturity or in terms of adaptation regarding what already exists or is out there? I mean, we have had these kinds of applications for a long time now, and this is an area that keeps growing on different fronts. So, how do you see .NET on that? I mean, the current stack that’s being used for this whole bunch of scenarios.

Irina Scurtu: It's diverse. I mean, a lot of things are mature. A lot of things are just showing up or just growing now, but they will have very much power in the future and we need to keep an eye on those. I don't know of a single technology out there around the .NET ecosystem that we will say, “hey, if you use this, it will solve all of your problems.” No - if you use that, it will solve your problem and cause then more problems additionally, and so on. But everything depends basically on what business case you have, what kind of app, how many users, and how you intend to use that. It's around, basically, business and the domain, and that will give you some extra flexibility or not.

Francois Tanguay: You're totally right, Irina. And I think at least the great thing that we have going with NET is obviously the frequency at which it's being updated now with their yearly release cadence, but also that story that .NET runs everywhere.

So at least you have some form of a stable foundation. If you're working with C# and.NET it works across the board, it's evolving still at a rapid pace, but you can rely on it across all layers of your tech stack. So even though some of these technologies that Microsoft, for example, is pushing out there, I'm not sure if they're ever gaining early majority status - yes WebAPI - but if you were to look at every single other technology that they've been pushing on, the communication layer with Dapper and Service Fabric and everything else, most people we work with, never heard of these technologies, even though they're super useful. So the barrier to entry might be high because they're complex technologies to tackle complex challenges. Whereas on the client side, maybe we have it a little bit more easy where it's more a sandbox in terms of the amount of challenges that we have given on client devices and all that. So it might be slightly less challenging in terms of scaling and all that. Whereas you have more elites to support on a communication layer.

Irina Scurtu: To be honest, I love the frequency of the releases and the things that they're getting - new things and improved things into the platform - but sometimes I think it's daunting to just keep up. At least if I were to put myself in the shoes of a beginner, how does the beginner keep up with everything that happens as a senior developer? If you have a background, then your background will help you to understand what's happening and what will happen inside this ecosystem. But as a beginner, you won't have comparison terms. You'll see, okay, this is the current state, what the next state and what the previous state was. You simply won't know. To give you an example, minimal APIs. It's a very nice feature. It's straight-up and bare-bone API for endpoints, if I can say that, but for example, for a beginner, it's hard to understand how you can put everything in there to make it work for a single case and so on.

Francois Tanguay: You're totally right. And that's a challenge, right? With the adoption of these technologies because there are so many of them and it's evolving so fast. At some point, you need to pick one and specialize in it. And if you're specializing as a technology developer, how can you make sure that these technologies get the adoption and the critical adoption to cross the chasm they are through, and get to “early majority”? If people are all specializing and diversifying in one of these technologies, they're all basically being stuck in the innovator's role of exploring these technologies and just specializing in one, possibly.

Irina Scurtu: One thing that is very nice and I really enjoy about .NET is that they are keeping the application models pretty much similar. They're keeping the convention over configuration philosophy and it's easier for a developer to switch from one tech stack to another tech stack around the .NET ecosystem because the same principles will apply there also.

Francois Tanguay: And maybe that's the real tech way. So we're getting adoption in terms of application models and know-how, but we're not getting massive adoption in terms of specific technologies because they're evolving too quickly.

Arthur Casals: Yes, absolutely. If you have anything else important to say, especially for new developers, as you both said, it's pretty hectic right now. If someone just dives into .NET and says, okay, what should I learn next? There's a whole bunch of stuff to choose from. Yes, it can be chaotic. So is there anything you could say about that or any advice you could give, for example, for newcomers, for people trying to learn new things about .NET or just new developers?

Irina Scurtu: I would say that as an advice don't ever try to learn everything because that would be counterproductive and you won't be able to do that. Just focus on one particular thing and start learning that. For example: WebAPI, learn that, or C#, if you were talking about language learning, and so on, but don't ever think that you will learn and know everything. You need to have a use case, you need to have practice with that specific thing, to be able to master it all.

Francois Tanguay: And I would actually go back to something that - Irina you've mentioned that before - beyond technology, understanding the underlying principles, the application models and paradigms - the underlying architecture currents, if you wish. They are way more important than the actual UI framework or whatever framework you're using, right, because those paradigms are similar across technology stacks. The way you develop an UNO app today is similar to what Flutter is doing and their own ecosystem and to what React is doing in the JavaScript world. Right? So it's more important, and that knowledge can be carried over between technology stacks if you actually understand what's happening conceptually under the hood.

Irina Scurtu: I think you said it perfectly: it is just conceptually understanding something versus using a platform. It's a total different thing.

Arthur Casals: Yes, I couldn’t agree more. Thank you both very much. It was a pleasure having you here today. We also have an invitation both for you and for everyone listening right now: we'd love to receive your contributions in terms of technical articles. So if you want to, if you have the experience and if you want to write about something more specific on .NET just send me an email, or there's a contact at InfoQ page at the bottom of this article. And you're more than welcome to submit, we’ll be glad to receive your contributions. Thank you, both of you.

Francois Tanguay: Thank you, Arthur.

Irina Scurtu: Thank you. I enjoyed talking with you today.

Arthur Casals: Yes, this was really great to me. I loved how the conversation flowed. I hope we have more opportunities like that in the future.

Mentioned

• InfoQ Trends Report: Architecture
• InfoQ Trends Report: Cloud and DevOps
• InfoQ Trends Report: Culture and Methods
• UNO
• Xamarin Forms
• MAUI
• Flutter
• Blazor
• Angular
• React
• gRPC
• WCF
• SignalR
• WebAssembly
• WebSockets
• Dapper
• Service Fabric
• GraphQL
• WebAPI