OOP PHP Sucks!

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.

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.

Conclusion

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!

All PHP Frameworks Suck… Except for Mine

The thing about frameworks is that they’re built by developers to meet an out of the box solution. Sometimes, that’s a complicated piece of spaghetti code that can be used for anything, such as Zend 2, and sometimes, it can be a simple scaffolding set up in a very opened Core PHP way such as Yii, but still has the tread marks of included files and unnecessary nested functions, with an abstracted database layer.

The problem I’m having with any out of the box framework is this… Well, there are several problems.

1. Layer of abstraction for database.

I’ve heard this so many times before. What if the database changes? it’s easier to change that layer of abstraction than to go through your whole site and change the sql statements.

The problem I have with this is again, lazy developers will always make things worse for the rest of us. What you don’t realize is that by being lazy, you’re destroying your performance. Let me explain.

Typical mysqli statement:

1
2
3
4
5
6
7
8
$sql_i = "SELECT name FROM table WHERE id = ?";
$dbi = mysqli_connect(...
$stmt = $dbi->prepare($sql_i);
$stmt->bind_param("i",$id);
$stmt->execute();
$stmt->bind_result($name);

echo $name;

Ok, still a few functions to run through. Not bad though when you compare with how Yii, or Zend 2 propel queries for the same data. let me explain.

1
$query->select('table')->where('id',$id);

Yes, it looks smaller, but you’ve just added at least another object, and two more function calls. This is in addition to the back end mysql calls that happen to actually get that data. As far as micro optimization goes, this sucks. You’re not just adding two more function calls and an object; you’re adding an object and two function calls for EVERY QUERY that you run against the database.

In one of my previous work places, the lead developer was so obsessed with micro optimization that he would create arrays that would be build with brackets instead of array_push(). Obviously, the function call is more expensive when it comes to micro optimization. So, it’s ok to not be optimized when it comes to database calls only?

Then, they were wondering why their website loads at over 4 seconds. They had over 100 http request calls. No website should have over 25 calls, I don’t care how complicated your business logic. In the end, that’s what matters. Site speed is mostly determined by the amount of http requests. The problem was that with the framework they were using, it would have been nearly impossible to refactor the site to allow for concatenation of css and js files without writing it in Core PHP. What’s the point of this framework? Which brings me to my second point.

2. No flexibility for custom code

No matter how robust a framework is, it will always have constraints. There are limits to the things you can do with it. Symfony 2 for example, only allows for either sessions or cookies to be set in one call. Sessions are overwritten by cookies. So, in the end, we ended up writing Core PHP to handle both being set. Explain to me exactly what the win was there. If we’re going to avoid the framework and not use the framework’s internal functions, what’s the point of using the framework? Only to have it as a “cool” layer of abstraction? Because you think you’re cool that you know the framework?

Updates

Whenever PHP had an update, it was still PHP. New functions that would allow for more things to be done, and deprecated functions slowly making their way out. Slowly. You could still run your old code on the new PHP platform. You didn’t have to change anything, unless you wanted to optimize some of your code.

Have you ever tried upgrading from Zend to Zend 2? Symfony to Symfony 2? A freakin’ nightmare. And what’s ever worse is that with any new update to PHP, you couldn’t take advantage of this new version inside your framework. So, now you’re stuck using an older version of PHP, and a never changing framework, until the new version comes out, not having the guarantee that the new version of your framework will work with your old code.

When PHP updates, it has been usually tested by many more developers than if Yii updates. There’s a larger support group that will help you understand this new functionality. When a framework updates, the only ones that fully understand the framework are the developers of that framework. You have to pick up from the beginning and re-learn it. Sometimes this can take months. And once it’s perfected, a new version comes out. How is this progressive towards development?

PHP on its own is a framework. A much more robust, and opened framework. It will allow you to do whatever you want.

In conclusion, my theory holds true about frameworks. The best framework is the one you build from the ground up. I keep saying the same thing over and over:

“It’s not the tools you use, it’s how you use them”.

Thoughts?

Update: 8/1/2014

Happy Friday! Just to make sure we’re on the same page, I found an awesome article that pretty much states what I stated. Do not use an out of the box framework for project that require long term maintenance. Build your own with as little abstraction as possible, and only make functions out of code that absolutely repeats itself. No parameters. Read for yourself and decide. Yes, it’s a bit long of a read, but definitely worth it!

https://www.simple-talk.com/content/article.aspx?article=1274

PHP Frameworks Suck

Updated on by

It’s kind of funny. After trying to understand Zend 2, I decided that I was happier with Core PHP. I noticed that anyone can pick up any framework and learn it in a few days, or even a few weeks, but to master it, you really need to spend a lot of time with it. I’ve spent 11+ years with PHP at the time of this writing. I know PHP.

Why have any framework? For most do it yourself type projects, just build a website from the ground up. You already have 4 great layers (Apache or server, MySQL or Database, PHP or backend language, and HTML, CSS, JS all in one). This looks like a LAMP stack to me. Why do I like keeping it this simple? Well, you don’t “need” anything else. Really. This is all you need to build anything. And I do mean, ANYTHING! You name your project, and i can build it.

My only caveat is jQuery. I’ve gotten used to it over the years, and in a way I wish I could go back to plain JS. I mean, for the most part, I still use JS, I just use jQuery for selectors / DOM manipulation, events, and the ever so simple to use ajax function. The main reason I use jQuery is because, otherwise, I would just write my own functions to do all these things. jQuery just makes sense to use.

My next task is to convert all my jQuery into JS at some point. Why? Because that’s what the browsers understand. The browsers don’t understand jQuery, or angular, or LESS or SASS on their own. They need pre-processors and libraries to convert all that.

This brings me to my other point. The backend should be no different. PHP is what is already installed on the server. Running PHP code in your files speaks directly to the PHP installation on Apache. You don’t need additional overhead to make things work better. Write PHP, done. You can structure your PHP in logical functions to make it work for you, such as getMeSomeData(), or renderThisHtmlBlock(). But that’s it. At its core, PHP is a great and most opened and powerful framework of all. Why add so many layers of abstraction on top of it?

My next good practice is to write MySQL directly into my php code. Why not? That’s the fastest processing you’re ever going to get without involving overhead. Use propell? Why? Just so you can stack php functions that eventually build out what you meant to say with MySQL anyway? Again, more layers of abstraction? What’s the point? Because it doesn’t “LOOK” like SQL? Is that really a valid excuse? Learn some damn MySQL like a good programmer, and remove all those PHP overhead functions to keep your site optimal.

It’s not what you use, it’s how you use it. Developers have become so lazy over the years, and no one cares about code itself. They treat it like they’re bored of it and just need to add layers of complexity.

The only thing that matters is how the client side performs. All of my projects’ pages load faster than 2 seconds, out of which most load under 1 second. In the end, that’s what matters. And, the turnaround time for most of my development is minutes, not days like most projects dependent on builds.

And I simply don’t want to discuss things like memcached, composer, ruby (for SASS), or any other dependency that’s simply not necessary. Are your websites fast? Then, that’s what matters. I worked at this one company where they would be concerned with micro optimizations such as to use array brackets instead of array_push function. At the same time, they were using propel that would run through dozens of php functions to get data, and their pages were loading in over 4 seconds, with unoptimized images, and over a hundred http requests. I just don’t understand this sort of mentality. These things should matter no matter if you are running an SEO site, or a private LAN intranet. Users will complain when your site loads in over 2 seconds. That’s a rule.

I’ve built many systems over and over and over only to come to the same conclusion. Simplicity just works better. Ask Steve Jobs.

Zend 2 For Beginners Step 2

All right, guys. In response to the Zend 2 For Beginners post, I thought I’d carry on and show more on how not to be afraid of Zend 2.

If you find yourself frustrated with frameworks as I was a couple of years ago, don’t lose hope. A lot of the frameworks out there have evolved to the point where they’re very manageable. If you’re like me though, and want to do pure PHP on your own projects, no one is forcing you to do Zend. And no, using Zend doesn’t guarantee that everyone who will use it will be a better coder, or that your code will be cleaner, or faster. In fact, it takes 10 times more of the processing power to render out a zend call than a pure php call.

But, if you’re involved in working with others on Zend, I’m writing this to show you that anyone with a bit of programming knowledge can pick up Zend 2 and go with it. Simple.

Let’s start!

Here’s the structure you will need for the basic module. The bare essentials to just render out some text.

1
2
3
4
5
6
7
8
9
10
11
12
13
modules
|-- Articles
    |-- config
    |   |-- module.congif.php
    |-- src
    |   |-- Articles
    |       |-- Controller
    |           |-- IndexController.php
    |-- view
    |   |-- articles
    |       |-- index
    |           |-- index.phtml
    |-- Module.php

Don’t be scared. this is only 4 files if you look at it carefully. Yes, it’s a lot of folders, but it’s not a lot of code. Yes, clean PHP could do it in one file, but there is a lot more to worry about as far as keeping track of all of the including, etc.

So, now, let’s look at the first file: The Module.php off of the module root folder:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// /module/Articles/Module.php
// This line defines our namespace. The place where our module resides. Keep this the same name as our module.
namespace Articles;

// Name our class, obviously.
class Module
{
    // this is to load our configurations for routes, etc.
    public function getConfig()
    {
        return include __DIR__ . '/config/module.config.php';
    }
   
    // this it to load our source files (namely, our controllers).
    public function getAutoloaderConfig()
    {
        return array(
            'Zend\Loader\StandardAutoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
                ),
            ),
        );
    }
   
}

