The client-side Glide API is partly a sub-set of the server-side API, but also provides APIs for dealing with forms and lists. These APIs allow for the control and manipulation of the behavior of elements of the ServiceNow interface, and interaction with the database, user, and session information.
Many client-side APIs don't provide constructor methods, or require instantiation. For example, rather than declaring a new instance of the GlideUser class, we simply have access to the g_user object.
One of the most important things to understand about client-side code, is that it can have serious impact on the user-experience, in terms of performance. Querying a record from the database, for example, requires constructing a query, sending it across to the server, waiting for the response, and then waiting for all of the data associated with the response to that query (and all of the records contained therein) to be sent back to the client from the server.
While all of this happens, the user's browser session is effectively locked up, which can make for a very negative user experience. Luckily though, nearly any time you need to do something that would result in potentially locking up or slowing down the user's browser session, client-side APIs provide the option to specify a callback function.
A callback function is a function that's passed into another function as an argument, and then executed at some point within the body of the function to which it was passed; often with some specific argument, that is the result of execution.
If you want to test out any of the APIs you see here, you can navigate to a page on which the API should be present (for example, navigate to a record form to test out the g_form API), and then press Ctrl + Shift + J. You should notice that in addition to your browser's console window/pane opening up, a client-side javascript executor shows up. Any code that you write or paste in this window can be executed in the same context that any client script, UI script, or UI policy script.
