Interested in guest writing for Frontend Masters Blog? It\u2019s always a win-win-win.<\/p>\n\n\n\n
\nWrite the article you wish you found when you Googled for it<\/p>\n<\/blockquote>\n\n\n\n
Would you<\/em> be happy to land on this article from a search? Are you speaking to me, developer-to-developer, from experience? We want you to sound like the developer you are, talking to other developers you respect. <\/p>\n\n\n\n
Teach the reader and empower them to code what they learn independently rather than relying on third-party tools! If you link to third-party tools, ensure the reader knows how or where to find out how to do the same for themselves\u2014encouraging a first-principles approach. The blog empowers and informs the reader, not making them reliant on third-party tools and services.<\/p>\n\n\n\n
Don’t use AI to write the article for you. We get so many submissions that are clearly bland, flat AI generated writing. It’s obvious and it’ll never get published here.<\/p>\n\n\n\n
<\/a>What you should write about<\/h3>\n\n\n\n
We\u2019re looking for technical<\/strong>, referential<\/strong>, and instructional<\/strong> content, and veering away from editorial. Think \u201cHow to X\u201d by default, in the realm of building websites. We’re focused on the front end, so the technologies around HTML, CSS, and JavaScript, as well as the tooling and meta-languages around them.<\/p>\n\n\n\n
We prefer if you are motivated because you have something you very much want to share<\/em>. And, that you have a deep knowledge<\/em> on this topic. You are excited<\/em> about it. <\/p>\n\n\n\n
<\/a>Audience, tone, and length<\/h3>\n\n\n\n
The audience of Frontend Masters is front-end web designers and developers at all different points in their professional journeys. We\u2019re not going to tell you to target your articles at some arbitrary skill level like \u201cbeginner\u201d or \u201cadvanced\u201d \u2014 what you should target is\u00a0clarity<\/em>. Everyone appreciates an article written that makes technology understandable. You can generally assume basic knowledge of HTML, CSS, and JavaScript, except when covering those basics adds to the clarity of your article.<\/p>\n\n\n\n
The tone should be:<\/p>\n\n\n\n
\n
- Comprehensive and written for all experience levels<\/li>\n\n\n\n
- Technically detailed and correct<\/li>\n\n\n\n
- Practical, useful, and self-contained<\/li>\n\n\n\n
- Friendly but formal<\/a><\/li>\n<\/ul>\n\n\n\n
The loose goal for length is 600 words<\/strong>. An article can be shorter if it\u2019s extremely useful and clear. Or an article can be a huge guide covering a technology’s intimate details.<\/p>\n\n\n\n
Always good:<\/strong><\/p>\n\n\n\n
\n
- A healthy amount of relevant images\/videos. Images have proper alt text and may have captions. Images may not be meme\/joke pics or pictures of code.<\/li>\n\n\n\n
- Blocks of code that get right to the most important concepts.<\/li>\n\n\n\n
- Demos. CodePen<\/a>, if possible; other interactive code embeds, if needed.<\/li>\n<\/ol>\n\n\n\n
<\/a>Submit your proposal<\/h3>\n\n\n\n
You\u2019ll need to write the article to the best of your ability upfront to provide a sense of your writing style, concept, and professional acumen. It doesn\u2019t have to be perfect. There will be an editing process that happens after that.<\/p>\n\n\n\n
If you don\u2019t have the time to write an article that may not be published, we totally understand, but we can\u2019t commit to publishing anything without seeing a complete draft. If you\u2019d like to send in a shorter pitch instead to get a signal on if the idea is worth pursuing, that\u2019s fine, but no publishing decision will be made until a complete draft is in.<\/p>\n\n\n\n
No AI slop, please. We know AI is very capable of outputting technical writing, but it has a tendency to be lifeless and full of awkward mistakes. Articles need to be written by you and we need to hear your voice. <\/p>\n\n\n\n