And that’s it. Basically, this file tells us to load our module configuration and autoload any controller files we may have.

The next step is to look at our config file.:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// /module/Articles/config/module.config.php
return array(
    'router' => array(
        'routes' => array(
            // this is going to be what we call our route. It's a good idea to keep it the same name as our "link"
            'articles' => array(
                // Yes, this time, were passing in an exact match for the route. No parameters, no trailing slashes, done.
                'type' => 'Literal',
                'options' => array(
                    // Finally, this is what the URL should say to access this route.
                    'route' => '/articles',
                    'defaults' => array(
                        // And of course, we define our default controller and action.
                        'controller' => 'Articles\Controller\Index',
                        'action' => 'index'
                    )
                )
            )
        )
    ),
    // Specify our controller shortcuts (from the controller above)
    'controllers' => array(
        'invokables' => array(
            'Articles\Controller\Index' => 'Articles\Controller\IndexController'
        )
    ),
    // and, finally, where to look for our main file when the /articles link is hit.
    'view_manager' => array(
        'template_map' => array(
            'articles/index/index' => __DIR__ . '/../view/articles/index/index.phtml'
        )
    )
   
);

Simply put, this code above will direct any calls that come in to the right logic in the code and the right template file to use when rendering.

Next, our Controller file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// /module/Articles/src/Articles/Controller/IndexController.php
// Our namespace to define module and usage
namespace Articles\Controller;

