July 26, 2017
Recognizing that issues exist is only the first step in a long journey; actually finding a solution is the hard part. But as it turns out, the solution had already been created. In fact, it had been created even before CMSs like Joomla and WordPress had been invented! The answer is static websites, which are not generated by software on a server. Let’s break it down. with something like WordPress, the CMS is acting as the intermediary between the server and the user; when you visit a WP site, the browser requests the page, WordPress pulls the information, such as text, images and whatnot from its database, then uses predefined layouts from themes, plugins etc…to generate workable webpage from all that information that is then sent to the browser. In a static website, either the page is manually created, or generated using static-page-generation-tools. Either way, since the actual generation is done in advance, when your browser sends a request to the website’s server, the only thing the server needs to do is send the pre-generated files to the browser, rather than running through the entire fetch-generate-send process. This approach offers some pretty major benefits that directly answer the issues discussed earlier. For one, a static website hugely increases wetite security; many hacking attempts take advantage of exploits that allow them to ‘inject’ their own code into the CMS’ or website’s code, but in order to do this there needs to be actual code being run. In a static website everything is, as the name implies, static; no code is being run, only the generated website files are sent to the browser, making the site nigh-impossible to hack without gaining direct access to the server. Secondly, since a static website doesn’t demand any additional operations to be run by a server, such as compressing PHP code or connecting to a database, to generate the final content it allows for significant improvement in load speed and optimization. Compare the speed of a fully-optimized dynamic website: …/smashingmagazine.com with its faster static counterpart: …/smashing-static.netlify.com
Why is WebriQ using Roots?
The short answer is because roots was built very specifically for static site builds, so it’s cleaner and better than general purpose build tools, since it’s specialized to that purpose. The longer answer is that it’s a qualitative thing. Much like people would ask “Why should I use snapchat when I can just text a photo” or “Why should I use slack when I already have hipchat?”, there is no logical answer other than that the experience is different, and in my opinion, much better — tailored exactly to what you need. So just try it, and you just might find that you really like it.
WebriQ CMS is bridging the GAP between Static Site Generators and Flat File CMS Systems. The days when a brand only needed one website to house its online presence are long gone. Today, webinars, events, pop-up shops and product promotions all require their own microsites or landing pages. When we moved into what some call the post-CMS landscape, the usage of static site generators and Flat-file CMS and Static Site Generator functionality overlaps in many ways ; so how do you choose between the two?
When we moved into what some call the post-CMS landscape, the usage of static site generators (SSGs) and flat-file CMS for these microsites (and at times for lightweight corporate sites), grew. And now, with the headless CMS hype in full flow, the interest in these front-end solutions is returning.
Once you signed up and have your site created on our APP you can freely integrate