Full Width Map and Full Size Images

So it seems like Trulia doesn’t respond well to user feedback. They shrunk their images and added that house list that simply hides the awesome map feature we all loved in the past, and the awful image swipe effect that makes me dizzy! No worries, I found a Chrome Extension that fixes their site.

Introducing Stylebot

It’s called Stylebot, and it’s made a world of difference for me. After installing it, open it up, go to edit the CSS and paste the following in there.

(minor updates to work with every browser)

.mediaCarouselSwipe {
 height: 100%;
 width: 100%;

.mediaCarouselSlides {
 height: 100%;

.mediaCarouselSlide.left,, .mediaCarouselSlide.right {
 width: 100%;
 height: 100%;
 position: absolute;
 bottom: 0;

.mediaCarouselImage {
 height: 100%;
 width: 100%;

.mediaCarouselSlide {
 transition: transform 0s;

.propertyLocalInfoContainer > div > .tabList {
 display: none;

.mediaCarouselMediaCounter {
 display: none;

.beingModal {
 height: 97%;

.titleBar {
 height: 0px;

.titleBar ul.section .mhm.linkTypeReversed {
 position: fixed;
 top: 0;
 right: 0;

#leftColumn {
 display: none;

.hpRtContain {
 display: none;

#heroContainer {
 width: 100%;

#searchOverlay .banner .box-holder {
 width: 50%;
 margin-left: 25%;



Learn Web Development – The Super Simple Way

So you want to learn web development, but are too intimidated by the complexities of it. It should never be intimidating. It should be pleasant and fun. You should feel like you want and enjoy to write code. After a friend of mine asked me to show him how to code, I thought I would write this post to make him understand how to write code. Just like everything worthwhile, take your time to gradually learn all of basic things before diving in.

Languages used to do learn web development

Languages used to do simple web development

You might have heard of other developers stinking their noses up in the air when you ask them about how to code, and they may throw words at you that will intimidate you. IDE. OOP, Abstract, Signleton, DOM, methods, attributes, and on and on. These words are simply just words to describe some things you will learn in the following paragraphs.

The setup to learn web development

I prefer to code on my Windows machine. At the time of this writing, Window 7. I’ve tried Windows 8. It just didn’t do it for me. It had nice bells and whistles, but there were significant driver issues, plus the start menu took over the whole screen. I personally found it counter productive.

Why not a Mac? Because of Notepad++. I’ve tried other integrated development environments, or IDEs, the program you use to write your code, but Notepad++ was always ahead of the curve. Netbeans, Eclipse, Coda (Mac only), Brackets, and many, many more. I just didn’t understand why developers would use such bulky, slow programs that would take a developer just to configure it? On the other hand, Coda and Brackets just lacks all of the nice features that Notepad++ has.


So, I decided on Notepad++ because of the following reasons (don’t worry if you don’t know what they mean yet:

  1. Fast Application Startup Time (FAST)
  2. FTP
  3. Easy File Explorer
  4. Plugins Manager
  5. Multi line tabs
  6. Multi Window Split Screen

Coding Preferences

I prefer to use PHP for the backend. Why? Simple. It’s open source and TONS of support. Yes, I made it all caps because it’s the most supported open source back-end language.

Same reason for using MySQL (or Maria DB as it’s known now), and jQuery as a front end JavaScript library.

For an explanation of what languages I use:

  1. HTML – Render content
  2. JavaScript / jQuery – Page manipulation after the page renders.
  3. CSS – Make things pretty
  4. PHP – Create dynamic content
  5. MySQL – Manage data

To learn web development and create websites, that’s all you typically need.

Next: Let’s just get down to it

Package Managers and why I hate them: npm or composer

Package Managers Just Suck

They suck big time. Let me tell you how I arrived at that conclusion. First off, theoretically, package managers sound amazing. The idea of running one command sand have everything magically created for you, updated for you, compiled, without too much sweating, is truly a marvel.

package managers suck

Sure, package entire servers when you can simply run a couple of git / svn commands.

In reality, however, this is sadly not the case. Every freakin’ time I try to go back to npm to install something, either for a cordova app, or a Laravel install, or just some custom dependency, I start off following some instruction manual. npm install this, npm install that, and on I go. Until I get to a package that requires something else.

This happens every time. Documentation is very unclear most of the time. Sometimes I have to run npm install with a -g flag, somtimes –save-dev, all sort of options. And Make sure you always have the latest version of npm, unless their site is down, which happens every hour on the hour, or it’s slow, or non responsive, etc.

Communism is the Perfect Form of Government

Just like communism, package managers packatoo shall fail. Not today, not tomorrow, but one day when developers figure out that they can do installs simply by downloading libraries or git/svn-ing them to their development environments.

Just as an example, this one project, I had to install about 30 packages, but that wasn’t enough. There were dependencies like .Net framework, and python, ruby, etc. All for a one page website. Who are these idiots developing websites and making them so complicated? It’s a one page website that could have simply ran off of a simple CMS like WordPress if you really needed a CMS. It was insane.

Ah, Magento Probably Sucks Worse

It was like my old days of when I worked on a one page Magento Sucks project. What a waste. One page just to store addresses of people wishing to win an iPad, with a gigantic, full Magento install in the backend. Ridiculous!

The Dependencies

I honestly thought the whole idea of writing code is to be less dependent on crap and architect something that can easily be modified by others, pick up, learn and hit the ground running. Instead, we find that most developers who enter a new environment these days, have to re-learn a whole new flavor of development. Everything to learning a new server (nginx), backend (node), database (postgress and express), and even front end (sass, less, angular), and there are a bunch more that I haven’t listed, but they’re there. And all for what? There’s no gain in any of it. It’s all how you use the tools at hand. Nginx can be much slower than apache if not configured right, and it’s much more limited in what it can do. Same with Angular and everything else in between.

Why stick with systems that are broken? Use things that were tested over the years and can be more dependable. Things that have a much larger community.

Capistrano is useless: not as good as SVN or Git

Once again, something comes out to “revolutionize” the way things are done. I suppose when Git came out, everyone was going to jump off of the SVN boat. In reality, SVN works just as good as Git. It’s always about how you use the tool. My argument is this: Can you mess up a Capistrano release? Just as much as you can anything else. It’s all about how you do it, not necessarily what tool you use. Not to mention that it’s a Ruby Gem. So if you’re a PHP guy, you’re screwed. Gotta install a bunch more stuff on your server just to make it work. Bollocks!

If it ain’t broke, don’t fix it

So, if a company has been using SVN for years and years, why would they “need” to switch to Git, or Capistrano? I would hope that a company that’s been using SVN for 5 years, would have figured out by now how they’re using SVN. In fact, one of my old work places used SVN brilliantly.

The solution

What they did was this: They had sandboxes for devs, each set up with their own virtual box. Dev environment is complete. They would spin off individual features branches and a sprint branch at the beginning of each sprint. Done. Good so far. At the end of the sprint, they would test on their dev boxes, get business approval, and merge to the sprint branch.

Regression testing

The sprint branch would be pulled down on the qa server, and tested. Two other devs would test the original dev’s story. It took a day, and we didn’t need QA. Once the qa dev (sprint) got approval… no, we would not release to live. In fact, at this point, the lead dev would create a tag. This tag would become the snapshot for the release.

The live server

The tag would be pulled into the live server. Let me explain how the live server was set up. The vhosts had two servers set up. One was a pre-live environment, and one would be a live environment. Both of these had symlinks that pointed to previously created tags. This way you can have the code tested on the live server, using the live database, without affecting the live site code.

Update: Here’s sample bash script ./tag_www

echo "Tag: "
read thetag
echo "Tagging $thetag"
ln -sfn $thetag www
echo "Done!"

And you would just need to run:

# bash tage_www
Tag: tag2

And you’re done

Capistrano is essentially useless

Now that we have symlinks point to different releases, and we know that we can roll back by swapping the symlink to a previous tag, and the only scripts we need are Git’s (SVN’s) commands, why exactly do we need Capistrano as an abstract layer of complication? We don’t. But, because it’s a new tool that sounds cool, your CTO who may not understand how a light switch works, may decide to go with it anyway.

Git vs SVN

So, now, that we realized the Capistrano is a useless piece of software, even though evangelists may swear that it’s better (they’re probably just too lazy to do the actual work required), it really comes down to a personal flavor. Are you used to SVN? Use SVN. Are you used to Git? Use Git. It’s that simple.

What about the scripts?

I, personally, would rather write my own scripts. I know what goes in them, I know I tested them myself, and they don’t require additional software to run. Git and SVN come with their own pre hooks and post hooks. Use the tools at hand. To me, if someone tells me that they want to use Capistrano, it tells me that they don’t know Git or SVN all that well. And to use a new tool with services that they don’t understand is ever scarier.

The shortest road is the one best known

In reality, it comes down to what you know best. But, if you don’t know SVN or Git and are using tools and scripts on a higher level, it’s like saying that you can run a marathon at the age of 50 because you did a 1k when you were 18 years old. it’s like using Zend before you pick up PHP. You’ll have a heck of a time, let me tell you. Learn the basics. If you truly learn the basics of Git, SVN, or any other similar repository, you’ll understand why you’ll never need to use Capistrano.

Don’t be afraid

You might be saying to yourself… “But, I learned Capistrano, why do I need to learn anything else?” Simply because it’s valuable. You’ll be a better developer for doing so. You’ll have a better grasp of deployment and the hows and the whys. Don’t be afraid to master the tools at hand.

What about the database?

There’s a nice UI tool that I personally use. It’s called SLQYog. For about $100 you can get yourself the SQLYog Enterprise or Ultimate which includes some much needed features, such as schema sync, data sync, SSH tunneling, and many more features. Why would you let PHP handle database syncing? I’m talking to you Laravel, and your promise to make database syncing easier with your eloquent. It’s silly to think that PHP can manage your DB. Use smarter tools, don’t be stubborn and don’t fight PHP please.

Do a schema sync before every release. You typically won’t be erasing fields, so you won’t have to worry about that problem. Very rare issue to have. So, changes are that your code will only break when you rename things or remove fields. But, for those times that you do make those exceptions, this tool will be a life saver.

Best practice for when renaming fields, don’t just rename. Add a new field, copy the data, release code, next sprint remove the previous field and done.

More control

In the end, you’ll gain much more control over deployment processes. You’ll understand what’s being pulled / pushed on what server, and you’ll be much more confident running your own scripts. Running a tool that was designed by someone else comes with its own caveats. Just be careful of others’ work. Just like composer, don’t get me started. Basically, if the main install file for composer somehow runs a command to delete your files, there’s no coming back. So much complexity for so little gained.

And remember, always K. I. S. S. (Keep it short and simple).

Want to add image to linkedin app, but don’t have https

Well now, haven’t we all been super excited about creating social logins and such, especially with HybridAuth’s awesomeness.

So, you build out your app, your URLs, callbacks, implement the library, and when you try to set up the app, BAM! Your logo has to have an HTTPS protocol. Rats.

No worries, simplicity to the rescue. All you need is a Dropbox account. No, really, Dropbox. The file sharing account.

* Signup for Dropbox. It’s free, if you don’t already have an account.
* Create a public folder.
* Add your logo to the public folder.
* On your PC, or Mac, or within the app, copy the public link. Right click the image and select “Copy public link”.
* Take the copied link and paste it in your linkedin image field.
* Done!

I hope this helps you guys out as much as it helped me. This comes in handy if you don’t feel like making the trip to ssl land, or are developing locally, but need to use the linkedin app.


Are PHP Frameworks All Hype?

The short answer is, yes.

Let’s explore why that is.

Who in their right mind would try to sell their framework idea by saying, “It’s slower than straight php”, or “it lacks form customization”? I’m pretty sure no one would. This article is based solely on my own personal experience of dealing with web development for over 13 years.

I want to start out by saying that I’ve tried many PHP frameworks. I’ve tried Cake, Magento (a CMS loosely based on Zend philosophy), Symfony2, Zend2, Yii, Codeigniter, Light VC, Laravel, and many other in my own personal time). One thing to note is the amount of frameworks that exist out there just for PHP alone. Why so many? If any one of them were as good as PHP itself, why hasn’t it become the standard? The reason may shock you… or not. PHP frameworks suck! Even Rasmus Leerdorf himself (the creator of PHP) had said it.

Web development and web application development is not the same as any other type of programming. It’s development that creates short lived web pages (applications) and rapid AJAX calls in order to provide the end user with some sort of interaction and/or data management. These little pages, together create the illusion of being “logged in” an application. Applications keep massive amounts of data alive until that application is shut off. Think of the OS that you’re on right now. TONS of things happening in RAM while you’re listening to your favorite music and reading this post. On this particular website, the page has already loaded. Nothing much else is happening. The web app finished rendering a long time ago and is now in a sort of an “off” state. I just want to make sure we understand the differences between web app development and any other type of application development where the data stays alive for the entire duration of the application.

Yes, there are exceptions, such as sockets, but for the most part, most websites render out, and boom, done! The server on the other hand may keep a session alive. If not, your authentication is probably handled by cookies, or RESTful api keys and secrets. Anyway.

Trying to introduce a concept of MVC, previously only used in single language environments (i.e. Java), to a multi language environment (Apache, PHP, MySQL, HTML, CSS, JS, etc) is plain ridiculous. I understand the idea behind separating code, but for a website, it’s ludicrous to think that you can do all of data collection through PHP, or all of the JS calls from PHP, or even CSS rendering from PHP. Websites are a special type of applications that can, and should handle multiple types of languages in order to provide the best experience for end users, visually, and functionally. Imagine if we could only code websites in PHP alone. What a mess that would be.

The simple truth, and this may hurt anyone out there, is that with all of these different frameworks, not one has stood the test of time over a two year period. Everytime PHP gets updated, your frameworks becomes useless. All the bells and whistles just became obsolete. And forget about v2.0 of the framework since nothing is backwards compatible. It’s a complete nightmare.

I always hear the argument about how noobs pick up a framework faster. Faster than what? PHP? Don’t they have to learn PHP first? And if they know PHP, why learn another layer on top? What if you had to hire new developers? You’d have to teach them the framework, and look back at how long it took you to become an expert in the framework, not learn it, but become an expert. Why an expert? Because you made a lot of mistakes while you were learning it, and you can’t afford that with noobs.

Build your PHP code to make sense, and the same goes for code as it does for UI. If it takes more than 3 clicks to get somewhere, it’s probably too complicated. And you know what? No one is going to want to work on that project. Sure, you can hire a framework or CMS specialist and pay them twice as much… but why do all that when you can get two developers for that same price with a simpler system in place? Response / request. That’s it. That’s what the browser understands. Built it that way, and stop calling everything an application as if you were building something in JAVA. Focus on architecture, not frameworks.

The shortest path is one best known. And surprisingly, most php developers know php.

Are flowcharts making a comeback?

If they’re not, they should be.

Once too many times I’ve seen development go awry. It’s insane to think that you can build a full application by code alone. Since the days of “modern” programming practices, such as OOP and frameworks, there has been this misconception of the code documenting itself. What a misnomer!

Proper software development is done in three main stages. 33% of the time should be spent on documentation. 33% on development, and the last 33% on QA. The leftover 1% can be spent on whatever else you’d like. But seriously speaking, this is the way software development has proven to be effective and efficient. But wait, you might say, what about projects that change their requirements from day to day? Think about what was just said. We’re going to build a product that will change from day to day. Might as well build a house out of LEGOs. It will not be a well design product. Imagine if any other industry would do that wing-it approach. Cars that break down once you drive them off the lot because they haven’t been tested properly, even though their internal tests say nothing’s wrong. Imagine having to tweak the car every day or week because new bugs have been discovered. If you want to be serious about the product, know and understand what you’re building. Commit to what you’re building, and build it. Just like building houses. There’s a blueprint for a reason. You draw it, commit to it, then you build based on that commitment. Once you chose to not have a basement, it will be super expensive, and insane to try to add a basement to your house. And all the while the blueprints are being developed, guess what. There’s no house to demo to the owners. There are prototypes and models and artist renderings. Modern day software can make a 3D replica of it on your PC, but the house itself is not actually built. Why is software any different? Why are we not showing software the same level of respect?

When you commit to it, that’s where the fist 33% comes in handy. This is something you’re going to build, not just “wing it”. Yes, I’ve actually heard the phrase to “wing it” in planning meetings, by the director of IT. Flow charts, flow diagrams, user flow design, interactive wireframes, mocks all should be done at this point. The product being built has to be understood. NO CODING! I’ve heard one too many times (but we have to show something). Show the flowcharts, the prototype if you built one, the wireframes, the mocks, everything else. Just don’t code it. There could be the small chance of the project changing direction, and instead of it being something easily built in JAVA, it could be something that could be best built as a web-app.

Another 33% of the time should be spent on actual development. Does this mean that there won’t be questions regarding processes? Absolutely not. There should be questions. There should always be questions, but the amount of misunderstanding is significantly lower. It’s no longer about “should we have a basement or not”, but more like, what paint would fit better with this room because of the light coming in from the Sun. The changes here are minimal, with very little impact. By this point you have to FULLY understand the business logic of the application. In the case of games, you have to understand the user flow, the storyline, etc. If you don’t know what comes into the black box, and you don’t know what you’re supposed to be out of the black box, don’t code! When you do begin coding, you should have all of your flowcharts not only fully complete, but also approved by everyone on your team. But, you say, why would a designer need to look at flowcharts? Well, I say, if there’s a logical process happening, and the “No” response generates a process such as “Display email format error to the end user”, the designer needs to know that he needs to make a mock for that scenario. The copy people (text assets) need to clarify the exact text that goes in that error. The UI person needs to understand if this error will be a generic pop up, an inline element below the input field, or a general error box below the form. So, for something that a “winger” might consider a waste, I just showed you exactly why we need flowcharts discussed by all team members from design, to UI, to product, to copy, and then the developer. And it’s for something as simple as “display error”. Think about the mess of having to re-code your code base because you placed a typical alert box, and then someone comes by and tells you that it should be an inline red text appearing below the input box.

This is why the 33/33/33 rule works extremely well and effective. I have been on too many projects where we spend 150% of the time developing and re-developing, and the rest of your life QAing. No clear scope, no defined requirements, no DOD (definition of done), nothing. It’s ridiculous to think you’re accomplishing anything of good quality this way. For me, personally, I refuse to write code before I understand the product for the same reason a mason refuses to lay down the first brick… carpenter refuses to hammer their first nail… or concrete mixer refuses to pour their first cistern before they get a blueprint. Whatever it is they’re building, it could be a wooden framed house, a military bunker, or a castle. Imagine the waste, or crappy construction if they built their masterpieces like we write code today. Major FAIL!

Let’s treat every project as if it was our own, and treat it with the respect it deserves.

And please, code responsibly.

CodeIgniter, The one semi decent framework… is done

I’ve been playing around with CodeIgniter, and although I’m not a huge fan of 3rd party PHP frameworks, I would have to say that CodeIgniter is probably the easiest out of the box solution. Of course, I still have to build everything that I need for it. It’s not like it comes with an image cropper, or a customized user profile area already built, but for its MVC structure, it’s pretty decent.

I’ve recently started to dabble in its query-ing capabilities. Although I like writing sql queries out by hand, and yes, insert them into my PHP code (model files under my models folders), what it has is a decent enough, and simple way to do get and set some data. Not bad… Until you come up to a query like this:

SELECT id, ( 3959 * acos ( cos ( radians(78.3232) ) * cos( radians( lat ) ) * cos( radians( lng ) - radians(65.3234) ) + sin ( radians(78.3232) ) * sin( radians( lat ) ) ) ) AS distance FROM markers HAVING distance < 30 ORDER BY distance LIMIT 0 , 20;

At which point… why even bother to use an ORM, or DAO? You’re just going to mix up your code anyway… Stop trying to write everything in PHP. MySQL is powerful as is without abstract layers.

Anyway, that’s one point. The other is all of the session and cookie handing.

Why load an entire new class, object, etc like $this->load->library(‘session’); when all you really need is $_SESSION. Done! All for the purpose of writing saving some additional info that you rarely use, or can gather any other way? I suppose it’s a shortcut that needs to be learned, but PHP already does that in its way.

The best feature, which it took a little convincing, was its MVC structure. Although I like to develop modularly (MVC structure should be kept in modules, not in the entire site), I was ok with its structure, considering that I can build folders for all of my “modules” but then I would have the same module folder in three different places.

The routing for it was something that was all right. It didn’t wow me. Basically, we took htaccess rewrite conditions and converted them into an array… Sigh… 6 of a kind, half a dozen. htaccess is faster though if you want to talk performance.

So in finale, it was probably the easiest to pick up and go with, considering its learning curve and its openness to be more like PHP.

Toggle Functionality for Clean PHP

* jQuery
* Font Awesome
* AJAX capabilities
* .hidden = display: none;

So, I decided that just controlling the front end via the back end wasn’t enough. I debated for a long time and was reluctant to add new functionality to the ajax controller… then I realized that I’m using a lot more of this functionality, so, I caved in.

This complements the ajax functionality by adding a toggle feature for either items that toggle out (2 state on/off), or items that toggle other elements on or off; still 2 state.

The first thing I did was to add some classes to the elements that will perform the toggling. I added a wrapper around two elements (the togglers) and proceeded to play around with them.

<span class="trigger-wrapper" data-trigger="toggle">
    <a href="" class="tmbtn trigger hidden" data-action="test_toggle"><i class="fa fa-toggle-on"></i> Active</a>
    <a href="" class="tmbtn trigger" data-action="test_toggle"><i class="fa fa-toggle-off"></i> Inactive</a>

The trigger-wrapper class was added to wrap everything in one molecule.

I added the data-trigger attribute to the wrapper because this is what will determine what toggle type to perform… Is it a straight toggle of two items, show / hide an element, or both?

The trigger classes are what determines what triggers the toggle. These trigger elements will swap out their hidden classes. That’s how they toggle.

Here’s two more HTML examples of the content pieces:

<div class="trigger-wrapper reset" data-trigger="dropdown">
    <a href="" class="tmbtn trigger" data-action="test_toggle"><i class="fa fa-ellipsis-h"></i></a>
    <div class="target hidden init-hidden">

… and…

<div class="trigger-wrapper reset" data-trigger="dropdown-toggle">
    <a href="" class="tmbtn trigger hidden init-hidden" data-action="test_toggle"><i class="fa fa-chevron-up"></i> Show Less </a>
    <a href="" class="tmbtn trigger" data-action="test_toggle"><i class="fa fa-chevron-down"></i> Show More </a>
    <div class="target hidden init-hidden">

Notice how these last two items had the “init-hidden” class added, and the togglable content has “target” on it.

Now, for the JavaScript (jQuery) that drives the whole thing… (Assuming that .hidden already exists in your CSS as display: none).

var _toggle_type = '';
var $parent = $this.parent();
if (typeof($parent.attr('data-trigger')) !== 'undefined') {_toggle_type = $parent.attr('data-trigger');}
// In the ajax call of the JavaScript file (data is what comes back in the success function) ...
data._toggle_type = _toggle_type;
data.$parent = $parent;
// And of course, the switch case for the different toggles...
switch (data._toggle_type) {
    case "toggle":
    case "dropdown":
    case "dropdown-toggle":

So now, we have a lot of the functionality to handle our togglability.

This completes our addition to the Clean PHP code that I’ve been working on here:

OOP PHP Sucks!

Update: Before you bash my head in, let me re-phrase the title… ehem… Today’s misuse of OOP sucks as much as misuse of procedural style.

After considering how the web has evolved, I’ve noticed that is not what you use to code, but how you code it that matters more. Yes, what you use still matters, but how you do it matters more. After trying to work on a project using Zend2, I gave up on it when I noticed the ridiculousness of just rendering a page with some dynamic data on it. Autoloading unnecessary libraries, adding layers of abstraction from propel which really all it does is use unnecessary clock cycles to do the same thing that writing your SQL inside a string, building objects that use something like 5% of its functions, “ingest” template files to create some sort of rendering, adding smarty templatizing on top of it that needs to convert to php tags anyway, and finally, the end result.

For real? We NEED to do all that to just render some dynamic page? Wow! We have come a long way in abstracting the simplest solutions into difficult to understand spaghetti code. I’ll explain what I mean by all this.

Let’s look at what actually happens when a web page gets rendered for end users… after all, that’s typically the medium that end users get to interact with in order to have productive or entertaining lives.

It’s a long trip. Hope you brought a book along for the ride.

– Request gets sent to a server via URL inputted by end user typically via the address bar.
– That url gets to travel to DNS servers that send the request to servers identified by IP addresses.
– The server is hit, the server then access its first landing point (htaccess and folder structures) and makes a smart decision in order to try to build some sort of a response to send back.
– At this point, the server will either send you back a message about how it can’t find a file requested, or continue to try to render something to send back.
– Let’s say some default index.html was found without complicating things too much. And let’s say that this file contains basic html, and hopefully somewhat valid html code that gets served to be sent back as data packets back to the original requester.
– The html code comes back to the browser, gets interpreted by the browser, and the browser does its thing to render out the HTML, style with some css code, and run its internal JS engine to see if it has something to do on the client side.

This is where things can get complicated, but why? We don’t have to complicate things. Let’s keep in mind that the final response is simply a long line of characters. There’s absolutely nothing “object oriented” about it. The browser simply takes what it receives and tries to do its job. It’s that simple.

Yes, some JS gets interpreted as objects by the JS engine within the browser, but that’s not for this discussion. Let’s focus on why PHP shouldn’t be OOP.

Back to the server… Here’s what the browser wants:

< html code >
< script code >
< style code >
< html code >
< html code >
< more html code >
< maybe even more script code >

Done. The browser interprets what it gets… or tries to… and renders stuff on the screen. The browser is your application layer.

I cringe every time I hear web developers saying that they’re building an application… You’re nor building squat. Your job is to create browser readable code. That’s it. Just because you’ve overcomplicated your code so much that only you can understand it half the time does not make you an application developer. Creating a browser… now that’s application development. Until that point, you’re just creating a string of characters.

So, then, webpages started to evolve to create dynamic content… So whenever you land on the root of a site, you’re really hitting a script file… something like index.php. Somewhere on the server, in a configuration file, we’ve created the logic to say that the initial point, the entry point should be index.php… we call this the Directory Index.

This file can simply contain pure HTML code just like your *.html files. But… you can do something magical on them. You can render different content. PHP (as well as VB Script used to do), can make this happen. By using the php tags () respectively, you’ve just told the php engine that there’s some code in between. So… PHP, do your thing. Look between these tags and do some work.

I keep hearing from so many new aged developers about keeping your code separated… something about code separation makes things cleaner. I couldn’t agree more… when you’re talking about keeping your styles and JS separate, that’s a great idea. When you’re talking about adding PHP tags in your pages, why are we so scared? the code is completely separated. There’s HTML and then there’s dynamic code inside that HTML that makes sense to have there. The page becomes a template. You don’t need to have template files nested 10 directories deep. The php file itself becomes the template.

I’ve actually heard this argument before… “But php tags look so ugly… so I use smarty tags”. O_O … Are you an idiot? They look ugly? So that’s why you have to add a layer of abstraction on top of it? Adding smarty is not so smarty, is it?… That layer of abstraction just made your code slower because the PHP engine has to now convert ALL of the curly brackets on the page to “ugly” php tags… You know what? If php tags are ugly, then smarty tags are stupid. If that’s the case, I’d rather be ugly than stupid.

It feels like abstraction has gotten out of hand where we now pull HTML templates inside some private function inside a file nested another 10 directories deep.

This mentality of super abstraction is what I have a big issue with when it comes to development for the web. It’s typically engineers who consider themselves super smart coming from the world of Java or C++ who somehow believe that coding on the web is the same thing as console, or application development. It’s not the same thing.

Let me explain so someone as smart as you can understand. Java development doesn’t have a browser for which you need to write a string. It doesn’t have multiple languages to handle, such as HTML, JS and CSS. It’s one code… assembly. And of course, to make it easy, there have been compilers built that can convert all of your nicely written OOP code in code that the machine understands. It gets compiled, and your code is typically living within the Java engine that you downloaded and installed (not a browser, it’s an engine with which the user never directly interacts). It stays in RAM. HTML code doesn’t stay in RAM. It gets put on a disk (browser cache). The CSS, same thing. The JS, same thing. All those pretty objects that you took all that time to build, are gone! Not in memory. Not on the disk. It’s all gone. Oh, you want to access them? Well, then we have to hit a database on a server somewhere far away from your home in order to re-build whatever you’re seeking. Get it? It’s not the same thing as app development.

If you work with PHP, you’re not building any application. You’re building code that’s to be interpreted by the PHP engine on the server in order to deliver a string of characters back to someone using a browser.

Applications, on the other hand, get installed on consoles, and PCs, and hand held devices. Upon starting the application, a whole bunch of stuff gets loaded in memory, and then the program itself uses those bits from memory. And all that stays in memory while the program is active. Only when you chose to quit the application does the application unload itself from memory. All those “object pointers” for functions and variables get cleared out.

In the end, I suppose some will never understand the difference between application and web page no matter how much you try to explain to them. Or, someone will come along claiming that they’re working on a huge website where OOP is saving their life, or some brainiac engineer claims that they don’t see how they could have built their “web app” without OOP. Obviously they’re not intelligent enough to realize that before “web oop” ALL websites were done without OOP, and they did just fine, because they built them well. It was how they coded them that mattered, not what techniques they used.

This was my rant. Thank you for listening / reading.

Update: After careful consideration, and many of your comments, I’ve come to the conclusion that it’s not OOP that I hate. I think it’s the misuse of it. Writing your models in a way that you have to load all of them for something simple… writing your SQL queries so you have to loop through database requests because you must use ORMs… instead of just writing a query that’s more complex, but increases performance 10 fold… Oh, and what’s wrong with SQL itself? It’s an awesome language to know.

I believe that it’s the way coders have been writing code that’s more of an issue for me than the actual style. PHP is not Ruby. Not everything is an object… especially when it comes to rendering things in HTML.

I’ve been using Code Igniter for my latest two projects and it’s not as painful anymore. I don’t like how it routes things as Apache is much more performant when it comes time to handle routes via Rewrite Module.

I also miss the idea of finding a page in the root (about.php) for an “/about.html” request. However… if you check your routes, it should be no problem to navigate through controllers then views (partials too). Still… looking through three or four different files to find what I’m seeking, is more work than I’d like to do… one file… off the root… about.php. Done. I suppose I can do that if I alter my htaccess file, but then… why am I using CI in the first place?

Anyway… I’ll continue to use a mix of procedural and OOP code as I’ve been doing more of lately. (Using 3rd party libraries has become a bit easier).

Once again, thanks for listening. I hope this can help other “non-believers” to understand that we need to understand our needs before we write any code.

I wonder if facebook or google uses any OOP development on the back end in their websites… er… web apps.