// load this for basic controller functionality
use Zend\Mvc\Controller\AbstractActionController;

// define our class for this Controller
class IndexController extends AbstractActionController
{
    // And... define our main action.
    public function indexAction()
    {
       
    }
}

And that’s it with this one. Basically, the route points to this controller to do any sort of logic, or business logic, and calculations before sending stuff to the template for rendering.

And last, but not least, our view file!!! Yay!

1
2
<!-- /module/Articles/view/articles/index/index.phtml -->
This is my Articles Index file.

That’s it. There really isn’t much to it. This view file will produce a comment of the location and some text that mentions that this is my article index file.

If you could resist through this tutorial and the previous one, you can pretty much build your own Zend 2 modules. Yes, there’s a lot more to learn about Zend, which I’ll slowly be covering in other posts, but for now, to get you started to understand how everything is pulled into Zend to render out some simple pages, this is all you need.

I’m also going to teach you how to load scripts and css files into the header. That’s going to be fun. And later than that, I will be covering AJAX calls and partials.

Don’t forget to remove the /articles route from your Application module. ;)

See you next time!

Zend 2 For Beginners

If you’ve kinda touched Zend in the past and have been scared off like me of the complexity and everything you had to learn about it, I would like to share my Zend 2 experience with you. I’m assuming you have Zend 2 already set up on your local (Zend Server or apache and a project already set up), based on their documentation here:

1
http://framework.zend.com/manual/2.0/en/user-guide/skeleton-application.html

Let’s begin, shall we?

First thing you will notice is the folder structure of the main Application module. It’s the only module in the whole site. Let’s start with that.

Whenever you hit your site url local.mysite.com, you get to see the Zend default index page which resides in the /module/Application/view/application/index/index.phtml folder/file. If you modify this page’s HTML code, you will notice changes whenever you refresh your page. Ok, so this is good. This means that this module works, Zend works, the whole Universe makes sense, for now.

Also notice another piece of information in the /module/Application/config/module.config.php file. This is your routing mechanism. This is an array for your routes. Notice the ‘home’ route. It basically says that if you hit the ‘/’ root site, load up the index action from the Application/Controller/Index controller. Standby. How does it know what this controller is? Scroll down below and notice the controllers array. It holds an array called invokables. Seems familiar? Basically, whatever route you have set up, is pointed to the right controller in here. Make sure you keep this in mind for adding additional routes in the application module, or any module later.

The first thing I did was to create additional routes that load other templates within the Application module. I wanted to create a route for /login. Just to have a login page. The thing about a login page is that it should be accessible from anywhere publicly, so I made it part of the Application module. Making it part of a Profile module, or Authentication module doesn’t make too much sense here since the page is a public page that anyone can access. I might do the same for the registration module.

So, first thing I did was created the route for my /logic link.

1
2
3
4
5
6
7
8
9
10
11
12
13
// /module/Application/config/module.config.php
...
'login' => array(
    'type' => 'Literal',
    'options' => array(
        'route' => '/login',
        'defaults' => array(
            'controller' => 'Application\Controller\Account',
            'action' => 'login-page'
        )
    )
),
...

It’s a Literal because it’s a direct link. I don’t need to pass anything else other than an absolute check for /login in the URL.

Another thing to notice is the defaults. So, basically, this says to point to somewhere and load something by default if the route /login is matched. Don’t rush too fast. You need to add three more things.

1. Insert a pointer to your controllers invokables array:

1
2
3
4
5
6
7
8
9
// /module/Application/config/module.config.php
...
'controllers' => array(
    'invokables' => array(
        'Application\Controller\Index' => 'Application\Controller\IndexController',
        'Application\Controller\Account' => 'Application\Controller\AccountController'
    ),
),
...

2. Set up a new Controller in the /module/Application/src/Application/Controller/ folder. Keep the name as the invokable above: AccountController.php. Add the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// /module/Application/src/Application/Controller/AccountController.php

// This is to let the application know where this controller is located.
namespace Application\Controller;

// Default Zend Abstract Controller
use Zend\Mvc\Controller\AbstractActionController;

// Your Controller Class (Name should follow the same convention as above). This also extends the default Abstract Controller.
class AccountController extends AbstractActionController
{
    // Keep the name as in your route's action, replacing the dash with uppercase.
    // login-page becomes loginPage, and add Action so zend knows this is the action for the specified route.
    public function loginPageAction() {
        // Your logic code here.        
    }

}

