What Went Wrong with Web Design?

And what can we do to stop it? Standby.

First off, I’d like to start with the fact of what a website is. A website is nothing but some HTML passed in from some server. That’s it. The code that comes back from the server is static. Believe it or not, what ends up on your browser, is static HTML. The browser interprets the text that comes back from the server, and spits it out on the screen after it interprets it.

CSS and JS

If you see bells and whistles, without the page reloading, re-requesting more from the server, hover overs, text changing on the front end, that’s all controlled by some DOM manipulation. JavaScript and CSS are good at doing that. :hover and getElementById('id').innerHtml('newtext') are the secret. The good thing is that this code is available right away to use, and you can usually pipe it in additional .css and .js files loaded in the header, and/or footer.

Add Some AJAX

A great thing that JavaScript does is that is has the ability to send a request to a server, without having the browser reload the entire page, its header, rebuild its DOM, etc. That way you can really make your pages dynamic with fresh content and make it so much faster.

Here’s where it went right

The advancement of CSS2 and CSS3 has been a great release of burden on the JS engine for many of the bells and whistles. Transitions can control animation, canvas and video embedding has become a great solution for making things look pretty. jQuery, along with other JS libraries, have come along and have made the JS work easier for developers. No longer does an ajax call take 12 lines of code. I can be done in as simple as 3-4 lines. jQuery did not come along to complicate things. Let’s get this part straight.

There was MooTools, Prototype, YUI, Dojo, and many other. Why did jQuery survive? Intuitiveness to developers. It was easy to use. It was not confusing. It had decent documentation, even though it was mostly used for quick reference until you got the hang of things. But it wasn’t rocket science. With “frameworks” coming out for JavaScript these days, it just sounds like a lot of complexity for programmers who already know what they’re doing to tailor to those who have no clue how to program the proper way, and need a complex and restricting hand to hold them so they don’t color out of bounds. Yes, I’m talking about angular.js. What a bloated monster. I wonder how websites were build using just jQuery up to recently… Hm…

Here’s where it went all wrong

So, some graduating engineer students decided that a webpage was not a webpage after all, and that they needed to mess with code in order to make themselves feel better and feel more at home writing complex and overly engineered code. Then, they got lazy too. Let’s throw an out of the box framework. The boss will be impressed how quickly we can get a prototype going. And with that, the backend became constrained. No longer could you do whatever you wanted with a webpage. Now it had to follow certain paths and load every single file, even though you didn’t need to load it. This slowed down websites everywhere, because, well, autoloading does that. So what to do? Throw caching at it. So instead of realizing the problem that you’re using a framework that does not need to be used, you’re going to take what was once an exception, and make it a necessity. Besides, doesn’t caching make static files and data? How is the website dynamic anymore? Well, we’ll just delete the cache when a change is detected. So, more complexity in order to deal with the original issue of leaving the freaking webpage be a webpage.

Now you have two additional layers of maintenance to handle. Framework (which needs to be learned and experienced), and caching, which I personally know to have caused a significant number of errors throughout my development years.

But that wasn’t enough… What if we plan to change our database in the future? How are we ever going to be able to do that? Go through all of the lines of code with MySQL in them? No… why do all that work when we can throw another layer of abstraction on top? ORM Database Management. As if your website wasn’t slow as it was, let’s throw this bloated level of complexity on top of everything else that will make sure to have you spend thousands of hours re-learning how to write MySQL queries, or whatever it is that it uses. Let’s take Propel for example. Every single part of a SQL query has now become a PHP function. Talk about a waste of CPU Cycles. How often is it that you change databases? If you change your database once a year, there’s something very wrong with the architecture of your site.

Lack of documentation

Tell me you haven’t heard this a million times: “The code should comment itself”. What kind of absurd, lazy, half assed remark is that? I remember in the good ol’ days of designing a system. You should spend 1/3 of your time designing the system. 1/3 of the time implementing it, and 1/3 testing it. It seems like these days, we’d rather spend NO time on the system design, 150% of the time development, and the rest of your life QA and maintenance. There’s something very wrong with that concept. My grandfather had told me something that holds true even today. “Haste makes waste”. If you rush to get your project in front of your boss and impress him or her, you’re going to have to do a half assed job. And of course, they’re going to love it so much that instead of starting fresh to do it right, you’re just going to build on top of the prototype. And then we wonder how things got so bad. All in the name of pleasing someone else, at the risk of creating something that will break.

