Move some of the default plugins into plugin land

[zachleat]

Definitely keep

• HTML (plain text)
• Markdown
• 11ty.js
• Nunjucks
• Liquid

Up for discussion

• Handlebars
• Mustache
• EJS
• HAML
• Pug

Definitely move out

• JSTL Remove JSTL files from core #1084

[tomsturge]

Why definitely keep Nunjucks and Liquid?

[paulrobertlloyd]

I guess Liquid is useful for those coming from Jekyll. Not sure of the relative popularity of the other languages, but I’ve used both Nunjucks and Handlebars in my time, if that’s any measure.

[ThePeach]

Just to understand, even when moving out any of these, would the support to them remain at all or they will be deprecated? If that's the case, I'm voting to keep Handlebars in 👍

[solution-loisir]

So far, I'm always using Nunjucks, Markdown and HTML. I think it's nice to have the other options, but if I can use a plugin, I get the same result while keeping 11ty lightweight and relevant.

[Ryuno-Ki]

I use Nunjucks and EJS, but was about to port EJS over anyway. Nunjucks reminds on Jinja2, so it could help people moving over from a Django app.

[stuartpb]

Considering their popularity across the npm ecosystem, I'd definitely expect all the template languages under "Up for discussion" to come standard. (The only one I might not expect would be HAML, as I pretty much only ever saw people use Jade/Pug from the beginning with Node.)

[binyamin]

Considering their popularity across the npm ecosystem, I'd definitely expect all the template languages under "Up for discussion" to come standard.

@stuartpb The trade-off is that you can't choose not to install them. I'd rather have to install a plugin or two along with 11ty.

[binyamin]

I vote for shipping the lowest possible number of languages (if any), and having tons of plugins. I'd rather install an eleventy-liquid plugin, for example, and skip alternatives like nunjucks.

[zachleat]

I wanted to float this, haven’t made a decision yet.

I can say that it seems very unlikely that Liquid would move to plugin land.

If any of these move the choice needs to be done with great care as it creates an additional hurdle for beginners wanting to use them.

[nhoizey]

I understand the value of reducing Eleventy's dependencies, but I guess it should at least support 2 or 3 main template languages, to show how versatile it is.

I discovered Nunjucks when I started using Eleventy, and I immediately liked it, even coming from Jekyll and Liquid. So I would vote for it as the first candidate, even if I'm entirely capable of installing/using a plugin.

A second candidate might be Liquid, as many people come from Jekyll and don't make the same mistake I did, moving to another template language in the same time… 😅

A third candidate might be the one offering the fastest build times, as this is good for DX, and often used as a criteria to prefer Hugo for example. I thought it would be 11ty.js, but https://twitter.com/eleven_ty/status/1303086521763934214 shows it isn't… 🤷‍♂️

[marblewraith]

WOT incoming, skip the mistakes section to make it shorter.

Mistakes

Where are people coming from?

Asking this question, in a bid to use precursor compatibility as the criterion on which to base this decision is the wrong approach.

Even though the ethos behind 11ty is [to quote @zachleat] a jekyll-inspired utility. Stating the obvious, not everyone who uses 11ty will be migrating from jekyll. They could be coming from React, nuxt, laravel, django, or even be greenhorn with no experience at all.

What are people using? What's most popular?

Well discounting HTML, markdown, JS and JSTL, we can compare the github stats.

Depending on the metric used, any of them could be the best. However since 11ty lives in the JS universe, if we contextualize this to the JS stack (via npm stats), handlebars seems to be painted as the clear winner on activity alone.

While this does seem a little more concrete (because of the wider dev sample size), once again these questions still seem to be the wrong ones to be asking, namely because there's no way to determine objectivity / bias.

Forward

If the size / the dependency tree, is the driving motivation here, then the goal should be to take this to the extreme.

Goal: Out-of-the-box (ootb) 11ty support should only include: markup langs (HTML / markdown), JS of course, and one templating language.

I make this statement for 2 reasons:

1. Ultimately it doesn't matter which one is shipped by default, so long as the others are given first class citizen support via "plugin land" and documentation. I mean getting to know templating syntax (especially if you're already familiar with it as a concept) takes all of 20mins reading docs.

2. There is an inverse relationship between time and the number of choices provided to a person. Less choices by default means less time deciding what to do.

So which one? That depends on what kind of dev experience 11ty wants to accommodate by default?

Broadly speaking, templating languages can be objectively divided into Logic (e.g. liquid) and Logic-less (e.g. Mustache).

By my read, logic-less is easier for beginner devs because it forces stricter code organization i.e. you must have your data formatted appropriately (via abstracted logic) before you can pass it into the template. Which also keeps templates uncluttered / re-usable. It'd also prevent undesirable situations from happening e.g. unintended nested loops.

For intermediate devs and above, logic-less can seem a bit too rigid / featureless / restrictive.

If it were me, i'd go with logic-less by default (unfortunately meaning both nunjucks and liquid are out of the running). I'd do this for 2 reasons:

1. Logic-less is still robust enough that even advanced devs will find it fit for purpose most of the time.

2. As expounded on before, provided the other ones have first class citizen support, it's an extra 2 minutes (max) for devs to install the plugin. Less if they have a good net connection or have it cached.

At the very least hope this is food for thought.

P.S. Lookin forward to the 1.0 release. 😊

