[Suggestion] [2.0] - Inline Templates

[taylorotwell]

Is there a deeper technical reason for why inline-template can't be supported in Vue 2.0? A couple reasons for my interest. First, it makes it easy to get people attracted to Vue when we can demo some component stuff quickly using simple inline-template syntax for a component on a single page without having to do any ES6 compilation or anything like that. Secondly, it makes user experience (as in customer end-users) better because I don't get any weird flashes where stuff is loading behind the scenes.

I recently used it extensively to build Laravel Spark where I can use inline templates which allow me to export the "HTML" files into a vendor directory that purchasers of the scaffolding can easily edit without having to worry about JS compilation, etc. and can basically act like they are typical HTML pages.

I know it might not be the most "technically correct" approach in the eyes of more elite JS developers, but just speaking as a common person, it was fairly useful in several situations.

Was curious if there was some deep technical reason for why the syntax can't work with the other new Vue 2.0 stuff or if was being removed only for the reason that it's considered "bad practice" among some developers?

[phroggyy]

To add to this, I'd like to point out that inline templates is something that sets Vue apart from other frameworks. A lot of other JS frameworks will want you to write your templates in template files and compile them, but in Vue, you don't have to! This is something that makes Vue feel all the more magical; you have an existing template, but you want some reactivity and clean JS in there, so you wrap it in your custom tag, like <card-payment>, write the JS, and you're done. You use the server-side rendering and variables that you already have, and if you want, you can of course start migrating it to an API-based template. Furthermore, this also allows for much more comprehensible server-side routing.

I think what's crucial here is that Vue is something that can be added afterwards. You don't have to make a Vue project, you just start a project, and then pull in Vue, and to me that's always been the charm with Vue over e.g Angular or React.

[azamat-sharapov]

Hmm, maybe it could be a plugin? I personally don't use it at all. I think it's mostly useful, when template is partially rendered on server.

[phroggyy]

@azamat-sharapov indeed, and that is exactly the point. That's always what made Vue great to me, that I as a backend developer can still easily declare all my routes and functionality in the backend, and render the views there, and use JavaScript for its original intent – interaction.

[JeffreyWay]

@azamat-sharapov Tons of developers are doing that very thing. It's what makes Vue so special. It can adapt to whatever style of project you're working on.

If this is being removed solely because it's "bad practice" ... well, meh. It was awesome, and never bit me even once.

If inline-template and filters return, I will be very excited for Vue 2. Until then, I'm mostly stressed about the upgrade.

[agc93]

Especially surprising that inline templates (so useful for server-side rendering) are being removed in the same update that promises improved server-side rendering support.

[phroggyy]

@agc93 that in itself isn't very surprising. The goal of the server-side rendering was to have it non-blocking and streamed to your Vue instance rather than having the user wait for it to render before anything else can happen. Regardless, I find it a travesty.

[azamat-sharapov]

promises improved server-side rendering support

@agc93 no, I think that is completely different thing. In 2.0, Vue.js can work in server, itself, to render templates.

@JeffreyWay @phroggyy agreed. I was active PHP/Laravel user myself earlier and I know many people use it. But there should be some technical reason to remove it, at least to avoid increased size of library maybe. So, if it can be made plugin, that probably makes everybody happy then :)

[jackmcdade]

We use inline templates everywhere in Statamic 2 for the very same reasons @taylorotwell does with Spark - it provides a great middle-ground between PHP and JavaScript when you're not building SPAs. I want to understand and follow best practices, but this one is literally one of the reasons we love using Vue.js.

I can't even imagine how I'd approach what we're able to do with Vue without them. The thought of it is kind of making me panic a little.

[nirazul]

I'm so glad that I'm not the only one who feels like that. Vue is so magical because I can use it for CMS project and SPAs. You can't imagine how glad I was when I could use vue with inline-template within a CMS project for the first time and it just worked!
I'm quite sure that the removal of inline-template will make it impossible for me to use this framework in half (or more) of my projects. This leads again to the sad sad circumstance that I'll have to maintain/learn two different systems of frontend frameworks. inline-template is just a sublime piece of API in my opinion and there should be a really really good reason to remove it, as well as some possibility to support it as a plugin.

I see v2 just like JeffreyWay (wow, hi there btw!): Keep (a simple variant of) filters and inline-template and I'm happy. Keep (or implement) some sort of global event bus and I'm really looking forward to the next version!

[phroggyy]

After talking about this with @rizqidjamaluddin, he pointed out that you can currently use

<script type="x-template" id ="foo">
    <div>
        You can place your template here
    </div>
</script>

And then in your JS file you can just do

