In the author’s opinion, doing both is acceptable. It is a matter of choice, do you prefer to know every single line of code contained within your website, or are you okay knowing that you’ve not written all the code in your website, but that it has been contributed to by hundreds, if not thousands of people, potentially catching any problems before they can cause any issues, something which when writing on your own or in a small team, is more difficult? There are many different advantages and disadvantages to either method.
When you start to look at the different options, what should you look for?
- Compatibility with other systems and the platform you want to use to host your website on
These all make a difference, as when you are building your website, your approach may be radically different if you are building a website which is expected to receive 10 people an hour, compared to a website being built to receive 10,000 people an hour.
If you work within an organisation which builds websites every day of the week, then your approach again is likely to be very different to someone who is just starting out and building maybe their first website.
- Do you expect there to be any marketing done to promote the website once it has been launched?
- How many people do you expect will visit the website each hour/day/week/month/year?
- Will this website receive traffic from another website, because the two are owned by the same brand (or company), or similar?
When looking at your approach towards building a website, you should also consider how quickly you want to get the website finished, and how acceptable errors or fixes will be.
- Are there any standards or tests which you will need to pass before or after the website has been launched (like the ones used to test ecommerce websites for security and safety)?
- If you discover an error, do you expect that you will have some time to fix the problem, or will the problem require fixing immediately? (This might be the case if the website is critical to the success of the project, or has a large number of visitors)
- When you launch the website, will there be any controls over the amount of traffic, to allow for testing and attempting to find any problems with the website, or will it be ‘in the wild’ from the moment it is released?
- Will your website be used across multiple languages and different styles of language, such as languages which use Cyrillic, Latin, and Arabic based characters, with different styles and directions of writing?
Thinking about these things now save you hours in reworking a website at a later stage. Obviously, you cannot think about everything in advance, as there are just some things which you will not be able to predict. But you can try to make smart decisions which allow you to make the website more resilient to these issues.
When choosing whether to use your own framework, or a third-party framework, there is one option, which these days is pretty frowned upon, but is still valid in some very limited sets of circumstances. NO FRAMEWORK.
If you do go down this route however, the website you are building should ideally be static and very small, with no moving parts, so to speak. This means that you do not generally have bits which interact in the website, so no contact forms, no dynamically loaded template files, no language recognition, nothing like this.
Whichever route you decide to go down, make sure you do your research and choose the one which will not just work now, but will work for you and the website, for the foreseeable future. Rebuilding a website because it’s framework isn’t expandable in a way which means you lack a now-critical piece of functionality is a very costly and time consuming business.
So, whatever choice you make, choose carefully, and choose something which is suitable!