How to select a web developer

Many Sinu customers have asked us about web development. There are a number of good platform options out there (see Sinu blog for more info on website builder solutions), so I would evaluate which platform is right for you based on hosting costs, functionality, and pre-designed templates. Once you have decided on a platform, look for a developer from that ecosystem.

Several website builder solutions have lists of development shops that they recommend for their specific platforms. There is along list of impressive SquareSpace development shops to choose from. Wix provides a list of recommended developers, showcases designs, and you can even get a free quote at WixArena. The Code Poet Directory from Automattic, the company behind WordPress.com, lists enterprise-level WordPress professionals, web designers, and developers.

There are also many purpose-built platforms catering to specific industries. For instance, with NationBuilder you can build a website for a nonprofit or political candidate with built-in tools to facilitate fundraising, grassroots engagement, and letter-writing campaigns. NationBuilder has published a list of several developers for you to select from.

While Weebly does not have a published list of recommended developers, earlier this year the company launched an enterprise platform that combines the drag-and-drop website creation service they are known for with enterprise functionality. Features include a robust permissions system and administrative controls, as well as a suite of APIs that give enterprise customers the ability to integrate Weebly into their existing applications. Weebly is targeting a number of specific industries with its enterprise offering, including real estate agencies, franchises, and educational institutions.

21 Things Every Web Developer Should Be Doing

Keyword Research

If you have not performed keyword research before starting on the development of your site, then you are not building a website for your customers. You might as well just look in the mirror and say, “It’s all about me! It’s all about me!” Keyword research gives you a wealth of information on how your audience searches, what phrases have meaning to them and what, specifically, they are looking for. This feeds into the architecture and navigation of the site in huge ways.

Wire Frames

Wait. You are creating a design without putting together wire frames first? Big mistake. While skipping this step may get you a completed design quicker, without wire frames, your pages may end up missing critical elements or have functions in the wrong place. It may seem like a simple fix, but the design frequently distracts us from seeing the things we should be seeing.

That leaves you either approving a design you like, not realizing something is missing, or rejecting a design because something just seems wrong but you can’t quite put your finger on it. Build a wire frame for each unique section (or page) of your site so, without distraction of colors or other visual elements, you can ensure everything you need has its place on the page.

Grayscale Comp

Grayscale comps are common in the print design industry, but for whatever reason, not so much in the web design industry. In my opinion, they are just as important here as anywhere else. Color is a distraction. I’ve seen clients reject a site design because they didn’t like it. Turns out, they just didn’t like the colors! Grayscale comps allow designers to design the site using the appropriate contrasts without yet worrying about what colors the client does or doesn’t like, or how those colors are working together in particular areas of the site. Approve the design, then add color later.

Color Comp

The worst that can happen here is that the grayscale comp is accepted but the first color comp is rejected. Do you have to go back and reinvent the wheel? Nope, just change the colors until you get them right!

Coding & Implementation

Believe it or not, there are some web designers who don’t code websites. You have to find someone else to do that. Nothing wrong with that, just so long as you know this ahead of time. Sometimes you can have one person do both the design and code, and other times it might make sense to have two people with two different skill sets implementing your development in phases. Either way, for a site to work, the code has to be built to accommodate the design and the functionality you require.

HTML5 (Validated)

HTML5 can do some pretty sleek stuff, but many web developers are still coding in HTML4. Sure, old HTML still works, but it ensures your site is obsolete almost immediately. HTML5 is scalable for new media and gives advanced functionality with less code than other forms of HTML. That makes your site sleeker, cleaner and faster! While validation isn’t necessary for a site to work, a developer should be doing clean enough code that the HTML will validate properly. There are some exceptions to this (especially when using 3rd party tools) but validation should be considered a necessary component of good code development.

CSS3 (Validated)

HTML5 and CSS3 go hand in hand. CSS3 offers lots of cool tricks that used to have to be accomplished with excessive JavaScript code or even having to use images which slow site downloads. CSS3 plays a significant role in speeding up page downloads and giving your site a fresh, interactive feel. Again, your CSS should be validated too!

Search Engine-Friendly Architecture

I understand coding a site can be a daunting task, especially when you’re adding in unique functionality. But that’s no excuse not to code a site with search engines in mind!

