Hacker News Reader

Comment by bvcqw | Hacker News Reader

Why not just use Angular?

Because not everyone wants to define application behavior in markup.

I might be misunderstanding you but Angular behaviour isn't defined in markup. The views are, as well they should be, but they're just representations of the model behind the scenes.

http://angularjs.org/#todo-html

This just does not jive with me. My template knows that submission should be handled by `addTodo()`? Or even worse, looping. I want all of my logic to live in code, not some abstract framework specific attributes that don't add much in the way of clarity (context switching between template and view just to follow the workflow, for example).

I use (and love) Backbone because the DOM is considered a pure presentation layer, nothing else. Any behavior, logic, whatever that the code controls is defined only in the code.

To each his own. I don't think it's that big of a deal either way.

You don't actually have to do it that way in angular if you don't want to. You can put it all in code instead. The framework specific attributes you're looking at aren't exactly framework specific, they're kinda application specific (just happens they ship with the framework).

You can write your own ones to move any of that stuff into code instead of markup. I personally think that loops should be in markup - I happen to prefer templating systems with less restrictions.

>My template knows that submission should be handled by `addTodo()`? Or even worse, looping.

Most template engines support loops. Would be very weird without that capability, really.

Also, you have to add hooks to buttons and the like somehow. There isn't much of a difference between adding a class like "js-addWhatever" or using Angular's in-your-face approach.

you have to add visual styles somehow too. you might as well add them right in the html attributes, along with the <font> tags and <center> tags. We'll have js-addToDo and class="white big helvetica" and call it a day.

The best thing you can do is to connect those parts by one semi-generic identifier. There is no actual difference between using a class, an id, a data-attribute, or a ng-* attribute as hook. If you want to rename it, you have to rename it. If you want to move things around, you have to move them around. There is no way around it.

Your template will also use names of properties, arrays, and objects directly. There also isn't a way around that.

At some point you have to connect your pieces. They can't float around in mid-air forever.

The presentational things you mentioned are different. We can separate those things more, we can use abstractions, and we can make it extremely reusable.

I think you missed my point. Unless you really think there's no difference between naming an html element, and giving it an inline named function handler.

There is no difference. There is one identifier which ties them together. If you change that identifier on one side, but not the other, it will stop working.

It doesn't matter if that identifier is a class or something else.

Well, if it's a class people may feel inclined to reuse that identifier on the CSS side, which is a bad thing, because now you've tied 3 parts together instead of just 2. If I use classes for this, I prefix them with "js-" to indicate that they are only meant for scripting purposes.

with performAcceptanceRoutine(), that cooresponds to an actual global javascript function that must exist, and specifies how (imperative) not what (declarative).

With a class "acceptButton" you are specifying what it is, semantically and declaratively, without reference to some specific procedure that will be carried out, if anything will be done at all. This frees up to a great degree the range of code that you can write to "activate" This html, and also, makes it so that the HTML is not bound to some specific code base, and it can be parsed in situations that explicitly ban javascript.

> It's agnostic to ... if you render your HTML on the client or the server

I love Angular, but if you are rendering server side HTML (either as partials, or bootstrapping a page) it is currently lacking.

Flight is rendered server side? I must have missed that.

Okay, in that case I can see a need here.

Flight doesn't care where things are rendered.

> It's agnostic to how requests are routed, which templating language you use or even if you render your HTML on the client or the server.

Different purpose. This is for building reusable UI widget components.

Why not just use Ember?

There is a very nice thread on Quora comparing both Angula and Ember. One of Ember creators also participate with good insights

http://www.quora.com/Ember-js/Which-one-of-angular-js-and-em...

Why use anything when you could just hire a web developer?

Because it will "just fit" with corresponding Bootstrap assets, I'm assuming... I don't know if it does that now, but I'm assuming both frameworks will eventually share the same conventions and opinions so that developers can use them in tandem without too many extra ateps

Both of the Bootstrap developers left Twitter a few months ago and AFAIK they are still the ones developing Bootstrap.

While it is possible that they are collaborating with the current-Twitter developers working on this thing, it doesn't seem like much of a sure thing.

Why not just use KnockoutJS?

You can end up with a hard to maintain code with knockout.js if you don't structure it well. I found https://github.com/danderson00/knockout.composite recently that seems to adopt a similar philosophy (pubsub) to what Flight does while keeping the benefit of knockout.

I've used this knockout extension to great success [1]. It's intuitive, it leverages knockout's internal pubsub, and fits in with the KO ethos. It can be used to synchronise observables across models (which is awesome as it's events without overhead), or as a general purpose event system.

Ryan is one of the core contributors to knockout, by the way, so you can be assured of its quality.

[1] http://www.knockmeout.net/2012/05/using-ko-native-pubsub.htm...

IMO the real question is why use KO when you know Angular? (except perhaps for the lib size)

Really, I was using KO and it was really nice at the time but since I've tried angularJS I don't see a reason to go back to KO.

Two way binding without ko.observable/ko.observableArray/ko.computed, just plain js objects is really a big win.

Reply on news.ycombinator.com