which engine to default to post jade?

[dougwilson]

The issue has been brought up with the renaming of jade: if we have to change the default engine away from jade, which engine should it be? There are three main contenders, with, i.m.o. the main pro of each:

1. pug. pro: very similar language to jade
2. hbs. pro: this is an Express.js project
3. ejs. pro: it's a basic, flexible language
4. no defulat. pro: reduces reliance on external dependencies

Very old previous discussion: #47
Discussion on this in TC: https://youtu.be/bolB3vHBNK4 (it's the first topic)

Summary of votes from conversation below:

1. 1 (@jonathanong)
2. 2 (@dougwilson @joewagner)
3. 0
4. 4 (@ChiperSoft @hacksparrow @crandmck @gokaygurcan)

/cc @expressjs/express-tc

[jonathanong]

pug is jade, so i would say pug.

or... why even bother with a default engin?

[niftylettuce]

Nunjucks

1. pug

[dougwilson]

or... why even bother with a default engin?

good point. I added this as #4

pug is jade, so i would say pug.

well, pug is a new major version of jade, with a bunch of weird incompatibilities, file extension changes, and such. I understand it's just a renamed jade, but with all the changes it, at least to me when I switched, felt more like using a different templating language that just felt similar to jade.

[Twipped]

I agree with @jonathanong, don't set a default. Anything that is a default becomes an included dependency that cannot be opted out of. That's added weight that express doesn't need.

Pulling a number out of my ass here, but at best maybe 1 in 5 users will actually use whatever engine you pick.

At one time there was a discussion about leaving the view engine out of express entirely, making it an optional middleware. I still think that's the best direction.

[Twipped]

Sorry, I just realized this was the generator repo, not the express repo. That changes things a little...

The generator should prompt from a list of popular choices.

[crandmck]

I think we should either go with no default, or default to hbs, since it's an expressjs project. No default kind of makes sense, but might not serve totally new users well, since they would have no idea what to choose....

If we decide to change the generator to "no default", docs would still need to provide a "getting started" example that uses something, so it would probably be either hbs or pug (just as a concrete example).... but that's just an aside.

[hacksparrow]

I am also inclined towards #4.

[dougwilson]

So my thoughts on number 4:

I think having no default view engine seems good, because it means that people are picking their view engine and there will seem like less favoritism. On the other hand, most people I see who use the generator (just ones I see; I cannot speak for the greater usage) will almost immediately reach for res.render, which of course requires a view engine.

I really don't feel strongly either way, but if I were to pick, I'd pick to number 2.

I'll update the top with the current votes with names (so you can correct it or me if i had your vote wrong) un just a bit. I plan to give people time to respond, since this is a large change, and will close it with the resolution on 10/25 if there is no crazy objection and we'll simply go with whatever is the majority.

[crandmck]

Please add my vote for num 4.

[gokaygurcan]

Even though I like handlebars most in this list, I'd say #4. But then, I'm thinking about this: http://eng.localytics.com/exploring-cli-best-practices/

Every option that can have a default option should have a default option.

Btw, does my vote count? Or just TC? haha

[dougwilson]

@gokaygurcan everyone's vote counts :) I added you as #4 above; TC is not to make decisions in isolation, mainly to discuss issues where there does not seem to be a resolution, act as a tie breaker, etc.

[joewagner]

+1 for hbs

[dougwilson]

Ok, just wanted to provide an update for everyone subscribed: currently "no view engine" is the consensus.

[steved3s]

Well, I'm a new user, led here by VS codes example of using express-gen. My very limited use of both node and express, leaves me out in the boonies with option 4. My request would be to add command line options for them (like --ejs, --hbs --pug), and to keep from having to update everyone's use of the VS code example, keep jade as the default. At least this way I can get going and eventually dig deeper.

[dougwilson]

Hi @steved3s, I definitely understand your concern, but your comments also make me think you may not have the full context of this issue. So the issue is around that we cannot keep jade as the default, for 2 reasons: (1) at some point, jade will be unpublished from npm to finish complying with a legal name dispute and (2) it currently generates a real support burden on us, as can be seen by searching for jade in our repos, since the users get a scary warning.

That being said, the express generator already does, and will continue to have command line options like --ejs, --hbs, etc. to choose your engine. This issue is only about the behavior when you do not specify any particular command line argument. Even the --jade argument will be kept around until jade disappears from npm. Does that make sense? Does that change your thoughts at all?

[dougwilson]

