Client or server choose your side
Writing server-side code was the way to go in the past for building SharePoint solutions. The server API was the only way to really benefit of the extensibility capabilities that the platform offered.
One of the investments in SharePoint 2013 was the improvement of the client API. Many of the things that in the past could be achieved only using the server-side API, can now be done by interacting with the client-side object model or REST services.
Separating code and UI
Often solutions consist not only of the logic but also of some user interface that allows users to interact with the system. When building solutions it’s a common good practice to separate the code from the UI. Not only it allows for changing the UI and reusing the code but it also simplifies maintaining the code.
One of the things done during the separation of the UI and code is extracting all strings and storing them in resource files (resx). Storing text labels in resource files helps you build a more consistent UI but also makes it easier for you to localize your solution if necessary.
The name query string parameter contains the name of the resource and the culture parameter contains the name of the culture for which the resources should be loaded.
The resource strings defined in the file are defined as properties and wrapped in the namespace defined in that particular resource file. In the case of the SP.Publishing.Resources.en-US.resx file all resource strings are defined as properties within the SP.Publishing.Resources namespace, eg.:
SP.Publishing.Resources.spellcheckerCheckSpelling = "Check Spelling";
The ScriptResx HTTP Handler can be perfectly combined with the Script On Demand (SOD) script loading approach offered by SharePoint. In your code you would then use the following snippet to refer to your resource file:
SP.SOD.registerSod("sp.publishing.resources.resx", "/_layouts/15/ScriptResx.ashx?name=sp.publishing.resources&culture=" + STSHtmlEncode(Strings.STS.L_CurrentUICulture_Name));