Wait. Do you mean you hired her to handle all of the JavaScript or you don't want to use JavaScript at all?

Fuck Richard Stallman. The man is a grade A bellend who has no idea about how the world works.

GTFO! Seriously though, you're right. Very few projects require a JS framework and even then, a lot of the ones are used on could probably use jQuery. Too many devs use a tool because its cool rather than it being the best fit for the needs of a project.

@loserboi – If you've never used one before, start with Vue. It's easy to pick up and will give you a good idea of whether your project needs a JS framework or not. You'll soon start learning where the boundaries of Vue are, and at that point – and only at that point – start investigating Angular 2 and React. The reality is that very few projects will benefit from React or Angular 2, so there's no point in diving into them until you need to.

@tamar "-1 bears"? That QAs going to get a nasty surprise if that worked haha.

You be screwed if the investigator had JS disabled. Be better hiding it like:

body {
display: none;
visibility: hidden;
}

Headless Ecommerce (Motlin)
Brilliant for having complete control of your site, but you do have issues with being beholden to their feature set if you can't extend them. Not got too much experience with this.

Legacy Content Management Frameworks (Drupal/Joomla)
Just don't. These were great once. They've since been surpassed by far more modern, specialist frameworks.

Self Hosted Ecommerce (Magento/Opencart/Prestashop/Bigcommerce/Woocommerce)
Complex, headache inducing, but often hugely powerful and extendable. Watch out for some solutions' issues when it comes to security, database set ups and just god damn strange fucking coding decisions and complex code for the sake of showing off rather than making my job as a front-ender easier (I'm looking at you Magento 2).

Often need large teams and come with huge expenses in development, addons and maintenance.

Hosted Ecommerce (Shopify)
Great when you don't want to worry about server or security stuff. Also excels when it comes to cross-channel stock management thanks to its EPOS stuff. Limitations come in from its use of liquid and the inability to run it locally – cowboy coding all the way.

Blogging CMSs (WordPress/Ghost)
These excel at their core purpose – blogging and media publications. However, WordPress in particular is expensive to maintain and keep secure. Not an issue if all you're using it for is a blog, or you're a media organisation.

NB for WordPress 'specialists'. I don't care how many plugins you have that make it look and act like a 'real' CMS. It's still a blogging platform. The WordPress Foundation and Automattic both recognise this.

It only became commonly used because it was in the right place at the right time and was most people's first experience of editing content online. It was then bastardised and stretched beyond its original purpose to manage blog content because people wanted to be able to edit the rest of their sites as easily.

Template-based small CMSs (Processwire/ModX)
Great if you plan on templating everything in a site, but kind of defeats the purpose of having a small CMS in terms of minimising screwing around hooking in a site.

Modern Content Management Frameworks (Perch Runway/Craft)
These are amazing tools if you're looking to build a large site with a lot of different content that aren't necessarily just blogs.

These two are my go to for larger sites with complex needs and requirements.

Tag-based small CMSs (Perch/Couch CMS/)
Great for retrofitting existing HTML sites with a CMS or building small sites. Perch is my personal favourite. If you've never used a tag-based CMS, they work by using tags to hook just what you want to be editable into a CMS. They don't mess with your markup or output.

Great for when you want to get the benefit of handcoding everyline of HTML or make use of a framework like Foundation/Bootstrap/Bourbon without having to fight with the template output of other CMSs.

Also work really well with design-based tools like Adobe Muse in being able to add functionality to sites build using visual tools.

Business benefit: Lightening fast (most of my Perch sites hit 99/100 on Pingdom Tools tests), ability to control every aspect of markup means extremely SEO friendly tools and often the CMSs are extremely user friendly.

Flatfile (Grav/Statamic etc)
Great for situations where you need lightening fast sites and don't want the headache of a database. Have limitations in terms of content processing, though Statamic in particular does well at scale. Not really something I'd recommend unless there's a specific need for avoiding a database.

Business decisions that might guide that are security concerns, for example. However, you then have the issue of data being stored – potentially – as plain text. Like I said, only really useful in some situations.

Cost of implementing – especially if you don't work with them often (i.e. time to get your head around them) can make them costly to implement.

Static (and I don't mean static generator. I mean pure, handcoded with no database)
Small biz & tradespeople. Primarily get business from referrals. Website is simply there as a brochure and isn't updated more than once every 3-6 months, if at all.

It simply isn't worth building a database or CMS into these sorts of sites. The time it would take a dev to git pull, edit, commit, push and deploy is far less over the average life of the site than it would take to implement a CMS and maintain/keep secure any database.

Not worth the hassle for dynamic content sites (blogs), but you can split the responsibility for different parts of sites between static and a blogging CMS.

Static site generators (Jekyll, Middleman etc)
Developer blogs or blogs the developer maintains. I know they're amazing, but they're only really user friendly to devs who are fairly experienced. Also, they're not great for huge sites/busy sites where the rebuild can take a site offline for a significant period of time.

Right. Sorry about not getting this up at lunchtime. I had to shoot back from the office to let the dog out and didn't get a chance to finish off writing this up. This isn't going to be comprehensive, and it's going to be limited to the CMSs I've used (for example, I've never used any .NET CMSs so apologies if I miss them out).

So. This will be a long one. I'm going try and break it down by CMS type (simply because there's too many options out there).

Here it comes. It'll be broken down because of the limits on the post lengths.

@practiseSafeHex Haha. I will. I'll list some examples at lunch time (in about 4-5 hours). Promise.

@biscuit There is no 'better' CMS, so to speak. Each project has its own needs and KPIs. The best CMS is the one that meets those needs and KPIs. Sometimes it's WordPress. Most of the time though, it probably isn't.

Often you'll find that the decision of which CMS to use is based on what suits the person building the website. And I use the term 'building' deliberately. Because many of those choosing WordPress are doing so because they can't code and they have access to tools that enable them to build sites without knowing what they're actually doing.

@spencerbeige

You do realise that a huge amount of a web developers work on Apple computers?

To expand, it's a dig at how over-engineered some things are in some open source projects.

There's been a couple of instances lately where the same goal is achieved in propriety apps with a single function and intelligent use of arguments. The open source code on the other hand requires a ton of conditions in the view template. It's the difference of 1 line vs 15 lines to do the same thing.

And it's not like the propriety software doesn't have those conditions. They're just hidden away in the function. For me, elegant, intelligent code is code that requires the end user (in this case another developer) to use the least amount of code possible to achieve the desired outcome.

All to often, I've found that that isn't the case in *some* OSS. Rather the logic is front and centre, screaming "hey y'all! Look how clever I am"!

Not all OSS projects fall into this category of course.

A couple of the agencies I've worked at could do with learning that. Designers design. Developers code. If the job involves coding, you're a developer. Mixing them up only serves to devalue the hard work and effort each discipline has to put into the role.

I don't know...

UI guys are usually design only. I'd be more concerned with their design skills than their knowledge of coding. This would be like asking me what is the difference between an aspirated engine and a naturally aspirated engine.

The correct answer is it has fuck all to do with my job, so why are you asking me it?

To be fair, with Redstone coming out this summer, there will be a Windows Linux. Sort of...

I'd seriously question anyone who claims to be a developer and then states you should minimise the number of plugins or put functionality into themes. The number of plugins are irrelevant; it's what the plugins are doing that's important. It's like saying you should only use three functions at most.