6 ms·

I like that Vue seems to be carrying Angular1's torch of "make it easy for non-programmers to write templates" but I feel like that has been an illusory strawma

by pluma 10y ago

I like that Vue seems to be carrying Angular1's torch of "make it easy for non-programmers to write templates" but I feel like that has been an illusory strawman from the start. Not only does it mask the fact that the supposed non-programmer template designer would still have to understand HTML and CSS yet somehow not have even the most basic knowledge of JS, but they would still have to be able to use whatever build tools are necessary to actually render those templates, including version control and node.js (which is the de facto platform for client-side build tools these days). The target audience seem to be old-school "webmasters" who FTP their PHP templates to the live server yet we're talking about technologies requiring a workflow that already precludes them. So we're talking about a scenario that only benefits people who already tick all the boxes for "front-end developer" except they apparently suffer from a nervous breakdown if they have to look at an if-block or understand a for-loop yet they'll be fine learning another template language that is typically based on JS expressions anyway (though Angular was guiltier of this than Vue). Maybe these people exist. Maybe there are teams where optimizing technical decisions for these people results in a net benefit. But I strongly doubt that this scenario is so widely applicable that this design decision makes a framework inherently superior when the cost of JSX to a team of JS devs is practically nil.

wojcech 10y ago
I am that person. Coming from an electrical engineering/Low Level programming background HTML is a Markup language. I get those. CSS is stylesheets and in my opinion very straightforward. The hard part is making designs that are functional and beautiful and making it cross browser compatible, but CSS has very few warts if the "wtf" variety JavaScript and it's ecosystem is disgusting for me. It's not hard, I can write stuff in it, it's ugly. I just don't want to touch it if I can avoid it. Pure personal preference. Typescript and elm help me to minimise the work I have to do in that mindspace. Maybe vue aims at similar clientele with less taste for statically typed/functional programming
- pluma 10y ago
  You admit you understand it and it's just a personal preference. Therefore you're not that person. The stated goal of making templating accessible to programmers isn't to shield people who don't like JS, it's to shield non-programmers who don't understand programming languages. This is the absurdity I'm arguing against. If it was just about making JS look different, there would be no need to use Vue in the first place.
  - goatlover 10y ago
    I thought the point also was not to mix the programming language in with the display logic, which was done a lot with PHP in the past, resulting in messy applications.
    - matt4077 10y ago
      Yeah, and that idea was always pretty stupid. They'd create some some new, terribly ugly, syntax. Maybe at first functions were limited, nut inevitably, they'd add connectors for every function in the "host" language (php/js/...). Or just something generic, allowing you to do something like <this-is-definately-not-a-programming-language native="Kernel.exec('sudo rm -rf /'"/>. OF course it meant you had to learn a new language, even though you were perfectly capable of perfectly suitable language already. But at least designers didn't have to learn "programming". There's no way around this. Templates need logic, mostly for loops (or maps, same difference), or dynamic formatting.
      - dpcx 10y ago
        Templates need some level of logic, yes. Putting the entirety of the business logic in your templates is not only bad, but dangerous. Because unless you're replicating your business logic in your non-template code, I can change things in the DOM, and potentially corrupt the system. Unless I completely miss the boat about how Angular/React/Vue/etc are supposed to be used. I only know from my previous years of seeing it done in the way I mentioned above, and every time, the work always ended up duplicated in the non-template code.
- mataug 10y ago
  You're not the only one who finds JS and its ecosystem disgusting.
- subpixel 10y ago
  Vue's single-file components (html, js, and scoped css) are super-appealing to me. The message is something like: "These concepts you understand and use all the time? We aren't going to make you abstract them away. We're going to use them as the foundation for a new way to build apps."
dismantlethesun 10y ago
> Maybe these people exist. Maybe there are teams where optimizing technical decisions for these people results in a net benefit. I've seen this reflected strongly in large companies on the east coast. Design staff is expected to know HTML/CSS, but aren't exepected to have more than a cursory understanding of javascript. Design will often start with HTMl prototypes, then do a handoff to engineering who will using a JS framework to wire it into the real app. Lately, though companies are swithcing to React, because JSX seems similar enough to HTML that people presume that design staff will be able to understand it.
- jdbernard 10y ago
  I'm in a startup using Angular for some of our stuff and we get the same benefit. Our primary design guy is able to create pages before devs wire them up, and make a lot of the UI changes directly himself without our help.
  - Roboprog 10y ago
    I hear you. JSX sounds like the wrong thing to me, as well. (but I'm also working on a long Angular 1 project at my job, so I "may" be biased) I REALLY like that Angular 1 allows you to simply make a mockup, then add the "programming stuff" behind the scenes. WITHOUT an enormous build chain (I have enough of that on the server side already, and the server is not Node for historical reasons - I'm not sure about node yet, and even if I wanted it, that just won't fly in my group) I'm not done yet, but I'm doing a presentation on this in December at one of the local user groups: https://github.com/roboprog/ang-prog-enh https://github.com/roboprog/ang-prog-enh
- pluma 10y ago
  I've had the misfortune to work with a Java developer who insisted he didn't know JavaScript and therefore wouldn't ever touch JavaScript code even if it would have saved everyone a ton of time. Yet at the same time the Java code would often generate HTML or even JS code directly. There are companies with stupid silos like this, but for the reasons I laid out I doubt they actually benefit from the "toy-language templates" approach -- even in the aforementioned company the non-developer designers would implement the entire layout as a mockup in HTML and then toss it over to a frontend dev who would cut it up and add the actual template logic (because although the template language was "easy" non-programmers couldn't be "trusted" to get the logic right).