So I've been thinking on @steved3s comment, especially related to all the tutorials around the web. This doesn't directly relate to the decision here, but does probably mean we need to make this change in two releases of this generator. Since there is no --jade right now (I made a mistake above when I said there was), any tutorials that want to keep using jade cannot update their documentation before we release. The current 4.14 release proposal (#117) adds --view=jade, which provides a way to continued usage of jade for those who want it.

Perhaps we should split this change into two releases: (1) release with the added --view=jade and a printed warning for those calling with no --view=... specified, then (2) release with the new default, removing the warning.

[crandmck]

I think the two release idea makes sense. Looking at #117, it already has quite a few significant changes, so pushing the default change to the next release sounds reasonable.

[steved3s]

I understand your dilemma, and appreciate the consideration given. I did not see --pug as an option in the current version I have installed (4.13.4) from the --help switch. It was sort of out of curiosity that I arrived here. I installed express 4.14.0, but when I added the generator, it reverted back to 4.13.4 and I of course, expected the generator to use the latest express version installed. I'm certainly not opposed to the reversion, just expected it to use the updated version.

I don't know if adding a new default keeps the web tutorials alive or not, but I sense regardless of which way it goes, there's some work to do the clean up the exit of jade. It does sound like the two step process has merit, and it will give those responsible for the web tutorials time to get their end prepared as well (assuming they desire to do so, which I hope they do).

At the end of the day, I trust you'll make the best decision possible. I'm happy to see that some alternatives are on the table, which for me, may help keep the sailing smooth.

Thank you.

[OutsourcedGuru]

As was said before, pug = jade. If you look at the great collection of tutorials out there which provide examples for jade, those examples will still work in the world of a pug-named viewing engine. If you change the default to something else then you've radically broken those examples.

"¡Para los noobos!"

[dougwilson]

We are working to get tutorials to update such that the template engine is in the command line, which would leave the tutorials to be much more future proof. You're welcome to help: Any you find make a PR or whatever to add --view=jade or --view=pug to their command line for people to follow.

[OutsourcedGuru]

@dougwilson Not your tutorials, Doug, the interweb's: Search google for 'node.js express tutorial' = 831K hits. I wrote about this costly problem recently, btw. Quantifying the damage

[dougwilson]

I understand. We care heavily about tutorials, which is why no decision has been made. Unfortunately we cannot stay on jade and pug is not jade, no matter how similar. Changing it to pug still breaks certain tutorials, so we are in a no win situation. Something will change and we are trying to make it as less impactful as possible. We are still trying to figure it out. Your attitude is not very helpful.

[dougwilson]

Not your tutorials, Doug, the interweb's

I was originally referring to the "interweb's". I have been sending emails to lots of sites for a long time now with this issue to get them updated to explicitly ask for either the template engine or the version of this module.

When Express 5 comes out, tutorials that are not even set to use a specific version of this module are going to break as well. The best way forward is to help tutorial writers update their tutorials, at the very least having them specify versions in there so they can continue to work in the future.

I care deeply about them, so it is hurtful when you think otherwise and certainly makes me want to stop caring, which is the opposite of what it seems you want to achieve with your comments...

[gokaygurcan]

Can I suggest something radical at this point?

Instead of passing selections as parameters, let's make a simple CLI with prompts to make users choose. So even if they pass the unused or wrong params, we can let them pick the desired option via arrows or something.

I'm not sure how this will effect the overall usage but surely this is the most future-proof option that I can come up with.

Ideas?

[OutsourcedGuru]

@dougwilson Sorry if I hurt your feelings, Doug, that wasn't my intention. My aggravation would be for JADE's lawyers rather than for anything you've done to make things work.

[thamaranth]

Why not do both a no default option and default to pug? As a teacher, I think it's good to default to a language that is similar to HTML because it's basic and easy to read.

[dougwilson]

Hi @thamaranth thanks for commenting! I'm not sure what your suggestion mean, can you explain? When you run the command, it can only do one thing by default, so I'm not clear on how it can default to both nothing and to pug at the same time.

[thamaranth]

@dougwilson I apologize. I think it should default to pug, but there should be the option to have no engine as well.

[Gchesta]

Nunjucks.

[jamg44]

2. hbs

[mykeblack]

agree with @thamaranth - have it default to pug because it lowers the barriers to entry for new users and then have a --noviews configuration option if you want to leave that part out. From a pure programmer viewpoint this would create implicit dependencies, but from a usability perspective for beginners, it would be one less step on a very steep hill to learning this technology.

[luckylooke]

#4 👍

[ahtee]

by default, should the command line ask if you want to use pug or any templating engines? and display the list? by default, the default selection will be no templating engine or something...

What is the current plan to migrate this? Migrate to pug or ask if templating is to be used?

[DivyanshBatham]

Any updates on this? I can happily send a PR to migrate the current default from jade to pug (As jade is now called pug).

[DivyanshBatham]

Another option is to make the user pick the View Engine with an interactive Command-Line Menu.

[1323ED5]

I vote for hbs

[ghost]

This debate can go on forever, as people are voting for their preferred engine. The simple -- and best -- answer is to go with 4. Everybody's second vote. If not, here's why 3. (EJS) makes the most sense.

Popularity

EJS currently has the widest audience on NPM by a large margin.

Any other option is inconsistent with Node and Express

Using a template engine that introduces different syntax/structure makes little sense. Embedded JavaScript is similar to ERB - used in Ruby on Rails - and, IMO, should be the default in a server-side JavaScript framework.

Some candidates are inconsistent altogether (to me)

Handlebars, for instance, tries to "separate concerns" as if this is the HTML/CSS that's in the browser. Yet, it lets the use of some logic in the templates through if blocks, for loops, and custom helpers. Also, even if it was consistent, why separate them in a template engine? It spits out pure HTML anyway, which itself is enough separation of concerns for the end product. If the reason is to be portable, I can't say much other than to show EJS's popularity.

Again, I believe 4. makes the most sense for an unopinionated framework. I can make a PR real fast if we come to a conclusion.