The Golden Age of SEO is long over. They days when you could hire a specialist and get overnight results are gone. There were a lot of smart people out there who soon had the search engine algorithms completely reverse-engineered. With little expenditure, you could get yourself on the first page of most search engines that fast. Of course, this also produced a disruptive effect. Given it was that easy to rank so high, there was a short time when SERP’s (search engine result pages) were filled with garbage. If you searched for custom-built cabinets, the top of the first page was filled with ads for insurance companies and dick pills. It’s very reasonable to see why the search engines didn’t like this. However, there is one thing the SEO industry didn’t tell you. After you spent hundreds (or more) getting to the first page, by the time you checked your rankings a week or two later your great rankings were gone. You had to keep spending money in order to remain on the first page. This was bad news for small businesses, as only the larger ones with deeper pockets could persist. Then one day, Google started blowing it all up. What worked one day didn’t work the next.

Starting in 2011, Google started a series of algorithm updates code named Panda. They soon moved on to other updates with names like Penguin, Caffeine and May Day. The algorithms completely changed the way Google ranks sites. No longer could you spend a nominal sum and go from page 10 to page 1 overnight. Instead, they looked at other items such as the 1) quality of your markup and code, 2) page traffic, 3) backlinks, 4) URL structures, 5) XML site maps, 6) internal linking strategies and the list goes on. The rankings now weren’t only about what you didn’t do (blacklist techniques), but the quality of your page. One of the biggest items not mentioned above is content. Content is king, plain and simple. Search engines also want to make sure your business is active and going concern as opposed to a landing page or site. The algorithms look at social media, your post frequency and the form of your posts. (They like self-generated videos.) Things such as blog posts with frequent updates also matter. If you have a YouTube channel with custom content, that will go a long way to your rankings. I could go on and one, but you get the point.

This approach to page rankings makes sure SERP’s are of the highest quality, which plays well for the search engine company and the end-user. Many of today’s site quality issues are sufficiently solved with so many content management systems running websites. CMS’s such as WordPress and Joomla! are already built with great SEO features, and they easily allow you to do more. Same with sites like Squarespace and Wix. eCommerce CMS’s such as WooCommerce (WordPress plugin) are also well designed for SEO.

If you’re a micro business it could be bad news, but it depends on your industry. If you’re selling a niche item and have less competition, great. However, if you’re a small insurance broker it will be much tougher. In that case, you’re better off concentrating on geocentric rankings. No matter how you approach it, in addition to the other many other items a small business owner has to do on a daily basis, you must constantly update your online content to rank higher. The advice I give to small business owners who ask me about SEO is this: use a CMS and constantly update your content. Over time, you will learn how to do more and more with regard to enhancing your results beyond the built-in features. Unless your small business has the financial resources to hire a company or dedicated marketer, you’re on your own and that’s the truth.

When a developer is first starting out, the first things learned are almost always basic HTML and CSS. To be fair, that’s all you really need to know especially if you’re on your way to learning additional skills. Once you have the basics, increases in skill levels comes through the job. Unless a developer deliberately makes a focused, long-term effort to become truly advanced, they’ll probably reach an intermediate level and stay right there. I consider these skills to have four levels; beginner, proficient, intermediate and expert/advanced.

Even though I’ve been a developer/technology manager for nearly 17 years, I’m admittedly an intermediate level in the two. I must acknowledge at one time I thought of myself as advanced in each until I had to eat some humble pie. The truth is both HTML/CSS are much tougher to master than even many developers think. Most developers get to the point where most of the HTML/CSS they write is pretty solid, but it’s usually limited in scope. In other words, they do very well with what they know but are far from knowing it all to the point they can be considered expert/advanced.

In the case of CSS, just do a quick search for amazing CSS animations or designs. It’s gotten to the point where CSS is almost a programming language in its own right. Some of the CSS is so advanced, I don’t even know what I’m looking at and I’ve been using it for years! Most of the advanced designs center around CSS transitions (animation), but not everything. On many of the instruction videos I’ve often seen people demonstrate better ways of doing things I never knew. It doesn’t mean I’m clueless, it just means I’m not as knowledgeable as I thought. I just know what I need to know quite well, but there’s always room for improvement and more to learn.

The same holds true with HTML 5. It now has things like Web Storage, Web Workers, Canvas , Geo-Location tools, Drag & Drop and many more. I’ve only used one of of the features I just mentioned even though I’ve used HTML for all these years. I simply never had a need to know any of them. No project I ever worked on required most of them. So, you can see why most developers aren’t truly HTML5 experts. Even thought it’s not an official part of the HTML5 spec, a new development tool called HTMX is slowly gaining popularity.

