RFC 0016-remove-inline-templates - do not deprecate!

[lauxley]

(It's not super clear where I should talk about RFCs)

What problem does this feature solve?

About RFC https://github.com/vuejs/rfcs/blob/master/active-rfcs/0016-remove-inline-templates.md
I don't understand why come back from the very reasonable decision taken in: vuejs/vue#2765.
As stated multiple time before, what makes vue.js so attractive and powerful for us backend developers is that it does not force us into having the logic on the frontend side, or use js tools. The most important for us is the same as everybody else, maintainability, but it means for us that the html has to be in the same place and looks decently nice, which is exactly what inline-template does for us.

The biggest issue with inline-template is that it makes template scoping very inconsistent.

Nested scopes/contexts are not inconsistent, they exist in most template languages and make perfect sense (in my opinion).

The proposed replacements feel like hacks and I personally wouldn't want to use them for everything I do in vue.
I believe a large portion of vue.js user base are backend developers because of this feature, don't make us change framework please..

What does the proposed API look like?

Don't touch the inline-template api, it works.

[thecrypticace]

The point about nested scopes is that they're not possible with inline-template. As soon as you have an inline template you cannot reference anything from any outer scope.

inline-template can be entirely replaced by using v-slot in Vue 3 (and in Vue 2 for the most part as well) and does not have any of the scoping problems but keeps the inline compilation support that inline-template provided. I use v-slot in place of inline-template in many places due to having a mix of server-rendered and client-side-rendered behavior.

The only thing I've encountered, in Vue 2 at least, when using v-slot as an inline template replacement is that having to manually define a render function w/ all the appropriate props is a bit inconvenient b/c of the need to list computed options explicitly (proxy's can work around this limitation but then you're out for IE 11 support if you need it).

An API made to simplify inline-template -> v-slot scoping at the component level could be a nice transition point. Maybe something like a higher-order component that will handle the edge cases here w/ regards to computed props, injections, etc… I'd also say that w/ the new setup method + composition API + support for returning render functions this is less likely to be necessary but could likely still be wrapped if it proved to provide a better API.

[yyx990803]

The ship has already sailed. Reiterating what's been discussed doesn't really make any difference, unless you can provide a reason why the proposed replacements in the RFC (in particular <script type="text/html">) do not work for you. ("I'm used to the old API" is not a valid reason)