It is a triumph that jQuery, and subsequently Bootstrap, are boring. They solved their problems so conclusively that we had to go and find a whole bevy of new ones.
jQuery is years of hard-won wisdom in a tiny little file. jQuery 3.6.0 shipped on 2 March, nearly 15 years after 1.0, and code written for 3.0 should mostly still work. Bootstrap 5, now in beta, drops jQuery because browsers caught up. But fades, events and odd browsers are tricky problems, and it’s much better to outsource them to a mature library than write your own.
Why boring wins
- It doesn’t change. Server-side code is mature, well documented, easy to maintain and simple to fix, trace and optimise. You spend your time on business requirements, not on what’s coming next from your vendor.
- Configuration ages well. The longer a system stays configured, the better the return on the money spent building it.
- Libraries carry the edge cases. In Australia, people on poor data reception tend to have older, stranger devices and browsers. jQuery has already been tested against them. If a browser can’t run jQuery, the device is useless anyway. If it can’t run your code, that’s your fault. The same goes for screen readers and accessibility.
- Novelty serves the experienced. Experienced developers over-emphasise novelty and don’t repeat the obvious enough, so newcomers miss the proven tools. When an old tool starts to feel dull, the change is in us.
A vendor that rewards new ideas over commitment to existing customers and code will keep shipping new frameworks. AngularJS, released in 2010, gets long-term support until 31 December 2021 and then stops. Its successor, Angular, is a different framework, and its libraries are meant for Angular apps only. React, Vue and Svelte are libraries you can drop into part of a page, so you can take or leave bits of them.
When a front-end framework earns its place
Front-end frameworks such as React and Angular make sense when:
- Server capacity matters: public-facing work with low margins per interaction. With modern compute costs, that’s start-ups, Facebook and Google, not most business apps.
- You don’t control the server.
- You really need weird UI. Most of the time that’s poor design, and users end up confused.
Outside those, some custom JavaScript usually handles the problem better than a framework.
SharePoint: configure first, code last
Avoid custom development where you can. Out-of-the-box web parts, lists and pages get you a long way.
Code-based sandbox solutions are gone from SharePoint Online, and SharePoint 2010 workflows were removed from existing tenants on 1 November 2020. Every bit of code you deploy into SharePoint is something to migrate later.
The SharePoint Framework (SPFx) has grown up since its rough start. The app catalog and ALM APIs handle deployment and upgrades, it works on classic and modern pages, in Teams and on SharePoint Server 2016 and 2019, and you can use whatever JavaScript framework you like, or none. Modern sites block custom script by default, so the old trick of injecting script through a web part is on its way out. Custom web parts the old way are dead. SPFx is stable, so if you need a web part, build it there.
Keep it thin:
- Logic in plain TypeScript, calling APIs that don’t change much: the SharePoint REST API and Microsoft Graph.
- Bigger apps on your own server or in Azure, calling the same APIs.
- A toolchain you know. Webpack, TypeScript, PnPjs, Fluent UI, Bootstrap and jQuery all still work inside an SPFx web part.