And now, for the template that you’ll be using. By default, Zend will look for the template based on the action specified in your routes. So, it will look for this file: /module/Application/view/application/account/login-page.phtml

Notice the login-page naming convention. It’s good to keep this the same to avoid further confusion. If this page is blank, you will only see the default Zend header and footer.

And now, load your page. If it didn’t work, go back through the steps, and if it still doesn’t work, leave a comment on how you fixed it.

** Next step **

Let’s add some dynamic behavior. Let’s pass in some variables and play around with getting route information from Zend itself.

One thing to notice here is that our routes will change slightly.

Add the below code under your previous “login” route.

1
2
3
4
5
6
7
8
9
10
11
12
13
// /module/Application/config/module.config.php
...
'articles' => array(
    'type' => 'Segment',
    'options' => array(
        'route' => '/articles[/][:id]',
        'defaults' => array(
            'controller' => 'Application\Controller\Account',
            'action' => 'test-with-param'
        )
    )
),
...

We will call this the /articles link, as in news, or blog posts. It could be whatever you wanted, of course, but for now, we’ll play with articles.

Notice our “Literal” has become a “Segment” route. This means that the route will be broken up into little pieces and dynamic stuff will be added to it.

This could be moved into an “Articles” module, which we will later, but for now, we’ll keep it as part of our app, since this, just like the login page, is going to be accessed on our main site.

We don’t need to add anything to our controllers invokables, because we’re calling the same controller. let’s look at our AccountController.php file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// /module/Application/src/Application/Controller/AccountController.php
...
public function showArticlesAction() {
    $routeMatch = $this->getEvent()->getRouteMatch();
    $params = $routeMatch->getParams();
   
    $query = $this->params()->fromQuery();
   
    return array(
        'params' => $params,
        'query' => $query
    );
}
...

Notice something not right here? That’s right, we’re putting article stuff in our AccountController.php Controller file. Articles have nothing to do with accounts, so, we should probably move this function out of here. For now, just to write some spaghetti code that we will learn to refactor later, let’s leave it here.

Notice what’s happening in this controller action. We’re setting some variables that we return in an array. This array will contain a key / value pair that coincidentally have the same name. The keys will become variables in our template that we get to write out, or loop through. Example: the ‘params’ key will become a variable “$params” for the template to use. Let’s see how that looks.

1
2
3
4
5
6
7
8
9
// /module/Application/view/application/account/show-articles.phtml
<div>
    Test With Param
   
    <pre>
        <?php print_r($params); ?>
        <?php print_r($query); ?>
    </pre>
</div>

And when we hit the url: /articles, we should see a nicely formatted list of our variables.

Next post, I will go through the process of moving this feature into our very own Article module.

Comments always welcomed.

Magento Sucks

Some might think that I want some attention, or have become a grumpy old man. Considering my birthday is tomorrow, turning 36 might be as close to a grumpy old man as I can get.

I want to make some things clear. I have nothing against people using these awesome tools coming out every six months, only to be used for a short period of time. I just want to share my experiences in the 12+ years I’ve been developing. Also considering the fact that I’ve been programming since the age of 11, self taught in basic, I think I understand a few things about writing code.

For the same reason that Apple became the number one company in the world, I like simplicity. Even when it comes to programming. Just because I’m a programmer doesn’t mean that I have to be some rocket scientist that only a few can understand.

Good programmers can write complex code that intertwines on itself in amazing loops and conditionals that will make even the smartest of people look at the code like a dog looks at someone whistling. Great programmers will write code that programmers at any level will easily understand.

This reminds me of the time I picked up Magento. What a convoluted piece of crap! I’m not talking about the basic use of pulling it out of the box and creating a template, but I’m talking about trying to revert from Enterprise back to the Community edition. I mean, holy crap! My head spun around for over 3 months trying to duplicate all of the functionality that already existed in Enterprise. Don’t ask me why business wanted to do that. They’re the ones that think they understand the product and sell it like that to their clients.

I vowed to never touch Magento ever again. Unless, someone needs a simple out of the box solution with a pre-purchased tempalte, there are other programs out there that can do everything much simpler. Presta-shop, wordpress, even weebly has introduced an ecommerce solution for moms and pops.

I like the idea behind Magento and its flexibility, but there’s no way you can build something so flexible to allow for everything you ever wanted. There are workarounds around it, and even then, you still have to revert back to simple PHP in many cases. If it was so flexible that you could do anything, well, then, you’d have PHP. So, why the need of a framework?

From my understanding, Magento was built in two weeks by an offshore Russian or Ukranian who worked nights and weekends to get this magestic piece of crap out to the market… And boy, was it buggy… Many revisions later, it’s still a monster that no normal developer wants to touch. For those that do, best of luck to you. You’re obviously MUCH more intelligent than someone like me.

At one point, the company that I worked for even had a project where the only reason to use Magento was to store user information. Everything was ignored, even the templating system. Everything was bootstrapped to render out custom template files outside of the working template folders. Talk about spreading butter with a chainsaw.

