Is Web Development Dead?

Personally, I’d give it about 5 to 7 more years, maximum 10. I’d even kill off web design alongside it. I am talking about website development, specifically where the developer is concentrating on writing code that manifests directly on a website, rendering HTML and Javascript.

Web development is a broad term though because API development that manifests as JSON data across HTTP requests could also be considered web development.

When web design was a top role for designers, about 12-15 years ago, it was because design demands were rooted in print design. This was before mobile phones were a viable browsing tool, so you could bank on having consistent screen sizes. This was also at the time when broadband for the home was common enough that the average person could view a complex website that was so abundant with a skeuomorphic design that the bandwidth requirements were high, but the quality was high as well. As a result of complex design, web development was also a dominant role, because it was a lot of work to develop alongside that complexity of the design.

But as mobile device usage has grown, and the separation of concerns from websites being king, to instead a combination of websites, apps, and other services, the website’s need for being gloriously designed decreased. Given that we continue to have an increase in device variety, this trend is not going to reverse itself. A simple, clean design is best suited to auto-adapt to the variety of screen sizes and types that will be available for decades: visually, this is all the way from a wristwatch to a billboard.

Based on that, the majority of website development has already shifted to more data-centric work, above design-centric. If I’m viewing website content on my computer, the design might matter to me. But when I switch to my phone, design (at least, heavy graphical design) is only going to get in my way. The design components that will matter on my phone are color, typography, readability, etc. There will still be a need for designers, but far less than what we needed a decade ago, and certainly less than we need now. Designers will need to branch into more cross-device creative direction than simply “website design.”

And developers are already heading that way, by avoiding design and focusing on API development, which is critical for driving website content while also driving the two other most important technologies needed right now:

  • Apps, which are currently manifesting primarily as mobile apps, but which also include voice-activated apps, and VR apps (through independent devices like what Google tried with Glass), and
  • Integration, which is the data-sharing aspect of API development that allows the data from one app to be integrated with the service of another app to provide suite-like features across disparate systems.

When a design is needed, most of the existing frameworks can already handle 95% of the design needs a company has. What we’ll be lacking though, unless the trend changes, is qualified business experts who can properly capture web application needs from business owners to develop solutions that fit company requirements. The demand will be on making custom applications at a fraction of the cost of what it used to be. The more APIs there are out there to perform the functions we need, with integration at their core, the more a website is just going to be a clean merger of technologies from a variety of sources, and design is going to remain minimal, because that same content needs to adapt to varying phone sizes, a watch, a lens over my face, an audio interface reading back to me, VR projections from a headset, and so forth.

So web design and development as we know it today, is going to be mostly gone within a decade. API development, app development (in many forms) and systems integration will be the primary focus.

Understanding Dependency Injection using PHP

Dependency Injection is a software design pattern that allows avoiding hard-coding dependencies and makes possible to change the dependencies both at runtime and compile time.

By using Dependency Injection we can write more maintainable, testable, and modular code. All projects have dependencies. The larger the project the more dependencies is it bound to have; now having a great number of dependencies is nothing bad by itself however how those dependencies are managed and maintained is.

Dependency Injection is not a new pattern and it has been commonly used on many languages like Java, but this pattern is somewhat new in the PHP world and it’s gaining traction quickly thanks for frameworks like laravel

Let’s exemplify these concepts by creating a pair of classes first without dependency injection and then rewriting the code to use the dependency injection pattern; I’ll be really original (wink, wink) and create a Product and a StockItem class.

StockItem.php

Product.php

At first glance, the code looks pretty normal and it’s what many PHP developers would call good code, however, if we take a closer look at it using the S.O.L.I.D principle we can see that the code actually has many problems:

  • The StockItem is tightly coupled with the Product class, and while this might not look bad on this particular example. Let’s imagine that we made a change to the StockItem class to include a new parameter, we would then have to modify every single class where the StockItem object was created.
  • The Product class knows too much, in this case, the stock status and quantity, let’s say that our application can handle inventories from multiple sources and stores but for the same product. With that in mind, it would be in our best interest to make the Product class know less about its inventory.
  • We just made our life harder when it comes to unit testing the code. Since we are instantiating the stockItem inside the constructor it would be impossible to unit test the Product class without also testing the StockItem class.

Let’s Inject something!

On the other hand by using dependency injection we can correct most of these problems, let’s take at the same code but using dependency injection:

StockItem.php

Product.php

Constructor Injection

By using dependency injection we have a more maintainable code, in the previous example, we are using a type of dependency injection normally referred to as Constructor Injection. By doing a simple change we can reduce the level of complexity of our code and improve the overall quality; not to mention that now we can easily run unit tests.

Constructor injection is by far the most common method used and there are several advantages of using this particular type of injection:

  • If the dependency is required by the class and cannot work without it, by using constructor injection we guarantee that the required dependencies are present.
  • Since the constructor is only ever called when instantiating our object we can be sure that the dependency can’t be changed or altered during the object lifetime.

These two points make Constructor Injection extremely useful, however, there is also a few drawbacks that make it unsuitable for all scenarios:

  • Since all dependencies are required, it’s not suitable when optional dependencies are needed.
  • While using class inheritance trying to extend and override the constructor becomes difficult.

Setter Injection

Another common type of dependency injection is called setter injection and the same code as above would look something like this:

StockItem.php

Product.php

As we can see, with Setter Injection the dependencies are provided to our class after it has been instantiated using setter methods. Setter Injection has a few advantages:

  • Allows for optional dependencies and the class can be created with default values.
  • Adding new dependencies is as easy as adding a new setter method and it won’t break any existing code.

Setter Injection might be more suitable for situations where more flexibility is required.

So is Dependency Injection right for my application?

At the end of the day is up to each developer the one that has to make the decision about what design patterns are the right fit for his application be it Dependency Injection or something else; that being said from personal experience using patterns like this might be an overkill for smaller projects.

But if you are working on a large and long-running project, then there is a good chance that dependency injection might the right solution for your project.