You now know how to make HTML5/JavaScript web applications that run purely on the client device. You may want to make them available for others to use and enjoy. This page describes the necessary steps for doing that.
You could consider setting up a machine of your own as a server. After all the most commonly used server software is freely available: Apache HTTP server. However managing your own server and ensuring it is secure against unwanted intrusions requires a lot of know-how and could easily become a full time job, so this path is NOT recommended.
There are many organisations providing hosting services. Some of them offer free hosting for small users such as hobbyists. You only need the most basic package, allowing you just to upload your files. You do not need web design packages that are likely to be offered, because you know how to write your own HTML and JavaScript. Hosts such as Wordpress and Weebly are not suitable because they are for people who do not have those skills. Their packages put a big overhead of extra code on top of what you simply want to do.
I have used 1&1 (now renamed Ionos) for many years. It is not free but the basic package offers excellent facilities. In the UK: ionos.co.uk but in the US: ionos.com
Your hosting company will almost certainly enable you to choose and purchase a domain name. If you try several variants of what you really want you are likely to find an available one that costs very few pounds (or dollars) per year. For my forest program I really wanted something that begins "theforest" but all available ones turned out to be hugely expensive, so I settled for myforest.uk which was almost free for the first year and about £10 annually thereafter.
You will then be able to assign the domain name to your root directory on your host server.
Most simple hosting packages will enable you to use FTP (File Transfer Protocol) to upload your files. I use the free Filezilla Client. After configuring the connection to your host directory this is very easy to use. You simply drag files across from your own disc to copy them to the host, rather like using Windows File Explorer. It is also easy to create sub-directories on the host and navigate them.
Browsers are likely to cache files that they download. This means that when asked for the same file again they will find it in their local cache memory rather than looking online. This has speed advantages for the user but what happens if there is a new version of the file on the web server? The likelihood is that the new version will not be seen unless the user deliberately refreshes the page.
It used to be the case that we could control caching by means of HTML <meta> elements in the head section of the page but that no longer works. Instead it is now necessary to configure the server to tell the browser whether caching of certain files is allowed.
My approach is that HTML pages really ought not to be cached if there is any possibility of them changing, which usually there is. Provided that the user can be sure of seeing any new version of the HTML then other resources (images, script, CSS) can be given new file names in the HTML whenever they change. So the important thing is to tell browsers not to cache HTML files.
Probably your host server will be of the Apache type but your provider is unlikely to let you tamper with its main configuration files. In that case the solution is to put a file called .htaccess (note the starting dot but no extension) in the root directory for your domain, with the following contents.
<FilesMatch "\.(html|css)$">
Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0"
</FilesMatch>
This example causes any file with the extension .html or .css not to be cached. CSS files are generally small so not caching makes little difference but avoids having to keep renaming them for new versions.
Images and script files can be large and are therefore best cached if they are unchanged, for the benefit of the user.
If my script file is called myfile.js then on subsequent edits I would rename it myfileA.js, myfileB.js, and so on. I would of course also change the corresponding <script> element in the HTML file to point to each new version. The HTML is not cached so the user will get the new script.
Increasingly (2019) browsers are refusing to display web sites that still use the plain http:// protocol instead of https:// which sends the files across the internet in encrypted form. It is therefore necessary to set the server to use the more secure form. This involves having a TLS (Transport Layer Security) certificate. (TLS used to be SSL, Secure Sockets Layer.) Your host provider should enable you to purchase such a certificate and renew it annually.
For this to work you also need to ensure that anyone attempting to access your site by using a URL that begins http:// will automatically be switched to the https:// version. This can be achieved with another set of statements in the .htaccess file introduced in the previous section. The following code is recommended by Apache's wiki site and seems to work for me (but there is much contradictory discussion on the internet about the best way to do it).
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
There are some modifications which can usefully be made to your HTML files.
You should specify the language in which your site is written. This is done in the html tag itself, for example:
<html lang="en">
There are <meta> elements which can go in the head section. One that really should always be used determines the character set used in your file, and this should correspond to the setting in your text editor. The best set to use is UTF-8 and the corresponding meta element is
<meta charset="utf-8">
Other meta elements are designed to help your site to be found by search engines. Read about them on this page on Mozilla's reference site.
Downloading script files blocks browsers from doing other things until the downloads are complete (at least, this certainly used to be the case and I have no evidence that it has changed). Therefore it is best to put your <script> elements at the very end of the body section of your HTML. That way the browser can display some of the page, to show the user that something is happening, before the scripts are loaded and run.
A possible next step would be to start making your code interact with code on your host server and thence to communicate with other servers across the internet. So here are some of the things you will need to consider.
Learn the basics of the HTTP (HyperText Transfer Protocol) request and response mechanism. You will most likely want to see how form submission works and how a response comes, in the form of a new HTML page.
You will need a program on your server to field the requests and make the responses. There can be JavaScript on the server - study, for example, node.js - but the most likely language to be already provided on your host server will be PHP. In that case you do have to learn that language.
Then you will probably want to study the AJAX mechanism for getting quick responses from your server in the form of XML or JSON to use within a page instead of whole replacement HTML pages. There are JavaScript libraries which may make using AJAX simpler. The most common of these is jQuery which has many other interesting features but bear in mind that such libraries add to the downloads for your users.