Basically, I’m never happy working in an environment where we start out with a framework, and in months we’re using custom code to run everything. Why not start fresh? Tabula Rasa! Clean slate. So much more control over what you do, and so much you can customize from the beginning.

So much abstraction in the programming world. I left the world of Physics because I wanted less abstraction and more reality based practical involvement and construction. Abstract thinking is just that. Abstract. It has its place in the world of physics and math. Engineering just doesn’t function on abstract ideas. You have to be precise and realistic, otherwise your building collapses.

I guess some programmers just like to be challenged for the sake of being challenged. Not this guy. I like keeping my brain functioning beyond the age of 50.

Let’s keep it real, folks!

The reason Angular JS will fail

I’m all about new technology, but just like Steve Jobs had put it, it has to be intuitive. It has to feel comfortable, and easy to learn. This is reference to another one of my posts done here: Angular JS Kinda Sucks. The main reason Angular JS will fail is because it’s difficult. Honestly, who likes to make their lives more difficult? Not this guy. That’s not to say I’m looking for the easy way out. I believe in hard work paying off, but to make things difficult just for the sake of saying that I did something difficult that I could have done with ease, other ways? That’s just ridiculous. Yes, I can take a boat across the English channel, but why not make it harder and swim it? Other than getting into the book of world records, there really is no practical reason to do so.

Which brings me to the pattern of ever failing technologies. Remember Moo Tools? Prototype? I do too, and sadly, I use NONE of them in any of my projects. jQuery has evolved with the times. It has gotten better and better, and even with its 2.0 release, revolutionized. All while keeping its key ingredient of keeping itself simple to use and logically understandable. Any one of us who struggled with JS before jQuery came along created our own JS libraries to handle mundane tasks of JS. Class lookups, selecting elements, animation, AJAX, etc. We all wondered if there was an easier way to do repetitive work like that. jQuery came along and helped us out in that department.

Prototype and moo tools tried to be innovative, but they just made things harder. Not only were they not intuitive to use, but referring to the documentation was even worse. Would take hours what jQuery could accomplish in mere minutes.

Don’t look at how many companies use those other tools right now. Wait for it and see how many companies will use those same tools in the future. 5 years, 10 years… jQuery has stood the test of time. And the reason they keep winning is because they cater to the developer, the people who are using the tool the most, and making their lives easier to deal with. It’s a complement to code, not a spaghetti nightmare filled with complexities and high learning curves.

I remember the first time I built a web page using jQuery. It was easy. It was instinctive. It was amazing. It made want to use more of it. AngularJS unfortunately, did not have that same effect on me.

In the end, I guess it’s to each their own, but too many times I’ve come across reviews that are not so pleasant to read about Angular JS. Even doing a google search on “jQuery sucks” vs “AngularJS sucks” shows that there are more results for the latter, and AngularJS has only been around for a few years, while jQuery, almost a couple of decades. You’d think that there would be more results for jQuery since it’s been around for longer, and that AngularJS has been harbored by Google.

What are your thoughts?

UPDATE: 7/18/2014

As promised, here it is. The first update of my attempt to compare angular vs jQuery. Before you jump in and start yelling at me about how they’re apples and oranges, I wanted to compare the ease of use of angular and jQuery to do something simple. Here are the three tests:

* Load elements onto a page
* User clicks on stuff
* Use AJAX calls to…
* Manipulate DOM elements.

Basically, this explains any sort of application that I’ve ever worked with.

* Program loads
* User clicks around
* A call is made to the “controller” which calculates some things, and returns some “views” to be rendered by the front end
* Swap out HTML elements, add classes, remove classes, etc.

Doing my research, I found out that angularjs does AJAX calls as simple and as easy as jQuery. Here’s some examples:

jQuery:

1
2
3
4
5
6
7
8
9
10
    $.ajax({
        url: '/ajax.php',
        dataType: 'JSON',
        success: function (data) {
            $('#element').html(data);
        },
        fail: function (data) {
            alert("AJAX failed!");
        }
    });

angularjs

1
2
3
4
5
6
7
8
9
10
    $scope.myData = {};
    $scope.myData.doClick = function (item, event) {
        var responsePromise = $http.get("/ajax.php");
        responsePromise.success(function(data, status, headers, config) {
            $scope.myData.fromServer = data.title;
        });
        responsePromise.error(function(data, status, headers, config) {
            alert("AJAX failed!");
        });
    }

Code Size:
+ jQuery
The very first noticeable thing here is the fact that jQuery has significantly less code. This may not matter right now because it’s a small ajax call, but what happens when you have multiple AJAX controllers (as I’d like to call them)? This can escalate quickly.

Library Size:
+jQuery
If you check your network tab like I do, you’ll also notice that jQuery is about 20% smaller in size. Not a biggie really, just a small win, but still a win.

Maintainability:
= neither / both
While I like how angular binds everything with variable names to make it easier to manage your code, there’s absolutely nothing holding you back from writing well structured jQuery code that will accomplish the same thing. Well structured code is well structured code. I can see either fail at this if either code is spaghetti.

