To finish my blog post series about learning in public, I want to share some more observations, learnings and recommendations, partially factful, but mostly representing my own, subjective opinion, which is probably influenced by my own experience and habits.
Even more subjectively, I collected some rants and fun stuff in my post I enjoy life-long learning, but... which might be more fun to read, even if you don't share my opinions:
Personally, I had several reasons not to say goodbye to PHP and, more specifically, WordPress, but instead commit myself to supporting these kind of projects and helping to find ways to make them more secure, sustainable, and developer-friendly.
Many customers approach me with this kind of projects, based on my prior professional experience.
PHP, Symfony, Shopware, and WordPress have evolved a lot, they have a roadmap and supportive communities.
Many alternative tech stacks did not spark joy in my heart!
I enjoy doing front-end web development with a very visual and descriptive focus, writing markup and style sheets, using separation of concerns, progressive enhancement, and trying to combine usability, accessibility, speed, and beauty.
I also enjoy solving logical challenges to some extent, but I don't like how single page frameworks brought too much of the back-end programming mindset to front-end development.
After getting frustrated about ReactJS, with its overly complicated logic, ever evolving APIs and best practices, unintuitive syntax (hooks, JSX, CSS-in-JS including some
I tried TypeScript, a great improvement for front-end development, but hard to use with popular Node / Express / MongoDB code. I also discovered JSDoc as a pragmatic alternative, especially for improving legacy code. I tried Preact as a replacement for React. I tried the infamous Tailwind CSS library. I tried JAMStack, failing to upgrade to eleventy 1.0 without breaking changes. I tried a lot, and I tried to set up scalable projects without using Webpack, which had been a constant annoyance in the past years as well. So far, so good.
I also had a look at low-code and no-code solutions, trying to help customers with their Webflow, Squarespace, Wix, and Jimdo sites, most of which combine a bad user experience, both for end-users and site maintainers, with a bad developer experience (probably both for web developers like me, and core developers trying to maintain those services).
Time to give the traditional systems another chance, then?
I used WordPress, again and again, to see that no two instances are identical, that you should not mix old and new syntax, and that some major problems are still not solved in 2022. On the other hand, we have modular systems with a lot of plugins, customizability, and content management interfaces with a great live preview.
Unless something goes wrong.
The greatest disadvantages of WordPress and no-code services might be
- missing quality assurance
- missing staging workflows
- missing backup, restore and migration workflows
- missing separation of data and presentation
- missing documentation
Now WordPress does have a development roadmap, support communities, and there is even an official coding standard, that I might get to work with PHP Code Sniffer in my current PhpStorm instance on a system with both PHP 8.1 and PHP 7.4 installed. But let's just acknowledge they have been moving forward in the right direction.
WordPress also moved towards client side applications, as some new block based code tends to load content using the WordPress API instead of server-side rendering using PHP. Which is the main reason why many classic plugins, that rely on classic PHP hooks, stopped to work with modern themes and plugin blocks like the new, block-based WooCommerce checkout.
Like PHP has shown a way to transform existing creative chaos into a more orderly modus operandi, the Symfony framework is way ahead of WordPress in my opinion, and I hope that WordPress core developers might find some inspiration there.
We urgently need to improve staging, quality assurance, and backup/restore workflows, as long as people continue to use production systems as the single source of truth to handle stock, orders, and customer data.
It does not matter if our customers have a staging environment, we developers do. We can run a local instance, now easily set up using docker, composer, or npm, and try our best to keep it in sync with real data and content updates from the production system.
When planning, developing, and refactoring existing projects, themes and plugins, we should strive for a greater separation of data and customization, so that we can develop and test themes and plugins before deploying them on our customers's systems.
To sum it up, I believe that there are ways to use WordPress and other popular, user-friendly, web software, in a modern and sensible way. But this is still not the standard way, and it is on us as web developers, to help define a better way to use those systems.