This week we’re trying out a new format for the “Dev Diary” videos
Myself and @ben dive into how AI is shaping web development, moving to Tailwind v4, and why the Elements Store is such a key part of the platform’s future.
We also talk about long-term sustainability, how optional purchases help fund ongoing development, and share some honest thoughts about the bumpy transition from Classic to Elements
Watch or listen below to get the full story from behind the scenes at Elements HQ:
We want your feedback
Let us know what you think of the new format, and drop your questions for next week in the comments.
FYI: “Flash” is a nickname given to me as a chef. I tend to work fast all the time, even when it’s not necessary. No time like the present.
I am a business owner and as such I understand priorities, like building and completing the store. Keep going and get it done.
The idea of building a site design in Elements is great. As you mentioned, the ecosystem has potential, especially with third parties being able to fill in the gaps.
My preference for long-form support inside Elements rather than the CMS is based on the following:
Flat-file HTML/CSS/JS
Avoiding the ongoing expense of the online version of the CMS
I’d like you to try building a page with 800–2,500 words. Add one or two images that flow using media queries, include multiple headlines, lists, block quotes, and simple tables—and make sure everything is responsive, as mentioned earlier.
Perhaps this is an opportunity for a third party to step in, especially if you’re committed to not providing a full native long-form solution in Elements. If you’re a third party and interested in developing this, please reach out to @dan or @ben. If there’s a clear commitment that this solution will never be provided natively, I’d be willing to pay for it if it’s done right. I @flash have a specific but concise list of features that would make it excellent for writers—for example, a “writer’s mode” in the typography component, just like this one in the forum. When you preview or hit publish, it simply works based on the theme settings. Not true WYSIWYG, I know, but exactly what a writer needs in a distraction-free environment.
To be direct: yes, I could move to a competitor like WordPress or SoftPress Xway—but is that really the message you want to send while building your business?
Sorry guys, but you’re just not getting it. You insistence upon “just lay out a bunch of components as you go” or “use the CMS” for long-form writing is getting annoying. Typography is broken. You’re going to actually drive a lot of folk, ironically, to WordPress (which is a CMS).
You keep pointing to “blog,” but that’s not the only way long form things get created or their function. Consider the situation of a site with permanent side bar/nodal attributes and a long form read of some sort that needs to be on the same page. I simply don’t want to be designing when I’m writing, nor do I want those I work with doing that, either.
So you point to the CMS. Sure, but it’s not finished or fully documented and subject to change, which makes it impossible to commit to. Moreover, the CMS is mostly for multiple articles doing the same thing over and over (e.g. blog). What if I have just one long-form thing I want to put on a page. That is a thing.
So I have a solution ;~).
Create a new component that’s Single Markdown item. You create and position the MD file the same way we currently do for the CMS. But when you need that single file you just bring in a Single Markdown component, then point it at the MD file. That way I can separate all the design work from the writing work (which I currently do in One Markdown and then move the resulting file into my CMS pile).
I sure wish we had something like this. I have been wanting it ever since I started the BETA program at the very beginning. But for some reason, the Elements devs think that Markdown support is not WYSIWYG enough for Elements.
I wish we could get Will Woodgate to port his markdown stack to Elements; it was the one I used the most in Classic.
I’m not sure i followed that. Are you saying/asking for a blog component that can simultaneously format on a page like a newspaper instantly? Around other random content.
I specifically did not say what I wanted from Tailwind v4 because I wanted to be very general. But @ben touched some of the things, like 3D transforms and numerous other ones as well. But there are also a lot of properties in v4 that seem to make things easier in a custom component.
With regards to long-form text. You mentioned the ability in Elements to break up long-form content into distinct blocks to accomplish what you need. That is perfectly valid, but my feeling is that it completely misses the point of the argument for long-form text. For me, this means the ability to keep your embedded content tied to the context of your writing. Think more along the lines of a layout program where you have a lot of text that is sprinkled with images and other content tied to specific parts of the text. These apps make it very easy, allowing you to manage relationships using a variety of techniques.
Sure, we could break this up in Elements, but because there is no way for text to flow from one typography block to another, this becomes very cumbersome to manage. Sure, not impossible, but just not productive. This is the main reason I have always advocated for Markdown support, as it allows you to accomplish this easily with Markdown.
Anyway, I’ll stop there.
I look forward to more of these talks, especially those focused on custom components and how anyone writing them can better integrate with Elements to provide the user with a consistent experience when working with a custom component. I want any custom component to feel like a core component to a user.
The problem I see with creating things like this that would be well suited to being part of the core package is “Sherlocked”
Meaning of “Sherlocked”
In developer or startup slang, to be Sherlocked means:
Apple (or another platform owner) copied your app or feature and built it directly into the operating system, making your product obsolete.
Origin
The term comes from Apple’s “Sherlock” search tool in the late 1990s:
A third-party developer created a Mac app called Watson that extended Apple’s Sherlock search utility with extra features (like weather, stocks, dictionary, etc.).
In macOS 10.2 (2002), Apple added nearly all of Watson’s features directly into Sherlock.
Watson quickly became irrelevant — it was “Sherlocked.”
I assume you’re referring to the risk taken on by third-party developers, and then later having RM Sherlock it in whole or in part. If you read my initial post, this is exactly why I mentioned Dan and Ben. I understand there’s precedent for that being a possibility.
I am not understanding the need for one long post?
Can you elaborate?
Why not break it into sections?
The way I ‘got around’ it was to initially take my 365 songs webpage and turn onto one massive block of html - but I - at the time didn’t want to re link 365 songs to Google Drive…
Google Drive has since removed my ability to link the songs, and I’m self hosting them at DreamHost.com
So I’m starting over - will do 20 songs a day with the new media player…
It would be nice if it was stock in elements - don’t get me wrong - but not a deal breaker - for me…
Each page ranges from 800 to 2,400 words and includes multiple content variations, such as lists, headlines, blockquotes, small tables, and images. The layout must render responsively while maintaining consistent structure and readability. Internal linking is implemented in a deliberate way to strengthen topical authority and improve SEO performance. Because the target market is highly competitive, every element must follow a precise structure and optimization method; otherwise, the effort produces minimal return.
Standard blogging approaches, along with basic category and tag setups, don’t provide sufficient SEO value in this type of market. A defined content architecture with strategic internal linking achieves stronger and more reliable visibility. While I could technically handle configuring Elements block by block and managing the optimization myself, it makes more sense to have the component perform the work correctly from the start.
Spending one to two hours per page on manual adjustments that could be completed in ten minutes is not an efficient use of time. When multiplied across 300 initial pages—and several hundred to a thousand more over time—the lost hours become significant. Since each page already requires three to eight hours of research and writing, efficiency and accuracy in execution are critical.
As always, Gary, this sounds like a wonderfully helpful tool. I feel it is essential that the custom components we create include as many of the core properties as possible to provide a consistent user experience. Being able to use something like this would indeed eliminate a lot of the tediousness.
Hopefully, when we have the new store, you could consider making it available for purchase.
Meaning of “Sherlocked”
Origin