Eleventy: 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 #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 :+1:

[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.