RFC: What would you like to see for V2?

[timlrx]

Introduction

Hi all, we have gone a long way developing this template and it currently supports numerous features and makes bootstrapping a blog in nextjs pretty straightforward! Nonetheless, I see some teething problems which I wish to solve in the next version. I think there's a space to be filled for a markdown first, batteries included nextjs template. The new project would also more easily support user contributions and reduce redundant config and files.

Here's a list of changes I have in mind. Feel free to provide feedback on any of them or suggest other changes you would like to see. Thanks!

1. Modular components
2. Modular layouts
3. Abstract away the loading of MDX files
4. Support for authenticated routes
5. CMS for editing markdown files

1. Modular components

Rather than having a large config file with varying options and selectively render components based on the configuration options, the new project would provide these components in a more modular manner. Users can import the components where required.

Example, instead of a config object and component as part of the template, V2 would consist of a more barebones template with various importable components as part of a mono-repo structure. To add a giscus comment component, the user would import the GiscusComment component and add the following code to the post template.

<GiscusComment
  repo="..."
  repositoryId="..."
  category="..."
/>

Pros:

• This would allow us to add support for more providers
• Reduce code bloat of the main template (you import only what you need)

Cons:

• There would not be a single config file to control all this settings

2. Modular layouts

Rather than shipping various layouts with the template, the layouts would also be extracted as a separate mono-repo and can be imported on demand. To add a layout to your blog you can use a CLI command e.g. next-blog add PostSimple to download the PostSimple layout to the layouts folder.

Pros:

• This would allow us to support more community templates.
• Reduce code bloat of the main template (you import only what you need)

Cons:

• Some work needs to be done upfront in defining the props that the template would consume

3. Abstract away the loading of MDX files

All the scripts in the lib folder e.g. mdx.js could be abstracted away and imported on demand. No change is required in the other parts, but the user will import from the project package rather than refer to a local script.

Pros:

• This would allow transitioning the codebase to typescript (the main template can still be in js though)
• Reduce implementation details of the main template

Cons:

• It might be hard to modify the loading scripts. We could probably add some parameter to customize the remark / rehype plugins, but I would like to know if any one makes significant modifications beyond the plugins?

4. Support for authenticated routes

Both next-auth or supabase are relatively easy to support. The difficulty is knowing the right level of abstraction which depends on the intended use case.

Pros:

• Authenticated route out of the box

Cons:

• This makes exporting as a static site no longer possible. We could create modular components and hooks but the user might as well just refer to the documentation of their preferred authentication service directly - it's fairly straightforward.
• There are also two different use cases for authentication, internal (for me to view a private page) and external (e.g. substack). It's hard to pick the right choice to support both needs.

5. CMS for editing markdown files

This would be an opt-in feature to add netlify-cms or an equivalent to the template. An ideal CMS would allow inserting MDX components and work both locally and remotely.

Pros:

• Allow the blog to be edited by less technical folks

[levpa]

Totally agree with 5, it must be simple, to write and publish content for the blog. Maybe it will be fast authorization for content manager and then live editing on the blog pages! I use vercel(zeit) for deploy, it's fast and free for hobby plan.

[piyushpaliwal]

I would recommend possibility for both GIT and API based CMS. Makes migration a whole lot easier.

[osseonews]

Thanks for the amazing work. I think 5 is critical, as its a massive pain to edit MD files for all but the most tech saavy. With a good CMS, this theme can compete with Wordpress and would be much easier to set up. I think there are quite a few services that can be integrated, but not sure which is best. Maybe just integrate forestry.io? I also think Authentication would be great and I'd lean toward just implement the basic functionality with next-auth. I think next-auth easily supports internal and external authentication. Thanks again for your all your hard work.

[osseonews]

BTW, was just looking thru forestry.io and didn't realize the team there has developed tina.io. I think just implementing tina.io into this would be great. Tina has their own starter blog, but yours is much, much better, so we would be great to just work your starter with Tina included. Thanks!

[timlrx]

Tina cms looks interesting. I have to try that out to see how easily it integrates. Looks like they support MDX too which is neat.

[osseonews]

I did some work on Tina. I think this is hands down the best CMS editor tool you can add here. It integrates very smoothly with NextJs and supports MDX. They have a bunch of code in their examples also, so I don't think it's much work to integrate. With Tina added, I think you would now have an alternative to Wordpress. Thanks.

[animemandir]

A good customizable CMS is a must, would love that. Probably some highly customizable cms like that in wordpress. Strapi cms is good.
Post thumbnails would look absolutely cool. some more extra widgets like a popular post slider which will show images and post title. Disqus comments integration.