g00gler 10y ago
How do you mean, "templates for non-programmers"? I see Angular's directives as a pure convenience compared to most every templating engine I've used across languages, never considered it something that makes it accessible to non-programmers. I'd actually think someone who only knows html/css would be more thrown off from a page with random, unsanctioned (by W3C), tags and attributes that may or may not reveal what they actually do. As a programmer I don't want to write long templates, I seriously prefer Jade/Pug for that reason. When I can't use them for a client I typically use them to do all initial work, compile them to HTML, then make whatever minor changes from there. Consider ng-for: <div data-ng-for="y in x"> <h1>{{y.title}}</h1> </div> The ASP.Net solution is a pain, a function with HTML string template to dynamically add elements to a "runat" div. This PHP example seems more idiomatic, at least to me, yet takes more to write <?php foreach($x as $y){ ?> <h1> <? echo $y->title; ?> </h1> <? } ?> The JSP style is kinda similar to Angular, again maybe more idiomatic at first glance but still not as quick/simple to write <c:forEach items="${x}" var="y"> <h1>${y.title}</h1> </c:forEach> The jQuery/plain JS solution, especially before ES6 is not preferable by any means, especially beyond this simple example. var body = document.getElementsByTagName("body")[0]; [...].map(function(y){ body.innerHTML += "<div>"+ "<h1>"+y.title+"</h1>"+ "</div>"; }); Unlike all the other solutions, angular has 2 way data binding so when you programmatically add elements to the array in ng-for, they are added to the DOM without a reload. So, is the goal of a programmer to simply write more code? If so, then Angular is definitely not for programmers. Is the goal of a programmer to solve problems? If so, Angular is definitely a tool for programmers.
- michaelcampbell 10y ago
  Unrelated question: was there a reason you swapped the iterator and container (x and y) in your angular example compared to the others? Just to keep 'x' before 'y'? It confused me a bit.
  - g00gler 10y ago
    No, I wrote it on my phone and didn't double check the angular example. I noticed another little mistake so I'll edit it

by pluma 10y ago

wojcech 10y ago

I am that person. Coming from an electrical engineering/Low Level programming background HTML is a Markup language. I get those. CSS is stylesheets and in my opinion very straightforward. The hard part is making designs that are functional and beautiful and making it cross browser compatible, but CSS has very few warts if the "wtf" variety JavaScript and it's ecosystem is disgusting for me. It's not hard, I can write stuff in it, it's ugly. I just don't want to touch it if I can avoid it. Pure personal preference. Typescript and elm help me to minimise the work I have to do in that mindspace. Maybe vue aims at similar clientele with less taste for statically typed/functional programming

pluma 10y ago
You admit you understand it and it's just a personal preference. Therefore you're not that person. The stated goal of making templating accessible to programmers isn't to shield people who don't like JS, it's to shield non-programmers who don't understand programming languages. This is the absurdity I'm arguing against. If it was just about making JS look different, there would be no need to use Vue in the first place.
- goatlover 10y ago
  I thought the point also was not to mix the programming language in with the display logic, which was done a lot with PHP in the past, resulting in messy applications.
  - matt4077 10y ago
    Yeah, and that idea was always pretty stupid. They'd create some some new, terribly ugly, syntax. Maybe at first functions were limited, nut inevitably, they'd add connectors for every function in the "host" language (php/js/...). Or just something generic, allowing you to do something like <this-is-definately-not-a-programming-language native="Kernel.exec('sudo rm -rf /'"/>. OF course it meant you had to learn a new language, even though you were perfectly capable of perfectly suitable language already. But at least designers didn't have to learn "programming". There's no way around this. Templates need logic, mostly for loops (or maps, same difference), or dynamic formatting.
    - dpcx 10y ago
      Templates need some level of logic, yes. Putting the entirety of the business logic in your templates is not only bad, but dangerous. Because unless you're replicating your business logic in your non-template code, I can change things in the DOM, and potentially corrupt the system. Unless I completely miss the boat about how Angular/React/Vue/etc are supposed to be used. I only know from my previous years of seeing it done in the way I mentioned above, and every time, the work always ended up duplicated in the non-template code.