Developers need to consider common architectural issues that hinder a site’s performance in the search results, including poor navigation implementation, excessive internal linking, readable URLs, unspiderable links and pages, slow-loading pages, and more. While most developers don’t have search engine optimization experts on staff (even if they claim to!), it’s important to have someone to look over the work being done to ensure the architecture of the site won’t cause problems for you later.

Duplicate Content Prevention

Along with the SE friendly architecture, developers must make sure that your site solves any potential duplicate content problems before the search engines spider a single page. There are many duplicate content workarounds and band-aids, which can be applied after the fact, but a good developer will consider this when building the website from the beginning.

Off-Page Styling

This is also a component of a search friendly architecture, but it bears its own commentary. One thing developers must understand is the less code there is on each page, the better the site tends to perform for visitors. That’s not because visitors care about the code, but because the code can impede their on-site experience. Styles and JavaScript code should, as much as possible, be moved off the page into external sheets that can be downloaded by the browser separately. This makes pages run faster and eliminates the need to downloaded all that code with each page they visit.

Size Optimized Media

Using any media on your site? If so, is it optimized properly? Often they aren’t, and that’s a problem. Everything from images to video should be optimized for speed and search friendliness. Most media can be compressed to be smaller in size (file size and display size) so they download faster.

There is usually a keyword optimization component in alt tags or captions which can be implemented as well when the media is being created. Most video can be optimized for YouTube and images can be optimized for image search. These considerations are an important part of the development process.

ALT Text For All Images

Speaking of images, if ALT tags are not used on images in the development stage, then when? Oh, right, they have to be done after the site is developed. Again, why go back and re-do what should have been done to begin with?

CSS Image Sprites

Another way to speed up page load times is to use image sprites to consolidate several small images into one. Each image download places a certain amount of strain on the server. One larger image causes less strain and quicker downloading. This is especially true for images used on multiple pages. Use CSS to display the relevant portion of the image

Mobile Reactive

Not concerned about what your site looks like on a mobile device? You should be! Even if your customers don’t complete transactions on your site from their mobile devices, mobile is often the start of their research process. This is usually the first place branding occurs.

If your site doesn’t work or isn’t visually appealing in a mobile environment, you blew your first chance to make a good impression! Yet, with the growth of mobile devices, you can be sure if your audience isn’t using mobile widely today, they will be tomorrow. If you’re not there, you’re not for them.

Scalable at Various Resolutions

Your site must scale well across multiple resolutions and screen sizes. It’s not just mobile that have multiple screen sizes and resolutions (iPad, iPad mini, smart phone, over-sized smart phone, etc.) but desktop screens rang from 19″ to 24+”. Your site needs to work well across the board by being responsive.

Site Optimized For Speed

I’ve talked a lot about site speed in different points above, but site speed warrants its own commentary. After you’ve optimized everything else for speed, look again to see what is slowing the site down. Is it a plugin that should be hard-coded? Is it an unnecessary bit of functionality that just looks cool? Speed is an important factor of a visitor’s experience and the developer needs to look for additional ways to speed the site up.

Install Analytics

All this web design stuff is great, but if you don’t have analytics code installed then you have no way of knowing how your new site is performing. Adding analytics code is easy and shouldn’t be an after-thought. It should come standard on all new websites.

Broken Link Checks

If I had a dollar for every broken link that I’ve found on a brand new site or re-designed site, I’d have a whole lot more money than I do now! Ensuring the site rolls out without any broken links is the developer’s job. Period. That’s part of ensuring the site works correctly on all fronts and preventing user frustration.

Extensive Testing

Under no circumstances should a developer give you a completed site without extensive live testing. There is just no excuse for a new site to be buggy and broken after the developer turns it over to you. Time for testing should be worked into the timing for site development. Under no circumstances should the site be rushed out before the bugs are worked out and tested– it’s worth it to wait!

Custom 404 & Favicon Branding

Yet another relatively small task that developers don’t think about. While they are usually not huge issues, it’s a nice added touch of “completion.” Ever see the little image that appears in the URL bar when you’re on a site, or in the tab title of a site you have open? That’s the favicon. A small visual piece but one that can make a huge impact.

So can a custom 404 page that is accessed when a visitor lands on your site via a bad link. A custom designed page keeps the visitor engaged on your site rather than a generic “page not found” message that often sends them back where they came from.

Printer Friendly