[timlrx]

Unlikely to go down the directly of wordpress / strapi, if you want to use a CMS with all those features, just use them directly! I don't see the advantage of using a markdown based blog with a database CMS. Noted on post thumbnails and other widgets, but Disqus is already supported out of the box.

[PsyGik]

Image optimization, more specifically, build-time image optimization when using next build && next export.

Maybe not as a default option, because I assume we want to keep this compatible with Vercel deployments. I propose an opt-in config, when enabled, generates optimized images during build. This opens up the ability to build a purely static site with optimized images.

Inspirations:

• cyrilwanner/next-optimized-images
• or a fully custom solution following along the lines of https://github.com/tomik23/node-sharp-images/blob/master/index.js#L90

[timlrx]

Let me know if you managed to get that integrated. Would like to see how it looks. Currently, I lean on not supporting it as it is one additional thing to maintain and is quite prone to breaking as nextjs does not officially supports it. I would much prefer if nextjs implements it on their side - vercel/next.js#19065

[thedevdavid]

Instead of modular components, I think a Blitz.js-like recipe functionality might be a better idea.

This way the base package size and the clutters could stay minimal, and it'd be easier for others to contribute new recipes. What do you think?

[timlrx]

Thanks for pointing that out - I was also thinking of a similar approach for the layouts. It's nice that there is something already built that we could leverage on!

I still think there is value in having modular components in combination with layouts / recipes. The components would be for things which the user does not need to care about the implementation details beyond passing in certain props e.g. <GoogleAnalytics /> or <PlausibleAnalytics />. The layouts can also import these components and conditionally render them depending on the user's preference.

This way, there would be 3 sub-repos:

1. A minimal starter template
2. Common reusable logic components (non-UI)
3. Full page layouts / recipes

How does that sound?

[juicyjusung]

Thank you for the awesome project! How about embed Code pen, or something like that..?

[juicyjusung]

Never mind! I solved it with mdx-embed.

[animemandir]

A search bar in header.
btw I recently got to know about this tailwind plugin - daisyui. It looks really cool. Can you implement it?

[timlrx]

There's a search bar in the blog page already. You can move it to the header if that's what you want.

Same with daisyui, you can install it and use it for your own layouts. My preference is to use tailwind directly.

[AlexanderZeilmann]

The search bar on the blog page searches only through the blog posts, but not through the other pages. Maybe that is what @animemandir meant.
A search functionality for the entire website would indeed be nice.

[osseonews]

Suggest just using Algolia for the search feature. Easy to implement. Search is complicated.

[AlexanderZeilmann]

Meilisearch and Stork might be nice alternatives if Algolia is not working for some reason.

[lanbau]

These might be already solved but just wanted to try my luck..

• Auto generated slugs for posts like wordpress
• Internal linking suggestions (prolly a vscode extension?)
• table of content - out of the box
• estimated time to read - out of the box
• most importantly, backward compatibility with v1.. i've many sites on v1 😄 appreciate your work

[timlrx]

1. Isn't the slug already auto-generated from the markdown file name? I guess you want to auto-generate it from the title instead? I prefer to use the file name rather than the title, to get some flexibility to rename the post without changing the route.

2. What do you mean by internal linking? You can already use relative links in the template

3. It's pretty much out of the box. You just need to copy this code and paste it where you want to insert a TOC:

<TOCInline toc={props.toc} />

I prefer this approach over hard-coding it in the template (which you can also do), to have the flexibility to insert a TOC in any part of the blog.

4. It's already exported from the markdown code - see mdx.js. You just need to add frontMatter.readingTime in your layout. I don't really like a reading time indicator so it's not in the default template, but you should be able to add it easily.

5. Backward compatibility is a tough ask 😄. "V2" adopts a slightly different approach based on recipes which you can call to build your own blog - so creating tailwind-nextjs-starter-blog would be one of many recipes. With the new approach, I think maintenance will also be much easier. I might just spin it off as a different project...

[lanbau]

1. Yes. Didn't see that there's a compose option. Seems like compose already handles duplicate posts/slug out of the box.

[Error: EEXIST: file already exists, open 'data/blog/test.mdx'] {
  errno: -17,
  code: 'EEXIST',
  syscall: 'open',
  path: 'data/blog/test.mdx'
}

2. Internal link suggestions e.g in Wordpress, when you try to link something it gives you a list of suggested blog posts to link.
3. 👍
4. 👍
5. Cool.

[AlexanderZeilmann]