DOM Manipulation:
++jQuery
I wanted to see an example of how angularjs will do DOM manipulation since my app is mostly DOM elements being updated, added, removed. This is where angular fails for me by far! The first google search led me to this jsfiddle link: http://jsfiddle.net/simpulton/E7xER/

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
var myApp = angular.module('myApp', []);

myApp.directive('myWidget', function() {
    var linkFn;
    linkFn = function(scope, element, attrs) {
        var animateDown, animateRight, pageOne, pageTwo;
        pageOne = angular.element(element.children()[0]);
        pageTwo = angular.element(element.children()[1]);

        animateDown = function() {
            $(this).animate({
                top: '+=50'
            });
        };

        animateRight = function() {
            $(this).animate({
                left: '+=50'
            });
        };

        $(pageOne).on('click', animateDown);
        $(pageTwo).on('click', animateRight);
    };
    return {
        restrict: 'E',
        link: linkFn
    };
});

Notice something awkward? It starts all nice an ajngularjs-y, but the on line 11 of 28, something awesome happens. All of the DOM manipulation is handled by jQuery. Um…….. What? So not only do I have to load a library (jQuery), on top of a heavier framework, and handle my DOM with jQuery still? This is what I was referring to when I first started writing about this article. 8/28 lines are jQuery. And this after a google search on how to manipulate DOM with angularjs. I guess the answer is: use jQuery.

Most of my front end code is ajax calls and DOM manipulation. As most apps are, that’s the norm. And I mean 99.999% of my jQuery is just that. AJAX and DOM manipulation. This is why we’re creating an app in the first place; so we don’t have to constantly reload a page. This is as simple as it gets, and angularjs has failed me.

An app without DOM manipulation is no app. It’s an applet. Forget about building full SPAs without jQuery.

Scalability:
++jQuery
So, I wanted to see how my friends here would fare against some extended code to handle a dynamic AJAX controller with JSON data coming back from the back-end. I won’t post the back-end code since it’s the same code. I just want to see the difference of how angularjs handles the data coming back from the server, and how jQuery handles the same data.

For the purpose of simplicity, here’s the requirements:

* Two links, and two output elements on the page.
* One link loads a random number in the first element.
* The second link loads today’s date in the second element.

angularjs:
—-angularjs
First off, I had to search the documentation… A LOT. And although the documentation lists functions and methods, it doesn’t show examples like jQuery does. How do I know how to use it if there’s no example? Is it assumed that I already know how to use angularjs? Then why is there documentation if I know how to use it? It’s illogical garbage. If you, the reader, can show me how to achieve something similar to the jQuery example below, please, I beg you, show me!

Forget about trying to get an attribute value from an element. The documentation page about attributes… NOTHING. No examples:
https://docs.angularjs.org/api/ng/type/$compile.directive.Attributes

I found “some” answers on stackoverflow.

First, there was this:

1
2
3
4
5
6
// Use $observe to observe changes to the attribute:

attrs.$observe('data', function(value) {
  console.log('data has changed value to ' + value);
});
attrs.$set('data', 'new value');

Where am I supposed to put this code? In my controller file? My main app file? In the HTML as a script tag? And I don’t care about detecting changes to the attribute. I want to get the value of an attribute. Found something else while browsing:

http://stackoverflow.com/questions/20636537/angularjs-find-element-by-attribute-value
“In AngularJS you won’t do direct DOM manipulation from the controller, you should create a directive to to that. Inside the directive you can use JQuery as you wish.”

……. dandy! So, while really trying to make DOM manipulations, which is the visual feedback that end users require in order to know if something happened… I went back to jQuery.

Binding and directives? How am I going to write them to achieve the dynamic world that jQuery offers through IDs and Class Names? How can one bind anything to achieve that beautiful DOM manipulation? What about rendering new elements (created after DOM ready) on the page that I can continue to manipulate with jQuery using the $(document).on(); function?

jQuery:

1
2
3
4
<a class="ajaxClick" data-action="dobuttonone" href="/ajax.php">Link 1</a>
<a class="ajaxClick" data-action="dobuttontwo" href="/ajax.php">Link 2</a>
<div id="elemOne"></div>
<div id="elemTwo"></div>

The backend will return some JSON encoded code with the following structure:

1
2
3
{"htmls":{"#elemOne":496609}}
// or
{"htmls":{"#elemTwo":"2014-07-19 00:32:09"}}

The JS that will show the main controller that I was talking about:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
var manipulateMyDOM = function (data) {
    for(htmlElem in data.htmls) {
        $(htmlElem).html(data.htmls[htmlElem]);
    };
    for(appendElem in data.appends) {
        $(appendElem).append(data.appends[appendElem]);
    };
    for(prependElem in data.prepends) {
        $(prependElem).prepend(data.prepends[prependElem]);
    };
    for(updatableElem in data.updatables) {
        $(updatableElem).html(data.updatables[updatableElem]);
    };
    for(replaceableElem in data.replaceables) {
        $(replaceableElem).replaceWith(data.replaceables[replaceableElem]);
    };
    for(removeElem in data.removes) {
        $(document).find(data.removes[removeElem]).remove();
    };
    for(after in data.afters) {
        $(after).after(data.afters[after]);
    };
    for(attrchange in data.attrchanges) {
        for (value in data.attrchanges[attrchange]) {
            $(attrchange).attr(value,data.attrchanges[attrchange][value]);
        }
    };
    for(classRemoveElem in data.classRemoves) {
        $(classRemoveElem).removeClass(data.classRemoves[classRemoveElem]);
    };
    for(classAddElem in data.classAdds) {
        $(classAddElem).addClass(data.classAdds[classAddElem]);
    };
}

