WordPress REST performance sucks. There, I said it. Not because I dislike WordPress — in fact I think it is the best open source web application we have seen thus far. It is a great piece of technology. It even has the potential to be a great web application framework — in fact I use it for the Store Locator Plus managed service, MySLP.
However, unless you are in 100% complete control of every component in the system you are going to very likely end up with an underperforming over-burdened web service if you build your tech on typical WordPress components. Even the highly customized MySLP service is 5-10x slower than it would be if it was build on a completely customized application stack outside of WordPress.
WordPress is NOT built around performance. WordPress is built on two core tenants – ALWAYS support legacy users at all costs. Be extensible.
Google dropped a bombshell on most maps users, including many of the people using the Store Locator Plus WordPress plugin — they now require ALL SITES to register for an API key. The bigger part of the announcement was that ALL registered API keys must now be attached to a Google Billing Account. That’s right, Google now wants your credit card information on file and ready-to-bill at a moments notice if you garner any traffic on your displayed maps.
You will see a lot of map plugins and services changing over the coming months because of this. The WordPress plugin version of Store Locator Plus is one of them. Thankfully those clients that opted to use the fully-managed My Store Locator Plus service won’t need to deal with Google — but there will be “in the background” changes made to that service as well.
Businesses have been hiring programmers for decades now. Back in the 70s it was something only Fortune 100 companies did. Today everyone from your local cafe to full-fledged software companies do it. Unfortunately few now how to hire a programmer.
Nearly every-single business outside of the tech sector gets screwed when paying an outside agency to write their apps. If you’ve hired a programmer recently it is very likely you are on that list. If you don’t think you’ve been screwed, you are likely just wallowing in a pool of naivety as your coder-for-hire laughs all the way to the bank.
While updating an inherited web project, I’ve been slowly introducing some well-defined libraries to the mix. My current favorite being Vuetify — designed to add some decent style standards to reactive Vue components. This happens to be what I’ve chosen for the overwhelming task of modernizing the Store Locator Plus plugin UX (you’ll see the first hints on the forthcoming Add Locations interface in the next release) as well as for several other “clean slate” projects.
If you are writing web apps and are not familiar with CSS standard libraries or haven’t heard of the “12-point Grid System” you should start learning it. It will save a lot of time building web and mobile apps that are responsive. Libraries like Vuetify and Foundation for Sites with only the CSS components are well-tested with pre-defined rules that not only you will learn and be able to re-use but you’ll likely find many other web developers are already familiar with this configuration.
Digging into Cypress.IO in a sprint to replace my almost-completely-useless stack of Selenium IDE tests for Store Locator Plus, I’ve run into some issues that seem to go beyond my lack of knowledge with the tool.
Yes, it is a great step in the right direction and it can be man-handled to do what I need. For now. But tools should not be forcing you to do things a specific way. That are supposed to make you more efficient, no re-train you or add extra steps.
Cypress.IO has shortcomings when it comes to doing real-world end-to-end testing of web apps. Order of tests is one of them.