 Too many Microsoft 365 developers are laser focused on creating Microsoft Teams apps and SharePoint apps using the SharePoint framework, when the focus should be on creating web apps. And before I explain what I mean, let's first look at the different choices that Microsoft 365 developers have. I want to be clear that I'm not saying that this applies to all Microsoft 365 customizations. In this episode, I'm talking about things like Microsoft Teams, SharePoint Online, and Viva Connections. Hey, I'm Andrew Connell. If you're new here, be sure to hit that subscribe button to stay up to date on all my videos for Microsoft 365 and Microsoft Azure full stack developers. Let's start by looking at different customization options that developers have at their disposal in the various Microsoft 365 products and services. Now Microsoft gives developers three different options to customize their hosted experiences and to create apps. You can customize the user experience, you can extend access to your business apps with native extensions, and you can host web apps. Now let's look at each of these and see where they fit in using this slide that Microsoft is often using when they talk about this stuff. The first option is handled by parts of the SharePoint framework or natively in SharePoint online through the browser. Now I've updated the image to show where this applies to black out what it does not cover. For example, customers can use JSON to customize the formatting of a list, but that's only done using a browser enabled customization. Using the SharePoint framework, developers can also customize how fields are rendered with field customizers and add buttons to the toolbar or context menus and document libraries and lists, and they can do that with command sets. They can create custom forms with list form customizers and they can add headers and footers to pages with application customizers. And these are all grouped together as different types of SharePoint framework extensions. The second option is to use native capabilities in one of the Microsoft 365 hosted experiences like Microsoft Teams so that you can integrate your existing business applications. For example, message extensions and bots in Microsoft Teams use web services that expose customer data or your other business data within a native experience in the team's client. The last option covers the other experiences where developers can build complete applications within the Microsoft 365 hosted experiences. SharePoint online and Viva Connections by extension enables SharePoint developers to create web apps that are deployed to sites and pages for users. These exist as app pages, the Microsoft 365 and SharePoint name for them that are commonly known as single page apps or spas, or as smaller components known as web parts. Microsoft Teams also enables developers to create web apps. A tab in Microsoft Teams as just an iframe to an existing web app a developer has created and then they host. For the most part are simply collections of these tabs. Now most of the guidance and documentation on building Microsoft 365 apps, it jumps straight to the how you build the apps or customizations and it skips over all the more important questions such as what should you build or why should you pick one type of extension over another. Now based on my experience teaching developers in various settings such as courses or sessions at conferences and with Microsoft customers, developers tend to get stuck on the mindset of building a Teams tab or a SharePoint web part. These hosted experiences like SharePoint online and Microsoft Teams have many nuances that can complicate app development and these challenges have often been solved outside of the Microsoft 365 world. Developers can make app creation simpler by focusing on creating a web app and using the extensibility hooks and APIs that are provided by these different 365 component types to the hosted experience to get answers to their questions. Now I'll tell you about a time someone had trouble during my SharePoint framework workshop at a conference. They were looking for React component to show data from many SharePoint lists. They had a hard time setting up the automated testing for their web part which was also used as the implementation for a tab of their Microsoft Teams app. The problems they were having did have anything to do with their app but with the SharePoint framework project structure and dependency hierarchy in the build tool chain had been there. Making automated testing work with the SharePoint framework can be tough. Other things like accessing data, managing state, and setting up continuous integration and deployment can all get too complicated when you try to do them within these hosted environments and tools. Another challenge for developers is when they get stuck on a project many of them head straight to Microsoft 365 forums to get answers but usually there are more resources available if they don't limit their search to just SharePoint or Microsoft Teams forums. Remember you're just building a web app. Is the problem you're facing really related to the fact that you're working within Teams or SharePoint or is it just a web app issue? If when you're asking that question you determine it's just a web app question you'll have many more resources and options at your disposal than if you were searching for results with Microsoft 365, Microsoft Teams, or SharePoint in a filter that you're applying. Now I recommend building most Microsoft 365 apps as just web apps instead of SharePoint apps or Teams apps or Microsoft 365 apps for that matter. Before building your next Microsoft 365 app, ask yourself is it better to build a web app using tools like React and then load and host that app within a web part in SharePoint or a tab in Teams? Look building web apps means developers have more resources and a simpler app architecture and more flexibility not only in how but where they can use the app. Now while this approach won't work for every situation, ask yourself that question before writing the first line of code. The answer very well may be no this is a SharePoint app such as a SharePoint framework field customizer and in those situations it might make sense to build your app that's tightly coupled with the host environment. Let's look at another example. One of such scenarios could be a Microsoft Teams meeting app and in this scenario the meeting itself is a key part of the app so it would make sense to build the app on its own for use inside of Microsoft Teams? Maybe but then again maybe these are parts of an experience that you can build as self standing web apps. Meeting apps can use things like bots and messaging extensions but tabs are used in most of the UI experiences within a meeting app such as the pre and post experience of the meeting details the side panel and the main stage and a tab as I've already covered it's just a web app hosted inside of an iframe in Microsoft Teams. Using the features of hosted platforms it can be helpful in your apps developers can make web parts and SharePoint or Microsoft Teams tabs that can be customized to create a better app experience. What I strive for in my apps and I recommend is to use the SharePoint framework web part or Teams tab as the host for the web part and have it act as a bridge between the host environment and your app. In this scenario Microsoft 365 components act as more as a shim to provide my web part with what it needs rather than tightly coupling the app with the host application. Now if my app needs to get information about the current user or an access token to call a protected endpoint the web part or the tab must give those details to my app. Now but what I avoided all cost is injecting SharePoint or Teams artifacts into my web apps. Anybody who has tried to create test suites for a react component when they have injected in the SharePoint page context or the SPHTB client or the MS Graph client or any other object from one of the SharePoint framework or Teams related MPM packages you all know how hard this can be. None of these packages are intended to run outside of a SharePoint or a Teams context and mocking them for testing purpose it's just that it's a very significant undertaking. But when your web app is not tightly coupled to the host Microsoft 365 experience it results in an increased developer productivity and less complexity in creating web apps. This approach also yields a web app that can be reused in other scenarios. I get it you may be looking at this and say well those are Andrew's thoughts but what do other people think? Well I shared these thoughts on my site and on LinkedIn and I was quite surprised by the reaction that I received from my fellow web developers. Frankly I was pleasantly surprised by the reactions and passionate responses that I received from that article on my LinkedIn post. It wasn't just the quality of the reactions but the overwhelming sense of agreement that caught me off guard. So let's return to the idea of creating web apps for Microsoft 365 instead of using native Microsoft 365 apps. Again as I said I received a few responses from people who agree with this concept including this one from Gabor. He said preach it Andrew right on this is interesting to see the new direction with initiatives like SendText for Pository Services which has now been renamed to SharePoint Embedded. And some of the SharePoint services are becoming more headless and that is the right direction in his opinion. This makes my point even more valid. Most of the other responses were in line with what was best summed up by Juan. Most of the other responses were in line with what was best summed up from someone named Juan Larios. Juan said that he moved away from the SharePoint framework in Microsoft 365 specific development a long time ago. It seemed like a lot of the tech moved from .NET to full stack development. And most of the time the scaffolding that was provided in the templates and Microsoft specific templates they didn't move fast enough or mature enough to base your development on. He builds applications in general. He also looks at Microsoft Graph and other Microsoft specific tools as platforms and extensions and integrations. I totally agree with what Juan said. When you tightly couple your solutions to Microsoft's dependencies, tool chains and project scaffolding you may not be able to use some of the latest tools that are available. For instance, the SharePoint framework still only supports React 17.0.1. That was released almost three years ago in October of 2020. Meanwhile, React 18, the most recent major release, has been available to developers for over a year and a half since March 2022. Now this means if you create solutions using the SharePoint framework in Microsoft's SPFX scaffolding, you may be restricted to using outdated features. This is because the SharePoint framework and SharePoint Online don't yet support these latest versions. Microsoft Teams on the other hand, that's different because most of the web interface is run within an iframe and thus they're not dependent on the host capabilities. And so that means that you can safely upgrade to different versions of React. I agree with Juan's point about using Microsoft specific tools and platforms as extension points or integration points rather than the core platform for app development. This is precisely how I approach building apps using these tools. If I use the native capabilities as extension points for the web apps that I create, section on building Microsoft Teams apps as web apps. Juan provided an excellent example of how to build apps for Microsoft Teams, which he well articulated. He said, this is actually how I enjoy building Microsoft Teams app development. I did away with a Microsoft tool chain and built my own Microsoft Teams template using Next.js and React.js and wrote all of the auth flows directly into the app. And then he just used the Microsoft Teams context to react to theme, language and user profile changes. He was able to hire full stack developers to build the product in the web app without much or any Microsoft Teams in SharePoint or Microsoft specific tooling and knowledge. With this approach, he was able to pick the strategic frameworks and patterns that frankly are much more recent and exciting than the default Microsoft options. The Teams app package was just a pointer to the web app and either way, a lot more exciting architectures and technical options than the SharePoint framework or Microsoft 365 developer options presented. You just have to think about it a little bit differently. Typically frameworks like React.js or Next.js offer various project templates and tools to help developers start building apps quickly. However, you can take it a step further and create your own project templates to enhance your own productivity. Take a look what Juan did. He said that he ended up building Next.js and React.js templates for Teams apps because the Yo Teams and Teams toolkits had lots of drawbacks and unnecessary bulk and constraints that were a bit baffling. For example, the Yo Teams templates can only be hosted in a Windows app service plan on Azure. Maybe it's changed since he did it, but he found the Linux app service plans to be much slicker, faster and cheaper. At the point that he tried using the Teams toolkit it didn't support TypeScript. Now it does today. None of those toolkits are really needed. He built a microservice system with a family of apps working together and so he needed an app template. So what he did was he distributed out a Yo Man Generator that would scaffold a project template and it was a replacement for the Yo Teams and included components, features, and features that replaced the Teams toolkit options. His small little team did more in six months with these toolkits that he created internally than using the Teams toolkit. Now Next.js was a big game changer for the architecture that he built. Long story short, they used Next.js zones to essentially distribute independent Teams apps outside or inside one Microsoft Teams published application. He could secure them differently and install them on an as needed basis and using the SAS model. I believe this is an excellent example that perfectly illustrates my point. It demonstrates what I was advocating and why you should consider it. You don't have to sit there and build apps just as a SharePoint app or as a Viva Connections app or a Teams app. Think about building web apps. It gave Juan a lot more options when he was building out his application of how not only they built it and how they deployed it. Things that are not by nature supported or really promoted from the tools that we get from Microsoft for building Teams apps. Do you wanna learn more? I was interviewed by Scott Hogue and Ben Stegick on their podcast, the Microsoft Cloud IT Pro podcast in episode 344. If you wanna learn more about this near bigger discussion, check out that interview. Again, it was episode 344 of the Microsoft IT Pro podcast. The title was the Paradox of Choice as a SharePoint developer with Andrew Connell. Have you tried this approach with your Microsoft Teams, SharePoint, or Microsoft 365 apps? Does it make sense to you? Or do you have any questions about how you can do this? Let me know by dropping a comment below the video. And also let me know if you wanna see more videos about building web apps as the core of your Microsoft 365 apps. If you found this video useful, please give the video a thumbs up and subscribe by smashing that big subscribe button below the video so you'll see when I publish more videos for full stack developers on Microsoft 365 and Microsoft Azure. I'm Andrew Connell, thank you for watching and I'll see you in my next video.