$(document).on('click','.ajaxClick',function(e) {
    e.preventDefault();
    var $this = $(this);
    var _action = $this.attr('data-action');
    var _url = $this.attr('href') + '?action=' + _action;
    $.ajax({
        url: _url,
        dataType: 'JSON',
        success: function (data) {
            manipulateMyDOM(data);
        }
    });
});

And you’re done!!!! The only thing you will have to take care of is to provide elements with the class name “ajaxClick” and add a “data-action” attribute to tell the back-end which function to run. Here’s that PHP file I said I won’t put up. For each one of those links, you just add another function to your ajax file. The binding happens because of the data-action attribute is named the same as the php function. Yes you can obfuscate them if you’d like, but this is just to give you an idea of how code can be structured without the aid of 3rd party frameworks.

What I did above was to build my DOM Manipulator for as much of the functionality that I will use for most of my apps. You can reuse this for every application out there as a plug and play piece of code. Angular cannot make this possible as it can’t do DOM Manipulation on its own.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$action = isset($_GET['action']) ? $_GET['action'] : 'badcall';
call_user_func($action);

function dobuttonone() {
    // DO PHP STUFF HERE
    echo json_encode(array(
    'htmls' => array(
        '#elemTwo' => date('Y-m-d H:i:s')
    )
    ));
}
function dobuttontwo() {
    // DO PHP STUFF HERE
    echo json_encode(array(
    'htmls' => array(
        '#elemOne' => rand(111111,999999)
    )
    ));
}
function badcall() {
    echo json_encode(array(
        'error' => true,
        'message' => 'No action was provided'
    ));
}

Now THAT’S good structure. No frameworks necessary. Just good ol’ code. An entire dynamic and scalable application.

I really wanted to compare a real life world example on how I can achieve something with angular that I already have with jQuery. Unfortunately, angular has already failed for me, and I provided examples on how it did so.

To all those angularjs developers who keep claiming how awesome the holy grail of angularjs is, please provide some examples of some work so I can understand what you keep claiming to be real. It’s like a religion, I swear. AngularJS is just awesome. You just have to be immersed in it to realize it. Sounds just like religion.

For me, angular has failed for the following reasons:

* No clear examples of the two most widely used front end features, DOM Manipulation and AJAX calls.
* Most of my development (over 99%) consists of those two features.
* jQuery easily provides AJAX calls, and keeps the code lighter and cleaner than angular.
* Even angular documentation suggests you use jQuery for DOM Manipulation.
* Why even bother using angular if most of my work consists of features easily implemented by jQuery?

I’m sorry to say that my research with angularjs has just strengthened my trust in jQuery to be my library of choice.

Well, actually, I’m not sorry. I’m glad I chose wisely from the beginning.

UPDATE: 10/15/2014

After reading a lot of your comments, I’ve started to realize why the two are apples and oranges. Most angular developers speak of SPAs as something that doesn’t require DOM manipulation. Just numbers or text values changing here and there. Or even replacing your curly brackets with chunks of html within the document.

AJAX can be done by both, fairly easily. So that’s not a problem. I have noticed several comments that are less than nice towards someone trying to understand something new. It’s as if it should be simple because you understand it. Some people have an easier time with apples than oranges I suppose.

Performance wise, both can be good or bad. I keep saying it over and over, but it’s HOW you code, now what you use that matters in the end.

As far as making things easier… well, the shortest road is the one best known. Shortcuts can sometimes leave you wasting time if you’re not familiar with them.

Having been in the web dev field for quite some time now, I’ve realized that it all comes down to the basics. Adding levels of abstraction just creates necessity for no reason. Necessity to learn new things, which some people may be opened to, but this old timer (and apparently a lot of the commenters and readers of this post) is about done with learning new things that go obsolete before they get famous (prototype, mootools, GWT, Code Igniter for backend, I could go on and on).

Frameworks are nice when you understand them, that’s why I believe that the best framework is the one that’s easiest to learn. Unfortunately, most people don’t understand that the most popular framework is JavaScript itself. As for BackEnd PHP Frameworks, PHP still outlived every other abstract layered framework on top of it, and their many non backwards compatible versions. Looking at Laralvel, the greatest marketed PHP framework since Zend, it honestly looks like all of the other frameworks before it… just done differently with a little more or a little less abstraction, and its own quirks. Sparse documentation doesn’t help it either.

In the end, it comes down to the choice of the developer. I give a lot of respect to developers that still write pure JS. No abstraction for them. They know what’s needed from the language for their project.

I’ll stick to my apples, thank you.

Git Kinda’ Sucks

