One of the most challenging things about website front-end development is choosing a technology or a tool to help with delivery, internal efficiency and client satisfaction. There's a lot to balance and test to make sure we have a solid solution that's agnostic of the backend technology being used, as well as the context of the project. It's certainly been a journey and continues to be one as we improve our front-end stack. I believe what sets Verndale apart from other front-end groups that I've been a part of is our passion to never fall behind in our technology stack, and our outright refusal to accept that we need to slow down in our evolution.
Our goal is simple - provide static assets for the backend to implement. No matter what the backend stack is, they should have an easy way to grab our compiled HTML, CSS and JS to integrate to their solution. There are tools out there to help us with this: user interfaces that organize your components, modules and templates. As an organization that may be working with Verndale or looking to learn from our experience, it's important to understand our evolution and how we got to where we are with our building process and bundling stack.
The ultimate goal for us is automation. We try to remove the "human" in any way we can in our process of delivering assets, documentation, and testing. One of the ways we have accomplished this is choosing the right bundling tools and continuous integration tasks.
Before I get into the tools we have used previously and currently use today, I will say that our front-end code is in a separate repository than our backend code. We do this for a number of reasons. We treat front-end code as a product that we deliver to the backend using semantic versioning and automated changelogs. This makes what's being delivered in a particular build very clear and easy to create release branches. This gives us the ability to separate our solutions and develop faster. We are basically creating static sites and delivering production ready assets to the backend team.
We got here from an organic evolution of the most popular front-end build tools. In the beginning, there was Grunt. We implemented Grunt and Webpack together to run a simple, local dev server to develop our static site. Grunt is simple to use - it's a bunch of plug-ins and configurations. When the backend needed to implement a new module, we would have to manually run a build command to compile our assets and deliver a distribution folder, which the backend would have to dig into to find specific HTML. This accomplished what we wanted at the time, but as the tech became smarter, we did too.
We didn't jump straight to Storybook - we experimented with Fractal first. Fractal is similar to Storybook in that it gives us the ability to develop and deliver renderings in an organized manner, as well as gives us documentation. Fractal works great for reusable component creation out-of-the-box. We ultimately went with Storybook because it just works better for us with the modules we were creating. Storybook also works better out-of-the-box with our current tooling, so we're able to integrate with it more easily. Although some aspects of our applications are reusable, and for that Fractal still plays a role, many of the applications require creating complex and custom modules per client. So Storybook wins this one.
When we're happy with the way it looks, we create a story out of it that renders it in Storybook. We have a "stories" folder in which we keep all our stories. We follow a simple interface to create a story and add some editable fields to it. This is an example of a simple input component. We've exposed some editable fields in the "argTypes" object. The end user of Storybook will be able to change these fields on the fly and see the changes in the input field immediately.
We also expose editable fields and parts of our modules so that anyone can play with it and test it in any way they want.
Storybook organizes these components and modules in folders if there are different types. This gives us separation of concern. CMS content authors are able to build their pages like Legos, so this is a very appropriate way to visualize these renderings.
Storybook is self-documenting out-of-the-box. One of the most valuable features of Storybook is the backend developer will click "show code" on the right and it will give them a small snippet to paste into their solution and their renderings - no more digging around the compiled HTML template. We also make fields editable that will change the properties (eg: for the button in this screenshot). This allows the front-end, backend and QA to "mess" with the module and test it with different properties applied. We're an all-inclusive company when it comes to development, which means we consistently create experiences that are AA-compliant. Storybook gives us a way to quickly test accessibility per module. We can easily see the passed tests and the violations.
We host the Storybook instance in Azure Storage to allow our internal team to navigate the work via a URL. We also have build and release pipelines enabling us to run our build manually, run through our linters, upload compiled files to Azure Storage, and push everything back to our repo. There is no more manual process for handing assets to the backend team. We simply push to our develop branch and a build and release build gets triggered.
We're always looking for ways to improve our build process and our tooling. Switching to Storybook, getting rid of Gulp, and adding continuous integration are huge steps towards our technological goal in our front-end department. You can count on us to always be looking for ways to evolve. When it comes down to it, we're striving to make huge moves to improve our efficiency, which will give us more time to focus on our quality and ensuring our clients are happy with their experience. If you'd like to learn more about our process, or if this makes you as excited about the future of development as it does for us, reach out and let's talk.