Finally, all sites should be printer friendly. It is quite common for visitors to print pages for later review or reading. When pages are not printer friendly the text is often difficult to read, multiple blank pages are printed, or other ghastly annoyances turn up on the page. Using CSS, each page of your site can be printed with minimal junk, while making sure the content they want is readable to boot!

 

 

10 Reasons Web Developers Should Learn AngularJS

There is no doubt that AngularJS – the self-proclaimed “superheroic JavaScript framework” – is gaining traction. I’ll refer to it frequently as just “Angular” in this post. I’ve had the privilege of working on an enterprise web application with a large team (almost 10 developers, soon growing to over 20) using Angular for over half of a year now. What’s even more interesting is that we started with a more traditional MVC/SPA approach using pure JavaScript and KnockoutJS before we switched over to using the power-packed combination of TypeScript and Angular. It’s important to note that we added comprehensive testing using Jasmine, but overall, the team agrees the combination of technologies has increased our quality and efficiency: we are seeing far fewer bugs and delivering features far more quickly.

If you are familiar with Angular, this post may give you some ideas to think about that you hadn’t encountered before. If you know Angular and are trying to justify its adoption at your company or on your project, this post can provide you with some background information that may help. If you have no idea what Angular is, read on, because I’ll share why it’s so powerful and then point you to resources that will get you up to speed, quickly.

I can only assume other organizations are seeing positive results after adopting Angular. According to Google Trends the popularity of AngularJS (blue) compared to KnockoutJS (red) and “Single Page Applications” (yellow) is exploding.

One of the first single-track AngularJS conferences, ng-conf, sold out hundreds of tickets in just a few minutes.

This post isn’t intended to bash KnockoutJS or Ember or Backbone or any of the other popular frameworks that you may already be using and are familiar with. Instead, I’d like to focus on why I believe AngularJS is gaining so much momentum so quickly and is something anyone who works on web applications should take very seriously and at least learn more about to decide if it’s the right tool to put in your box.

1. AngularJS Gives XAML Developers a Place to Go on the Web

I make this bullet a little “tongue-in-cheek” because the majority of developers using Angular probably haven’t touched XAML with a 10 foot pole. That’s OK; the reasons why XAML became popular in the Microsoft world through WPF, Silverlight, and now Windows Store app development are important to look at because they translate quite well to Angular. If you’re not familiar with XAML, it is a declarative language based on XML used to instantiate object graphs and set values. You can define various types of objects with properties and literally mark up a set that will get created. The most common types of objects to create are user interface elements such as panels and controls that create a display. XAML makes it easy to layout complex UIs that may change over time. XAML supports inheritance (properties defined as children of parents can pick up values set higher in the tree) and bubbles events similar to the HTML DOM.

Another interesting component of XAML is the support for data-binding. This allows there to exist a declared relationship between the presentation layer and your data without creating hard dependencies between components. The XAML layer understands there is a contract – i.e. “I expect a name to be published” and the imperative code simply exposes a property without any knowledge of how it will be rendered. This enables any number of testing scenarios, decouples the UI from underlying logic in a way that allows your design to be volatile without having to refactor tons of code, and enables a truly parallel workflow between designers and developers.

This may sound like lip-service, but I’ve been on many projects and have seen it in action. I recall two specific examples. One was a project with Microsoft that we had to finish in around 4 months. We estimated a solid 4 months of hands-on development and a separate design team required about 4 months of design before all was said and done – they went from wireframes to comps to interactive mock-ups and motion study and other terms that make me thankful I can let the designers do that while I focus on code. Of course if we followed the traditional, sequential approach, we would have missed our deadline and waited 8 months (4 months of design followed by 4 months of coding). XAML allowed us to work in parallel, by agreeing upon an interface for a screen – “These are the elements we’ll expose.” The developers worked on grabbing the data to make those properties available and wrote all of the tests around them, and the designers took the elements and manipulated, animated, and moved them around until they reached the desired design. It all came together brilliantly in the end.

The other real world example was a pilot program with a cable company. We were building a Silverlight-based version of their interactive guide. The only problem was that they didn’t have the APIs ready yet. We were able to design the system based on a domain model that mapped what the user would experience – listings, times, etc. – then fill those domain objects with the APIs once they were defined and available. Again, it enabled a parallel workflow that greatly improved our efficiency and the flexibility of the design.

I see these same principles reflected in the Angular framework. It enables a separation of concerns that allows a true parallel workflow between various components including the markup for the UI itself and the underlying logic that fetches and processes data.

