By Michael Ross
Anyone entering the related fields of web design or web development has undoubtedly seen countless websites, all hosted on remote web servers. Consequently, it is tempting for such a technical neophyte to assume that all websites must be built and tested on remote servers, and that doing so on a modest laptop and desktop machine would be impossible. While there is the option of performing all of your development work on remote servers, it is possible to do most if not all of that work locally, on your own computer, and then upload the finished website files to the destination server, along with any database(s) needed by that site.
Each approach offers its own advantages. Why might you want to skip the local step?
1) It avoids having to store and maintain two copies of the site files and database, which double the space used and add the risk that the two versions could get out of sync. If the website allows changes by users or client staff, then as soon as that occurs for the first time on the remote version of the site, then your local version is out of date — typically not the site files themselves, but rather the database, where user changes are stored, unless you are using file-based data storage, such as SQLite. Admittedly, you could always download the remote database and any new files, to bring your local version up to date, but that becomes tedious and somewhat prone to error. There are methods of automating this process, but those introduce even more work and points of potential failure.
2) Remote-only development allows the client to monitor your progress, although that could prove disadvantageous or even disastrous if the client turns out to be a fanatical micromanager, or one who does not trust your professional abilities and begins listening to the critical commentary provided by the proverbial "nephew who is a little genius with computers".
3) Development tools, as well as hosting companies, are making it easier than ever to apply code changes over the Internet, obviating the need for local files.
4) There are some cases where you would not be able to set up the remote environment on your own computer. For instance, the remote database may be larger than what your local RDBMS can accommodate. The remote setup may include software that you cannot install locally, for technical or licensing reasons. There may be incoming data streams that only the remote server has access to, such as video feeds from live web cams (a situation I once encountered).
Think Globally, Act Locally
Yet I would argue that there are more substantial benefits conferred by building a local version of a website first, and continuing with that approach for any future modifications to the site. A variation of this is to use a virtual machine (VM), but that requires a substantially powerful computer and a sizable amount of memory and disk space.
1) In terms of mobility and convenience, you can work on creating the website even without Internet access, such as when traveling and away from any Wi-Fi hotspots.
2) It is faster to create and change files locally, without having to go "over the wire". This is especially true if you are burdened by a spotty or slow Internet connection.
3) If you are editing any files locally, then you can see your changes immediately, without waiting for the new or changed files to finish being uploaded to the remote server.
4) Some operations, such as graphical debugging, may be prohibitively slow or even impossible if attempted on a remote copy of your code.
5) Your local operating system might differ from the remote OS (which is usually Linux, a favorite among hosting companies). Thus your local OS will likely support tools not installed on the remote OS — such as graphics programs, integrated development environments (IDEs), and code preprocessors only available for Windows or Mac OS. Perhaps some favorite development software could run on the remote server, but for whatever reason the hosting company does not allow it.
6) Another advantage to local development is that many web hosting services do not provide shell access in their lower-cost hosting plans, which is never an issue when working on your own computer.
7) Building locally first, in your own sandbox environment, allows you to test changes and new ideas to the website, its styling, and its database, without the risk of breaking the live site. While it is never fun to inadvertently ruin a local website, it is much better for your copy of the site to implode than the client's copy — particularly if the client site is a heavily-trafficked online store or other mission-critical part of the client's business. Similarly, if the target site is one of many within the same hosting account, then a fatal flaw introduced to the site's code might disrupt the operations of the other websites, including getting the domain names or IP addresses blacklisted if the problem is malware. An unfinished website should not be on a live server anyway, because it is much more likely to be missing security patches, CAPTCHAs, spam countermeasures, and other critical security safeguards.
8) Proponents of remote development may argue that professional hosting companies can more easily roll out newer versions of operating systems, scripting languages, and database systems. On the other hand, my experience is that most companies are not that diligent about updating those components, and are often still using versions much older than those in my development environment. Just be sure to keep your software current, especially with security updates. Moreover, this is something that you have complete control over, while you have no control over the pace at which the hosting company updates its software — aside from changing companies, which can quickly become expensive and inconvenient.
9) In a similar vein, you have full control over the configuration settings in your own environment, in contrast to the configurations chosen by any hosting company when you opt for a shared hosting plan, or your client has already chosen one. Admittedly, you will likely have far more control when the remote website is on a dedicated server.
10) By going through the process (ordeal?!) of setting up your own development environment — encompassing a web server, database management system, web scripting languages, etc. — you will learn a lot about these technologies, especially if you install and configure all of the components separately, instead of using a package such as XAMPP. This knowledge gained can benefit you and your clients when you install your sites on remote servers and are called upon to help troubleshoot problems associated with the configurations.
All of these factors — and others you may learn of — should be considered when you decide whether to build websites in their own local environments or to work directly on remote servers.
Copyright © 2013 Michael Ross. All rights reserved.
