It’s finally here! Part two on building our new site in Gatsby. This one took a bit longer than I intended, because while we initially launched our site with we called internally our V1 component set, we were still working hard on upgrading a bunch of V2 components and miscellaneous upgrades.
Those are now complete (-ish; are we ever really done?), and we’re ready to talk more about what our experiences building with Gatsby were like.
JavaScript frameworks aren’t going anywhere. While many developers, including myself over the years, have scoffed at the over abundance of JavaScript frameworks, they’re not going anywhere. The likes of Angular, React, and Vue.js are developing into mature, enterprise ready frameworks, and it’s time to get on board.
That doesn’t mean our transition to GatsbyJS, and it’s React-yness, was all warm and fuzzy, however. With the move to JavaScript frameworks, it quickly becomes apparent how truly nightmarish dependencies can quickly become.
On the plus side, if you can think of it, someone probably wrote a module for it.
On the down side, if you can think of it, someone probably wrote a module for it.
What does that mean exactly? Well, because as developers, we often find ourselves repeating common patterns, there’s a whole world of available modules and packages that reduce the amount of re-work we have to do. But while it may save some upfront cost on developing a new module, it also means you have to be hyper-aware of the packages you’re pulling in.
Why?
Because, as I covered in our first post on security, updates are king. If a package you pulled in hasn’t been maintained, seriously consider whether or not you truly need that package. Maybe even dig a bit deeper on it’s source to make sure it looks tip-top, and if it’s not, contribute back (that’s the whole point of open-source, right?).
So while the NPM ecosystem at this point is fairly mature, we did still keep an eye on all the dependencies declared for each Gatsby plugin, as well as any of the NPM module we used.
There is no doubt that modularity when it comes to applications is the future (and that it’s here now). JavaScript systems like Vue.js, React, and Angular, are were created in an effort to better create re-usable, and modular, components.
As more and more CMS’s arrive that let content authors do what they do best (read: content), developers are continually trying to come up with better ways to serve that content. Whether it’s a web page, inside an app, or even feeding another companies app (hello, Open Graph tags and Schema), content should be available for whatever platform you need it to exist on.
So when we set out on building with Gatsby, we thought a lot about how we could make re-usable components. While part of that was to feed my own innate curiosity on what could be done, it also sets some really important ground work for things we’ll be doing next as a company.
That said, building a modular, component based UI wasn’t a cake walk. Here are somethings we initially struggled with:
You know what the best part of static site generators are?
Static files you can host anywhere, for virtually nothing.
We use Netlify, because we love it. We host a bunch of single landing pages for clients there, as well some other projects, and we’re floored with how easy they make managing front-end experiences.
One-click deployments, automatically staged branches, form integration, and more make for an experience that reduces the amount of time we have to spend spinning up new infrastructure, and that gets an A+ in my book.
Before this starts sounding even more like a glorified pitch for Netlify, I encourage you to check
Coming Soon (TM), with system wide dark mode capability.
That’s all for now folks! If you have any technical questions about Gatsby, or comments about development in general, feel free to send them my way at steven@eightfold.io