2. AngularJS Gets Rid of Ritual and Ceremony

Have you ever created a text property on a model that you want to bind to your UI? How is that done in various frameworks? In Angular, this will work without any issues and immediately reflect what you type in the span:

<input data-ng-model=’synchronizeThis’/><span>{{synchronizeThis}}</span>

Of course, you’ll seldom have the luxury of building an app that simple, but it illustrates how easy and straightforward data-binding can be in the Angular world. There is very little ritual or ceremony involved with standing up a model that participates in data-binding. You don’t have to derive from an existing object or explicitly declare your properties and dependencies – for the most part, you can just pass something you already have to Angular and it just works. That’s very powerful. If you’re curious how it works, Angular uses dirty tracking.

Although I understand some other frameworks have gotten better with this, moving away from our existing framework where we had to explicitly map everything over to an interim object to data-bind to Angular was like a breath of fresh air … things just started coming together more quickly and I felt like I was duplicating less code. Who wants to define a contact table, then a contact domain object on the server, then a contact JSON object that then has to be passed to a contact client-side model just to, ah, display details about a contact?

3. AngularJS Handles Dependencies

Dependency injection is something Angular does quite well. I’ll admit I was skeptical we even needed something like that on the client, but I was used to the key scenario being the dynamic loading of modules. Oh, wait – what did you say? That’s right, with libraries like RequireJS you can dynamically load JavaScript if and when you need it. Where dependency injection really shines, however, is two scenarios: testing and Single Page Applications.

For testing, Angular allows you to divide your app into logical modules that can have dependencies on each other but are initialized separately. This lets you take a very tactical approach to your tests by bringing in only the modules you are interested in. Then, because dependencies are injected, you can take an existing service like Angular’s $HTTP service and swap it out with the $httpBackend mock for testing. This enables true unit testing that doesn’t rely on services to be stood up or browser UI to render, while also embracing the ability to create end-to-end tests as well.

Single Page Applications use dynamic loading to present a very “native application” feel from a web-based app. People like to shout the SPA acronym like it’s something new but we’ve been building those style apps from the days of Atlas and Ajax. It is ironic to think that Ajax today is really what drives SPA despite the fact that there is seldom any XML involved anymore, as it is all JSON. What you’ll find is these apps can grow quickly with lots of dependencies on various services and modules. Angular makes it easy to organize these and grab them as needed without worrying about things like, “What namespace does it live in?” or “Did I already spin up an instance?” Instead, you just tell Angular what you need and Angular goes and gets it for you and manages the lifetime of the objects for you (so, for example, you’re not running around with 100 copies of the same simple service that fetches that contact information).

4. AngularJS Allows Developers to Express UI Declaratively and Reduce Side Effects

There are many advantages to a declarative UI. I mentioned several when I discussed XAML earlier in this post, but HTML is in the same boat. Having a structured UI makes it easier to understand and manipulate. Designers who aren’t necessarily programmers can learn markup far easier than they can programming. Using jQuery you end up having to know a lot about the structure of your documents. This creates two issues: first, the result is a lot of unstable code working as “glue” that is tightly coupled to changes in the UI, and second, you end up with plenty “magic” because it’s not evident from looking at the markup just what the UI will do. In other words, you may have a lot of behaviors and animations that are wired up “behind the scenes” so it’s not apparent from looking at the form tags that any validation or transitions are taking place.

By declaring your UI and placing markup directly in HTML, you keep the presentation logic in one place and separated from the imperative logic. Once you understand the extended markup that Angular provides, code snippets like the one above make it clear where data is being bound and what it is being bound to. The addition of tools like directives and filters makes it even more clear what the intent of the UI is, but also how the information is being shaped because the shaping is done right there in the markup rather in some isolated code.

Maintaining large systems – whether large software projects or mid-sized projects with large teams – is about reducing side effects. A side effect is when you change something with unexpected or even catastrophic results. If your jQuery depends on an id to latch onto an element and a designer changes it, you lose that binding. If you are explicitly populating options in a dropdown and the designer (or the customer, or you) decides to switch to a third party component, the code breaks. A declarative UI reduces these side effects by declaring the bindings at the source, removing the need for hidden code that glues the behaviors to the UI, and allowing data-binding to decouple the dependency on the idea (i.e. “a list”) from the presentation of the idea (i.e., a dropdown vs. a bulleted list).