Take your time, and do it right.

A Custom Framework

The framework should be something that your code naturally evolves into, not something out of the box with instructions on how to do everything. How did the original creator of the framework know exactly what I was looking for? They didn’t. They made the framework to be a quick out of the box solution for themselves, and thought, hey, others might like this. And BAM, one after another, junior developers and lazy developers alike downloaded it, installed it, and now we have something that we can’t customize without breaking the barriers of the framework itself. You don’t believe me? Try setting a cookie and a session variable in Symfony2 at the start of a page. Oh, you can’t? Hm… That sucks. Well, time to whip out the good ol PHP code on its own.

How to do it right

Build an index.php file. Done. Build a header file and a footer file. Done. Build a css and js global file. Load them in your header / footer. Done. I would prefer to load JS in the header because it makes for better DOM handling within your rendering code. A rendered page would be aware of the $ jQuery object if you load your jQuery in the head.

Now that you have a one page site, make another site, and load the header and footer in that one too. Done, you have two pages. Now you can make even more pages.

Next, let’s make those URLs friendly. Modify your .htaccess file a bit and make all .html calls point to respective .php files. SEO and friendly looking, done.

So you have a very simple custom framework that doesn’t require loading hundreds of modules, models, views, helpers and God knows what other crap.

Need a global function file? Make it! Store it in a /extra folder, call it reasonably well, functions.php and start writing some functions in it. Load this file on every page before your header file. Call it a pre-header. this is before any markup is rendered. Use common sense. Store functions in here that are globally necessary. Things like database connections, input validation for emails, random password generators, number formatting (to add a 0 before a number if it’s less than 10), etc. You will need these globally, and when you need them, you don’t have to hunt for them. They are in ONE file. This file should never grow over 1000 lines of code.

If it’s too complex, it’s probably wrong

My last argument is this. NO SITE should be considered too complex to navigate, or construct. If it is, it’s probably too complex and needs to be re-thought and re-done. If your code is spaghetti, please, please, please, re-write it so anyone coming on board can easily understand what’s happening and they could trace the code easily just by starting at the index file and the htaccess file.

Growing your site to application level

Need a profile management page for your users? And admin section? A module that’s a one page app? Notice. I’ve mentioned three different things here. An admin section is not a module and it’s not a profile page to be managed. A profile page could easily be a one page form that the end user can submit. A one page app module can be a series of php, js, css files in one folder, routed through your .htaccess file. An admin section could simply be a collection of files and modules that serve the purpose to look through data on the site. Unfortunately, lately, all frameworks treat those three sections as sections of the same type. They’re all modules. That’s such prejudice. How can you say you care about your site and treat all its components the same? Not fair.


I just have to say that sometimes it’s good to go back to the basics and realize that even a house needs blueprints for a reason. Taken straight from the Wikipedia:

“Occam’s razor (also written as Ockham’s razor and in Latin lex parsimoniae) is a principle of parsimony, economy, or succinctness used in problem-solving devised by William of Ockham (c. 1287–1347). It states that among competing hypotheses, the one with the fewest assumptions should be selected. Other, more complicated solutions may ultimately prove correct, but—in the absence of certainty—the fewer assumptions that are made, the better.”

After all, aren’t we all essentially problem solvers?

In the end, the only thing that will matter will be the HTTP requests done by a page, and how fast your content loads in a browser. I think this is the goal that google has in mind. That’s why they try to make people develop pages that run smoother without the complicated bloated code.

On the backend, the simpler the better. Understand that it shouldn’t be rocket science. Programming should be as simple as loops and conditionals. That’s it. If it gets more complex than that, it’s wrong. If it needs to repeat, loop it. If there’s business logic, condition it (pun intended). The rest is as simple as getting data from a database (data files), and rendering them as HTML for the browser.