If someone ever claims to be an expert in HTML/CSS, they’re probably more of an intermediate level. To be fair, intermediate skills are all they need to know in most cases. Also, I would never call out a developer for calling themself an expert in either or both. I know what they really mean.

The true expert/advanced people are those who use both as their primary focus on a daily basis. This is especially true of the online training gurus. In my case, I’ve always had entire separate technology stacks demanding my attention. Unless a developer’s job requires they focus at least 90% of their time to becoming expert/advanced at HTML/CSS, they’ll probably never get there.

There’s usually a better way to use HTML/CSS than even a lot of experienced developers know. Most of the time, advanced programmers don’t care to seek extra training on something they feel is a beginning skill. That’s where the humble pie is served.

Check out YouTuber Kevin Powell’s channel to humble yourself in the face of what you thought you knew well enough.

In fact, it’s just getting started. Let’s start by making a clarification: Typescript is NOT a programming language, rather a development tool. Its purpose is to make loosely typed language (javascript) into a strongly typed one. It enforces discipline by disallowing developers to cut corners or be straight-up sloppy. It’s much easier to be write bad code in javascript. Once devs get the hang of TS, which isn’t that difficult, they’ll all be converts. Look, if you need to do something quick & dirty, write the javascript. It’s no big deal. Depending on the snippet’s purpose and scope, just don’t expect to use it in production. I won’t go through the technical or operational differences regarding how each is deployed or the pros and cons of each. Rather, the bigger items are what matters most to management. Does it make the code base more reliable? YES. Is it very difficult to learn, causing the company longer and thus more expensive development? NO. Is it be difficult to implement? NO. Does Typescript receive regular updates and enjoy widespread community support? YES. Will some of the devs bellyache about it? Of course.

Exactly what is Typescript? It’s a superset of javascript. To illustrate: a developer writes the Typescript file and saves the it, which is then trans-piled (processed and output) on-the-fly to a javascript file the browser can read. That’s right, browsers don’t read native Typescript. FYI: the Typescript is maintained by Microsoft.

All the videos I’ve seen about people asking this question amount to nothing more than sour-grapes complaining. It’s level-red cynicism. Typescript does not allow the developer to continue with undisciplined practices and blatant laziness and they’re upset about it. (These are the same people who hate test-driven development.) Sometimes a developer outputs a larger javascript file than what they wrote in the Typescript file. This means it saved keystrokes, and thus time. Sometimes the opposite it true, which means the javascript file is usually more robust and not bloated. Either way, Typescript has your back. Much more often that not, Typescript-generated javascript is better quality than natively written javascript.

Again, Typescript is NOT dead. In fact, whenever someone declares a specific technology dead you should beware. People often say this and it’s usually untrue. How many languages were supposed to kill PHP? Cold Fusion, Ruby, Python, ASP.net, etc. It never happened and most likely won’t.

Do not let strong opinions and cynicism sway you. Stay objective and research it for yourself. There are two sides to every story.

A Dedicated Hosting Provider (DHP) is a web hosting service which specializes in hosting a specific Content Management System (CMS). The CMS can be WordPress, Shopify, Magento, Joomla! or any other number of countless CMS’s on the market. The other way to host a website is by using a traditional web server. Most of the world’s websites are hosted this way. DHP’s are a relatively new offering.

First, let’s discuss the pros.

They’re good for anyone without much, or any technical knowledge. They offer automatic backups which can be restored by the click of a button in case anything goes wrong. You’re provided with a list of incremental backups so you may restore the site from any point in the past. They also manage WordPress core updates/upgrades for you. If you’re running a simple (non-eCommerce) website, this is usually a welcome feature. Another advantage is they usually come with a Content Delivery Network (CDN). A CDN hosts images, files, video, downloads, etc. Since DHP’s are one-trick-ponies, they usually have better than average tech support. With a traditional web host, you’re mostly on your own. A traditional host does not offer CMS specific advice or support. If you build custom WP templates for a client, the site can be easily transferred to another account once you’re done. They also offer great out-of-the box security. Even though OTB WordPress is fairly secure, with a traditional web host some of the security “hardening” might fall to you. Most offer a free website restore if your site gets hacked. They also offer various other free services such as SSL certificate management, migrations, malware cleanup and demo sites. They also tend to be cheaper than traditional web hosts, but not by much. Finally, they offer great performance with automatic server load balancing and managed caching. This all probably sounds like a no-brainer, right? Not so fast. As I said at the beginning, they’re great for beginners. It also depends on what type of site you’re running. If you’re running an eCommerce site, a DHP might be good for getting started but sooner or later you’ll inevitably demand more out of your site as your business grows. A DHP may not be able to accommodate your growth, as this means you’ll have to perform more advanced activities involved in development and management. This is where it goes south.

