7 ms·

I really don't get how separating templates is a good thing. Been there, done that. Not going back. Not going back to separate CSS either. Because having everyt

I really don't get how separating templates is a good thing. Been there, done that. Not going back. Not going back to separate CSS either. Because having everything together is great. Not to mention using JS for render logic. That's great too. It's what I always wanted. People kept pushing "best practices" on me—like not using the style attribute, separating templates—and I am so grateful for the people at Facebook for ending that. Like most articles about Vue.js—and I keep looking because I keep wanting to understand the appeal—there's never a clear explanation regarding why separating templates and not using JS for render logic is good. Maybe it's a matter of taste. For me, having everything about a component in one place is very convenient and simplifies abstraction and composability. Maybe I just need to try Vue.js to understand the draw. That was true for me with React. But React was a totally new paradigm for me. Vue.js seems like a combination of several familiar paradigms in a way that doesn't really make sense having gone React.

cjalmeida 9y ago
My experience is that the HTML CSS experts can more easily understand Vue components. So going back and forth between dev and UX is simpler with Vue.
jgalvez 9y ago
https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html
outsidetheparty 9y ago
Vue components have the html template, the javascript code, and the component's scoped CSS all in one file. You can define the template in a string, or even in JSX if for some reason you wanted to do that, or you can just use regular old HTML which is stored alongside the javascript that controls it and the css that styles it.
- deleted 9y ago
  [deleted]
- nkg 9y ago
  That is what I like the most in Vuejs : you have the choice.
  - kiliancs 9y ago
    This might not apply to the case here, where are talking about code style, but I find that in programming it is often good not to have a choice. More options means more decisions, more decisions means more complexity involved in completing a task, and it means more questions the next person reading or maintaining the code will have.
    - nkg 9y ago
      There are clear patterns in Vue that encourage you to put your filters, methods and every other piece in its place, but at the same time, depending on your deadline you can choose not to create a single-file component for every <li> and just use a <template> tag. I like that! I understand your point, though.
- pdfernhout 9y ago
  But a template is not "regular old HTML". HTML is a standard for declaring marked up text. What Vue and similar libraries do is make adhoc variants of HTML (all different) with extra looping constructs and if/then constructs and so on. The templates also require embedding snippets of JavaScript code in them -- code which standard JavaScript/TypeScript IDE tools don't know about and so can't refactor, validate, or navigate. These templates may look declarative because the look HTML-ish but they are not -- because of the embedded code that can call arbitrary functions in your application. The result is hard to debug and reason about. Where do you put a breakpoint in such a template? How do you abstract part of a template into a function? How do you add logging to such templates? How do you know what object is having its data accessed for templating languages like with Angular that do complex contextual lookups behind the scenes? How do you get code coverage reports? How do you get code completion? How do you get precise error reports? And so on. For more on why templates are a bad idea, see: https://blog.dantup.com/2014/08/you-have-ruined-html/ https://blog.dantup.com/2014/08/you-have-ruined-html/ That is why I feel these sorts of template-based approaches will eventually be discarded as obsolete for writing single page applications as web programming continues to progress (in favor of generating UIs directly from code). HTML-ish templates feel familiar to people with experience building progressively enhanced web apps by sprinkling a bit of CSS and JavaScript on top of HTML generated from a server -- but for single-page apps that spend most of their time converting JSON from a server into HTML (or just doing stand-alone activities), a templating HTML-first approach make little sense. You just don't need extra templating machinery that you need to learn and maintain and that just gets in the way of development. By contrast, consider the HyperScript API for generating HTML from JavaScript/TypeScript (as used in Mithril, Maquette, and optionally in Inferno and some other vdom libraries). For example: h("div", h("ul", h("li", "one"), h("li", "two"), h("li", "three"), someExtraListItems(), otherItems.map((item) => h("li", item.name)) ), isListEditable ? h("button", { onclick: editList }, "Edit extra list items") : [] ) If you use the HyperScript approach (especially with Tachyons.css or similar), you are just writing JavaScript/TypeScript/whatever and can leverage all of the language's features. JavaScript-first for modern SPAs!
  - ricksharp 9y ago
throwasehasdwi 9y ago
Separating CSS always seemed stupid to me, I was so happy when it finally became "best practice" to have inline styles within isolated components. HTML is the markup and as far as I'm concerned the styling is part of that markup. I don't understand how anyone ever thought CSS's style inheritance was a good idea. I don't mind HTML and even JS these days but CSS really needs to be sent straight back to hell where it came from.
- drderidder 9y ago
  One word: re-usability.
  - deleted 9y ago
    [deleted]
  - throwasehasdwi 9y ago
    the components should be reusable, not the styles on them. Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.
    - drderidder 9y ago
      For components, bundling the CSS makes sense. For other use cases external CSS resources with inheritance are very beneficial.See for example Scalable and Modular Architecture for CSS or any modern CSS framework for lots of examples.
  - joncampbelldev 9y ago
    reusing css is a great idea for websites, react and Vue are most commonly used for web app where the atomic unit of reusability is the component.
