While I am still a fan of JAMStack and modern JavaScript development, including Node.js and TypeScript, I have many years of full-stack experience using classic stacks with server-side rendering using PHP and relational databases. And there are still many customers relying on this stack as well.
The PHP community as a vanguard of JavaScript's transformation.
While some people, either jokingly or out of ignorance, claimed PHP to be dead, the PHP community (specifically PHP-FIG, the PHP Framework Interop Group) pioneered the transition from a pragmatic, but chaotic, scripting language, to a modern, type-safe, programming language with coding standards, static analysis and great tooling. JavaScript followed in the same direction, still more chaotic and unsafe despite updated core syntax, unless you choose to use nothing but TypeScript (which in turn, renders most existing tutorials and code snippets useless). We might never see a JavaScript Framework Interop Group, as that would be too "opinionated" and JS folks just love to argue about best practices and coding styles, but at least most of TypeScript's features should become part of JavaScript's core specification.
Looking back on learning in public
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.
Reasons to commit myself to PHP-based web development
Many customers approach me with this kind of project, 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 this.props boilerplate code on every other line), and client-side JavaScript libraries and frameworks in general for compromising speed and security by moving unnecessary amounts of business logic and rendering to the client side, I started several side projects to find out about best practices for modern web development.
I tried TypeScript, a great improvement for front-end development, but hard to use with popular Node / Express / MongoDB code in the backend at that time. 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.
Disadvantages of No-Code Services
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. This is the main reason why many classic plugins, that rely on classic PHP hooks, stopped working with modern themes and plugin blocks like the new, block-based WooCommerce checkout.
But this is optional. And by providing our customers with custom blocks and features in our block themes, they have to use fewer what-you-see-is-what-you-get editor styling features, so we can still rely on CSS classes instead of inline styles and JavaScript-based styling controlled by parameters hidden inside of HTML comments.
Making web development more secure, sustainable, user-friendly and developer-friendly
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.
Top comments (1)
After fellow developers pointed out that I seem to be quite critical about the current state of WordPress, and I remember being critical about Shopware 6.4, and, in a past project, about React, this post is one blog that reminds me that I actually like my job as a web developer, even when I'm not coding a static, CSS-focused, static website from scratch.
I often wonder how our technology can possibly be so immature and unstable in 2023?!
Still, I will try to be more positive and constructive in the future. Watch out for more upcoming content...