5. AngularJS Embraces ‘DD … Er, Testing

It doesn’t matter if you embrace Test-Driven Development, Behavior-Driven Development, or any of the driven-development methodologies, Angular embraces this approach to building your application. I don’t want to use this post to get into all of the advantages and reasons why you should test (I’m actually amazed that in 2013 people still question the value) but I’ve recently taken far more of a traditional “test-first” approach and it’s helped. I believe that on our project, the introduction of Jasmine and the tests we included were responsible for reducing defects by up to 4x. Maybe it’s less (or it could be more) but there was a significant drop-off. This isn’t just because of Angular – it’s a combination of the requirements, good acceptance criteria, understanding how to write tests correctly and then having the framework to run them – but it certainly was easier to build those tests. (Photo credit: George Hodan).

If you want to see what this looks like, take a look at my 6502 emulator and then browse the source code. Aside from some initial plumbing, the app was written with a pure test-first approach. That means when I want to add an op code, I write tests for the op code then I turn around and implement it. When I want to extend the compiler, I write a test for the desire outcome of compilation that fails, then I refactor the compiler to ensure the test passes. That approach saved me time and served to both change the way I structured and thought about the application, but also to document it – you can look at the specs yourself and understand what the code is supposed to do. The ability to mock dependencies and inject them in Angular is very important and, as you can see from the example, you can test everything from UI behaviors down to your business logic.

6. AngularJS Enables Massively Parallel Development.

One of the biggest issues we encountered early in the project was developers stepping on each other’s toes. Part of this is just a discipline, and even with raw JavaScript you can follow patterns that make it more modular, but Angular just took it to another level. That’s not to say it completely eliminates dependencies, but it certainly makes them easier to manage. As a specific case in point, there is a massive grid in the application that is used to drive several key operations. In a traditional JavaScript application it could have been a merge nightmare to scale this across a large team. With Angular, however, it was straightforward to break down the various actions into their own services and sub-controllers that developers could independently test and code without crashing into each other as often.

Obviously, for larger projects, this is key. It’s not just about the technology from the perspective of how it enables something on the client, but actually how it enables a workflow and process that empowers your company to scale the team.

7, AngularJS Enables a Design <—> Development Workflow.

OK, who am I kidding, right? You can get this with HTML and CSS and other fun technologies. The reason this gets its own bullet, however, is because of just how well this works with Angular. The designer can add markup without completely breaking an application because it depends on a certain id or structure to locate an element and perform tasks. Instead, rearranging portions of code is as easy as moving elements around and the corresponding code that does the binding and filtering moves with it. Although I haven’t yet seen a savvy environment where the developers share a “design contract” with the UI/UX team, I don’t doubt it’s far off – essentially the teams agree on the elements that will be displayed, then design goes and lays it out however they want while development wires in the $scope with their controllers and other logic, and the two pieces just come together in the end. That’s how we did it with XAML and there is nothing preventing you from doing the same with Angular.

If you’re a Microsoft developer and have worked with Blend … wouldn’t it be cool to see an IDE that understands Angular and could provide the UI to set up bindings and design-time data? The ability is there, it just needs to be built, and with the popularity I’m seeing, I don’t doubt that will take long.

8. AngularJS Gives Developers Controls.

One of the most common complaints I heard about moving to MVC was “what do we do with all of those controls?” The early perception was that controls don’t work/wouldn’t function in the non-ASP.NET space, but web developers who use other platforms know that’s just not the case. There are a variety of ways to embrace reusable code on the web, from the concept of jQuery plugins to third-party control vendors like one of my favorites, KendoUI.

Angular enables a new scenario known as a “directive” that allows you to create new HTML elements and attributes. In the earlier example, the directive for the “data-ng-model” allowed data-binding to take place. In my emulator, I use a directive to create two new tags: a “console” tag that writes the console messages and a “display” tag that uses SVG to render the pixels for the emulator (OK, by this time if you’ve checked it out I realize it’s more like a simulator). This gives developers their controls – and more importantly, control over the controls.

Our project has evolved with literally dozens of directives and they all participate in previous points:

  • Directives are testable
  • Directives can be worked on in parallel
  • Directives enable a declarative way to extend the UI, rather than using code to wire up new constructs
  • Directives reduce ritual and ceremony
  • Directives participate in dependency injection

