A Website, A Deadline, and Gatsby
Having witnessed commendable growth in Big Data Analysis and Security last year, the time had come for us to showcase our accomplishments. In other words, we needed to update Staqu’s website.
Soon enough, the collective consciousness of the holy trinity (Design, Front-end, Back-end) had come up with an efficient design. Although it took us a few meetings, the result was quite appealing.
Fast forward to getting our hands dirty, the front-end warriors were pondering over the framework and libraries to keep the website as light as possible. With a shared affinity to React, we wanted to build an SEO friendly static website which held its integrity regardless of resolution.
Hence in addition to our arsenal; Gatsby Js.
Although static sites come with fewer security risks and make them more performant, large static sites could become difficult and time-consuming to maintain compared to a web server. That’s when static site generators like Gatsby Js walk in to make things easier. Since it makes use of the latest and popular technologies including ReactJS, Webpack, GraphQL, CSS, modern ES6+ and JavaScript; we knew our choice won’t be something we would second guess.
Gatsby for Us:
Gatsby is built upon a popular tech stack and was easy to get our hands upon. To make things fun and efficient, Gatsby gives us hot reloading and built-in code-splitting; hence better site performance and great development experience.
Evidently, it allowed us to write minimal tooling configuration so we could focus entirely on rapid site development and nothing else.
Things We Loved:
Webpack Bundling: Webpack creates minified bundles of HTML, JavaScript, and CSS. As it is pre-configured with Babel and several plugins; it gives us more power to develop with all the modern features available.
Components: A key feature of React and a commonly followed web design pattern, it is probably the best part of Gatsby as a static site generator. Modern user interfaces tend to get complex and it is tedious to write maintainable code in long pages of HTML. We kept our components streamlined and followed best practices for a more organized codebase.
Styling: Our first preference for styling was SCSS and since it is supported by Gatsby, it was a breeze to bring the designs to action.
Responsiveness: With no reloads between pages using gatsby-link, the site appears smooth and performant thanks to lazy-loading images and code-splitting regardless of the device screen.
Of course, integrating our React experience helped us build fast for rapid testing. Although it has to be stressed enough that our website is content-heavy.
There aren’t any huge data sets or tricky plugin integrations, for now. And apart from a couple of IFrames for social media embedding, we haven’t included any third party links. Since the beginning, we knew our primary focus had to be on representation and had planned accordingly before diving in. Which leads me to the final point:
Our Two Cents:
Gatsby stands out when it comes to creating beautiful and visually appealing static websites, but keeping in mind that ours wasn’t a complex app it’s better to think through and be careful in choosing your tech arsenal if there are heavy data interactions involved. Also, the difference between running something in Develop mode and running the same thing in Build could never be anticipated. We ran our builds regularly and used a Netlify server to check everything, hence ensuring periodic meet-ups of The Holy Trinity are essential.
As to our deadline, we decided it’s better to follow the established convention:
“The first rule of a deadline is you don’t talk about the deadline.”
Do check www.staqu.com to see what we made.
Go break some eggs; happy developing!
