The Switch to Static Websites
Is static is the future?
With everyone, including ourselves, switching over to static based websites - you'd think they were the next big thing next to Node. Despite their flexibility, software packages like Wordpress end up providing too much bloat for specific solutions. Static based systems break away from the restrictions and pitfalls of a database and lay the sitemap out visibly for developers and editors to easily manage. It's a huge transition, and it's definitely faster in most cases.
But is it the future? You'd definitely think so with multitude of websites and publications switching over to static site generators like Hugo or Jekyll. With anything though, there are limitations and disadvantages.
The major flaw with most systems? They're generators, not an actual CMS. Meaning we had to design our own admin interface, and editing files meant rebuilding the entire site (making iterating frustrating). Not only that, most are built on Python, Grunt, or some other language that requires a custom server setup (beyond the basic LAMP hosting companies offer). You can build an API for apps and 3rd party services, but it's still hindered by PHP needing to render from the server (vs Node spitting out data directly from the server). And it scales, but only as well as your structure allows.
In our case, it's a win win. Faster website, easier to manage, and flexibility. We can easily pump out new iterations of the website, fine tune elements, and experiment until our right brains melt -- and it's as simple as editing a couple of files here or there. No fussing with child themes, creating plugins to alter core processes, or creating massive backups of databases and excessive files. New version? Copy paste the folder on the development server, and simply upload when it's ready for production. No need to build or generate any files (like Hugo sites), and we get the benefit of data without the remote server placement.
Further reading