Automatically reload blog posts when mdx is changed
Right now, when writing a blog post, I have to go back and forth between my editor and browser to manually reload the page once I made a change to the mdx-files. It would be nice, if the browser could reload itself like it is doing for other file types.

[timlrx]

If you npm run start, it creates a websocket connection that should automatically reload on change. I am also experimenting with using contentlayer for the new template so hot-reloading is supported with fewer custom hacks on my side.

[AlexanderZeilmann]

Good to know, thanks! I was always using npm run dev.

[ChristineTham]

Is it possible to build in an image gallery and lightbox (using something like Photoswipe)?

[timlrx]

Posted a comment on the issues page but would repeat it here to centralize the information as well:

It's possible to take the images specified in the frontmatter and render them as a lightbox gallery in the post layout. Currently, that seems like a pretty niche use case and best implemented by the user. With the re-structure planned in v2, we can support more user-contributed layouts which might include something like what you described.

[ChristineTham]

Thanks. I look forward to seeing how the layout feature will evolve. It will be nice to have predefined layouts covering various use cases. I ended up not using this starter because my needs are quite different (I am trying to build a photo gallery) and I want to use Typescript, but I have starred this project and will revisit in the future.

[timlrx]

From @sokirill:

I love this theme! Have more of a question of sustaining the versioning and keeping up to date with customization. So in a way, increasing maintainability by understanding which components I can add / adjust and what is sort of a core that gets updated. Not sure if that is possible.

I am also thinking of connecting a Notion API (so that the posts get pulled from notion instead) but that would probably mess with the MDX.

Generally more out of the box integrations might be cool, but I guess depends on the demand.

[timlrx]

Thanks, yes the new version will improve maintainability by abstracting the various layouts, pages and integrations into something that can be added or updated in your site. There will be quite a few changes with the existing structure though.

The goal is to have first-class support for MDX, so I won't be supporting notion or other CMS out of the box as they sort of duplicate the work done. Contentlayer, which the new version is based on might support additional sources, but I will leave it to the user to figure out the configurations required.

[kirso]

1. Abstraction of layouts, pages and integration - that sounds great. I guess will have to start from scratch again :)

As an example, I want to create a page where I pull various links from my Raindrop collection via an API. Would be great to do this without actually breaking anything when pulling a new version of this template.

2. CMS - yep its ok, didn't expect out of the box Notion config, will figure out how to plug it it in with a separate function I guess, just to adhere to the format of the articles.

When is the planned release of V2?

Thank you!

[timlrx]

Waiting for contentlayer to enter beta before releasing it otherwise, there will be too many moving parts.

[kirso]

Understood! Do they have any indicative date in mind by any chance? I am just refraining from making any changes until the v2 is out :)

[timlrx]

From @piyushpaliwal:

I have a couple of suggestions

• Currently it shows just the title of tag with posts; what would be interesting is the ability to add things like tag images, descriptions, etc.
• Ability to add reactions to post
• Support for reading time, with an optional flag in siteMetadata
• Author page layout for multi-authored blog
• Support for webmentions

[timlrx]

1. That's for the user to implement according to their preference
2. You can already use one of the comments plugin to do that. Don't think we should support that out of the box.
3. Reading time is already generated, just not used in the current layout - personal preference. I don't think this requires a flag and is probably one line of code to add.
4. Yup, users can contribute their own layouts in v2 including multi-author pages
5. That's interesting. Seems pretty cool, but probably as another integration if somebody wishes to take it up.

[AlexanderZeilmann]

Move styling from elements to tailwind.config.js

Currently when one wants to modify how e.g. h1 elements look like, one has to search for all h1 and change their styling separately.
It would be nice, if as much styling as possible is moved to tailwind.config.js such that there is only one place where one has to go to change the CSS.

[timlrx]

I prefer to modify the base tailwind config file as little as possible. This makes it easy to support different user-contributed layouts while maintaining a consistent look and feel when copied as the layouts are not tied to specific tailwind configurations. Users can subsequently abstract some of this styling logic to a level that makes sense to them - my preference over here is to just use react components.

The exception is probably the prose plugin which is fairly opinionated because that's what tailwind does as well. If you want to standardise the look and feel of all the elements across the blog, perhaps wrapping the entire document with prose at the root level would help. I prefer just restricting it to actual prose where perhaps less freedom for creativity is required.

[kirso]

I standardize as much as I can in Tailwind config. But the rest needs to be indeed custom or with @apply property. I agree that sometimes its not ideal to have various setup for H1's in different components since it makes CSS a mess but thats more of a Tailwind quirk than the blog template.

[AlexanderZeilmann]

