SPFx: Is TypeScript compulsary for future SharePoint development?

Question

Been looking into ways to keep a development team with medior JavaScript skills into the loop.

Basically I just want a SPFx Content Editor WebPart where they can do anything they have done with SharePoint for the past 10 years.

Please correct my wrong assumptions:

• SPFx development can only be done with (thorough) TypeScript knowledge (and the whole dev stack)
• Any external library (eg. 3rd party jQuery libraries) needs .d.ts definition declarations
• 3rd party ES5 Libraries that are not strongly typed and interact out of their box (into DOM) might cause problems
• Its cheaper to 'let the team go' and find people with above skills

Answer 1

Short answer - no, it's not required.

Longer answer - The toolchain we'll provide and invest in will be TypeScript based, as that is what we use internally for our own work, and we've found that it is better for us to focus on one solution than spread out across many. That said, the plan is to

a) create additional documentation on what the final output of the toolchain needs to look like, and

b) enable the ability to plug different tasks into the build pipeline.

Those tasks could allow you to use ES6 for example, rather than TS. You could even, technically, use notepad to hand craft a pure .js file and a manifest.json file, with no toolchain at all.

As for "let everyone go and hire new people", I think that's a bit silly. Sure, you need to learn a new tech, but all the technical domains (SharePoint, javascript, HTML, CSS, etc.) are all the same. As Sebastian mentions, it might take a short while, but it's completely learn-able.

Answer 2

SPFx development can only be done with (thorough) TypeScript knowledge (and the whole dev stack)

No I have gone from no knowledge to producing proof of concept code for a relatively complex scenario (export search results to CSV) in a week.

The 'whole' dev stack is not too bad but you will need to understand npm, gulp, typescript and preferable REACT. The tutorials are good.

Any external library (eg. 3rd party jQuery libraries) needs .d.ts definition declarations

Yes but most of them have these already and even if not they are fairly simple to write yourself.

https://github.com/typings/typings is your friend as its a community project that has lots of support for third party libraries.

3rd party ES5 Libraries that are not strongly typed and interact out of their box (into DOM) might cause problems

Yes but again you need to be thinking about using frameworks instead, SPFx shines when used with REACT / Angular because that's how its constructed.

Third party libraries that directly edit the DOM won't cause SPFx problems but they are not a good idea generally (see https://facebook.github.io/react/docs/thinking-in-react.html for an better explanation).

Its cheaper to 'let the team go' and find people with above skills

No if they have JavaScript and an appetite to learn then I'd say a week is what you need to get up to speed. Building relationships with new people and learning to trust each other takes much longer.

1. Do the React Tutorial first (its quick and gentle)
2. Do the SPFx Tutorial next
3. Cut code

Hope this helps

Sebastian

Answer 3

Answer to the headline question: no, but for SharePoint Framework it's going to help a lot (see @patmill-msft answer).

If they are good developers they will have no problem learning TypeScript, and it will be a worthwhile investment for productivity. A thorough knowledge of the stack is necessary to be a good developer generally, in my opinion.

Without the d.ts files you won't get Intellisense in VS Code (and before someone asks, yes, you could of course use another editor if you prefer).

TypeScript "transpiles" to JavaScript; there's nothing special or "strongly-typed" about the output of the transpiler, and nothing to do with DOM interaction which is a separate issue.

If you have a good development team, it would be cheaper to invest time for them to acquire new skills, but this should be an ongoing process anyway as the technology is constantly changing.

Answer 4

SharePoint developers have known since late 2012 that client side development is the future. And from what I've heard from various startups, JavaScript development is key. So there is no surprise that SharePoint Framework appears now, and will be used alongside add-in (apps) development model.

Talking to senior SharePoint developers one can see two groups emerging. Those who love TypeScript, and those who don't. And as it's written all over the SPFx wiki, you don't have to use TypeScript. TypeScript only generate plain JavaScript, which is nice.

But I can see a risk here too which is the same for previous development models too: when you don't have access to the source code (may it be TypeScrpt, Visual Studio solutions etc) - maintenance is going to be time consuming.

Answer 5

Makeing the transition from JavaScript to TypeScript in 2017 is a whole lot easier than making the transition from COBOL and FORTRAN to C++ or C#.

Any valid JavaScript is, but definition, valid TypeScript. Sure, you should try to take advantage of TypeScript, but if you are not yet prepared to jump in with both feet, feel free to take your time, learn TypeScript for free using the Playground at TypeScriptLang.org.

I made the transition from CMD prompt to PowerShell back in 2007, so I see making the transition from JavaScript to TypeScript in the same way.