Authorability is a key contributor to the success of the JAMstack. Despite the JAMstack's superior performance in speed and relative cost over other methodologies, the mass adoption of the JAMstack hinges on its ability to operate in a cross functional team where not everyone is technical.
Content today is incredibly advanced. Thanks to the growing popularity of visual storytelling where text is combined with interactive visuals and compelling graphics, content authors must deliver stunning content experiences to keep users engaged. This entails authoring content that seamlessly blends text with different forms of media like charts and images. In the realm of the JAMstack where raw content is generally represented as markdown, authoring such "rich experiences" is a challenge. This is largely because content is decoupled from code in a typical JAMstack setup and there is huge disparity between how content is created and how content is displayed.
A rich authoring experience demands collaboration between code and content. This way, content creators can craft content that supports the work of developers and vice versa. MDX is one way in which this becomes possible. MDX is a file format, parser and loader that extracts and renders JSX components inside markdown files at build time. Compared to conventional setups where markdown is not configurable beyond injecting HTML directly into files, MDX gives content authors and authoring tools direct access to exposed JavaScript components. When used alongside a design system, developers and content authors can collaborate while still maintaining their relative independence.
The tablestakes for a rich content experience on the JAMstack is high.
Only with developments in authoring can the JAMstack become the defactor standard for modern web development. For more on MDX as a rich content experience, check out this fantastic talk by Josh Dzielak at JAMstack conf London
Top comments (3)
You absolutely can. I use gatsby to create dashboards in my work. Most of my focus is in building out Data Pipelines, but when I need a dashboard many times its driven from json that gets dumped onto s3 as a kind of static api.
I typically just load these dynamically with axios rather than routing data through gatsby. I still get wicked fast performance and the data is updated without rebuilding the site.
Thanks for all the ❄ #Jamuary articles BTW. I have enjoyed them.
Interesting, I've never thought of using Gatsby for dashboards but I'm sure it works for that purpose! Are you routing data in through axios instead of Gatsby because of performance?
More for agility right now. The sources are decoupled from the front end and I want to have live data without continuously rebuilding. Maybe in the future I'll have better ci/cd that would allow for more frequent rebuilds.
Anyways most of the data I am using at the moment can be aggregated down, put into json, and gzipped into sub 100kb files. It is still really responsive, 99 perf in lighthouse.