Respect the browser!

  • Hans

    It’s awkward how you say “frameworks” are too constrained and don’t fit everyone’s needs, but then go on to put out your own approach (essentially an opinionated framework) in a way that seems to say “this is the only right way!”.

    • George

      Well, what I show is what’s right for me, at the time of this writing, which goes to show that everyone does things a bit differently. But the lesson should hold. Build your own to meet the needs. I simply showed what works for me. What I do show is one example how to keep web dev simple. I’m not enforcing a certain type of coding standard. But, I also ask that you think about what you’re building before you build it.

      • lossendae

        Well, since you often like to remember us, you have YEARS of php development experience, so I sure hope that you can get your way around your own code.

        But it stops there, it’s your own code, with your own preferences. When working as a team of 5+ developpers, it’s nice to have conventions, preferably heavily documented (and not commented) like Symfony, Laravel or Aureus so that “any” dev can find his way without having to reinvent everything again because you see, John is an exeprienced developper and thinks that “George code sucks” and therefore, rewrite everything until the next developper come around and think that “John code sucks” and so on.

        One funny fact of your blog, you surely don’t like any of the new code flavour, either frontend or backend.

        BTW, do you code following PSR recommendations ?

        • George

          I’ve had my headaches with Laravel. Unfortunately, your “conventions” are not a standard, otherwise, Laravel would be the only thing people used. Or CI would be the only thing used.

          Having to depend on so many thing when working with Laravel has turned me off from it countless times. Same goes with every other framework. PHP is a great framework itself. Why the unnecessary abstraction of another framework on top of it?

          I try to write my code so that any PHP dev, even the noob that just got out of college can understand it and trace it within 3 functions. For me, personally, if I have to go back and forth among spaghetti code of functions just so I can implement one link on a page somewhere, I’m doing something wrong. It should be simple. Find the file, if not there, look at htaccess for the routes, and once found, search for your HTML where it should go, and add your link. 2 steps.

          I remember one time I worked on a cake 1.0 project where it took me half day to implement a button. How is this “work smarter”? I just don’t understand why we have to make simple things so complex.

          Everyone wants to talk about MVC like it’s a JAVA application they’re building when in reality, they’re creating HTML, or dynamic HTML that’s rendered in a file, or a file that it includes.

          The turnaround time on my “framework” http://spaf.io for any feature, or redesign is very quick. I was able to rebuild entire SPAs in a day. The code was right there, modularly built, and easy to find what I needed.

          There seems to be an illusion that the more complex a framework is, the better your product. Why does zend have so many security updates since it’s conception? Why is there a zend 2.0? No one wants to tackle these simple questions. Why is there a Laravel 3.1, 4.0, 5.0? What was wrong with 1.0? Why wasn’t it perfect? Apparently, because it sucked.

          Just sayin’

    • JohnnyWalker2K1

      The point is that Frameworks are never going to be as good as solving your problem as a bespoke solution you write yourself. Each problem is best solved with its own solution – obviously. Taking someone else’s framework and trying to shoe-horn your problem into it will never be as good.

    • George

      Plus a third party framework will never guess what I’m trying to build. Code should evolve into framework, not the other way around.

  • Guest

    I strongly disagree with the OP. R

  • JohnnyWalker2K1

    Well said! Being locked into a framework can have its benefits, but really, if you know how to code properly (and by “properly”, I mean writing easy to follow code that’s well structured and thought out), any developer worth their salt should be able to read, understand and modify what you’ve written. Frameworks are great for ensuring standards are kept, turning mediocre developers into productive ones, but if you’re a semi-decent developer already, you should be writing to a high standard anyway.

  • Mark Brooks

    I suggest that where things went wrong is that people tried to turn the view into a complete application. At the end of the day, business logic is able to be more cleanly implemented, better debugged, and more cheaply maintained if you leave the business logic of an application on the server side. Makes security, including data security (isn’t just about logins folks!) much easier too. Then you can focus on using HTML, CSS and Javascript for your visual components and to update the DOM in response to business logic coming from the server-side. AngularJS is really just another Javascript tag-based pre-processing scheme, and it has the same screenshop orientation, but those never achieve their goals of the long term in terms of saving time and effort. And Angular isn’t the only offender.

  • George

    I actually made a non OOP “framework” if you want to call it that. It goes back to the basics. It’s called SPAF for Single Page Application (non)Framework. http://spaf.io/ if you care to see it. No OOP, and it goes back to the basics of PHP and how it handles HTTP requests. Simplicity.

  • WithheldName

    The author is right. IT people are always looking for something shiny, new, fun-to-learn. And that’s why frameworks continue to hover around languages like flies around a rib roast. Fools go for the quick gain of using these frameworks…and pay the price later. IT managers get sold by advertising. Everybody is looking for an angle, an advantage to deliver more quickly. Developers clamor to get on the bandwagon because they don’t want to be left behind. These stupid technologies keep reappearing in different forms, generation after generation. For every good one like JQuery, there are 99 others that are a waste of time.