4 ms·
Ask HN: Why did dynamic CMSes become the norm?
I have been using static site generators for a while, and with Netlify, the convenience seems unparalleled. Just do a git push to publish. Although I understand a non-technical person would find it hard to deal with a version control system, I can't think of any reason why more tooling can't develop to address that concern.
Static sites have incredibly low overhead (hosting-costs wise) and are very reliable—you can be reasonably sure that a random plugin or high memory usage won't pull down the whole site (a pervasive issue for anyone dealing with WordPress).
That brings me to my question. Why did dynamic CMSes like Wordpress become the norm? It's not like static site generators couldn't exist in 2003 when the CMS was first released.
- viraptor 8y agoI think it's somewhere between the tooling and designer market. I can get a theme for any kind of business for wordpress in minutes, get a plugin for dealing with any kind of service integration, and point a non-tech person at the admin panel - done. Even though I use static sites normally and I'd definitely use that for a personal, technical business, I didn't even consider that as a possibility when setting up a service for someone else recently. Also, there's middle ground: edit wordpress, publish static - https://wordpress.org/plugins/simply-static/ https://wordpress.org/plugins/simply-static/
- superasn 8y agoI think it is because of the plugins. A lot of non technical users like to install plugins like Yoast Seo, Content lock, etc that require some sort of backend code in order to run. Not sure if that can be fully done with a static cms.
- quantummkv 8y ago> I can't think of any reason why more tooling can't develop to address that concern. This is what a dynamic CMS basically is. Tooling to work around the deployment process of a static site. WordPress became the norm because of its plugin system and its ability to scale. Creating a static site works well if you are a developer capable of writing the code or a single person writing nothing more than a small blog. A system like this would not scale, for example if you wanted to add some dynamic content such as comments or an e-store. At that point your static site simply falls apart. For a non-developer, writing or getting someone else to write all that code is an expensive proposition. WordPress, even with paid plugins, is way much more cheaper and hassle free for the job. And the WordPress admin page is a website accessible from any device with a web browser and does not require a setup of development tools on said device.
- cimmanom 8y agoWhat was revolutionary about the blog 15 years ago was the comment system. In 2003 you couldn’t embed something like Disqus on your blog. If you wanted commenting, it had to be dynamic. The same with other features like trackbacks and pingbacks. And search. Upload speeds were also a consideration. If you wanted to update hundreds of pages and upload them all, that could take an afternoon. Finally, version control was far more clumsy than it is now. Subversion was basically the most advanced option out there, and there was no Github equivalent to host repositories. There was no S3 back then. $15/mo got you all-inclusive shared hosting at a flat rate, and it included PHP and MySQL whether you were going to use them or not. It wasn’t cheaper to host a static blog - at least not at the outset. Your average blog wasn’t pulling enough traffic to have any sort of resource problems even in shared hosting; and there were caching plugins you could install that could scale traffic if your site got popular. If that still wasn’t enough, you would get enough advertising to cover the cost of a VPS or maybe a managed dedicated server.
- hluska 8y agoThere were static site generators in 2003. Dreamweaver and FrontPage were the big names, but there were many many more. With the tooling of the day, simple tasks (ie - adding a new page to a main menu) were error prone and time consuming. Some early ssgs offered templates and includes, but they were complicated for nontechnical people to setup and use. Version control sucked so in the wild, most Dreamweaver sites lived on one person's computer. If that computer's hard drive crashed, panic ensued.
- m-localhost 8y agoDreamweaver was pretty nice (compared to the mess that Adobe GoLive was) and definitely close to what static site generators are doing today, just with a gui. It was really awesome, when I discovered Dreamweavers dynamic templating, because at that time, I had no clue how to get PHP and MySQl to work. Now that I know everything about PHP and MySQL I have a hard time understanding node.js (beside grunt) etc.
- hluska 8y agoI had managed to forget the hell that was GoLive. Fuck you!!! :) (I kid) I had a hard time understanding node.js too. I'm old enough that I remember when jQuery was revolutionary and it really hurt my JavaScript for awhile. Then, I built something non trivial in vanilla ES5 and now, I'm okay with node. I still don't always understand the ecosystem, but the JavaScript community is not for mere mortals like me to understand! The point is, there's hope, if you want there to be hope. Otherwise, PHP and MySQL are very useful, so if you're happy where you are, you've got a good set of tools behind you. Keep having fun!
- open-source-ux 8y agoThere are lots of cases where a simple static site generator won't work well. For example: - company intranets which need different editing permissions for different users - blogs that want a 'subscribe' feature where users can get notified of new posts by email (not via RSS) - blogs that want to allow comments - password-protecting parts of a site A lot of static site generators recommend third party services for some of these features (e.g. Disqus, Mailchimp) - a messy solution that is arguably a worse experience for users who now have to contend with being tracked by third-party sites. We used to have static site generators before WordPress became popular (e.g. Moveable Type). Today's static site generators simply aren't user-friendly. Maybe friendly to the developer, but certainly not to end-users.
- CM30 8y agoWell, it comes down to a few things really: 1. These CMS systems made it easy for non technical users to add or update content. That's important given that for these people, even stuff like Git is seen as confusing and archaic, whereas 'go here, use an editor that looks a bit like Microsoft Word, publish' is easier to get the hang of. 2. Many popular systems like WordPress and Drupal ended up creating a large ecosystem around plugins, themes, etc. So for a non technical user, it was easier to just download or buy a plugin/theme that does what they want rather than have someone code it from scratch or bridge it with another system. It also led to companies where their only skill was to either build CMS plugins/themes or to install existing ones, and those companies then had a good incentive to suggest the same system for their future customers. 3. Shared hosting was/is still easier to understand for many people than a VPS or AWS might be. Even now, what do you think people are more likely to understand? Press a button in a tool like CPanel to auto install a CMS or manually set up a static site generator themselves? Stuff like Docker or containers or Git or SSH or whatever else all seem like black magic for many smaller development agencies, let alone end users who have no idea what a CMS actually is. 4. If you wanted dynamic features (like a comments system, poll, user login/account setup, etc) then you needed a CMS or programming knowledge. Hell, even today you need one of those if you don't want to be stuck relying on a third party service for your website. Do you trust Disqus? I sure don't. 5. Finally, I guess popularity just begets popularity. People like jumping on bandwagons, and once WordPress started growing in popularity, that meant a whole bunch more people wanted to use it as well.
- jimnotgym 8y agoI was thinking about the performance troubles of Magento, and thinking about how all of the product pages in the site, and the home page and category pages could be pre-rendered as static pages, and then the filter pages could be built dynamically...and if after a change the CMS could re-render the static parts in the background that had been changed...it's not like other changes to Magento are instant, due to all of the cacheing