I prefer to modify the base tailwind config file as little as possible.

Makes perfect sense to me.

my preference over here is to just use react components.

Yes, I thought about this, too, i.e., write a wrapper around tags like, h1. But the problem then is that the html generated from mdx is using plain html, and not my custom components.

wrapping the entire document with prose at the root level would help. I prefer just restricting it to actual prose where perhaps less freedom for creativity is required.

I will probably add the .prose class to the main tags (I have added one per page) and use the approach as in the screenshot by @sokirill.

[rsipakov]

I standardize as much as I can in Tailwind config. But the rest needs to be indeed custom or with @apply property. I agree that sometimes its not ideal to have various setup for H1's in different components since it makes CSS a mess but thats more of a Tailwind quirk than the blog template.

How it work if you will use different 'prose' like 'prose-lg', 'prose-md'? I think in this case you will have only one parameter for 'h1' that you specified in the 'tailwind.config'.

[kirso]

@rsipakov to be honest I haven't tried it, I am just using prose convention where needed for now but I guess you can config this with prose lg / md? Not sure how tailwind/typography handles it though these days.

[BraydenTW]

I think a newsletter signup API connected to Buttondown.email would be nice!

[timlrx]

https://github.com/timlrx/tailwind-nextjs-starter-blog/blob/master/pages/api/buttondown.js

[BraydenTW]

Oops! Didn't see that there. Thanks for pointing it out!

[brohvis]

I’m not sure if this should go somewhere else but I saw this. I’ve tried 5 or 6 different ways to expand the background color all the way to the notch on mobile view. (Tried meta viewport, safe area inset, etc.) I was looking through the example and featured sites when I noticed none of them do this. My next couple of adventures will be this, and PWA support, both of which I think would put this template over the top for built in functionality. I will update this if I think of anything else. Thank you for this, it was exactly the kind of meat and potatoes template I was looking for, and the featured sites are all public too so thank you guys for that as well because I’m just getting started and I knew it would take me a couple of days to get featured images working but Alois’s recipe blog had it right off the bat!

[0xDarni]

• Webmentions
• Maybe integration with Discourse for comments?

[timlrx]

Discourse is a forum, not blog comments.

[0xDarni]

There are integrations for other blog platforms (e.g. WP plugins) that create a thread for each post, and the comments go there... 🙄

[timlrx]

Thanks for pointing that out. It should be relatively easy to do so based on the instructions in this ghost/discourse integration. As I don't run a discourse group, it will be better if someone tests it out and makes a pull request.

[0xDarni]

Sounds good 👍

I can give it a try once I have some time and create a pull request! Would love to help!

I really like this project 🙂

[Xuanwo]

I would like to see the following features:

• i18n support
• native algolia search support

[dannysteenman]

Would be nice to have revue (newsletter) integration.

Update:
Implement google rich results, currently, the metadata of the articles aren't formatted properly and gives out a warning, see the test result of the demo blog article(https://tailwind-nextjs-starter-blog.vercel.app/blog/new-features-in-v1): https://search.google.com/test/rich-results/result/r%2Farticles?id=U8PKlwF8LJcQwm6qJD9ouA

[timlrx]

@onurgenes contributed a revue integration - #397

On the rich results test, I intentionally left the optional author URL field blank. It's hard to determine what it should be and depends on whether you are just running a personal blog or one with multiple contributors, whether you have separate pages for multiple authors or just want to put a twitter / linkedin url.

[AlexanderZeilmann]

I think the template can be "componentized" a lot more than 1. Modular components and 2. Modular layouts. Close to any file in components, css, layouts, lib, pages, scripts can be its own package.

Why? Because that would make updating the template a lot easier. Right now I have to copy the git diff from the pull requests over to my websites. When everything is a component, I just need to increment the version number in my package.json file.

Users that what to modify one of the files can still do so and - if needed - update the code by hand as we do right now.

[dannysteenman]

Implement Projen to maintain this projects configuration through code.

projen synthesizes project configuration files such as package.json, tsconfig.json, .gitignore, GitHub Workflows, eslint, jest, etc from a well-typed definition written in JavaScript.

I currently use it to manage multiple typescript projects and it becomes way easier to let people fork the repository and change it to their likings.

[dannysteenman]

Add Next SEO plugin to make managing SEO easier: https://github.com/garmeeh/next-seo

For instance, breadcrumbs can easily be added.

[timlrx]

The early versions of the template uses next-seo but I recalled quite a few issues configuring it and decided to just use next/head directly.

[iliamrv]

I've been used tailwind-nextjs-starter-blog for a long time, thanks a lot for its development. I'd suggest some features which demanded:

