Choosing the right set of technologies to build your application with can leave you feeling overwhelmed, especially if you are getting differing and conflicting opinions about what to use from different developers. While choosing the right developer can be a daunting task in and of itself, what you choose to build your web application with has its own challenges.

The bottom line is every web developer is different; we all have differing levels of experience; and that means we’ll all have different ways of solving the business’ technology problems. It’s just like the rivalry between Microsoft and Apple, PC or Mac? Neither is inherently better or worse than the other, both have their pros and cons. Often this literally comes down to a matter of personal preference or what you already have started.

The best solution is to hire an Application Architect to solve these kinds of issues for you. There are many pitfalls in selecting technologies that I want you to be aware of as you move down this road to completing your project.

Technology Stack

Here is where a lot of small businesses get themselves into trouble with web applications. As if finding the right developer were not enough of a maze to navigate, using the right technology stack (meaning the right collections of web technologies) can mean the difference between success and failure; or at best success now but expensive headaches down the road.

I once got a call from a contract recruiter frantic to find someone who could rewrite an entire application. The developer this business chose decided to write the entire application in a language called Python and now this business could not find Python developers, at least not inexpensively, to continue work on his businesses web application. He was literally junking the entire application’s code base and re-writing it in PHP, another language much more commonly used for web applications.

As software engineers and developers, all of us are “siloed” into technology stacks that we are comfortable with and have a lot of experience with. But this also creates pitfalls for the business when hiring developers. Will the developer be using a technology stack that is common (less expensive to hire other devs to fix later on) or uncommon (meaning that finding devs to update the code will cost more because there are fewer of them around).

As developers we are all opinionated and biased to our particular areas of knowledge and what we use on a daily basis. What I say here would be argued with by any engineer because they don’t like what I’m saying. It’s how we are. But the truth is, you need to choose a technology stack that isn’t way out in left field, one that is commonly used by the majority of web developers today.

Here are some of the more common technology stacks:

Stack	Components	Commonality	Notes
LAMP	Linux, Apache, Mysql, PHP	Most Common	The most common and the one you should be using as a small business.
WAMP	Windows, Apache, Mysql, PHP	Common	The same as LAMP but running on a Windows server instead of Linux.
.NET	Windows, IIS, SQL, C# / F#	Common for Enterprises	Many enterprises running on Windows will be using some variation of the .NET framework and Windows technology stack.
MEAN	Mongo, Express,js, Angular.js, Node.js	Common	Mongo is a no-SQL database and is probably not be the best DB for your use-case. Also, frontend frameworks are popular but expensive to maintain.
MERN	Mongo, Express,js, React.js, Node.js	Common	The same as MEAN, only uses the React.js frontend framework.
LAMPy	Linux, Apache, Mysql, Python	Less common	See notes on Python below.
Ruby	Ruby on Rails	Uncommon	While still in use, very few developers are using this stack.
Java	Java frameworks and components	Common for Enterprises	Most enterprises will be running a Java technology stack.

 

Frontend Languages

Web pages that display in the browser are built using the languages of: HTML5, CSS (Cascading Style Sheets), JavaScript, and various asset files like images, fonts, etc.

There has been a push in the past decade by bored engineers at Google to add what are called frontend frameworks to the UI (User Interface) to solve what are perceived to be common issues and problems, like code organization. Actually, if you need a framework to organize your frontend code, you’re a lousy developer. You don’t need the framework to do that.

“The best part, is no part.” —Elon Musk

The point is you don’t need and should never need a frontend framework gumming up your UI—ever. While these UI frameworks are all the rage with the kiddies these days, all they do is add complexity without really adding any value. Yes, you can do some really whiz-bang stuff with frameworks, like DOM to model binding—oooh! (Yes, I’m being a bit sarcastic.) But at the end of the day, the whiz-bang features are not worth to additional complexity that you add to the application. It’s just one more cog in the pipeline waiting to break something later on.

Avoid flavor-of-the-day frontend frameworks.

Back in 2021 I created quite a stir among my fellow software engineers by posting a couple of articles on Medium about Why You Should Stop Using Frontend Frameworks and how Angular Is Costing Companies Billions. While a boatload of fellow engineers chastised and roasted me for eschewing Google’s sainted Angular frontend framework, the vast majority of private emails sent to me were just the opposite, people praising me for having the courage to stand up and tell the world that using a frontend framework is totally a waste of time and money.

You simply don’t need them. Feel free to read the above articles later to find out why.

“The more they complicate the plumbing, the easier it is to
stop-up the works.” —Montgomery Scott, Starfleet

When setting your technology stack, just tell your developer, you don’t want to use a frontend framework. Not Angular. Not React. Not TypeScript. Not Tailwind. Nothing but plain vanilla JS closures or perhaps the jQuery library is fine. Anything more than this and you are locking yourself into an expensive headache down the road.

As a side note, there has been a manufactured bias in the younger dev crowd against using libraries like jQuery. I even wrote an article about the rivalry: jQuery Will Still Be Around Long After Angular Is Dead. I use jQuery in every application I write because unlike a frontend framework, jQuery is a simple library that doesn’t need to be compiled and actually does same me time when writing code.

CSS Frameworks—Bootstrap is a must-have.

Bootstrap is a CSS framework used by every web developer on Earth. If they are not using it, fire them and find a real developer. Bootstrap essentially allows web applications to be mobile-friendly out of the box. When using Bootstrap properly, you can be rest assured that your web application will look and function just as well on mobile devices as it will on the desktop.

Avoid Pseudo-CSS Languages

