Originally Posted by
Synthaxx
You seem to be throwing these terms around but misunderstanding that they're not the same. HTML is a markup language that is understood by browsers. The other is a CMS that takes an inbound request, retrieves information from a database (example), performs some parsing, and then returns HTML to the client that made the original request. I've never heard anyone bad mouth HTML -- I've heard people bad mouth Internet Explorer and how it's often awkward to code for, but that's a different topic.
A CMS is a tool, HTML is a markup language. They are not the same. All CMS will produce HTML, but not all HTML is a CMS. While we're on the subject, CSS is a markup language, and JavaScript is a scripting language, but neither of them are CMS. I'd argue neither of them are tools, but we're onto semantics at that point.
For example, I use an environment known as node.js to build web apps, and even normal websites. I code almost entirely in JavaScript/JS. Even my HTML isn't strictly HTML, but I don't have to worry about that as it sends the HTML that a browser can understand to the client that requested it.
HTML does not interact with SQL databases, does not interact with websockets, and does not do anything functional. It tells a browser how it should display a web page, it's layout, and usually the content. Javascript can interact with websockets as it's a scripting language. It can interact with SQL databases too, but this itself is a much more complex topic than is in the scope of this discussion.
On the subject of what would I choose;
I would choose whatever your experience level dictates. I don't know if you know how to write HTML (it's not that difficult), or if you simply want a solution that's ready to go, but go with what your experience allows.
As for me, If I was choosing anything, I'd always go for the option that ticks the most boxes for me. I haven't used anyone else CMS for many years simply because of the range of exploits out there, and that keeping up to date with patches while not breaking everything was always a headache. Plugins being exploited and taking down your whole site isn't my idea of fun.
These days, I custom build almost everything. At least a few times every week, I see random attempts to access pages that don't exist in the hopes of exploiting vulnerable software running on my server. The usual ones are for wordpress, but since I don't run wordpress, there's nothing for them to exploit. Because of the frameworks and tools I use, I'm able to access all the nitty gritty information about every request coming into my website. I can choose how I log things. I could even build my own heuristics to do something based upon a visitors previous history (e.g. if they're scanning for vulnerabilities, I could block them, or lure them into a faux-honeypot).
It's not just the security side of things, but the community surrounding it, the language it's coded in, and the sheer range of modules out there that let me interact with other services. If you can think of it, someone's probably written a module for it, and if not, it's usually not difficult to write one yourself. The ability to decide how things click together is why I take this route.