SPFx: Back to the future? (reloaded)

Question

OK, following my previous post:

1. I stepped back from this SharePoint forum for a few weeks.
2. I tried to dig into the SPFx framework with a good faith. After all, add-ins were crappy (almost MS words), so could not be worse (spoiler: wrong!).

Here are my first actual feedbacks on SPFx:

1. First, while you could install only Visual Studio to have a "all-in-one" tool to develop, you now have to setup: NodeJS (mind the version!), Gulp, Yeoman, Yeoman SharePoint generator (mind the version), Visual Studio Code.
2. Visual Studio code is far from being as powerful as Visual Studio: to be convinced, only consider the very basic search tool.
   And you constantly have to switch between VS Code and a cmd prompt. VS Code is much more like a Notepad++ than an actual modern IDE.
3. To create a simple Hello World template project, you need to run yeoman @microsoft/SharePoint and wait... 10 minutes! Back in the old days, it was a matter of 3 clicks and 10 seconds.
4. A simple Hello World project is... 230MB of files. 230MB to display "HelloWorld". It's heavier than a complete .NET installation!
5. A lot of different config files to deal with, located at different places, and with different formats.
6. Nothing to provision files into SharePoint. It's like if SharePoint itself never existed. Provisioning technical files (like JavaScript, CSS, images) into SP libraries was like the DNA of the product. A kind of "Von Neumann architecture" where data and code used to be stored the same way.
   Now you have to store files outside SharePoint. Where? Not Microsoft's problem. Ho, of course, you can use Azure (i.e. create an account, don't forget to pay for it, etc.)
7. Even simple problems like "how do I rename a Web part" are problematic.
8. How to package common code between multiple Web parts to a separate bundle? An old classic question we should have an answer to for ages, you think? Ugh, not that simple apparently.
9. We've heard for years that JSOM is the way to go, so, obviously, it's easy to integrate it to SPFx... hum... not that sure actually.

10. After 15 years, a lot of developers are now familiar with .NET and C#. Apparently a bad thing. Now the official guidance is "leverage your famous JavaScript/TypeScript/Gulp/React/Angular/Yeoman/NodeJS/Sass/Azure skills". Quick survey:

    • How many proficient C# developers do you know?
    • versus: How many JavaScript/TypeScript/Gulp/React/Angular/Yeoman/NodeJS/Sass/Azure developers do you know?

    But as we have a word for all this mess ("toolchain"), everything is under control.

So here's my actual question: what can we build with SPFx, apart from 1990's state-of-the-art weather widgets?

Answer 1

Disclaimer: This was written by me in June 2017. But we came a long way since then and years later I can finally say that I actually enjoy the SPFx development process.

Some people will say that "It's progress and you have to learn". As if they assume that we complain about this part. I'm totally fine with learning, and I've spent a lot of time with yeoman, npm, TypeScript, gulp, etc. However, I'm still horrified with the abomination that they call SPFx. Hopefully, it will get better in the future. And I think, it already does.

I've found a Visual Studio Extension that might get you some F5 experience (Update: I would not recommend using it today):

Instead of SPFx, I have been using the amazing sppp yeoman generator. For some reason it works way faster, does not take hours to create a new project. While it does not produce SPFx web parts, I do create full screen custom aspx pages or CEWP using this. Update: I no longer use the sppp generator unless something needs to be developed for SP 2013 or SP 2016.

Answer 2

SPFx is the new way to build web parts, other customizations require other tools and skill sets. Workflows are built via Flow or Azure Logic Apps. Event Receivers can be created via webhooks. Timer Jobs could be built via Azure functions. PowerShell can be used to provision any files or assets into SharePoint such as lists, CSS files, content types, etc. Customizing menus and such still requires SharePoint add-ins.

Re the toolchain, if you haven't seen this, it's worth a read, though it won't make you feel better.

Answer 3

Will try and address your concerns one by one.

Have a feeling that you might now have dug enough :)

1) (Time taken to install Node, Yeoman, VS Code,gulp etc) < (Time taken to install Visual Studio). Licensing costs aside, once installed, VS code is sufficient for the purpose of building SPFx webparts. You don't bring a missile launcher to a knife fight :)

2) Agree with this, however, for the purpose of SPFx it's quite sufficient. Have you tried CTRL+SHIFT+F ? It also has an integrated terminal, so no need to switch VS code and cmd prompt. The entire command prompt is at your disposal inside VS Code. You can even run powershell from here.

3) Could be network/internet connection problem at your end, it takes me hardly 2-3 mins. Agree the process could be faster. Tried npm 5 ?

4) This is a bummer, but i think it will decrease in the days to come.

5) I dont see any issue here. Most of them are json format and afterwards depending on the framework(s) you use, they could be different.

6) You can also host your css,js artefacts in the Site Assets/Style library. Azure is just one of the options. Also, you can use the Office 365 Public CDN. The documentation is a bit sparse, i agree.

Host in site assets/style library -SPFx host sharepoint solution files

Package and Deploy SharePoint Framework WebPart

Office 365 CDN - Office 365 GA (you don't need to pay separately for this, its included in the subscription)

7) Agree with this.

8) Share data between webparts

DLL code SPFx

9) JSOM integration with SPFx is quite easy. Have created a PR in the SPFx dev webparts repository.

SPFx operations using JSOM

10) Proficient C# developers i know - around 200

Proficient JavaScript/TypeScript/Gulp/React/Angular/Yeoman/NodeJS/Sass/Azure developers i know - around 50

To answer your final question

Yes, besides kickass weather apps, you have access to access to the entire office graph, so you can build any app(s) consuming it, be it fetching outlook mails, calendar, delve, planner, yammer, onenote , dynamics CRM etc. One other scenario you can think of is Ecommerce, right from adding items to cart till payment gateways like paypal, mastercard/visa etc is possible(POC level code is already there).

Hope i have made things a bit more clear :)

Answer 4

Starting with a very famous quote:

Change is the only constant.

Back in the time, system used to have memory in kilobytes and today on the other hand we do have systems like IBM Watson. Think once, back in late 90's or early 2000's, how fast your systems were and compare them to today's smartphone.

Since then the technology is keeps on changing and now client devices are much more powerful to handle all such task. That's why, its a common trend seen in web development that people are moving away from Server Side development and preferring client side development method.

And finally what can we build using client side web part i.e. SPFx, i'll say, its upto once imagination (from a weather widget, to an enterprise wide application). One just need to think outside of box.

The problem i found with client side web parts is that, is it safe to build enterprise application using client technologies?