This is one installment in a series by Voitanos asking experienced SharePoint developers to share their thoughts on the new development model for SharePoint - the SharePoint Framework. In this series, we ask each person a series of questions and let them share their thoughts.
Actually, my background is web development, I start with web development 20 years ago with PHP and mySQL, and then I think twelve years ago I switched over to SharePoint and try to apply the things I already knew from the web development perspective to SharePoint.
Meanwhile a lot of time, because I tried it out from the first beta versions came out and played around. Was looking if I can do the that I did back in the classic experience to move to the modern experience. And now I’m currently working on how to make a story about how to make reusable components that you use throughout a project.
The favorite part of the SharePoint framework is the extensibility from my perspective. Because you can use all the libraries that are out there through the nod modules that you tend to use in regular web development, and also the frameworks, it’s pretty open to use different frameworks except some limitations with, for example.
But you can use , you can use … and to think one thing does really good when it comes out, which is currently progress, is the elements because it moves toward a web standard development through the web components that implemented in element.
Actually it’s not something that I would add to the SharePoint framework, I would remove something from the SharePoint framework because currently now it supports no framework web parts, it supports react framework web parts, and framework web parts. React is a no-brainer from this perspective because Microsoft built all the interfaces using React. That’s okay, but I think Nugget isn’t that useful to have it in SPFx. What I want to see in future is more an extensibility model that you can use different frameworks and plug it in the generator.
On the other hand for the web developers, there are so many specifics in there from the SharePoint framework that are specific to SharePoint that it might be hard for a regular web developer to start working with SPFx.
Yeah, from my perspective there are still some features missing that we have in the classic experience that should be implemented in SPFx. Like I told you before, the webpart to webpart communication, some more about the branding side that we used previously, I think I want to see this in the future that we have a comparable features set that we had in the classic experience and still have in the classic experience.
I think one big issue more from the organizational side of the whole development because you already built your classical experience component, and how you move those over to the modern experience. I created a for that, where I can really test out all the implementations you have with the classic experience, then adapt it to the modern experience and see where some … see less changes and feature changes are required to make it running in the modern experience.
Did you like this installment in the series? Let us know what you think in the comments below and share it on social media!