So, another “kinda sucks” article from me. This time, I’m taking on Git. I’m sure Git is wonderful for all of the companies that have adapted it and has dealt with its constraints and difficulties. Ask anyone who’s picked up Git after they’ve been used to SVN, or other repository. They will most likely tell you that it was difficult to implement, but now they’re happy that they spent the time to learn it.

What exactly was gained from it, other than for the sole purpose to learn something new? Nothing. I’ve picked up Git some time ago on one of my projects, and I was battling with it. It would fight me. Pull, push, commit, on and on. It just seemed like more ways one could screw up, that’s all.

SVN did everything I ever needed for my projects, and I have several projects, all with massive code bases, and some of which I run from multiple areas, and work with multiple developers. So, I gave Git another try when one of the team members I worked with on a project introduced it. He also introduced SASS at the same time. Let me tell you, for someone that knows their LAMP stack all too well, introducing all these bells and whistles makes you feel pretty stupid. Conflicts and overwrites became huge issues because the other team members weren’t told that SASS was going to be used, and no one mentioned that designers are going to change template code.

Don’t believe me? Check out others who are upset about Git as well:
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

…and the rebuttal:
http://www.tylerbutler.com/2012/08/ten-things-steve-bennett-hates-about-git/

Check out the first comment made by Steve Bennett, the writer in the first link.

In the end, it’s not about the technology that you use, it comes down to how well you use the technologies that you currently know. And I’ve always said the following two things, and follow them religiously:

1. If it ain’t broke, don’t fix it.
2. Stop trying to re-invent the wheel.

They pretty much say the same thing. It’s the same argument when it comes to using OOP for a web project. That’s for a later discussion. Check out the reason I made my own “opened framework” here.

PS. I really think someone invented Git to make SVN users much happier with their repository handling.

Angular JS Kinda Sucks

Ok, so I ran across this angular js framework and looked it over, tried to duplicate some functionality that I already had existing with jQuery, and was not impressed.

First of all, I can do anything in jQuery, and have full control. Full control of the selectors, HTML, the DOM. I like that. I like knowing what I’m doing and what’s happening in my application. Somehow, angular fails to let me know what’s happening behind closed doors, unless I go dig into the code itself. Hm. Never had to do that with jQuery.

+ jQuery

The documentation is just plain horrible. Basically, it comes down to how basics work, not how you can and should build an application, even though they stress that you must first architect your application before you build it. Architect it how? Are there examples? Some nice examples would be of projects that are relevant to the outside world. Data manipulation? Dynamic AJAX driven application? It just seems like a lot of hype because it’s the “cool” thing to do and everyone is doing it. Well, not everyone. About 0.1% of sites out there use Angular, while well over 55% of websites use jQuery. Most of the documentation is just hard to understand without explaining the parts of the application or explaining the magic behind the app, or even explaining why I’m naming certain things the way I name them. Anyway, just confusing.

+ jQuery

Which brings me to my final reason for not liking it. Intuitiveness. It’s not intuitive at all! If you know JS and jQuery, everything is build so you can just figure things out. .show(), .hide(), $.ajax({stuff}), $(‘whatever selector you want full control of here’).doThings(). It’s easy to read, just like OOP. In angular it feels like you’re looking at fog. ng-this, ng-that, and now you have to assume that somehow everything is aware of everything else on the page. WTF?

+ jQuery

Speed of development? Hardly. We had some experience with it at work where some front-end code was handed down to be integrated by back-end guys, and… well… everything broke. Why? The back-end guy knew only jQuery. Now, he has to spend additional time and resources to learn angular, and the learning curve is STEEP!!!! And once he learns it, maybe someone will come up with another stupid framework that will do exactly the same thing jQuery does, only more abstract. Can we get practical with our development, stop being such lazy-ass programmers, learn to code properly, and stop complaining about how working on something feels like work? Beware of lazy programming and short cuts to faster deployment schemes. Sounds a lot like get rich quick schemes. How well have those worked out so far? Is everyone rich yet?

+ jQuery

Just not for me. Might be for you, but for me, I stand by the saying, “If it ain’t broken, don’t fix it!” And jQuery is definitely not broken. It’s by far the most favorable, intuitive, powerful “framework”/library to date. It’s not a hula hoop. It’s a cellphone.

Updated on Feb 27th, 2014:
After attempting to look through documentation and examples on stackoverflow, I’ve come to the conclusion that I’m much happier with jQuery, for the simple reason that I know how to use it and it does everything I’ve ever wanted, because it’s a tool for short-cutting a lot of mundane tasks that JS threw at us. .each() loops, .ajax calls, class selectors, very easy to understand and build on top of. After looking at many examples of angular implementation, I’ve noticed a pattern of jQuery being used on top of angular. Obviously to take care of the many things that angular can’t. It seems to me that performance wise it wouldn’t be smart to use angular, simply because it would be additional bulk on top of your programming. It doesn’t complement JS, it complicates it by changing the rules, and way of thinking. jQuery respects JS and complements it greatly. So…

+ jQuery

If anyone has the solution to how they would take care of the example I’ve created using jQuery with angularjs here, I would love to read it.