Hacker News Reader

Comment by ben336 | Hacker News Reader

I think its important to note with the perf test and download size stuff that the frameworks that are bigger/slower to render provide more functionality and more templating options respectively. Thats not to say they're better, but just trying to clarify the tradeoffs under discussion.

View on HN

That's not necessarily true. I can't speak for the jsperf test since it's not mine, but for the Mithril site tests, I exclude "optional-but-not-really" things like Marionette and ngRoute/ngResource/friends from the tests (whereas I include the entirety of Mithril - templating engine, router, etc) to try and tilt the tests in other frameworks' favor.

Sure one could argue that Angular has filters or whatever, but hey with Mithril you can express templating things that you can't with Angular (e.g. tables with nested loops, or w/ for-else constructs), so it's not really a apples to apple trucks comparison. With an order of magnitude more code, one has to wonder how much of that extra code is more functionality and how much is just bloat.

A big factor here is that Mithril describes templates programmatically rather than strings of data. It's the difference between:

  function render() { eval("(function () {}());"); }

and

  function render() { (function () {}()); }

These are going to run at much different speeds because one involves parsing multiple times while the other only needs to be parsed once. The tradeoff is some complexity (though there's also more flexibility too).

  <ul class="foo">  
    <li data-ng-repeat="item in items">
      {{item.x}}
    </li>  
  </ul>

  m("ul.foo", [  
    items.map(function (item) { 
      m("li", item.x);  
    });  
  ]);

Yep. I'd argue that Angular is far more complex though, with its `track by $index` and `ng-repeat-start`/`ng-repeat-end` and the scoping implications of caching filtered expressions in the view and the `ng-init` watcher trap and all that. But I digress.

> With an order of magnitude more code, one has to wonder how much of that extra code is more functionality and how much is just bloat.

Sorry but that is almost the archetypal FUD sentence of the 'micro framework'. And the more you analyse the 'lots of code must = bloat' sentiment, the more ludicrous it becomes.

Look at the docs. If you see functionality in Angular that you think is unnecessary then file an issue, or write a blog post explaining the alternative approach. Please don't spread lazy FUD like this, it helps nobody.

I did write a little bit about this in the comparisons page on the Mithril site ( http://lhorie.github.io/mithril/comparison.html ) and I am actually writing an article about this topic (specifically, about lessons I learned from using Angular that apply to Mithril) that I'm planning on publishing this weekend over at the blog ( http://lhorie.github.io/mithril-blog ). There's a feed you can subscribe to if you're interested.

There's also a reasonable amount of docs on the main site about the approaches that I do propose for various aspects of the MVC stack (e.g. see templating, components, etc).

I'm not saying more code is always necessarily bloat, but the correlation between code size and bloatedness does exist, whether you like it or not. I think what is ludicrous is to assume that all of the organically grown code over the years is somehow made up of only useful harmonious features.

Off the top of my head, I could immediately think of angular's directive system, and $scope as things that are probably far more complex than they should be, but these aren't exactly things you can "file an issue" for. So I did the next best thing and scratched my own itch.

Sure. Size is a con, functionality is a pro. The point is to correctly weight each. I don't really have strong opinion on what "correct" is, in the general case - I could formulate opinions confronted with specifics.

Reply on news.ycombinator.com