Picking a technology to develop expertise and sell services

Note: This is part 2 in a series about making technology decisions. Read part 1 here.

Just like doing a client project, we apply DevOps to the decision-making process. Don’t start with a blank slate – start with something, anything, apply the requirements, and iterate.

We start by keeping current – reading technology news, listening to technology blog posts, talking to people at conferences, over IRC, in forums and newsgroups, so we are aware of what is out there that people are talking about. We defer making a choice until we have a problem we actually need to solve, that is not a good fit for our current technology stack, and then we write up a list of requirements, and take the top 3 or 4 platforms on our radar to evaluate against that list.

And we pick one for a pilot, try to complete the project. If it works out well, we run with it. If it does not seem as good as we thought, we might switch if we have reason to believe another alternative might work better. When we settle on a solution, that’s it – that becomes our go-to answer for this particular kind of problem.

But we keep our eyes and ears open on the alternatives. Once we have chosen a technology, we won’t switch without a compelling reason. But if there is a compelling reason, and we don’t see a downside, we won’t hesitate to switch.

Example 1: Joomla, WordPress, Drupal

Way back when, as our web development practice was getting started, we actually were a Joomla shop (originally Mambo). We built somewhere around 150 sites in Joomla, but we were starting to reach a point where the projects we wanted to do were a better fit for Drupal – particularly because of its role-based authentication model, instead of the access level model that Joomla and WordPress used.

When we got a particular project that we decided should be in Drupal, we went out and hired an experienced Drupal developer to lead the work. This jump-started our Drupal expertise – suddenly we had an in-house expert who trained the rest of us in Drupal best practices, along with a ton of gotchas we avoided as a result. Over the next couple years, we found that Drupal not only did Joomla sites better than Joomla, it also did a better job of e-commerce, surveys, generic webforms, workflow – and we were able to stop using ZenCart, OS Commerce, LimeSurvey, and a bunch of other one-off solutions we had built and deployed for customers – Drupal was the Swiss Army knife that could do it all, pretty well – and the biggest benefit being how well all this functionality integrates with everything else.

The nail in the coffin for our Joomla work was maintenance. The “drush” tool for Drupal, along with the ability to upgrade existing sites through code deployments and scripts, along with the ease of running different site copies, has long put Drupal on top of the “big 3” PHP CMSs (which we considered at the time to be WordPress, Joomla, Drupal).

Why not WordPress? WP is a pain to run different copies – every time you move a WordPress site, you need to fiddle with the database. We did actually build a few sites in WP before it became popular – right after it forked from its predecessor – and liked it fine as a blog but didn’t find it powerful enough for the sites we were building.

We chose Drupal about 10 years ago for a bunch of reason, and most of these still apply, most have improved:

• PHP is the language we know best

• It solves a huge variety of problems, accomplishes a broader range of client goals than nearly any other CMS out there, and does particularly well integrating diverse goals into one site

• It is easy to make steady changes right down to the data model as needed, it is incredibly flexible and able to keep up with changes to business requirements – few other platforms support changing requirements as well as Drupal

• It has excellent support for being managed from a shell, it is very scriptable

• Drupal 8 (and moving forward, 9) solves the biggest downside to Drupal – expensive major upgrade projects. (We plan to support upgrades from 8 to 9 as part of our regular maintenance, with no extra charge!). This has made the project pass a threshold of maturity that it never had before, which I think changes the game going forward

• Excellent support for localization, multi-lingual sites

• Big focus on accessibility, supporting WCAG standards

• Drupal 8 adds web services to the core, lots of support for building and consuming APIs

• Large, devoted community supporting the project, DrupalCons have sold out for a decade, are up over 3000 attendees, dozens of $10M+ agencies

• Popularity is waning, I think largely due to repeated sticker shocks of major upgrades, but in all other respects the project is better than ever

Example 2: Front end Javascript frameworks

My first significant Javascript work was done in the days of IE 5 – I built a prototype report browser for a telecom software company using XML and the XMLHttpRequest object – what came to be known as AJAX after Google Maps and Gmail came out and showed the world what was possible. In 2006 or so, I evaluated the current crop of Javascript toolkits, and picked Dojo as the best one to learn.

Jquery quickly became the market leader, but it never did the data storage and state management that Dojo had from the beginning. I met the original author of Dojo, Alex “SlightlyOff” Russell, at OSCON in probably 2005, and since then he has become one of the most influential Javascript thought leaders out there. In Dojo, he developed a Flash-based local storage API long before that became standard in browsers – after leaving the Dojo project he joined Google where he was one of the people responsible for making LocalStorage a standard that all modern browsers now support. He was behind the “ChromeEngine” IE plugin, which embedded Chrome inside IE for corporate users who could not run Chrome directly… He’s now one of the authors of the new WebComponents standards, which is trying to bring React-like components directly into the browser – it’s on a standards track now.

All this to say, Dojo was the BetaMax of toolkits, technically way better and more forward thinking than anything else out there until Angular came along, which inherited and modernized much of what was in Dojo 10 years before.

Today, we consider 3 JS toolkits to be at the top of the heap, largely in terms of market share: React, Angular 2, and Vue.js. Given that Dojo still exists, but is no longer relevant, a couple years ago we made the decision to switch to a modern toolkit. Here are the basic factors that went into our decision:

• Market share – how much market does the platform have?

  • How many developers?

  • How much demand?

• “Likeability” – how much do the current developers love working with it?

• Freshness – how much has the toolkit learned from what came before?

• Size

• Speed

• Range of use, flexibility

• License

Based on reading what others had to say, React wins on demand and developer share. But Vue.js wins just about everywhere else – Vue.js is smaller, faster, can be deployed as an individual element on a page instead of taking over the whole page, can be more easily integrated in existing pages, is easier to learn, and developers using it love it. And it’s on a very rapid growth curve right now – already has more stars on Github than React, although only somewhere around 2% of React’s userbase.

So when we got a small project for an existing client that needed a good front-end toolkit (a Kiosk page to run on an iPad for check-ins and a couple tracking items on a website) we built it in Vue. We had already built a flashy demo destination site with some unused client budget, and since then we’ve gone on to develop a payroll app using it, and a handful of other rich interfaces.

[Note: this article was originally written in early 2019. Since then we've added Svelte.js to our technology watch list!]

Read on about picking a technology for a client project