Hacker News Reader

Comment by weego | Hacker News Reader

Remember when we were worried about the semantic purity of our HTML.

I don't know that "semantic" is what you mean here.

Semantics in HTML is about exposing the meaning of content through the DOM. Adding data-binding via attributes doesn't change that at all.

    <label>Name <input type="text" [(ng-model)]="model.name"></label>

still encodes just as much semantics as

    <label>Name <input type="text"></label>

I think what you might have meant, as mariusmg mentioned in a sibling comment, is "separation of concerns"? Personally I think that has diminishing returns as your application gets more complex. It's very difficult not to still have tight coupling, just hidden under a layer of indirection.

I think it's more like "syntactic" then semantic.

      <input type="text" ng-model="model.name">

Is syntatically valid HTML, although ng-model may not be a legal attribute name in standard HTML. On the other hand:

      <input type="text" [(ng-model)]="model.name">

Isn't even syntactically valid HTML. It kind of rubs me the wrong way too, although I don't know if it matters in practice, although I'm not sure it doesn't either. It does seem ugly.

I'm not sure you are correct. According to the w3 spec for HTML attributes [0], html element attribute names must consist of one or more characters other than the space characters, U+0000 NULL, """, "'", ">", "/", "=", the control characters, and any characters that are not defined by Unicode.

Granted, it isn't necessarily what I'd expect to be legal, but it doesn't look illegal either. We may just need to add some logic to HTML colorizing syntax checkers in our IDEs is all.

[0]: http://www.w3.org/TR/html-markup/syntax.html#syntax-attribut...

interesting!

To emphasize what you are saying, on multiple occasions the Angular team has said that they chose this new syntax because it is valid.

It's illegal. Go to your console and type el.setAttribute("(foo)", "bar") and see what happens.

No it is not. See the discussion here: https://github.com/angular/angular/issues/133

What there contradicts what I said? I'm aware of innerHTML hacks that make it possible to work around but those are not valid attribute names. I'm not even against the syntax; i like it, but that doesn't change the fact that it is invalid html.

Parent quotes the W3 Spec to prove that it's legal, and your response is "it's illegal because $BROWSER say's so"?

I trust the spec more than an implementation.

The parent didn't quote the spec, they quoted a GitHub issue with 71 participants. If you want to post a link to the spec text please do.

If true I'm not sure it matters if every browser throws an exception.

User pfooti's comment referenced the specification[1]. You said that a browsers' implementation of the DOM API proves that it is illegal. I then linked to an issue with a detailed discussion of how the DOM API isn't consistent with itself, much less the HTML specification.

[1]:http://www.w3.org/TR/html-markup/syntax.html#syntax-attribut...

Others have pointed out that it is in fact syntactically valid HTML. It's also worth mentioning that this is syntactic sugar, and you can get the same behavior with:

  <input type="text" bindon-ng-model="model.name">

Similarly, property bindings surrounded by brackets "[myprop]" and event bindings surrounded by parens "(myevent)" are equivalent to the following:

  <input type="text" bind-myprop="model.foo" on-myevent="bar()">

All of angular2's template syntax can be replaced by more normal-looking tag properties with "reserved" prefixes that tell Angular what to do with them.[0] The less verbose symbols are probably easier for the eye to parse than the long forms once you're used to them, and either form can be easily analyzed and highlighted by an IDE.

[0]http://victorsavkin.com/post/119943127151/angular-2-template...

Remember separation of concerns ? Fuck that, let's just mash code and markup together.

What concerns do you think you're separating exactly, when you're dealing with presentation-tier markup and code that combine intimately to a single component?

I think a lot of the people worrying about this separation of concerns, and feel it's such an obvious problem that they don't even need to expand on it at all, are probably people who had to deal with hideous PHP (in the unenlightened days before Laravel, let's say) where views, business logic, and everything else get snarled up together in a horrible mess between some opening and closing PHP tags.

I had similar worries when I first saw JSX. Having used it quite extensively, though, it does feel like it's a sensible idea now, from a development perspective at least. That said, it does increasingly feel like the days where certain people could just write HTML and CSS, and other people could handle the trickier JavaScript, are long gone (especially with things like Radium for React).

Business logic should still remain separate. This would be display logic.

The fun part is that Angular (1, anyway) has pretend-separation. Sure, there's truth in DOM, but not really. Littering your custom directives all over the place may feel like progressive enhancement but if you're using an app framework like Angular your JS is likely already complex enough that you can't meaningfully consider it a mere "enhancement" -- we're talking core functionality, not fairy dust.

People react (heh) strongly to React's JSX when they first come across it but at the end of the day I find React far more honest in its approach. Your Angular templates don't really gain anything from looking like they're just HTML templates -- instead you end up either serializing your data into some kind of string format or faffing about with magical nested "scope" objects (as if JS scoping wasn't enough to keep in your head).

But in order to maintain that illusion you also have to buy into these huge layers of added complexity when writing your own directives. I'd rather go all the way back to steamrolling the DOM with Backbone templates than these pretend-semantical lumps of custom elements and attributes.

Sorry for ranting. I'm still sore about being burned by Angular.

How exactly were you "burned by Angular"? Many of us here are using it very successfully. And no, you don't need to "serialize your data into some kind of string format" (at least in the sense that you would never flatten JS objects into serialized strings in order to work with them). Scopes definitely take some getting used to, but they are not magical.

Reply on news.ycombinator.com