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
  • 1
    I was under the impression that all valid JavaScript is valid TypeScript. Isn't the TypeScript just transpiled to JavaScript in the end anyway? Aug 25, 2016 at 14:48
  • 2
    I have seen them say no, it isn't required, you can write plain old javascript if you want. I feel like they want to you to though, cause of the whole type safety features and stuff, but honestly, I only see that as a crutch for those that come over from strong typed languages and don't understand JS. Aug 25, 2016 at 14:48
  • Yes, it is JS in the end. I haven't tried going that route yet [altering the JS that is in the dist folder] At this point in time it feels like it would be like buying a new Tesla, stripping it with a blow torch, replacing the engine, and glue-ing the logo back on. Aug 25, 2016 at 14:53
  • +1 I've thought of this myself, and hope it will be "solved" in the near future...
    – Benny Skogberg
    Aug 27, 2016 at 5:52

5 Answers 5


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.


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


  • Very good answer, thanks! Sounds to me I have to educate the Front-End team into more back-end technologies and let the .Net heads who want to learn TypeScript go (unless they can proof they understand CSS Specificity) Aug 25, 2016 at 16:53
  • I think the transition from JavaScript is about a week. The BIG learning curve is the web stack stuff (gulp, npm etc) If you have been following OfficeDev/PnP and the videos and articles coming out of there since the spring of this year (2016) you should be fairly familiar with the Web Stack Stuff. The IT world keeps evolving and re-inventing itself. Its just a fact of life over the last 30 - 40 years. Embrace it. If the team wants to embrace the new technology, then great let them get on with it. If not, then as Seb says "let them go". Aug 28, 2016 at 11:01

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.


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.

  • I see 3 groups, your black/white pro/con TS and the group of Internet developers that sees opportunities and are eager to learn. (or maybe it was just me in this group for the past 26 years) Bottom line is always: Can I do more than I could yesterday? The investment in this new Stack is huge (and don't forget you privileged MVPs - by Marketing Valued Persons have a huge head-start) After a week with SPFx half my whiteboard is full with arrows where we will probably cut corners, we will purposely deliver bad code because the investment in good code(rs) is just too huge at the moment. Aug 27, 2016 at 7:56
  • BTW regarding "SharePoint developers have known since late 2012 that client side development is the future." -- Front-End Developers have known this for a way longer time; and had Microsoft paid attention to Douglas Crockford in 2008 at one of their own MSDN knowledge sessions, this whole transition could have started 4 years earlier, and would have been a lot smoother Aug 27, 2016 at 8:02
  • Maybe the problem with TS is that it does do JS. Even JSWizard Waldek doesn't go 100% OOP with his TS Todo example, Instead of creating a Class "Todo" with methods, he wraps "bad" non-OOP JS functional code in a "dataservice". Mind you, I don't have a problem with bad coding; I do have a problem (because I am bound to hire them) with 90% of "Developers" going to copy/paste these 'guru' patterns, not knowing wtf they are doing. Aug 27, 2016 at 8:19
  • @Danny'365CSI'Engelman I agree to what your saying, and it's good your asking. My main concern is maintenance sharepoint.stackexchange.com/questions/192028/…
    – Benny Skogberg
    Aug 27, 2016 at 8:38
  • 1
    @Benny I agree with you maintenance is a concern, but Pat and Vesa have said that maintenance will be coming as will the whole ALM story. So I think I suggest reserving judgement on the maintenance question until then. Aug 28, 2016 at 11:10

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.