mataug 10y ago
You're not the only one who finds JS and its ecosystem disgusting.
subpixel 10y ago
Vue's single-file components (html, js, and scoped css) are super-appealing to me. The message is something like: "These concepts you understand and use all the time? We aren't going to make you abstract them away. We're going to use them as the foundation for a new way to build apps."

dismantlethesun 10y ago

> Maybe these people exist. Maybe there are teams where optimizing technical decisions for these people results in a net benefit. I've seen this reflected strongly in large companies on the east coast. Design staff is expected to know HTML/CSS, but aren't exepected to have more than a cursory understanding of javascript. Design will often start with HTMl prototypes, then do a handoff to engineering who will using a JS framework to wire it into the real app. Lately, though companies are swithcing to React, because JSX seems similar enough to HTML that people presume that design staff will be able to understand it.

jdbernard 10y ago
I'm in a startup using Angular for some of our stuff and we get the same benefit. Our primary design guy is able to create pages before devs wire them up, and make a lot of the UI changes directly himself without our help.
- Roboprog 10y ago
  I hear you. JSX sounds like the wrong thing to me, as well. (but I'm also working on a long Angular 1 project at my job, so I "may" be biased) I REALLY like that Angular 1 allows you to simply make a mockup, then add the "programming stuff" behind the scenes. WITHOUT an enormous build chain (I have enough of that on the server side already, and the server is not Node for historical reasons - I'm not sure about node yet, and even if I wanted it, that just won't fly in my group) I'm not done yet, but I'm doing a presentation on this in December at one of the local user groups: https://github.com/roboprog/ang-prog-enh https://github.com/roboprog/ang-prog-enh
pluma 10y ago
I've had the misfortune to work with a Java developer who insisted he didn't know JavaScript and therefore wouldn't ever touch JavaScript code even if it would have saved everyone a ton of time. Yet at the same time the Java code would often generate HTML or even JS code directly. There are companies with stupid silos like this, but for the reasons I laid out I doubt they actually benefit from the "toy-language templates" approach -- even in the aforementioned company the non-developer designers would implement the entire layout as a mockup in HTML and then toss it over to a frontend dev who would cut it up and add the actual template logic (because although the template language was "easy" non-programmers couldn't be "trusted" to get the logic right).

g00gler 10y ago

How do you mean, "templates for non-programmers"? I see Angular's directives as a pure convenience compared to most every templating engine I've used across languages, never considered it something that makes it accessible to non-programmers. I'd actually think someone who only knows html/css would be more thrown off from a page with random, unsanctioned (by W3C), tags and attributes that may or may not reveal what they actually do. As a programmer I don't want to write long templates, I seriously prefer Jade/Pug for that reason. When I can't use them for a client I typically use them to do all initial work, compile them to HTML, then make whatever minor changes from there. Consider ng-for: <div data-ng-for="y in x"> <h1>{{y.title}}</h1> </div> The ASP.Net solution is a pain, a function with HTML string template to dynamically add elements to a "runat" div. This PHP example seems more idiomatic, at least to me, yet takes more to write <?php foreach($x as $y){ ?> <h1> <? echo $y->title; ?> </h1> <? } ?> The JSP style is kinda similar to Angular, again maybe more idiomatic at first glance but still not as quick/simple to write <c:forEach items="${x}" var="y"> <h1>${y.title}</h1> </c:forEach> The jQuery/plain JS solution, especially before ES6 is not preferable by any means, especially beyond this simple example. var body = document.getElementsByTagName("body")[0]; [...].map(function(y){ body.innerHTML += "<div>"+ "<h1>"+y.title+"</h1>"+ "</div>"; }); Unlike all the other solutions, angular has 2 way data binding so when you programmatically add elements to the array in ng-for, they are added to the DOM without a reload. So, is the goal of a programmer to simply write more code? If so, then Angular is definitely not for programmers. Is the goal of a programmer to solve problems? If so, Angular is definitely a tool for programmers.

michaelcampbell 10y ago
Unrelated question: was there a reason you swapped the iterator and container (x and y) in your angular example compared to the others? Just to keep 'x' before 'y'? It confused me a bit.
- g00gler 10y ago
  No, I wrote it on my phone and didn't double check the angular example. I noticed another little mistake so I'll edit it