Remember how I mentioned the huge grid that is central to the project? We happen to use a lot of grids (as does almost every enterprise web application ever written). We use the KendoUI variant, and there are several steps you must take to initialize the grid. For our purposes, many of the configuration options are consistent across grids, so why make developers type all of the code? Instead, we enable them to drop a new element (directive), tag it with a few attributes (directives), and they are up and running.

9. AngularJS Helps Developers Manage State.

I hesitate to add this point because savvy and experienced web developers understand the concept of what HTTP is and how to manage their application state. It’s the “illusion” of state that was perpetuated by ASP.NET that confuses developers when they shift to MVC. I once read on a rather popular forum a self-proclaimed architect declare that MVC was an inferior approach to web design because he had to “build his own state management.” What? That just demonstrates a complete lack of understanding of how the web works. If you rely on a 15K view state for your application to work, you’re doing it wrong.

I’m referring more to client state and how you manage properties, permissions, and other common cross-cutting concerns across your app in the browser. Angular not only handles dependency injection, but it also manages the lifetime of your components for you. That means you can approach code in a very different way. Here’s a quick example to explain what I mean:

One of the portions of the application involved a complex search. It is a traditional pattern: enter your search criteria, click “search” and see a grid with the results, then click on a row to see details. The initial implementation involved two pages: first, a detailed criteria page, then a grid page with a pane that would slide in from the right to reveal the details of the currently selected row. Later in the project, this was refactored to a dialog for the search criteria that would overlay the grid itself, then a separate full screen page for the details.

In a traditional web application, this would involve rewriting a bit of logic. I’d likely have some calls that would get detail information and expect to pass them on the same page to a panel for the detail, then suddenly have to refactor that to pass a detail id to a separate page and have that page make the call, etc. If you’ve developed for the web for any amount of time, you’ve had to suffer through some rewrites that felt like they were a bit much for just moving things around. There are multiple pieces of “state” to manage, including the selection criteria and the identifier for the detailed record being shown.

In Angular, this was a breeze. I created a controller for the search dialog, a controller for the grid, and a controller for the detail page. A parent controller kept track of the search criteria and current detail. This meant that switching from one approach to the other really meant just reorganizing my markup. I moved the details to a new page, switched the criteria to a dialog, and the only real code I had to write was a new function to invoke the dialog when requested. All of the other logic – fetching and filtering the data and displaying it – remained the same. It was a fast refactoring. This is because my controllers weren’t concerned with how the pages were organized or flowed – they simply focused on obtaining the information and exposing it through the scope. The organization was a concern of routing and we used Angular’s routing mechanisms to “reroute” to the new approach while preserving the same controllers and logic behind the UI. Even the markup for the search criteria remained the same – it just changed from a template that was used as a full page to a template that was used within a dialog.

Of course, this type of refactoring was possible due to the fact that the application is a hybrid Single Page Application (SPA).

10. AngularJS Supports Single Page Applications.

In case you missed it, this point continues the last one. Single Page Applications are becoming more popular for a good reason. They fill a very specific need. More functionality is being moved to the web, and the browser is finally realizing its potential as a distributed computing node. By design, SPA applications are far more responsive (even though some of that is perception). They can provide an experience that feels almost like a native app in the web. By rendering on the client they cut down load on the server as well as reduce network traffic – instead of sending a full page of markup, you can send a payload of data and turn it into markup at the client.

In our experience, large apps make more sense to build as hybrid SPA apps. By hybrid I mean instead of treating the entire application as a single page application, you divide it into logical units of work or paths (“activities”) through the system and implement each of those as a SPA. You end up with certain areas that result in a full page refresh, but the key interactions take place in a series of different SPA modules. For example, administration might be one “mini” SPA app while configuration is another. Angular provides all of the necessary infrastructure from routing (being able to take a URL and map it to dynamically loaded pages), templates, to journaling (deep linking and allowing users to use the built-in browser controls to navigate even though the pages are not refreshing) needed to stand up a functional SPA application, and is quite adept at enabling you to share all of the bits and pieces across individual areas or “mini-SPA” sections to give the user the experience of being in a single application.

The Best 10 for Modern Web Development to PHP Frameworks

PHP web frameworks have an ecosystem of their own in the world of web development. PHP frameworks are used to build websites and web applications of all sizes and complexity, ranging from small static websites to large scale complex enterprise content management systems.

