So. Many. JS Libraries.

If you’ve run into a problem developing your web application and need a bit of functionality that just isn’t there, there’s a pretty good chance someone has come along and made a JS library to address it.  Here’s a bit of an idea about the categories of JS Libraries that are available.

• Helpers.  Provide developers with shortcuts for common tasks.  JQuery and Bootstrap fall in this category.
• Assets.  Icons, fonts, themes and so on that are likely to make a big impact on the look and feel of your web application.  FontAwesome is an example.   Bootstrap comes with icons as well.
• Controls.  Interactive UI elements that provide functionality roughly equivalent to what a Delphi component might offer.  There are countless date/time pickers, for example FlatPickr.
• Tools.  Similar to Helpers, these are used to extend or otherwise enhance the components core controls that you are already using.  Interact.js adds drag+resize functionality to any control, for example.
• Services.  These include libraries for connecting to external services or communications, and libraries that help with sending e-mail and SMS messages, that sort of thing.
• Devices.  Typically these are APIs that allow for interacting with local devices or other hardware. Anything to do with Raspberry Pi, for example, would fall into this category.

In this series we’re going to start out by focusing on those JS libraries that can help us craft better looking and easier to use web applications, so typically the first four categories. While the last two categories, Services and Devices, are hugely popular and important, they’re also very specific in nature.  Coverage of these would likely be far less about JS and TMS Web Core and instead be focused entirely on the Service or Device in question, and thus somewhat different than what we’re trying to do with this series.

Managing JS Libraries.

For the more adventurous, there are some additional considerations.  The first is about where the JS Library is actually hosted.  When you create a TMS WEB Core project, the final output is a collection of HTML, JS and CSS files that are then uploaded to your web server.  When the Project.html file is loaded into a visitor’s web browser, it tells the browser where all the other JS and CSS files are to be found.  There are typically three places where a JS library might ultimately reside, each with its own considerations.

• CDN.  A content delivery network like jsDelivr hosts many such libraries and is often the preferred choice.  The main benefit is that you don’t have to handle the traffic that comes from delivering the JS library to the visitor’s browser.  For small libraries, or if you have a small number of visitors, this is likely not an issue.  But if you have thousands of daily visitors and a JS library that is several megabytes, it certainly can be.  If your visitors are geographically spread out, the CDN may also be able to serve the content faster than you can by virtue of them having typically many more servers located strategically for explicitly this purpose.
• JS library Vendor.  If the JS library is popular enough (and commercially supported) the vendor may offer links to its own servers for you to use. This has many of the same benefits as a CDN. The delivery is handled by others.  Some vendors may provide such functionality but may also have service limits to be aware of.  Typically these are very high. Some might even require custom API keys or other means of authentication before the JS library can be used in this fashion.  We’ll cover more of this when we get to FontAwesome, which does all of these things.
• Self-hosted. The JS library can also be downloaded and included directly in your project, living alongside the rest of your HTML, JS and CSS files.  The very nature of the web means that if you can link to a JS library at a CDN, you can also download it and include it directly in your project.  This may also be needed if you’re wanting to use a JS library that isn’t hosted by a CDN and isn’t hosted by the vendor.  But there’s another reason why you want to do this which we’ll get to next.

Many JS libraries, like most well-written software, are updated from time to time.  Due to the connected nature of web applications, many of these updates are security-related so there’s a need to keep them, and the applications that rely upon them, up-to-date.  You would be well-advised, particularly in the case of GitHub projects but others as well, to subscribe to notifications about the JS libraries that you regularly use.  Especially if they are under active development.  But like all software, any update of any kind has the potential to break functionality elsewhere in the application or introduce additional problems perhaps not foreseen by the developer of the JS library.  And as many Delphi developers are aware, keeping up with versions of different libraries in your projects can sometimes be a nightmare.  Fortunately, here we’re able to change versions often just by changing the one or two lines in our project that reference the JS library.  This makes it easy to upgrade or revert to an older version. But here again we have some things to consider.

