The article is interesting, although with a bit different perspective than
mine. Here's my take on the issue.
I think the perspective I've mentioned is about the proper abstraction. And
proper separation of concerns You say (or I think you do) that the goal of
your JavaScript code is to produce HTML code.
You say in your article that "Angular JS is a template language". I totally
don't see it that way, I see it as a "framework to write library code in".
Let's go with a crazy hypothesis. My wife should be able to build a
website. No programming skills, she knows how to click on things, drag and
drop and type stuff.
And she needs to produce this:
<header>Hello, David</header>
Basically, it's a <header>Hello {{ username }}</header>, in Angular terms.
Or as the component (simplified):
@Component({ selector: 'greeting-header', template: '<header>Hello,
{{name}}</header>' })
class Greeting {
@Input() name: string;
}
But since my wife doesn't know HTML, JavaScript, or anything, she would
have to have the Visual Studio, right? Drag and drop, simple as that.
Drag a nice little header block. And add a name.
What I've liked about the AngularJS (Angular 1.x) and some libraries before
that (like YUI and others) is that you could extend existing HTML tags and
add your own elements. But for me, this somehow resonated the best when I
first tried Polymer (and the wider concept of Web components).
Web Components standard tells me *explicitly*: go write new HTML tags.
What I do then is _I'm writing those components she's using in Visual
Studio_, not producing HTML. So, I'm not writing HTML, I'm writing things
as extra little buttons in Visual Studio. I'm not even writing for that,
as my wife may be using another IDE or a web tool or a text editor like vim
- the point is, she doesn't know HTML, she knows about blocks.
What I'm writing is, ultimately, Chrome code. Just not in C++.
Then she's using those components.
You have a native tag, say <input>. It has a simple declarative way to
specify it's details: type="text", minlength="3".
What I've given you up there is <greeting-header name="David"/>, right?
(I know, close that tag properly, but for brevity.)
So in Visual studio, when my wife is "programming", the "website" above
(couldn't resist it all :)), if she needs to drag an input block, there's a
popup or dropdown or something asking her for type. And for my
greeting-header, she needs to say what name. But she doesn't know the name
upfront. What she does know, though, is the variable name in the database
"sheet" she's pulling the data from: username. Hence, Visual studio is
asking her: specific name? (It would be <greeting-header name="David"/>)
No, she says.
Then, VS asks, from where should I pick the name? `username`, she says.
<greeting-header [name]="username"/>
So, for me, I'm trying to wear two+ hats when doing a webapp: 1 is a
library dev, who's creating components for my other selves to use, and the
other hat to use simple HTML tags, and simple HTML really, to get those.
So in my head, when I'm writing a template, I'm writing just HTML, I don't
care about JavaScript, API's, Observables etc. It's all just syntax.
Now, your article mentions that templates go crazy with branching, loops
etc. Let's just take _if_.
Hello, <span *ngIf="name">{{ name }}</span> <span *ngIf="!name">you</span>
(Ignore the fact that we can {{ name || 'you' }} for a moment.)
Right? Well, one way to remove that if is to have "name" ready right away,
in that calling component. But since "name" here is not HTML, but rather
_data_, let's do it in the programming part of the webapp - in JavaScript
(or TypeScript, whatever).
In this case we just default the name. There, if is gone. Because again,
separated my data management (in a programming language) from building
blocks in visual studio for my wife (HTML).
Compare that _if_ with your DSL example.
function greet(name) {
const label = 'you';
if (name) {
label = name;
}
return <header>Hello, {label}</header>
}
How is that different from
@Component({
template: `Hello {{name}}`
})
class GreetComp {
@Input() name = 'you';
}
(And I don't mean different by "this is functional, and the other.." thing.
I'm talking about logic.)
But say we have a bit more complex thing. If user.role === admin, show the
button, otherwise hide it. So, <button *ngIf="isAdmin">. Conditional,
logic, programming, right?
How does my wife tell visual studio that? She's dragging in a button.
"But", she says, "please show this only to admins". Let's assume the visual
studio added a checkbox on the form. "Show only to admins". Works for
input, button, <greeting-header>, whatever. As she's dragging that box in,
she's checking the "admin only" thing. From this perspective one might say
the loop is not programming, and we're not "programming" in the template,
we're just checking a checkbox. So when you're in the template itself,
you're away from logic, just check that box.
I believe I could go on to a simple repeater, or handling of events. As
I've said, it's mostly a matter of perspective, and remembering to change
hats when opening different files.
But one could argue that since it's a conditional up there in the template,
or a loop, it's algorithmic, so it's programming. Well in that case, even
writing the spec for this website ("Greet user by name, if such, and if no
name, write 'you'") is programming.
But how does the DSL do it?
return <div> { isAdmin ? (
<button>
) : (
'No buttonz for you.'
)}
</div>
It's the same damn thing. (Except my poor Angular-fanboyi eyes hurt :).)
After writing all of this, I have two more things to add.
One thing is, I believe this is why I never really liked React as much as I
like Angular. Yes, Angular is perhaps more verbose and you need more files.
But it helps you sort your hats around. Dunno, I'll think about it the next
time I give React a try and give up again.
And the second thing to say, I wish I wrote my Angular like what I've just
typed above. Sadly, I don't. I'm lazy, or in a hurry, or simply automated,
not thinking, and I'm writing *ngIf="user.ole === 'admin'", and using all
sorts of shortcuts, and sometimes I'm programming in my templates. But I
bet you can do it in your DSLs too, if you try hard :)
P.S. Clickbait titles FTW! You have to fight for your statements and use
all means available :)
On Friday, July 28, 2017 at 12:51:43 AM UTC+2, Dave Ford wrote:
>
> I have given this spiel in recent meetups and no one tried to kill me, so
> I thought I would make blog post.
>
> Sorry for the overly click bait-ish title. I know this will be a bit
> controversial on this particular forum. But I would like to hear some
> opposing thoughts from some Angular folks.
>
>
>
> https://medium.com/@daveford/80-of-my-coding-is-doing-this-or-why-templates-are-dead-b640fc149e22
>
--
You received this message because you are subscribed to the Google Groups
"Angular and AngularJS discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.