PHP is the language of choice for web development with almost 80% of all the existing websites breathing on PHP code. It would have been next to impossible to create such a huge web footprint by developing web applications using raw PHP code from scratch. It is the power of PHP frameworks that has fueled such a massive growth.

Why Use PHP Web Framework?

When we look at modern web development needs, the key to success is speed development with well organized, reusable and maintainable code, all the while ensuring scalability. The best way to achieve this is by using an existing, proven PHP framework.

Frameworks offer ready to use components, libraries, enforce proven architecture, ensure separation of model, view and controller logic (MVC paradigm), abstract you away from the low level security concerns, enforce file and code structure, and the list is quite long. In short, PHP frameworks make web development fun and make you more productive.

These are the frameworks that are actively maintained, popular among developer community, promote modern web development practices and make it possible to build websites and web applications of all sizes and complexity.

Laravel

Laravel is undisputedly the king of PHP frameworks and spans the widths and depths of large scale web application development. Laravel ecosystem has quickly grown huge with supportive community and boasts tons of free tutorials and learning resources to get you started within no time.

Laravel is built to be simple, easy to learn and supports rapid application development. You get rich set of features to bring any large scale project to life within days. Laravel comes with its own templating engine named “Blade”. The best thing about Blade is that it allows you to write plain PHP in the templates which essentially means that Blade brings no performance overheads to your application.

Another power fact about Laravel is the inclusion of “Homestead” which is the packaged Vagarant box to let you start development without the hassles of installing web server, HHVM, PHP or any other package on your local machine or server.

New to the world of Laravel or PHP development, no problems, there is a dedicated website named Laracasts.com that hosts hundreds of PHP video tutorials. You can access the basic tutorials as well as most advanced ones to master Laravel at a very minimal cost.

Laravel team has recently released “Lumen”, a micro PHP framework for the web developers who like to build lightning fast API’s as well as Laravel based services.

Symfony

Do you have a very complex and large scale enterprise project at hand? If yes, then Symfony 2 is the one framework to get your job done right. Symfony ecosystem as a whole consists of large set of reusable components, vibrant and active community, Symfony framework and a philosophy to take PHP to the next level.

Symfony framework gets all the super powers from the reusable and decoupled set of components it packs within. The power features of Symfony components can be guessed from the fact that even the big brother Laravel utilizes many of Symfony components.

Symfony components fuel some of the largest open source projects like Drupal, PHPBB, PIWIk, OROCRM and Laravel, to name a few. Symfony components also power one of the most popular templating engine named “Twig”.

Symfony framework was first released back in 2005 as open source PHP framework by interactive agency Sensiolabs. Symfony framework is available under MIT license and can be downloaded from its github repository – Github.com/symfony.

Symfony vs Laravel

In Short, I would go for Laravel for large scale rapid application development even with lesser experienced resources, but, if it is about complex enterprise grade application development, my preference would shift towards Symfony, with more skilled developers.

Phalcon

Phalcon is another modern framework and my personal favorite. Phalcon framework is built for speed, it is a PHP extension written in C and arguably the fastest PHP framework available as of today. Even though it is an extension written in C, it is full stack MVC framework and offers most of the modern features like routing, controllers, view templates, query language, Caching and ORM etc.

The framework beats all other frameworks by margins in performance, is easy to learn, brings in all features to develop web applications of any size and complexity, and PHP developers are loving it.

Phalcon is among the frameworks that have seen success in a very short span of time. It was released back in 2012 under BSD license and is a perfect candidate to complete for the top slot in the world of PHP frameworks.

Slightly underrated at the moment, but that is only because developers are finding it hard to accept that a framework is delivered as PHP extension, and written in C. Phalcon, otherwise is very well document with examples and beginners can easily get started with Phalcon PHP framework.

Yii

Yii dates back to 2008 and is amongst the oldest of PHP frameworks. It was lagging behind Laravel and Symfony for last couple of years but with the release of Yii 2.0, it is fast becoming the preferred choice for enterprise grade web application development.

Yii 2.0 is a modern PHP framework with complete set of features to cater to the needs of modern websites and applications development. Yii also features a very powerful and best in class code generator tool called Gii.

Yii framework competes with none other than Symfony when it comes to building multitenant, secure and performant (powerful caching) applications that need complex workflows. CMS and CRM are among the categories where Yii shines along with Symfony.

Yii 2 community is very active, helpful and determined to take the Yii 2 framework to the next level. It also hosts one of the best documentation you will see in the world of PHP frameworks.

