2 ms·

You can do script style templates, e.g. <script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script> Then when setting up you

You can do script style templates, e.g. <script type="text/x-template" id="component-name-template"> <div> {{ msg }} </div> </script> Then when setting up your component you specify the template property with the id, e.g. Vue.component('component-name', { template: '#component-name-template' }); Honestly though this sucks if you plan on reusing components. Can I ask why you don't want a build step? The single file components are great.

unclebucknasty 9y ago
Thanks. Yeah, I looked at that option too and agree that it does suck. :) Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible. I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name. Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components. EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic. The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.
- ElatedOwl 9y ago
  I absolutely had a lot of the same concerns, and I was just as confused as you as to why Vue wouldn't support remote url templates. That said, once I decided to roll with it, it took about a week* to get it configured how I have it now and have a decent understanding of how/why it was configured. *not a straight week of banging my head into webpack, but some bits of time here and there as I did development The one other thing that kind of pushed me over the fence into going down the build step route was that I get a minifier, a LINTer and get to use ES2015 (or typescript, or whatever) syntax. >"do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic. Totally valid concern and I see where you're coming from. Once I got into it, though, I realized the only webpack specific syntax is the configuration; how you link your JS files together is just through import/export statements (ES2015 and beyond module system).
  - unclebucknasty 9y ago
    That's good feedback. Yeah, I was really close. As with other frameworks, I do think Vue surfaces too much "old Web", but I also think it was the cleanest and simplest of the contenders. I could see it making dev at least somewhat more enjoyable, organized, and productive. >it took about a week to get it configured Funny, that's about what I thought it might take--a week of somewhat committed effort. Felt like we didn't have that to spare though, and wasn't 100% sure about the ROI on that time. Felt like a roll of the dice. Now, whether we'd have already recouped that week is an open question, and setting up a structured JS project was also no small task. But, likewise, we now have a good pattern/mini-framework with a component inheritance model. So, we're recouping that investment as I write this., and we're not tied to deep dependencies or magic. Next time out, I may have another look at Vue. But, I am really hoping for a more componentized-event driven model that completely abstracts the old Web. Even moreso than React, but with more simplicity and only JS or Typescript in the mix. Kind of a Swing for JS is the best analogy I can make.

unclebucknasty 9y ago

Thanks. Yeah, I looked at that option too and agree that it does suck. :) Just didn't want a build step due to complexity. I know it's not that difficult, but wanting to keep it as simple as possible. I don't really get why Vue opted not to support URLs for their templates. It could be easily managed via co-location of templates with components and/or naming conventions. You actually wouldn't even need to specify the URL. It just grabs it from the component's directory by name. Anyway, for me, this is a weakness. I get that they want to maintain the single file component model, but I'm not sure it's worth it when your choices are literals, script templates, or an extra build step. OTOH, co-locating a dependent file is no biggie, even if you don't get to claim single file components. EDIT: I was close to going with Vue for a project a month or so ago. But, wading into it, I realized the build step would be necessary to do it "right". Suddenly, you're downloading plugins, xcode, and all kinds of other stuff, then setting up a build. It just seems a lot for, essentially, single file templates. Granted, several steps are automated, and you're just issuing npm commands, etc. But, I started thinking, "do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic. The whole process was a stark reminder that you're in someone else's world. Maybe I'm too big on control. But, I don't want to be sucked into too many dependencies.

ElatedOwl 9y ago
I absolutely had a lot of the same concerns, and I was just as confused as you as to why Vue wouldn't support remote url templates. That said, once I decided to roll with it, it took about a week* to get it configured how I have it now and have a decent understanding of how/why it was configured. *not a straight week of banging my head into webpack, but some bits of time here and there as I did development The one other thing that kind of pushed me over the fence into going down the build step route was that I get a minifier, a LINTer and get to use ES2015 (or typescript, or whatever) syntax. >"do we really want all of this magic? What if the build just doesn't work one day or we need to reconfigure? Now we're troubleshooting and figuring out the linkages that were created and the other magic. Totally valid concern and I see where you're coming from. Once I got into it, though, I realized the only webpack specific syntax is the configuration; how you link your JS files together is just through import/export statements (ES2015 and beyond module system).
- unclebucknasty 9y ago
  That's good feedback. Yeah, I was really close. As with other frameworks, I do think Vue surfaces too much "old Web", but I also think it was the cleanest and simplest of the contenders. I could see it making dev at least somewhat more enjoyable, organized, and productive. >it took about a week to get it configured Funny, that's about what I thought it might take--a week of somewhat committed effort. Felt like we didn't have that to spare though, and wasn't 100% sure about the ROI on that time. Felt like a roll of the dice. Now, whether we'd have already recouped that week is an open question, and setting up a structured JS project was also no small task. But, likewise, we now have a good pattern/mini-framework with a component inheritance model. So, we're recouping that investment as I write this., and we're not tied to deep dependencies or magic. Next time out, I may have another look at Vue. But, I am really hoping for a more componentized-event driven model that completely abstracts the old Web. Even moreso than React, but with more simplicity and only JS or Typescript in the mix. Kind of a Swing for JS is the best analogy I can make.