A while back another group of really bored UI engineers decided they didn’t like how CSS was written and so they created their own forms (syntax) of writing CSS differently that allowed for better visualization, variables, things called “mix-ins” and other nonsense we as engineers really didn’t need. But languages like Sass and Less and SCSS took root and now engineers all over the world use these pseudo-CSS languages to write their code.

Avoid Anything That Needs Compiling

There are other pseudo-languages as well and they all have their adherents, dare I say evangelists, but they really don’t add value to the code base. They need to be compiled before they can be used in the UI. Compiling is a pre-process of processing this code before the browser can use it. Pseudo-CSS isn’t the only thing that needs to be compiled. TypeScript, CoffeeScript, and other JavaScript variants are all pseudo-JavaScript that also needs to be pre-compiled before they can be used. All this adds is unnecessary bloat to your technology stack.

Pseudo-CSS compiles to regular CSS. TypeScript and other variants all compile to regular JavaScript. So why not just write regular JavaScript and CSS to begin with? It’s all nonsense. Don’t use these. You’ll be much happier later on when it comes time to update your code and the engineer who saddled your code base with all this nonsense is nowhere to be found.

 

Backend Languages

I keep seeing these posts on Upwork where clients are asking for people who write Scala, Go, Kotlin, Swift, R, or some other “new” or off-the-wall language. Sure, many of these languages were developed for very specific industry use cases, but unless you’re in one of these industries, make sure your developer isn’t saddling you with an app built in a language almost nobody knows.

Colleges and universities have been teaching Python to their students for decades now—but still no one really uses Python for web development. Python is really better suited for more scientific types of applications and server management. If your newbie developer recommends you build a web application in Python because that’s what they learned in school, fire them and find someone who knows what they are talking about for business applications. No one is using Python for business applications.

Python people will tell you that Python is “the fastest growing language for web development.” Bullshit. I wrote an article on Medium torching this nonsense entitled Why PHP is Killing Python. The truth is, Python is used in less than 1.5% of websites on the worldwide web.

The fact is, despite the rivalry between Python purists and PHP devs who actually get stuff done, PHP is by far the more commonly used language.  (You can probably sense my inherent technical bias here.) Nearly 80% of the websites online today are running PHP and that is mostly because of WordPress. Facebook is written in PHP.

The fact is, you will ALWAYS be able to find a PHP developer and that means you will not be paying for someone’s specialization.

The most common backend languages you should be using to build your business’ web application are:

• PHP
• Java
• .NET
• Node.js

Avoid using anything else unless your use-case is so specialized in science or data that you need to use a particular language.

Backend Frameworks

Every developer you hire will be using a backend framework of some kind, it doesn’t matter the language, PHP, Java, Node.js, .NET, whatever. For Java the go-to framework is going to be Spring. It’s pretty much a given. For Node.js, it’s most likely going to be Express.js.

I’m sure there are others available that I didn’t mention, but you don’t want to be using them, if for no other reason that they do not have wide adoptions and not very many people are using them.

You want a technology stack that EVERYONE is at least somewhat familiar with.

PHP Frameworks

Which brings me to the PHP language of which there are several frameworks to choose from. I will give you my opinion of what to use and what to avoid. Another developer would give you the exact opposite opinion. We use what we like and what we know for varying reasons.

An MVC framework is one that your developer will need to configure from scratch out of the gate. A CMS is actually a fully functional app with user and content management already built-in and working.

Framework	Commonality	Type	Notes
Laravel	Very common	MVC	Easy to use. Popular with novice and mid-level experience developers.
Zend / Laminas	Common	MVC	Used more for enterprise applications.
Drupal	Common	CMS	Use more for small projects. Easily leveraged for all kinds of custom modules.
WordPress	Most common	CMS	In use by most small businesses. Easy to leverage for small web applications.
Symfony	Common	MVC	Used more for enterprise applications.

 

Typically, your developer will recommend a tech stack and/or framework they already know and like to use, but it may not be the best for your business’ use case. All of us will try to sell you on what we like because it’s what we know and like to use. We’re good with knowing our preferred frameworks inside and out and we will save you time rather than trying to learn a new framework.

You as a business owner need to take some part in the responsibility of choosing the technology that fits your business and the kind of application you want to build. In large organizations, this is typically the job of the CTO (Chief Technology Officer) or an Application Architect. But if you don’t have one of those, YOU get to play the part—or at the very least your lead developer will choose it for you.

Articles like this are designed to help you cut through the fog and understand what it is you are asking a web developer to build for you.

ALL of the above mentioned PHP frameworks and CMS’s are good to use for various use cases. All have their pros and cons that are much too technical to go into the details here.

Laravel is not a bad framework, but it has its issues, namely, it’s slow. I wrote an article a while back about Why You Should Not Use Laravel; again, lots of hate mail from the Laravel crowd, but also a lot of kudos from other devs for pointing out that Laravel, while cool to use and it does get stuff done, is not the be-all-end-all, especially for an enterprise development project.

---

---

Conclusion

As developers, we like to use what we know and sometimes that’s not the best technology for you to be using. Ask your developer what they intend to use for your technology stack. If it’s not LAMP, ask them why? You’ll get all kinds of rationalizations, but at the end of the day, your business needs a code base that you can hire most anyone to work on.

Developers will build what you ask them to using the technologies you specify. If you get pushback, fire them. It’s your money they will be wasting with unnecessary whiz-bang frontend frameworks or off-the-wall languages they like but no one else is really using. You’re the one in-charge. You will have this software for years and years long after they have moved on to screw up someone else’s project. Make sure you are using the most common technology stack that most anyone can easily work on.

Check out my other articles below that can help you with other aspects of your project as you move forward.

---

Up Next …

---