Now, for the cons.

My experiences with DHP’s have been frustrating to say the least. When it comes to the more advanced requests, they’re can’t-do-it sort of places.

Example 1: We had a script that would take the site offline a couple minutes before our desired backup time (11:50 PM PST). This was to ensure no more orders were placed that day, and all that day’s orders would be on that day’s backup. Unfortunately, most DHP’s cannot schedule backups. Rather, they are automated at a random time of the day. While it’s not the end of the world, it’s not ideal. In the event you need to perform a backup, scheduled backups provided the best knowledge of what orders were placed and which were lost.

Example 2: We needed an SSH connection into our MySQL database for some ETL work. They couldn’t do it. There is a workaround, but it was not ideal for what we were doing. It doesn’t matter if there’s a workaround or not, we needed it to be done a specific way that would have easily been done with a traditional web host.

Example 3: They do not disclose server resources. With traditional hosts, you know the exact hardware configuration of your server. It’s usually shared, business class, dedicated or virtual private server (VPS). (All the cloud engineers will undoubtedly weigh in on this one, but were assuming the eCommerce site doesn’t have money-growing trees in their backyards.) Whichever server setup you have, if your store ever slows down you can balance all your efforts to speed it up against your known hardware resources. If you have a VPS running CentOS with 4G of RAM and an 8-core processor and your best efforts to maximize speed still aren’t enough, you know it’s time to upgrade the hardware. DHP’s won’t tell you these specs. They simply “increased your server resources”. But why did you have to call them in the first place? Why are they not monitoring load failures and adjusting resources dynamically? (Cloud engineers, there is where you chime in again.) When it comes to DHP server configuration, you have to fly blind. This does not work well with strategic decision making.

Example 3.5: We’re calling this 3.5 because it strongly ties into example 3. As the business grew, so did the demands on the store. We got integrated with our customers’ procurement systems, fulfillment center, accounting, a sales tax service, CRM, data warehouse and a custom form. These things demand server resources. One day we began receiving strange errors. After a tech support call, the rep “increased our website resources”, but wouldn’t tell me exactly what he did. He wouldn’t reveal what additional resources he allocated. It was frustrating to say the least.

Example 4: Although we didn’t have SSH access to MySQL, we did have SSH access to the web root. Every Linux jockey almost certainly has customized BASH or Z shell profile (BASH & Z shell are to Linux what c:\> is to Windows) to expedite workflow for longer shell commands. Well, DHP’s do not offer this ability. One on the most common aliases is ll (two small case l’s) which is short for ls -al. IOW, you simply type ll and it executes the longer command: ls -al. Not having the ability to customize the profile is just ANNOYING. While this is just a short command, there are much longer ones you must type by hand every time you run it.

Example 5: Every single DHP I checked didn’t offer SMTP (the ability to send email). If you’re running a store, this means you’ll have to sign up and pay for a relay service like MailerSend or SendGrid. So, add that monthly expense. If you go with an eCommerce DHP, they might include this but not necessarily. If you sign a contract, make sure you look into this.

Example 6: We had a page on our store containing how-to videos for some of our products. Everything was fine for a while until the DHP notified us the videos were using too much bandwidth, and we had less than a week to remove them. This was in spite of the fact they offered a CDN along with the hosting service! We had no reason to think it would be an issue, and there was nothing in the fine print about usage limits. We had to drop other priorities to find another way to host them. It was a significantly disruptive PITA.

Example 7: In the interests of fairness, this is more specific to the DHP we were using at the time. Nonetheless, it still serves as an issue you might run into. The DHP offered a staging site which is just a copy of the live site at a different URL for testing and development purposes. A long time ago, a developer set up the staging site with a custom URL. It worked fine for a few years UNTIL….one day it didn’t. It abruptly stopped working. The live site was fine, it was just the staging site we couldn’t access. From there it was back-and-forth tech support hell until they casually mentioned their staging service didn’t support custom URL’s. WHAT? If that was the case, they could have SAID SOMETHING BEFORE blindsiding us like that! They should have done an audit first and set out a warning. Instead, it required a complete re-set up of the entire site and it was a disruptive, time-consuming PITA.

Again, if your site is not eCommerce you have much less to worry about. However, if you’re selling things just know as your business grown you’ll probably outgrow a DHP sooner than later. For eCommerce, do yourself a favor and go with a traditional host.