var FooComponent = Vue.extend({
    template: '#foo'
})

So an important question now is if Vue 2.0 will break this behaviour as well, e.g is this kind of templating considered inline-templating, or would this be a viable upgrade path?

(docs for reference)

[nilssolanki]

At my place of work, we do a lot of projects with Django CMS. inline-template, and custom delimiters for that matter, made it possible to declare vue components within the backend templates and was in a way our "server-rendering".

Without this possibility, we couldn't do any frontend-editing in the CMS anymore, thus it would effectively break. Apart from that, we would probably have to switch to an approach closer to SPAs, which would mean a lot more development work on the backend (defining APIs, etc.). Thus using vue might become a budgetary liability as well (at least, until we've adapted to these procedures).

[JosephSilber]

This is most definitely NOT an inline template, and there's been no indication that it would ever be removed.

[taylorotwell]

@phroggyy that's not quite the same convenience or functionality as pure inline templates.

[phroggyy]

Thanks for clarifying that @JosephSilber. @taylorotwell it might be the same, but it is quite similar meaning it might be a viable upgrade path, maybe.

[brendanbowidas]

Using inline-template is the only way I was able to get one of my projects working on IE because it doesn't support the template tag.

[seanhinkley]

i use inline templates quite a bit in a handful of spring 4 / thymeleaf apps, one of the reasons why i've been using it. i think the availability of them makes vue super flexible, can drop component on a legacy page to add some additional functionality without having to rebuild it or redo the build process.

[adamwathan]

@phroggyy The one thing that's different between using an inline-template vs. a template in a script tag is that an inline template is already rendered when the DOM loads, so there's no flicker. A template in a script tag still needs to be parsed by Vue and injected into the DOM after the fact, so you have an empty space that gets populated after the fact which sometimes looks a bit janky, even being able to use v-cloak to minimize it.

It stands out most to me when you have a component that needs to perform an AJAX request on load, so you want some sort of loading state displayed while the HTTP request happens. With an inline-template, that loading state can be shown as soon as the page renders, and wait for the HTTP request to finish. With any other approach, you get a white flicker before the component compiles and switches to the loading view that's waiting for the HTTP request. There's no easy way to share the same loading view from before Vue compiles with the view that needs to be displayed after Vue has compiled but the AJAX request is still happening.

[jackmcdade]

@boussou instead of +1, you could/should thumbs up the original post. Thanks, Github!

[boussou]

I did nt notice this new feature. Github almost becomes a dev FB

[kaorun343]

I didn't use inline-template at all, so it surprised me that there are many people who don't want the syntax be removed from this library. Reading your comments, I understood that it gives us some benefits.

1. I understood that those who utilizing it would like to combine logics and templates in their own ways. Is this correct? How about creating component constructors for each items like the example, instead of writing it to your templates?
2. Are there anyone here who think about the reason why inline-template is treated as a bad practice?

// example
var Base = Vue.extend({
  data: function() {
    return {}
  },
  methods: {}
})

var app = new Vue({
  components: {
    ComponentA: Base.extend({
      template: "#templateA"
    }),
    ComponentB: Base.extend({
      template: "<div></div>"
    })
  }
})

[zigomir]

I was confused with this deprecation as well and first thing I tried was testing it. This codepen uses latest vue 2.0 build: http://codepen.io/zigomir/pen/KzGywb

Using template still works here. I think @yyx990803 was referring to this feature: http://vuejs.org/guide/components.html#Inline-Template

I might be wrong, but I'd really like to clear out this first.

[JeffreyWay]

Right, the template property will still work. But that's not related to using inline-template.

[thelinuxlich]

I think it should be shipped as a separate plugin.

[adamwathan]

Out of curiosity, why is the standard Vue "hello world" sort of example considered fine, but inline-template is considered bad practice? Isn't attaching a new Vue object to existing markup conceptually just inline-template anyways (with some additional limitations)?

http://codepen.io/anon/pen/BKqmYq

[yyx990803]

So to clarify it a bit, the main reason I labelled it "bad practice" was assuming an SPA context in which I believe the collocation of a component's template and its logic is important for longer term maintainability. However I do admit that I overlooked the use case for progressive enhancement on largely server rendered apps. TBH this is not something I personally use Vue for so I didn't realize there's such a strong need for this feature. Technically it's not that complicated to support, so we'll bring it back.

[taylorotwell]

[mikewuu]

To everyone using inline-templates for a mainly server rendered site, is there a better solution than binding all our components in the global namespace? I've tried using Laravel's @include to place it in the footer, but that only allows one script at a time. Any suggestions?