• Either the CDN or the vendor will offer a link to the “latest” version of a JS library.  For non-critical web applications, or those in active development, this is probably the best approach.  Any updates are automatically included in your app without having to do anything at all.  For JS libraries that are responsibly supported, widely deployed, and that have been around a long time, this is great.  If something does break there are thousands of people that will let the developer know in short order.
• If the developer routinely breaks things with each new build, then it may be an idea to use a specific version of a library instead, using any of the methods we’ve covered.  CDNs and vendors typically don’t take away prior versions specifically because of this.  Some even offer some middle ground, like being able to have the latest updates for the current major release via the same link, but a different link when upgrading to a new major release. 
• Finally, if your project is mission-critical, is behind a firewall, or is particularly sensitive to changes in the JS libraries being used, then we’re back to self-hosting the JS library.  This means that you have the responsibility of updating it as well if there are security-related or other critical issues. The upside is that your application isn’t going to fail due to newly introduced bugs in an obscure JS library.  

One final topic about managing JS libraries: dependencies.  If a JS library depends on another JS library, it will need to be added to your project as well. Most of the JS libraries we’re going to cover won’t have any such dependencies, so this may be a non-issue for many.  However, many popular JS libraries do indeed have dependencies that we need to be aware of.  There are two that come up often.

• JQuery.  As a helper library, many, many other JS libraries rely on its availability in their own projects.  This has become less of an issue in more recent years, and many projects are actively working on removing dependencies on JQuery. 
• Frameworks.  Many JS libraries are either crafted or customized for a particular JS framework.  In this context, by framework I mean the JS environment that is used. React, Angular, and even TMS WEB Core are all frameworks in this context.  There are many such frameworks. So if a JS library has been crafted to work specifically within React, for example, that JS library may not always work directly in TMS WEB Core.  Often this just means there’s a different version of the JS library that is needed instead.

From our perspective, a dependency just means that the JS library must come after whatever it is dependent on in the Project.html file.  Fortunately the Manage JavaScript Libraries tool allows you to change the order that JS libraries are loaded.  So if something is dependent on JQuery, then make sure it appears after JQuery in the list. Note that it is rare, but some JS libraries need to be loaded before JQuery.  Generally this isn’t something that you have to worry about too much.  Put JQuery at the top and everything else follows.  If something is amiss there will likely be a console.log message about it and it won’t be difficult to sort out.

It Looks the Same.

Alright.  So you’ve got a JS library loaded and…. everything looks the same?  This is hopefully the case!  Because you’ve not yet incorporated anything from the JS library into the rest of your project.  This is of course the topic of each of the blog posts to come: the specifics of how to use a given JS library in your project.  Generally speaking, this will involve one or more of the following.

• Some JS libraries just work by being present.  Adding Bootstrap or FontAwesome, for example,  mean that you can style a TWebButton from the IDE.  Adding btn btn-primary to its ClassName property, and Flag to its caption – and a  dramatically different looking button will be the result, without having to change anything else at all.
• A handful of components included in TMS WEB Core depend on a JS library.  For example, if you want to use the Ace Editor component, you’ll need to be sure the relevant JS library has been added.  Then you can use the component as you do all the other IDE components, setting properties and so on, none the wiser that the JS library is even there.
• In order for a JS library to be functional, it may need to be initialized.  This is typically done through code, most often in the WebFormCreate procedure. 
• Visual controls will often need to be linked a
  on your page.  We’ll cover the details separately for each JS library.  As an example, I’m fond of using a TWebHJTML component and assigning it an ElementID property that is then passed to the JS library when it is initialized.
• Many JS libraries offer the ability to customize what they do via some kind of property mechanism. This translates generally into what we’re accustomed to in terms of Delphi IDE component properties.  But as JS doesn’t have a native IDE, this is done in code and typically also done using something akin to JSON. We’ll touch ever so briefly on JSON in a moment.
• Perhaps less familiar, some properties can passed a JS function reference or even in-line JS code.  So familiarity with JavaScript will be hugely beneficial for some JS libraries.