Yii 2 vs Symfony

Both Symfony and Yii2 are excellent frameworks and can deliver any modern large scale complex web application. I would personally select Symfony 2 for the shear elegance it brings on the table but at the cost of a bit more complexity. Yii 2 has more out of the box features, a little easier to grasp and can be selected for speed development instead of Symfony.

Slim

PHP developers love Slim for developing Restful APIs and services, thanks to Josh Lockhart for creating this tiny beast. The best thing about starting with a micro framework like slim is that you don’t need to spend time learning it. The code base is so small that you can run through the entire code in a late night session.

Slim is an open source, sophisticated micro framework that comes with URL routing and best in class middleware architecture. It also supports encrypted cookies, flash messages, page templates and caching apart from many other features.

Slim framework is best suited in scenarios where you want to build simple applications or API’s grounds up with full flexibility in your hands. Slim resides at the core of your application and you write the code around as required or plug existing components from other frameworks to create fully functional web application.

Silex and Lumen are two other frameworks similar to Slim that fall into category of micro PHP frameworks.

CakePHP

Another giant from the old times that doesn’t want to succumb in front of the most sophisticated modern PHP frameworks like Laravel and Phalcon. With the latest version “cakePHP 3.0”, this framework once again is back in demand and makes a definite point that it is here to stay.

CakePHP framework was originally released back in 2005 and is now available under MIT license. You can use it free of cost in personal, open source as well as commercial projects. CakePHP has held the spot of top PHP framework for a long time span and attracted corporates like BMW, Hyundai, Zumba and Express as its early users. Big names, isn’t it? That reflects the early life of this beast.

CakePHP 3.0 features enhanced session management, standalone libraries and decoupled components for better modularity, improvements in ORM and many helpers.

FuelPHP

FuelPHP is relatively new entrant in the world of PHP frameworks, specifically when we compare it with the old giants like Codeigniter, Symfony, cakePHP and Yii. FuelPHP is a simple, flexible, full stack modern MVC framework that supports HMVC as well at architecture level. FuelPHP has not been able to make a big impact ever since its release and doesn’t really have the biggest of fan following.

Having said that, there is a lot happening around FuelPHP lately and it is very actively developed and upgraded with new features. The framework at its core offers everything to build an end to end web application of any size and complexity. The future of FuelPHP looks quiet promising and I expect FuelPHP to gain grounds in the months to come and definitely plan to keep an eye on it.

Aura

Aura doesn’t compete with full stack PHP frameworks like Phalcon or with micro PHP frameworks like Slim. Aura is a collection of library packages where each package can be used independent of the other, in any code base.

Aura PHP framework is of particular interest and quite useful to PHP developers who love to write their code grounds up without starting off with a full stack opinionated framework. You can also plugin Aura packages to your application even if you are using any other full stack framework.

Codeigniter

Codeigniter is the one framework that has maintained itself well over the period of time, however, in recent times, it is seeming shaky against the modern and newly launched PHP frameworks. Codeigniter was created by Ellislab back in 2006 and made available to public for free use under MIT license.

Codeigniter has been the framework of choice for the reason that it was lightweight, fast as compared to other contemporary PHP frameworks and easier to learn. As of today, most of PHP beginners are attracted towards Laravel, Phalcon and even FuelPHP rather than Codeigniter.

Although, the framework has been among best of its times, “IMHO” the future ahead for Codeigniter doesn’t look bright. Ellislab also doesn’t seem to support it anymore and it is now fully in control of the community.

Let us see how Codeigniter shapes up in the days to come, read more about Codeigniter at -Codeigniter.com.

Zend PHP Framework

Zend framework has been around for 9 years now and would always be counted in the list of greatest PHP frameworks of all time. Many big corporates like BBC, BNP Paribas and Cisco WebEx use Zend framework in one or the other of their web projects.

Zend’s development team includes developers of the core PHP and ensures that framework is robust, complete and stable. On the other side, Zend is one of the most difficult frameworks to learn and has a very steep learning curve. Additionally, configuration options are enormous that simply increase the complexity.

Shall I go ahead with Zend Framework for my next project?

With many other simple and easy to learn frameworks around, Zend is a strict “no” for small to medium sized projects and for PHP beginners. Many PHP developers these days are moving from Zend framework to Laravel, Phalcon and other simple frameworks.