Throughout the past four years, I’ve had the opportunity to work for a unique, design focused company called InVision. For those not familiar with InVision, it is growing to be the operating system for digital product design. Its product line provides tools for designers, developers, and stakeholders to collaborate on designing and building websites, mobile applications, and almost anything else that is displayed on a screen.
The entire company is dispersed across the globe with people across all continents and in almost all time zones. There is no central office, but some make use of coworking spaces like WeWork. All communication happens on Slack and meetings take place on Zoom.
I’m a designer turned web developer that specializes in front-end applications. As an advocate for best practices and proper schematics, I believe that the web should be open and accessible for everyone.
I’ve struggled for years to get a decent blog up and running. It wasn’t because of the lack of content, on the contrary, it was the design aspect that was the obstacle. I designed countless mockups and developed fully functioning prototypes but they never entirely made the cut. I was so critical of everything I designed; I always found something that I didn’t like, and then found myself rejecting each concept.
This post features my challenges, frustrations, and why I ultimately landed on using Hugo as a static site generator to build my blog. The past three iterations of this website were written using Hugo, Next JS, and then back to Hugo again. Hugo gave me so much out of the box, and practically everything I needed, whereas Next JS, required me to write the functionality I wanted explicitly. This article is not meant to hate on any frameworks and instead voice my own experience.
I took the challenge to build a likes button into this blog. Since the site is compiled and then deployed as flat files, there is no backend or database to manage. From a security aspect, there is no safer way to develop a website, but it does add a bit of complexity to incorporate dynamic content.
My first attempt was to add Firebase as a dependency and wire it up to the likes button. This worked great as it gave me real-time updates across multiple browser sessions whenever I clicked the button. However, looking at the compiled, minified bundle, I noticed it had added over 220 KB!
Simple front-end applications I’ve worked with have one event (click, keypress, input change, etc.), which dispatches a single action to modify part of the application state tree. At the time your application scales in complexity, that single event may need to perform several actions at once and perform some sort business logic before they are dispatched.