In the process of deploying Static Websites, web app developers are always searching for the newest and most efficient tools to improve their website. Generally speaking, a Static Site Generator (SSG) improvises with hand-coded operations and a full CMS. This setup is perfect for most websites or web application projects, not server-side processed. Due to the trend, developers are switching over the webtask.io program to handle their different server endpoints. Along with a significant trend for web app development, this article elaborates on processes developers undergo for the growth of their static sites and “serverless” web applications.
What are Static Site Generators?
In detail, developers that use State Site Generators initiate the process by generating an HTML-only website. Being HTML-only, the site mostly runs off of raw data and templates. As mentioned, raw data is also classified as “markdown files.” For a better understanding, markdown files (Link: https://guides.github.com/features/mastering-markdown/) are generic text files that use dialects of the markdown language. The plain text formatting contains text symbols for creating formats with texts including bold, italics, indentation, headers, and displays. These files require relatively no programming knowledge and are the most basic type of website to create, as opposed to dynamic websites. Therefore, each webpage on the site has its own HTML file with fixed website content that displays the same for any user on any platform. The result, a build that transfers to your live server.
Static Sites versus Dynamic Sites
What is Surge?
Why Should I Use Surge?
Surge is a highly convenient tool that any front-end web developer should familiarize themselves with. It is incredibly straightforward to use, and you can publish a static site onto the Internet literally within seconds. All web publishing requires is a few commands into the command line. The best part is, there is no investment required. Also, users may add personal domains to their projects, share projects with other users, and create 404 error page’s to direct clients to other webpages. Surge even has some unique benefits that other popular static site deployers lack (see “Comparison of Surge and Github Pages”).
Is Surge a Free Service?
As implied above, Surge does not require any cost to use. However, there is a Surge Professional that comes with more benefits for users who are willing to invest the extra fees. This premium version of the service begins at $30 per month. Specifically, with the additional charge, you can create unlimited professional projects, have a custom SSL, and have a secured website with https. Also, you can share resources, develop redirects within your site, and protect your projects with passwords.
If you are simply planning to publish source files to create a small-scale or personal website, then the free plan should suffice. However, for anyone who regularly depends on Surge for publishing projects, then Surge Premium can also be considered a wise option.
Installing Surge and setting up an account is extremely simple and intuitive. Simply open up a new terminal window and type the following command:
npm install –global Surge
(Note: this step assumes Node and npm are already installed on your system. If not, you can install the latest version of both from the official Node.js website.)
To check if Node.js.website is correctly installed, head over to the command line and enter ‘node -v’ for status.
Upon your first time setting up, Surge will ask you to set up an account. The only requirements are is providing an email address and password, and verifying your email afterward. Upon completing this step, you’ll now be set up with a Surge account and ready to deploy to their service.
Deploying Your Site
To use your static website to Surge, first find the file path of the project directory you want to implement. As an example, I’m going to implement a project located at /Users/air/surge-test.
Once you know the file path of the directory to deploy, run the following command in a terminal window:
Your username (i.e., email address) will then display. Afterward, you’ll just need to provide the file path for the project:
Enter the full file path, then hit enter.
The surge program will automatically provide a domain name using random words. You can also create any custom domain if it is not already taken. Enter your chosen domain name, then hit enter.
(Note: If the custom domain name you input is already taken, you’ll see an error message.
Aborted – you do not have permission to publish to [<custom-domain.surge.sh>]
Once the deployment is complete, you’ll see a success message displayed in your terminal. The domain name and IP address for the project will show you where you can access the live deployment.
Enter the domain name into your web browser, and you should now see your site live:
Adding a Custom Domain Name
By default, Surge will provide a custom subdomain for any website that you deploy to their service. It will look something like your-custom-domain.surge.sh. You can customize and select what the subdomain is (provided it’s not already taken). Chances are, though, that you’ll want to use your own custom domain for any professional project.
To do so, you’ll want to add two new CNAME records in the DNS panel of your domain provider. One will be with a hostname of @, and the other will be with a hostname of www. Both CNAME records will point to the following IP address:
If for some reason, your domain provider doesn’t allow CNAME records, you can set an A record as an alternative. Have the A record point to an IP address of 184.108.40.206.
Using Custom Subdomains
You can also use any custom subdomain to point to Surge, such as sub.my-cool-site.com. To do so, you’ll want to set up a new CNAME record. This should lead to the same na-west1.surge.sh IP address above, but this time the hostname will be *. The * hostname is a wildcard. This means that any subdomain apart of the primary domain will be valid and allowed.
The surge program will recognize these DNS changes immediately. It can take time to propagate elsewhere, however, typically no more than 24 – 48 hours.
Deploying Project using Custom Domains
Once the DNS settings have taken effect, you can now deploy your project. You’ll just need to indicate the domain that you’d like to use. To do so, run the surge command in your terminal. Indicate the file path to your project first, then the custom domain afterward, like so:
surge filepath/of/project a-cool-custom-domain.com
Bind Custom Domains to Projects
You may want to bind your domain to the project, so you don’t have to enter it whenever you deploy. You can do so using the echo command, directing it to a CNAME file, like so:
echo a-cool-custom-domain.com > CNAME
Sharing your Surge project
To give other Surge users publishing permission, you must first post your project. Then, type in the add command into the command line to begin adding collaborators by their email address.
surge –add email@example.com
Guests invited to your project and have accepted your invitation now may publish their source files into the same domain.
Listing Surge Projects
To view all of the projects that you have published using Surge, type this simple Surge command into your command line. This will generate a list of all of your projects.
Adding Custom 404 Error Pages
If you would prefer to replace the default 404 error page with one custom-built, all you have to do is add a 404.html file to your Surge project. When you are ready to deploy the new 404 files, just command surge.
Much like the .gitignore file in the Git ecosystem, Surge offers it’s own ignore file. You can set up a list of files and directories that Surge will ignore at the time of deployment. This is useful for leaving out files that may only be relevant during the development process. Anything that you might want to keep entirely private is good to include here as well.
To set this up, create a new file called .surgeignore in the root of your project folder. Inside this file, you can list any files and directories you’d like to ignore. Some common examples might include node_modules, bower_components, and others. You can also ignore specific file types that aren’t relevant to the production version of a site. Adding * (the wildcard symbol) before the extension (i.e. *.swp, *.psd, etc.) will accomplish this.
Remove Site from Surge
If, for some reason, you’d like to take down your website, you can do this easily with the surge teardown command, followed by your project’s domain.
surge teardown your-domain.com
Before attempting to remove your project, ensure that your version of Surge is updated to the latest version.
Comparison of Surge and Github Pages
Similar to Surge, another popular alternative static hosting service is Github Pages. This free service allows users to host their personal static site projects into a Github repository. Github Pages boasts an extremely well-known reputation among web developers of any caliber as one of the highest-ranked static hosting services. Two types of pages can be built”Project pages or User and Organization pages”which can be created under the domain github.io. Of course, you have the freedom to use a custom domain as well. Github explicitly recommends that any projects that are intended to accomplish commercial purposes should not be published using their hosting service. Therefore, while it may be unable to accommodate large-scale websites, Github Pages is perfect for non-commercial or personal uses.
There are slight variations between the Project pages and User and Organization pages. Project pages can be published from multiple source locations, including the master and “GH-pages” branches. Without a custom domain, the default publishing domain would be https://<username/orgname>.github.io/. On the other hand, User and Organization pages are located in the master branch under your Github repository. They are published with the domain https://<username/orgname>.github.io.
Benefits of Surge
While Github Pages is undoubtedly a powerful tool, Surge offers some benefits that even Github Pages lacks. One of these benefits is client-side routing. Within your Surge project, you can redirect clients to a “backup” HTML file (200.html) if they request a nonexistent path. This is beneficial because rather than displaying an alarming 404 error, Surge will simply serve the fallback file.
Another notable benefit to Surge is that users can deploy any new changes to their site in a matter of seconds. As stated above, by simply typing the surge command into the command line, any changes you have made can be instantly viewed online. Especially helpful during test-experimentation, the simple edits to user websites are easier to manage. Because of the option to immediately refresh the webpage, seeing changes in the web browser are more noticeable. Alternatively, Github Page users will continue to push and commit changes towards their online interfaces and struggle with longer and more tedious processes. In the long run, the right static site prevents confusing time for software developers.
Crystal is a senior at a public high school in Santa Clarita, CA. She has been invested in technology since her sophomore year, when she took her first Web Development course and used Dreamweaver to design her first websites.
Crystal hopes to continue her studies in computing and technology in her post-secondary education.