WordPress is easy. No need for any knowledge about web development or coding whatsoever. A web-based Microsoft Word, with all functionalities available within a few clicks. So what’s all the fuss about?
At this point, we’d like to make a disclaimer about the previous paragraph. While not exactly untrue, there’s much, much more to WordPress than a set of one-click implementations. It’s about digging in and working on the guts of a framework which is designed to be ever-so-simple.
Let’s face it. WordPress development is not quite up there with Ruby, .NET or Python. Both in terms of overall prestige (in a broad sense) and more importantly – perception. The platform is still fighting the image of a blogging engine, despite operating as a Content Management System on enterprise level for a fair time by now. Just take a look at some statistics:
- Every day over 500 new sites are created using WordPress.org
- Every second 17 new blog posts appear
And these are from 2019. 75 million pages in the world wide web are WP-based (that’s 39%). Seventy-five million. You’re quite likely to spend your entire browsing session jumping from one WP to another. In fact, you’re currently on one. Yes, we use WordPress.
Even the White House does, as a matter of fact.
It’s all about one keyword, buzzing in all industries, from marketing to coding. Customisation. Having the correct tools, skills and, not less importantly, mindset, you can do anything you want with WordPress.
Below, we’ll give you a brief example of how we at HeroDOT approach WP-based web development. We also hope to somehow inspire you to change your perception of this tool. Or maybe you’re already on the #WPDevIN side. Then we would appreciate a good nod of your head by the end.
Table of Contents
The Perception of WordPress
We’ve already somewhat described this matter, but in this place we’d like to explain it on two axis. First, a hypothetical client’s perception. And then to compare – that of a web agency.
Clients vs. WordPress
Let’s name the hypothetical client Simon. So Simon is looking to put up a website for his company, knowing next to nothing about web development. Naturally, as a result of a brief Google search,he turned his attention to WordPress.
Tempted by the price, the available plugins and the speed of implementation, Simon splashes out. He hires an agency to implement the theme he purchased and voilà – he has a website.
But is it really that simple? If his intention is to have a simple platform for showcasing his work, or a URL he can put on his business card – he’ll be okay. But what if he actually wants to make money via the website?
After another set of research, he’ll find a marketing agency, preferably one excelling in on-page SEO. After a technical audit, he’ll find out that the beautiful page he invested his money in requires a thorough rebuild and optimisation.
From now on, the frustration grows. Having forked out a chunk of his budget on what he thought was a well-functioning website, Simon arrives at an understanding that the actual spending spree has just begun. You can now imagine what he thinks of WordPress…
Web Development Agencies vs. WordPress
Anyone who has experience as a full-time WordPress developer has experienced a full spectrum of approaches to the matter. By that we mean that certain agencies (or freelancers) are somewhat guilty for devaluating the process.
On the well-known triangular diagram with “good”, “cheap” and “fast” at the points, where you can only pick two (as all three together can’t coexist), “good” is the one being neglected. It’s essentially selling a semi-finished product to a not fully aware client. Don’t do that.
This kind of approach is holistically harmful to the community of WordPress developers. Several pieces have been written on underpaying in this field and overall talent shortage. It’s all about a huge flood of people, who seem to have read something similar to the first sentence of this blog post, and based on that are ready to provide WordPress services.
The market is reckless. It tempts clients with flashy words like… well, cheap, turning their attention to unworthy sources. This leads to less and less talented developers to look at WP as a career path, as the pay rates and demand are much higher elsewhere.
Alternatively, some companies treat WP with a fair amount of respect. It’s all about striking the correct balance between business and development. In this case, WordPress is not treated as a shortcut to implement a website fast and cheap, but as a facilitation of the process. All the work is based on creating a custom theme and developing it according to the client’s needs.
How we approach WordPress at HeroDOT
At HeroDOT, we have a full-time WordPress/WooCommerce developer, Krzysiek. The result of his latest work is a full boilerplate code, documenting a custom process. It allows the team to build high-quality web pages, while ensuring fluid development and unification of implementation. And fast forward, it will make the life of future devs much easier.
Fast and good.
What Are The Benefits?
A custom theme. Built from scratch, entirely responding to our needs. We fully optimised the theme, putting focus on performance and ease of use. It also gives us full control over the code’s quality, due to implementation of Husky and lint-staged. Together, they make sure commits of files are linted and formatted correctly – Husky takes care of pre-commit checking, while lint-staged narrows down the linting to just the modified files. Code not matching the configuration requirements will not be passed on to the repository.
A unified architecture. Having built a custom solution ready for implementation for all types of construction projects, WordPress devs can easily jump from task to task, without having to get familiar with the full environment. All documented within a boilerplate, easy to digest.
Staging with automatic deployment. With version control and the GitHub repository connected to the staging server, everything stays in sync, while it’s obvious which version of code is running. You can then easily implement changes, without being afraid of making risky operations on a living website. The staging pages are also a great touch from a business point of view, as both the Project Manager and the client can monitor the progress.
Full control over requests, JS files, CSS and images. They are “called out” exactly when and where they’re needed, improving the page’s performance.
Constant improvement. We’re far from finished! The theme still has plenty of room for improvement, especially in terms of boosting and facilitating the process of implementation. Overall, we look to provide the highest quality of service in proportion to the money spent.
What Are The Drawbacks?
Time. This workflow takes more time than simply hitting the “install” button. It’s still much, much more convenient than designing the theme every time all over again. As said above, there’s no checking all three points of the fast/cheap/good triangle. Fairytales aside.
WordPress + Next.js?
Thanks to WP’s REST API, a developer can integrate applications to interact with the CMS. There’s a wide variety of possibilities, including integrating modern front-end technologies. One of these could be Next.js, a framework based on React.js, with a key feature being server-side rendering (as opposed to React’s CSR – Client Side rendering). Next allows you to build a static website based on your React code.
What does this mean? In simple words, Next.js is a resource used to eliminate the major pain point of coding in React.js. The JavaScript rendering on the client side usually takes a while to show, resulting in both SEO related issues.
As for the former, it’s simply more convenient for the user to enter an already rendered page, instead of seeing a white screen. As for the latter, it’s… exactly the same issue. Although search engine bots are starting to get the grip of running JavaScript web pages, it’s beneficiary to have them enter pre-rendered content. They can then start the indexing straight away, rather than after a few attempts.
Our Internal Blog
A brilliant space for getting familiar with modern front-end turned out to be an internal project. It allowed us to experiment, try out new techniques and push our creative boundaries. As we were sure that we’d like to implement Next.js, it wasn’t all so obvious that the project’s foundation would be WordPress.
A headless CMS with a customisable API like Strapi.io seemed to be an obvious choice. But that would be too easy. We chose the path of digging into WP’s API to uncover its hidden potential.
„I’m a learner type – I enjoy discovering and studying new technologies. Currently, I’m all into React.js, but its issues it has with rendering web pages made me approach Next.js. Luckily, the company planned to launch an internal blog, so we came to an understanding that we could build it using a new technology. WordPress’s REST API, often omitted in standard development, was another fascinating area to explore. And as a result, we publish our company content on a Next.js-based platform”
Krzyszof Malec, WordPress and WooCommerce Developer
Go Static Or Go Dynamic
What’s so good about Next.js web development is the aforementioned pre-rendering feature – by default the technology generates each page in advance. Having the user enter an already generated HTML can prove to be beneficial for performance and technical SEO, but also User Experience.
Next.js allows you to set all pages to static generation. This generally means that they’re written in HTML and impossible to edit without interfering with the code. For a standard user, say, a writer like myself, having to tweak the code in order to publish fresh content, would be a backbreaker.
Here it’s slightly different, as content is managed via a classic WP CMS (the publisher works on an editing system). The WordPress-managed webpage supplies the REST API, while the application fully written in Next.js handles both extracting and displaying the content.
Pre-rendering settings depend on the page’s intent. If you decide that a page will not be regularly edited (like a Terms & Conditions tab), you can set them to be generated as static – Next will fetch the data at build time.
Oppositely, you can set each request to be dynamically rendered. In this case, the user clicks a link directing them to the page, where Next.js generates a static HTML file.
As a developer, you can choose which way each page will pre-render. Although Next itself recommends going for static (for performance-related reasons), you can easily build more of a “hybrid” using both methods.
Conclusion
It’s a bit like playing with LEGO – those Technic sets, which are a fair bit more difficult. What we’re trying to say is that WordPress web development allows you to do essentially anything you can imagine, while working on a dev-friendly, intuitive environment.
Front-end developers are in fact versatile artists, as we once wrote. WordPress can be one hell of a paintbrush, as long as you know what you’re doing.