Website development has come a long way since the days of HTML4, a 16-bit colour pallete, table based layouts et al. We’re in an age where the term “web developer” no longer means a person that exclusively develops websites, a web developer can now also describe somebody creating a full application with a web based interface.
Think about some of the websites you visit daily: How many would you class as a ‘website’ and how many would you class as an ‘app’ (ignoring the fact you access the interface through a web browser)? My most visited pages in Chrome are:
- Gmail
- StackOverflow
- GitHub
- Slack
- ZipBooks
I’d class the majority of those as apps, they provide killer functionality and features that make me re-use them near enough daily.
With this kind of paradigm shift it’s important to change the way we think about web development. Think of your project as an application with source code, compilation, third party package management – all the things that would come to mind with a “real” application. Would you develop a C++ application in Notepad?
Integrated Development Environment (IDE)
Seriously, using Notepad or any other kind of text editor for editing source code doesn’t make you a l33t developer. It makes you a poor one. This is a common misconception among junior developers who have this mindset that using a basic text editor somehow makes them a better developer. The best IDE out there currently in my opinion is the IntelliJ IDEA series by JetBrains (I use PhpStorm, but your particular package may differ depending on the technologies you work with). It’s not freeware but I’ve more then saved the money I paid for it in productivity hours over the last year. If you’re not in a position to pay for your IDE right now then a couple of good free alternatives are Netbeans and Eclipse (You’ll want the PDT version for PHP development).
Package Managers
Use NPM with Browserify (or Bower) for front-end dependencies. I used to recommend Bower for front-end dependencies but with the release of NPM v3 node modules are now installed in a “flat” tree where possible which solves the issue of duplicate dependencies and pretty much removes the need for Bower. If you do use NPM and Browserify, make sure you run npm dedupe to be on the safe side before bundling up your code.
Composer has become the de-facto standard for PHP dependencies and after working with it for a short period of time it’s easy to understand why.
The third party libraries and code your project depends on should all be listed in one authoritative place. It’s no good copy/pasting someone else’s library into your code, what happens if they find a critical bug or release a killer new feature? With a package manager you run one command to update the library to it’s latest and greatest version.
Build Process
Have a build process. Whether it’s Grunt, gulp, npm scripts or whatever; your build process should convert/compile/transpile your source code into a distributable version of your application. I personally use and prefer Grunt. I’ve tried gulp and I like what it’s trying to acheive by using streams and pipes instead of placeholder files, but it just feels so slow and sluggish compared to Grunt tasks which have the same functionality. npm scripts work and remove the need for another dependency but to me Grunt tasks are to npm scripts as SCSS is to CSS.
Source/Version Control Systems
Source code should be under version control. Use Git and revert that last breaking change you made, create feature branches for new features, tag versions of your application, track issues. Anybody you’re collaborating with can clone the repository and you both know for a fact you’re working from the same codebase.
Continuous Integration
Continuous integration is the process of continually integrating (believe it or not) your codebase to a central repository where it can be automatically built and tested to ensure everything is working as it should be. I use TravisCI for my open source projects. It allows me to set up a build matrix to run my tests in a plethora of different environments.
With my WordPress plugin PostLockdown tests are run on the latest version of WordPress plus all other versions the plugin supports, using PHP 7 all the way down to 5.2 (I wish I didn’t have to test 5.2 but unfortunately it’s still supported by WordPress). TravisCI parses the build matrix defined in the .travis.yml file and sets up all the different environments automatically.
CSS Preprocessors
Preprocessors for CSS seem to be something else junior developers shy away from. It’s another misconception that writing their own CSS ‘by hand’ gives them some sort of superiority over those who use Sass or LESS. If you’re not using a preprocessor you’re not being DRY, and you’re certainly not following the rule of three. I started out with LESS, but once Sass started using their SCSS syntax over Sass I made the switch and haven’t looked back since.
Coding Standards
Coding standards are quite a sensitive issue in the world of software development. I’m not going to go into the pros and cons of each particular standard or style, or tell you why the standard I use is the greatest and why you should use it. All I will say is that your team/fellow collaborators should all be working toward the same standard, whichever one that may be. This makes for easier code review, less time spent reading and understanding lines of code.
