The articles:
When building customisations and enhancements for SharePoint, JavaScript has been my technology of choice for the last few years. It simplifies the life cycle management, works across SharePoint Online or on-premises, and offers a huge foundation of libraries upon which to build. It also is being acknowledged as the way forwards within the SharePoint product itself - the "Modern Document Library" released in Office 365 uses the React JS framework.I have to admit, though, that my JavaScript was being created in the "old fashioned" way. No ES6, no build process, just the "quick" approach of a simple file in the style library within SharePoint. That approach brings the benefits of simplicity in structure, of being quickly updateable where needed, and of requiring just a text editor plus the dev tools in the browser. It is a very effective technique for small enhancements such as modifying the display of a column in a list view.
But those benefits are eclipsed by the downsides when building bigger applications in JavaScript. Very quickly a single JS file becomes too long. Encapsulating methods and properties in IIFEs helps to some extent, but refactoring and testing becomes hard. The code becomes sensitive to change. A better way is needed.
One such "better way" is to adopt the tools and practices that are commonplace in the open-source web dev world. Amongst these are the use of:
- Coding in modern JavaScript - ES6 and/or Typescript
- "Transpiling" that code into JavaScript that is compatible with current browsers (as the browsers are not keeping up with all features in the standards) - Babel
- Packaging the code to improve download times and browser processing
- Configuring flexible build processes through the creation of task runners - Gulp
- Manipulating code in nimble code editors rather than heavy-weight development environments - Visual Studio Code
No comments:
Post a Comment