dabernathy89 9y ago
Single file components are extremely common in Vue. You can also render templates with JavaScript (although from what i've seen, this is much more intuitive in React than Vue)
- ng12 9y ago
  That doesn't solve the problem though -- you still have two sources of truth. Is this array processed in the template or the JS? Where does this crazy directive get called? How does the model get updated when you click some element? That mental back-and-forth becomes a huge pain in a big project. With JSX you never have to worry about it. For the life of me I cannot shake the feeling that Vue is just a simpler Backbone/Marionette. React was life changing because it actually solved the problems I had as a professional I-do-this-every-day web developer. I can't feel that way about Vue.
  - linkmotif 9y ago
    Have you tried Vue? I had that impression too—that it's like Backbone/Marionette—but people have told me it's not. I don't think you mess with the DOM and I don't think you refer to elements except for the root, like in React.
  - outsidetheparty 9y ago
    I don't know where you formed your impression of what Vue is like, but what you're describing is really not anything like it.
    - ng12 9y ago
      This is my impression of templates as a tool. I dislike Vue for the same reasons I dislike Angular and Marionette.
      - outsidetheparty 9y ago
        Ok... I mean, JSX is templates too; it's just a different syntax. Vue supports JSX if you prefer that syntax. I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.
sebringj 9y ago
Yes, I agree on separation being overrated. It was probably pushed to promote teams working on UI/UX and programmers with overlap but code being on its own. In practice, developers usually modify the css from how it is done from designers as in practice, things seem to change. You still get reuse but use it like a default export if styles are used in more than one place.
itslennysfault 9y ago
I'm in the completely opposite camp. Many small files are easier to maintain with large teams. The one caveat is the files need to be very well organized. I'm personally a fan of having a folder for each component with separate js/html/css/test files living side by side. In general, mixing html/js/css in a single file feels really dirty to me, but that might just be PTSD from a past life where I did a bunch of work on PHP spaghetti code with no separation of concerns.
- ableton 9y ago
  I agree. I am building a big angular 1 project right now and for every new component I make a new folder with three files - html template, sass, and javascript controller. It works the best in my opinion. Otherwise the files would just be way too big.
- marklyon 9y ago
  Even worse, I once worked in an environment where our web server was an Oracle database, serving snippets of pages from stored procedures on port 80.
chuckdries 9y ago
I like Vue because it puts style, markup, and template into the same file (single file components), but separates them in a way that's incredibly intuitive. I also love how simple Vue feels. Like it doesn't feel like it's doing any sort of dark magic under the hood, it just makes sense in a way that you can wrap your head around the entire thing in an afternoon, and that's refreshing. Also the docs are like really really good. The Vue guide is a better experience than the official Angular tutorials (don't even get me started on the non-typescript angular documentation). They're a huge strong point for this project, especially considering how young it is.

cjalmeida 9y ago

My experience is that the HTML CSS experts can more easily understand Vue components. So going back and forth between dev and UX is simpler with Vue.

jgalvez 9y ago

https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html

outsidetheparty 9y ago

Vue components have the html template, the javascript code, and the component's scoped CSS all in one file. You can define the template in a string, or even in JSX if for some reason you wanted to do that, or you can just use regular old HTML which is stored alongside the javascript that controls it and the css that styles it.

deleted 9y ago
[deleted]
nkg 9y ago
That is what I like the most in Vuejs : you have the choice.
- kiliancs 9y ago
  This might not apply to the case here, where are talking about code style, but I find that in programming it is often good not to have a choice. More options means more decisions, more decisions means more complexity involved in completing a task, and it means more questions the next person reading or maintaining the code will have.
  - nkg 9y ago
    There are clear patterns in Vue that encourage you to put your filters, methods and every other piece in its place, but at the same time, depending on your deadline you can choose not to create a single-file component for every <li> and just use a <template> tag. I like that! I understand your point, though.
pdfernhout 9y ago
But a template is not "regular old HTML". HTML is a standard for declaring marked up text. What Vue and similar libraries do is make adhoc variants of HTML (all different) with extra looping constructs and if/then constructs and so on. The templates also require embedding snippets of JavaScript code in them -- code which standard JavaScript/TypeScript IDE tools don't know about and so can't refactor, validate, or navigate. These templates may look declarative because the look HTML-ish but they are not -- because of the embedded code that can call arbitrary functions in your application. The result is hard to debug and reason about. Where do you put a breakpoint in such a template? How do you abstract part of a template into a function? How do you add logging to such templates? How do you know what object is having its data accessed for templating languages like with Angular that do complex contextual lookups behind the scenes? How do you get code coverage reports? How do you get code completion? How do you get precise error reports? And so on. For more on why templates are a bad idea, see: https://blog.dantup.com/2014/08/you-have-ruined-html/ https://blog.dantup.com/2014/08/you-have-ruined-html/ That is why I feel these sorts of template-based approaches will eventually be discarded as obsolete for writing single page applications as web programming continues to progress (in favor of generating UIs directly from code). HTML-ish templates feel familiar to people with experience building progressively enhanced web apps by sprinkling a bit of CSS and JavaScript on top of HTML generated from a server -- but for single-page apps that spend most of their time converting JSON from a server into HTML (or just doing stand-alone activities), a templating HTML-first approach make little sense. You just don't need extra templating machinery that you need to learn and maintain and that just gets in the way of development. By contrast, consider the HyperScript API for generating HTML from JavaScript/TypeScript (as used in Mithril, Maquette, and optionally in Inferno and some other vdom libraries). For example: h("div", h("ul", h("li", "one"), h("li", "two"), h("li", "three"), someExtraListItems(), otherItems.map((item) => h("li", item.name)) ), isListEditable ? h("button", { onclick: editList }, "Edit extra list items") : [] ) If you use the HyperScript approach (especially with Tachyons.css or similar), you are just writing JavaScript/TypeScript/whatever and can leverage all of the language's features. JavaScript-first for modern SPAs!
- ricksharp 9y ago

throwasehasdwi 9y ago

Separating CSS always seemed stupid to me, I was so happy when it finally became "best practice" to have inline styles within isolated components. HTML is the markup and as far as I'm concerned the styling is part of that markup. I don't understand how anyone ever thought CSS's style inheritance was a good idea. I don't mind HTML and even JS these days but CSS really needs to be sent straight back to hell where it came from.

drderidder 9y ago
One word: re-usability.
- deleted 9y ago
  [deleted]
- throwasehasdwi 9y ago
  the components should be reusable, not the styles on them. Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.
  - drderidder 9y ago
    For components, bundling the CSS makes sense. For other use cases external CSS resources with inheritance are very beneficial.See for example Scalable and Modular Architecture for CSS or any modern CSS framework for lots of examples.
- joncampbelldev 9y ago
  reusing css is a great idea for websites, react and Vue are most commonly used for web app where the atomic unit of reusability is the component.

dabernathy89 9y ago

Single file components are extremely common in Vue. You can also render templates with JavaScript (although from what i've seen, this is much more intuitive in React than Vue)

ng12 9y ago
That doesn't solve the problem though -- you still have two sources of truth. Is this array processed in the template or the JS? Where does this crazy directive get called? How does the model get updated when you click some element? That mental back-and-forth becomes a huge pain in a big project. With JSX you never have to worry about it. For the life of me I cannot shake the feeling that Vue is just a simpler Backbone/Marionette. React was life changing because it actually solved the problems I had as a professional I-do-this-every-day web developer. I can't feel that way about Vue.
- linkmotif 9y ago
  Have you tried Vue? I had that impression too—that it's like Backbone/Marionette—but people have told me it's not. I don't think you mess with the DOM and I don't think you refer to elements except for the root, like in React.
- outsidetheparty 9y ago
  I don't know where you formed your impression of what Vue is like, but what you're describing is really not anything like it.
  - ng12 9y ago
    This is my impression of templates as a tool. I dislike Vue for the same reasons I dislike Angular and Marionette.
    - outsidetheparty 9y ago
      Ok... I mean, JSX is templates too; it's just a different syntax. Vue supports JSX if you prefer that syntax. I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.

sebringj 9y ago

Yes, I agree on separation being overrated. It was probably pushed to promote teams working on UI/UX and programmers with overlap but code being on its own. In practice, developers usually modify the css from how it is done from designers as in practice, things seem to change. You still get reuse but use it like a default export if styles are used in more than one place.

itslennysfault 9y ago

I'm in the completely opposite camp. Many small files are easier to maintain with large teams. The one caveat is the files need to be very well organized. I'm personally a fan of having a folder for each component with separate js/html/css/test files living side by side. In general, mixing html/js/css in a single file feels really dirty to me, but that might just be PTSD from a past life where I did a bunch of work on PHP spaghetti code with no separation of concerns.

ableton 9y ago
I agree. I am building a big angular 1 project right now and for every new component I make a new folder with three files - html template, sass, and javascript controller. It works the best in my opinion. Otherwise the files would just be way too big.
marklyon 9y ago
Even worse, I once worked in an environment where our web server was an Oracle database, serving snippets of pages from stored procedures on port 80.

chuckdries 9y ago

I like Vue because it puts style, markup, and template into the same file (single file components), but separates them in a way that's incredibly intuitive. I also love how simple Vue feels. Like it doesn't feel like it's doing any sort of dark magic under the hood, it just makes sense in a way that you can wrap your head around the entire thing in an afternoon, and that's refreshing. Also the docs are like really really good. The Vue guide is a better experience than the official Angular tutorials (don't even get me started on the non-typescript angular documentation). They're a huge strong point for this project, especially considering how young it is.