[pspeter3]

I wonder if a compromise is to make an eleventy-core package which has no plugins and all of the templating languages are plugins. Then we could make the eleventy package become an opinionated configuration for eleventy-core. This would let people concerned about dependency size cobble together their own build but still make it easy for new developers.

[Ryuno-Ki]

But if all template languages are plugins … Will npx eleventy still work ootb?

[pspeter3]

@Ryuno-Ki yes because in my proposal the eleventy package would include some of those plugins. The people who want to go to the bare bones installation would use eleventy-core (or some other name) instead.

[binyamin]

@pspeter3 That's brilliant! Maybe @11ty/core

[pspeter3]

Sounds like a good name to me!

[marblewraith]

It should be noted that will create more overhead for the main devs of 11ty who have commit access, as they will be going from 1 repo to 2 repo's. Even if this is structured correctly (via submodules) it's still a significant amount of added complexity just ensuring the 2 stay in sync.

Nonetheless this is definitely a good option in relation to providing flexibility to 11ty users and cleaning up the codebase.

As such, even if @pspeter3 suggestion cannot be fulfilled right now, i feel it should definitely be earmarked for the future.

[pspeter3]

@marblewraith having multiple packages does not require multiple repositories. You could use a tool like lerna so that all of the packages are in the same repository.

[Ryuno-Ki]

Those are then called „monorepo”.
Personally, I have to look up Lerna's syntax repeatedly.
So I'd welcome a markdown file (CONTRIBUTING.md, for example) explaining every command to use.

[MarcoZehe]

As someone who has just recently got into static site generators, Eleventy's appeal for me was that it is so versatile out of the box. I was a WordPress user for many years, am now in the final stages of a brush with Ghost and Handlebars, and have played with Jekyll and Hugo. The thing I like about Eleventy is not just that it is JavaScript-based, and therefore the one I feel right at home with, but also that through its filtering, I can use the Nunjucks filter on all kinds of files, like html, md, njk etc. With the different tutorials out there, I can set up my project to put everything through the Nunjucks filter, and it will all just work.

We should definitely not take away that simplicity. Maybe some of the more exotic ones from the "up for discussion" list can really be put into plugins, but the ones under "keep" should all definitely stay, to give the greatest success with the increasing number of tutorials out there.

[Snapstromegon]

As someone who recently started using 11ty and is still taking early steps I have to say:

The current way of being able to run 11ty on an empty folder and also on an existing directory without any configuration is really great.

I support the idea of @11ty/core which was mentioned above, because it'd keep the ease of getting started with a batteries included default install.

I came to 11ty because it made no assumptions about frameworks and tooling (I wanted to use vanilla as much as possible) and because it supported the templating languages I already knew and loved (in my case md and nunjucks).

In my opinion a "default" 11ty install is totally fine if it supports the following:

• HTML Plain
• Markdown
• Liquid and/or Nunjucks
• one logic-less language (e.g. handlebars because of its popularity)

Whichever languages get chosen, it has to be clear that the "default" install only includes those, because 11ty needs at least one to work and the selection was just a "good guess for most users". This can be achieved by still providing examples for "non-default" languages in the docs and an easy install path for other languages.

A big benefit of plugin based language support would IMO be, that it'd encourage people to build their own plugins to support other languages.

I know from experience that this is connected with a lot of work for the maintainers.

[zachleat]

Punting this out of 1.0 for now (sorry!)

[zachleat]

Some good discussion at #779 but this is now home base.

[Ryuno-Ki]

Is it still on the roadmap to 1.0?

[zachleat]

Per #1103 (comment) no, this was removed.

[zachleat]

Just another follow up here, after reviewing the module graph again (via #1375) I think a major win here would just be moving pug into plugin land.

https://npmgraph.js.org/?q=@11ty/eleventy@2.0.0-canary.24

It’s the biggest built-in template language by far

• mustache 6kB
• markdown-it 97kB
• liquidjs 54kB
• hamljs 8kB
• pug 732kB
• nunjucks 91kB
• handlebars 74kB
• ejs 11kB

[pdehaan]

FWIW, I still 💯 agree with the original idea of soft deprecating all the "Up for discussion" libraries for v2 and kicking them into separate plugins in v3.

• Handlebars
• Mustache
• EJS
• HAML
• Pug

Plus, if they are separate Node modules, it's really easy to see which official-unofficial languages are actually used or if .pug templates are only used in 2-3% of the Eleventy sites out there.
I don't think I've ever strayed from the giants of LiquidJS, Nunjucks, .11ty.js, and Markdown.

[pspeter3]

Agreed. I'd also like there to be an Eleventy Core ideally which has no plugins and then the Eleventy package depends on Eleventy Core and includes the recommended plugins.

[Zearin]

I love Pug.

…But, it seems like there are so many cases where some 11ty-related functionality breaks in Pug that even 11ty’s existing support seems like an afterthought.

It already feels like a(n abandoned) plugin, to be honest. ☹️

[zachleat]

Just to note, project slipstream included some of these changes #3074.

Deep link to package.json change: https://github.com/11ty/eleventy/pull/3074/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519

-     "pug",
-     "handlebars",
-     "mustache",
-     "ejs",
-     "haml"

I will pledge to have official support for all of these (official plugins) with 3.0 stable (but maybe not in the initial alphas).

#3081 has already been filed for Pug.