On our last episode of Static Feedback, I spoke with Joost van der Schee about ‘Artisanal Web Development’, the approach he takes to solo web development projects. Over the course of our conversation we talked at length about the importance of knowing the purpose and scope of each line of code, and the value of approaching new projects like this.
Joost interprets this approach as deliberately avoiding frameworks that ‘simplify’ code by including predefined classes and functions that are shipped client-side, even if they’re not used. In principle you’d think these frameworks would be helpful, and they certainly can be, on the development side. The trouble is, unless they’re pared back with additional tooling (like PurgeCSS, for example), even well designed and developed sites can bloat significantly.
When you’re working in teams, or handing off a site to a client developer who’s going to continue working with your front-end project, the most important thing to do is find common ground. This might take the form of a carefully scoped framework or a handcrafted component system, or code that you construct specifically for your use case.
Our conversation is above if you haven’t seen it, but we discussed three major arguments in favor of artisanal web development:
If you avoid frameworks and third-party code your websites will usually be considerably smaller, and will thus load faster for users. And generally speaking, faster page loads means happier users!
If you know the purpose of every single line, you’re much more likely to be able to make small tweaks and adjustments to the site. If you’re working on a client site, it’s particularly important to know which aspects of the site are easy to change, and which would require additional development time.
Developers are typically life-long learners — it’s one of the most exciting parts of the job, and it’s hard to argue against the benefits of learning more about the code you ship. Unless you’re extremely time-poor or don’t see yourself making more websites in the future, the return on investment for learning the limits of your code will make the effort worthwhile.
Further to this point, your own learnings will accumulate to the point that you’ll want to record them for later use, making you a more efficient developer while also helping others following in your tracks. Joost, for example, keeps track of the common solutions he encounters on his community sites, Hugo Codex and Jekyll Codex.
As he notes in his own follow-up post, your own understanding of every line of code can even make you a better user of web frameworks, because you get a better understanding of the problems that these frameworks are trying to solve.
As Joost has pointed out, over the course of our conversation there were a few other important benefits of the artisanal approach that we didn’t get to discuss.
Anyone who’s maintained a WordPress or Drupal site for longer than a few months at a time will likely be familiar with the concept of ‘dependency hell’, where a single out-of-date or broken plugin or extension can cause problems with other components. The artisanal approach tends to result in more stable projects, because it only relies on web standards that simply don’t change.
Third-party code in ‘black box’ containers like WordPress plugins — or indeed any externally hosted code — can be a huge risk from a privacy point of view. If you can’t see, understand, and approve the code you’re relying on, you might risk exposing user data or opening up your sites to attacks like cross-site scripting (XSS).
To be clear, the artisanal approach is a deliberate constraint. It’s a set of rules you define, and can choose to apply to yourself, or to a given project. Like most constraints, though, it does promote creativity — and often the most creative solutions emerge from rigorous constraints.
The open-source search tool Pagefind is a prime example of development under constraint, while also solving a distinct problem. In its case the constraint was network traffic — why ship a large search index file to every user, when indexes can be ‘chunked’ and served atomically, on demand?
The artisanal approach, then, is about making your websites both performant and sustainable, in the sense that they’re able to be maintained under a given set of constraints. Your constraints may be different from project to project, depending on your client, or you may bring a set of rules with you to each new site build.
No matter how permanent we might wish our sites would be, as Jake Albaugh writes, our code is always transient. Luckily, our best code can be the code right in front of us, and the best website we can make right now is the next one:
If you can justify the effort of writing your own code, you become more familiar with web specifications and learn just how robust they are on their own. You also end up with something that can be easier to maintain long-term because it is closest to the core evolutionary path of the web.
As long as you have a very clear idea of who you’re developing for — of who will work with your code, and what their level of knowledge will be — you’ll know whether the artisanal approach is right for you. But as Joost writes, it’s worth trying out on your personal project sites
Joost and I focused on knowledge in our conversation on Static Feedback, but we could have equally described the artisanal approach in terms of deliberate simplicity in development. Bringing these two concepts together is where a Git-based CMS like CloudCannon comes in — because CloudCannon is tightly integrated with the ways that your chosen SSGs build your sites, we’re able to offer much more flexible development and editing workflows, whether or not you prefer to take an artisanal approach to your code.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。