Marketing teams and designers have gathered around Webflow in recent years, as it allows teams to collaborate without the need to pull development resources away from your core product. Its CMS features took a while to mature, but when we started our redesign last fall, they were at a level where we decided to roll our blog into our Webflow site.
For most users, the CMS is great. Thereâs a WYSIWIG rich text editor and some surprisingly cool tricks you can do to link collection items together. Iâll admit it, you can accomplish much more than I expected once you wrap your head around the âWebflow way.â
One area where it really fails is with code block support. There isnât any. I donât mean it lacks syntax highlighting or customization, I mean they donât allow you to drop code blocksâlike the kind for engineering articlesâinto the rich text field. So what happens if you want to include code in a blog post? Thatâs where things get complicated.
Option 1: Third party embeds
When you canât do it in-house, you turn to third parties. Fortunately, the embed-a-snippet-of-code landscape is vast. You can use GitHub Gists, Codepen, or the handful of niche-specific services.
The workflow looks like this: Authors need to create individual snippets in the service, then backfill the embed code into the article. This is then dropped into Webflowâs rich text editor the same way you would include a YouTube video: using the editorâs embed block.

Itâs not flawless, but there are some benefits to embedding code snippets with a third party service.
- Fairly customizable, depending on the service.
- You can edit the code without editing the blog post, if needed.
- Code blocks have all the benefits of the third party tool, like revisions and commenting.
- More full-featured than static code snippets. You can embed full apps with some services.
Bearerâs journey from API monitoring tool to data security product means Iâve used the phrase âthird partyâ in the last few years more than I dare count. It also means I know the drawbacks of bringing in an external dependency. Some pitfalls include:
- Your code is now dependent on the uptime of others.
- Trackers aplenty! Many embeds contain tracking cookies, and if you care about user privacy, this is a big roadblock. This also means that ad and tracking blocking tools may block your code snippets.
- Itâs time-consuming to maintain and keep organized. Your source of truth is now in Webflow, while the code is in the external provider.
- Extra page weight from loading in the frameâs HTML, CSS, and JavaScript that comes with the embed.
Option 2: Death by a thousand copy/pastes
The next option is the one we currently use. It involves leveraging the embed WYSIWIG option, just like the previous method, but instead of dropping in the embedded code from a third party we wrap our code in pre and code tags.
Pasting code into an embed wrapped in the above tags wonât handle it all. You also need to use a syntax highlighting tool to make the code look nice. We use highlight.js. Our code-oriented pages include highlightâs Javascript library and the necessary CSS for theme colors. You can include these resources in the template itself to make things easier. Highlight.js attempts to detect the code type, but in many circumstances youâll need to manually define it as a class on the pre tag.Â

To make this easier on the admin side, I use a MacOS shortcut that takes in clipboard data and handles the wrapping and manipulation. This is ever evolving, as edge cases arise. You could also write a script to handle this, and if all of your content lives in a repo or text files it might be best to process it all at once.

This approach avoids many of the downfalls of option 1, but still isnât ideal. You have more control over the visual look, and can avoid any external tracking. You still have the added page-bloat from an external highlighting library, but that canât be avoided without pre-processing each code block further, the way some statically generated sites do. Youâll also need to manage any other quirks, like converting HTML entities, that the code embed services handle for you. I may end up wrapping all the functionality, and highlighting, into a pre-processing script, but that opens up new problems if the code needs to be edited later due to a bug or typo.
We chose this approach primarily from a privacy and control perspective. Weâd rather take a slight hit to workflow and features, but avoid the downsides of relying on a third party.
The big failure of both approaches: preview
Both approaches work in different ways, but they share the same foundation: the âcustom embedâ element. Webflow handles this element poorly. It feels like it is intended for running code more than embedding external content, and what weâre doing is clearly a hack.
This is most evident by Webflowâs preview. If youâve used their in-app preview before, you may know that it doesnât support Javascript very well. Animations not firing is a pretty common example that designers may run into. For content teams, this also manifests in pages that look like this:

Webflow wonât display embeds in previews. Whether for security reasons, or simply compatibility ones, there is no way to view your code-filled blog post without publishing it. We often do this by pushing to our test domain, but this too has a problem. Once you publish a blog post, it can no longer be scheduled for future publication. You can unpublish it to draft form, but the scheduling option goes away. This leaves you with two choices: accept not having a true preview, or accept the inability to schedule posts.
Where we go from here
There is one potential path forward, and thatâs through Webflowâs API. The documentation for which is limited, especially when it comes to uploading images with a collection item. That said, since many of our code-heavy blog posts start out as markdown, it seems feasible that with a little work we could POST the bulk of an article to their API and handle images manually if need be.
Waiting on Webflow feels like a lost cause. Theyâve scaled incredibly in recent years, and given that it sounds like they are happy with the feature as-is, I donât see much improvement in the near future. I didnât even mention inline code support, which is a problem weâve still yet to comfortably solve in our blog posts. While the CMS may work well for most teams, itâs hard to recommend Webflow for engineering or developer blogs.
Has your team found a better way of writing engineering blog posts in Webflow? Weâd love to hear about it. Let us know @trybearer or send @markmichon gifs of your tedious code snippet workflows.
â