You do cite experience with WP going back farther than that of mine… Yet I do not see these issues as that major. What scale of sites are we talking about?
It’s fairly slow
I feel this is bit too much of generalization. Slow can be put in context of specific hardware, tasks and level of traffic. It’s blanket statement otherwise.
It’s often overly complex for the needs of a simple website
Complex for whom? Users? Developer? WP is trivial to install and get running. Create some content and you have that simple site. Where is complexity here?
It has a lot of security issues (especially when using plugins)
Again, bit too much of blanket statement. WP itself is relatively secure and most of security issues that had major impact seems to be from running grossly outdated WP versions.
State of plugins and security is definitely far from perfect, but nothing prevents to be very selective or developing secure and reliable plugins, right?
It’s difficult to optimize page-load times
Again, I am not sure what scale are we talking about. Optimization from low to mid sized sites seems trivial – install good static cache plugin, buff with opcode caching… Throw in alternative web server or reverse proxy if really needed.
I really enjoy creating sites outside of the wordpress constraints, I’m just worried I might be overlooking some major issues with this approach.
I pretty much have only one question for you – are you absolutely sure that you are doing it better, faster and more secure than native WP front-end?
I do not ask this sarcastically, I think it might be plausible that for very narrow task custom-made and locked down front-end might be reasonable. But I also notice that overconfidence about custom solution being “just better” than collective work of many developers/companies is not uncommon in web development.
Update
My initial desire to create a custom front-end came from an observation. The WordPress sites I was building weren’t quite as fast as I wanted them to be (3-5 seconds, sometimes longer). […] They certainly were deployed on oversold shared-hosting, but they got good Yslow scores.
YSlow (and PageSpeed) are excellent tools, but they are inherently limited. They can only analyze and advise on front-end performance and how site is processed by browser. They give no insight in your server performance and blindly chasing high front-end scores can actually be harmful to server load.
You should use such tools, but you should never limit your insight in how site performs to them alone.
On hosting – any dynamic site on shared hosting will choke under high load. Again, while it may seem easy to tweak and get high front-end scores, on the server side shared hosting critically lacks hardware and web stack flexibility, necessary for site with high traffic and/or striving for fast load times.
I think that loading all of its resources is overkill for a lot of smaller projects, destined to be served from shared hosting.
Had you tried static page caching? It effectively removes WP core out of most requests and it’s about as fast as you can get on shared hosting. If you tried and not satisfied with pages, served from static cache, WordPress is not your problem – hosting is.
What I meant is that from my understanding, a WordPress site, beyond any actual security holes, is vulnerable because attackers know that it is a WordPress site. This creates a challenge (to breach a popular platform) and an inherent cheat sheet (WordPress vulnerabilities are well documented).
There are no public and known security vulnerabilities in stable WordPress version. Those that arise are fixed in matter of hours.
Poor server configuration (common occurrence on cheap hosts) or running outdated WP version is what gets you hacked, not the sheer fact of using WP.
What I meant by the difficulty of page-load optimization is that if one achieves interactive functionality via lots of plugins, many scripts are loaded and it becomes more tedious to go back and combine, modify, customize or optimize them. I find it easier to include jQuery plugins outside of WordPress and not have to deal with how they hook into wp_head.
Yes, some plugins have no clue how to properly load scripts. That is really arguments for picking plugins carefully, not against WordPress core.
Concatenating and optimizing scripts is trivial with good caching plugin.
Overall and after your updates I feel that you are too eager to discard WordPress for issues that are inherent to any complex and fully-featured CMS (you need decent hosting to get it snappy) and you hadn’t spend much time looking into caching solutions.
It just might not be a good fit for the type of sites you build and you are better off looking into lighter, simpler and less functional CMS that will perform better under your hosting constraints.