• links to similar articles (based on common tags)
• most popular articles on the front page
• breadcrumbs for articles
• Additional details for tag page

[timlrx]

Thanks for the suggestions. On the first two ideas, I did consider it initially but decided against it as it requires a backend database to tally the information or some external API to pull page analytics data.

Currently, it's relatively easy to deploy the project it as a static website with almost all the features provided through external services and integrations. Will have to give it more thought on how best to support all these enhancements while catering to different users who might not require them.

[kirso]

I love all of those suggestions and second them.

Maybe a separate fork with database features?

But agree its tricky as most templates just say - if you want to persist the data, just add it custom yourself. The issue then becomes again the maintainability. If the template gets updated - everything will probably break like in my case right now :)

I played with the contentlayer btw. and can't wait if it gets added into this template.

[timlrx]

Not sure if you have seen it but there's a contentlayer branch - https://github.com/timlrx/tailwind-nextjs-starter-blog/tree/contentlayer

It will form the basis of the new version. I am just hesitant of pushing it to the master branch as it will probably break most setups out there. So I am saving it for a fresh start :)

[kirso]

Awesome, I'll play around.

Personally I came to terms that I will have to rebuild the website but that is what we have components for?

For any other radical changes made to the codebase, I guess its expected that you can't maintain the main template.

Also people can stay on the older setups (thats why I am on v1). But I recall you mentioned that ContentLayer will be the basis for v3? Or by fresh start you mean you will have a separate template with it?

[timlrx]

Thanks all for the comments, feedback and suggestions! Please see the announcement page on v2 and the new project - #469

[timlrx]

@animemandir , @AlexanderZeilmann, @Xuanwo, @osseonews and everyone else interested in a search feature. You can test out the newly launched search provider component - supports both algolia and local search powered by kbar.

For more information, check out the PR, the updated starter config and _app.tsx which wraps the application with the search provider and imports some additional styles (more for algolia).

It should be relatively simple to add to your existing blog even if you are not on the latest versions as everything can now be imported from a modular package.

[mdarif]

@timlrx What's the latest about V2?

What about upgrading to latest Next.js (V13)

[timlrx]

That's in the works. I would have announced V2 already if not for the Next.js V13 change which might require some breaking changes. Have to investigate a little more to see which features I would want to support , most notably, whether to migrate to the new app/ directory and use RSC.

[mdarif]

Thanks for the update, count me in If you need another contributer :)

[timlrx]

Update on V2

I have been holding off on the upgrade as there were lots of breaking changes adopting Next 13 with app directory. Now that things have settled down, I think it's a good time to release a v2!

Rather than creating a template library and supporting both typescript and javascript like what I initially imagined with the pliny project, I plan on keeping it simple and trying to make the project as easy to maintain as possible.

This means moving away from the templating framework of pliny. Instead we will retain this repository as the main template which can be easily forked or cloned. Also, rather than supporting both js and ts, I would only maintain a typescript version. Pliny would still continue in a smaller scope - it would contain modular components that you can easily add to your project in areas such as comments or analytics.

Here are the main features and changes of V2:

• Next 13 App dir with React server components.
• Typescript
• Contentlayer for managing MDX content, with excellent typescript support for MDX files.
• Content layouts are handled at the React page level rather than defined by an MDX wrapper component - this works better with RSC and reduces client code.
• More in-framework libraries and features such as next/font and native metadata support.
• Modular add-ons are now imported from the pliny library.

The aim is to get the new version up within the week for beta testers to try and hopefully I can merge it to the master branch once addition documentation is written!

[thedevdavid]

That's great Timothy! I had a blast contributing to this project a few years ago.

Since I saw that it has stopped developing, I built another starter template with Contentlayer, app directory, etc. last month.

This weekend, I'm releasing a bunch of new features. Feel free to use that as an inspiration, and we'll close the full circle. Hahaha.

[timlrx]

Awesome, yours looks good as well and it's really packed full of features!

[timlrx]

v2 is ready for testing 🎉 - #658

Feel free to try it out and let me know if you encounter any issues.

[ttys3]

awesome!

[SangeetAgarwal]

@timlrx is there a way to add a rss feed similar to say https://blog.baeke.info/feed/.
Thanks

[ttys3]

you mean full content RSS ?

[SangeetAgarwal]

potentially, yes

[timlrx]

Have you taken a look at https://tailwind-nextjs-starter-blog.vercel.app/feed.xml? You can modify the rss script logic if you want to display the full content.

[SangeetAgarwal]

perfect, thanks, not sure how I missed that.