5 ms·

everybody who feels so strongly about separation of code from templates - do you realize that down there it's still just bunch of string concat calls? it's lite

everybody who feels so strongly about separation of code from templates - do you realize that down there it's still just bunch of string concat calls? it's literally what ERB templates in Ruby compile to, and similarly in literally every other template language. rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is. it's one of the reasons i love clojurescript's hiccup so much - i'm still clearly writing idiomatic clojure code but now the boundary is not some arbitrary "this file is named .html and this .js", but actual namespaces/functions, where it's obvious from scope and signature what data my templates depend on.

pweissbrod 9y ago
I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for. Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together. You write html inside js? or sql inside python? omg noob! Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .
- emodendroket 9y ago
  My theory is that a lot of us have gone down this road, eventually found the thing getting unwieldy and difficult to maintain, and swearing never again.
newcomcjoe 9y ago
Vue 2 allows you to precompile your templates so you're not sending out a bunch of strings of data. Since it uses a virtual DOM, you can use a build tool to compile your templates down to the virtual DOM code to help your application run faster.
emodendroket 9y ago
That's not really the point of separation of concerns. It's for the benefit of programmers, especially maintenance programmers, not the machine.
- keymone 9y ago
  Did I suggest mixing presentation and business logic anywhere? My point was that forcing textual representation and another syntactic layer for presentation logic is unnecessary and harmful.
  - emodendroket 9y ago
    OK, but I don't agree. I think it is valuable to separate your template and behaviors associated with it for exactly the same reasons.
    - keymone 9y ago
      it is valuable to separate, but why is it valuable to force a different syntactic layer, often with heavy constrains on what logic can be expressed which inevitably leaks back into various helpers implemented in the layer you've just separated yourself from? why is it not better to separate using mechanics native to your language?
      - emodendroket 9y ago
        Because what happens otherwise is you eventually end up with a whole program written in your templating language.
        keymone 9y ago
        Templating is a bad term, it implies string generation, which is only a subset of what presentation logic is or is about. Taking that into account - if your presentation language is your program's language - I don't see the problem.
jordache 9y ago
>rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is. Just no. many times presentation code is tightly coupled with some desired functionality that drives that presentation. HTML inside JS is just inherently weird. It's one level of counter-intuitiveness to have the HTML set to some variable and put away and referenced further by the var. It's another level to have html in-line with JS method calls. The two languages just doesn't jive syntactically
- keymone 9y ago
  > HTML inside JS is just inherently weird. ... The two languages just doesn't jive syntactically that's because you can't escape the notion that DOM must always be represented as HTML and nothing else. [v]DOM is a very well structured entity, and it so happens that our programming languages love structured entities and manipulating them.
  - jordache 9y ago
    Who said anything about DOM? You/Me/We are all talking about HTML code.. I'm not talking about the mental model of writing DOM manipulation code. React still has user write actual HTML syntax.
    - keymone 9y ago
      DOM is what we're talking about. The fact that it's commonly represented by HTML and that somehow influenced how we ought to create/manipulate it in our code is exactly the problem. React has users write HTML-like syntax sugar that turns into createElement calls and i don't like that one bit. Hiccup[1] lets me write idiomatic Clojure code that represents DOM tree using convenient data literals and provides all necessary functions to manipulate it - and that i like. [1] https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup
hateful 9y ago
I love this quote straight from the vuejs documentation: "separation of concerns is not equal to separation of file types" https://vuejs.org/v2/guide/single-file-components.html#What-About-Separation-of-Concerns https://vuejs.org/v2/guide/single-file-components.html#What-...

pweissbrod 9y ago

I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for. Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together. You write html inside js? or sql inside python? omg noob! Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .

emodendroket 9y ago
My theory is that a lot of us have gone down this road, eventually found the thing getting unwieldy and difficult to maintain, and swearing never again.

newcomcjoe 9y ago

Vue 2 allows you to precompile your templates so you're not sending out a bunch of strings of data. Since it uses a virtual DOM, you can use a build tool to compile your templates down to the virtual DOM code to help your application run faster.

emodendroket 9y ago

That's not really the point of separation of concerns. It's for the benefit of programmers, especially maintenance programmers, not the machine.

keymone 9y ago
Did I suggest mixing presentation and business logic anywhere? My point was that forcing textual representation and another syntactic layer for presentation logic is unnecessary and harmful.
- emodendroket 9y ago
  OK, but I don't agree. I think it is valuable to separate your template and behaviors associated with it for exactly the same reasons.
  - keymone 9y ago
    it is valuable to separate, but why is it valuable to force a different syntactic layer, often with heavy constrains on what logic can be expressed which inevitably leaks back into various helpers implemented in the layer you've just separated yourself from? why is it not better to separate using mechanics native to your language?
    - emodendroket 9y ago
      Because what happens otherwise is you eventually end up with a whole program written in your templating language.
      - keymone 9y ago
        Templating is a bad term, it implies string generation, which is only a subset of what presentation logic is or is about. Taking that into account - if your presentation language is your program's language - I don't see the problem.

jordache 9y ago

>rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is. Just no. many times presentation code is tightly coupled with some desired functionality that drives that presentation. HTML inside JS is just inherently weird. It's one level of counter-intuitiveness to have the HTML set to some variable and put away and referenced further by the var. It's another level to have html in-line with JS method calls. The two languages just doesn't jive syntactically

keymone 9y ago
> HTML inside JS is just inherently weird. ... The two languages just doesn't jive syntactically that's because you can't escape the notion that DOM must always be represented as HTML and nothing else. [v]DOM is a very well structured entity, and it so happens that our programming languages love structured entities and manipulating them.
- jordache 9y ago
  Who said anything about DOM? You/Me/We are all talking about HTML code.. I'm not talking about the mental model of writing DOM manipulation code. React still has user write actual HTML syntax.
  - keymone 9y ago
    DOM is what we're talking about. The fact that it's commonly represented by HTML and that somehow influenced how we ought to create/manipulate it in our code is exactly the problem. React has users write HTML-like syntax sugar that turns into createElement calls and i don't like that one bit. Hiccup[1] lets me write idiomatic Clojure code that represents DOM tree using convenient data literals and provides all necessary functions to manipulate it - and that i like. [1] https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup

hateful 9y ago

I love this quote straight from the vuejs documentation: "separation of concerns is not equal to separation of file types" https://vuejs.org/v2/guide/single-file-components.html#What-About-Separation-of-Concerns https://vuejs.org/v2/guide/single-file-components.html#What-...