delambo

The stats don't really suggest that vue is rapidly climbing in popularity:

https://npm-stat.com/charts.html?package=react&package=vue&p...

While popularity might not have anything to do with your use case, it still means a lot in terms of ecosystem, tooling, training, support and documentation.

In the React ecosystem, there are several really good tools for managing build, deploy, and test harnesses. See kyt [1] for example, or the list of Create React App Alternatives [2].

[1] https://github.com/NYTimes/kyt [2] https://github.com/facebookincubator/create-react-app#altern...

I think gmail was built using closure which is JavaScript. https://developers.google.com/closure/faq?hl=en#gwt

Again, thanks for the feedback. Right now, I'm literally putting together a pull request to improve this functionality.

Some cards do have links inside of them - they may have external source links or sticker links, and fortunately we just removed author links which will make this easier. I'm wrapping inner elements in hyperlinks which should fix everything that you mentioned.

As I mentioned, for the moment, you can use the card titles which are wrapped in hyperlinks.

I assume you are talking about the recipe cards not being links? It's tough to build a linkable card with links inside the card without using JavaScript. The actual html link is the title of the recipe so you should be able to use that if you really intend to not use JavaScript.

I'm in the process of putting together a pull request to make sure the link underline shows on hover (that worked at one point!) and to get middle-click working on the card for users that do use JavaScript.

Thanks for your feedback!

The best way to organize a mix in iTunes is to create a playlist with all of the songs, make sure the album title is the same for each artist, then select all of the songs and open the Info menu (CMD-I) and mark them as a Compilation. Marking them as a compilation will organize them on the file system together under the "iTunes/.../Music/Compilations/" directory, which hopefully will make migrating off of iTunes in the future an easier thing to do.

To that point, it's interesting how many claim that Backbone is yesterday's tech and that we are now 2 or 3 iterations of javascript frameworks past Backbone, yet most of these large sites are still using Backbone! It's possible that a lot of the sites would use something other than Backbone if they were built today, but it's clear that Backbone will be around for some time.

Even though Lebron James is the best player in the world, why is there a good chance that the Heat won't win the championship this year?

Also, could a team of Lebron James level players win a championship?

I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need.

"What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey

Another consideration is the projects that have been built with each framework. That can help you gauge popularity, where the jobs are, where you could get a job (or potentially poach someone from), and the capabilities of each library/framework:

http://backbonejs.org/#examples

http://emberjs.com/ember-users/

http://builtwith.angularjs.org/

Here's a trivial example:

I have a Modal class which depends on some utilities in a Utility class, but the Utility class depends on the Modal class because there are some utilities that show Modals.

This is not a broken architecture and is handled just fine by other programming languages/dependency handlers.

I used to think the same thing, but then I ran into the problem where my large app had circular dependencies which require.js/AMD does not support. Naturally, AMD supporters blame you and your project's architecture, but it is not uncommon to have some circular dependencies in a large app.

The work-around is to use require.js in commonjs style or to add hacks into your architecture. Not fun.

Agreed. I was laughing out loud at some of the analogies, but the author does make some good points -- it's really early in the client side framework evolution.

The subreddits I subscribe to:

http://www.reddit.com/r/javascript/

http://www.reddit.com/r/programming

http://www.reddit.com/r/worldnews/

http://www.reddit.com/r/DepthHub/

http://www.reddit.com/r/todayilearned/

http://www.reddit.com/r/AskHistorians/

http://www.reddit.com/r/IAmA/

Except for TIL and worldnews, this is a good mix since they all have about the same level of voting and activity.

Reddit is the unfiltered internet. I don't go there to get trustworthy news. The problem is any news source that quotes straight from Reddit - they should know better, and verify any leads before reporting.

The internet is raw, and people need to put their critical thinking hats on when digesting unfiltered data, speculation, and analysis.

I often search on "backbone" - docs are the first result. Same with "angular" and "ember".

Stickit author, here. To be clear, stickit will not make your "zombie views grow fatter" or contribute to any memory problems. In fact, stickit cleans up all of its model and view bindings automatically on view.remove(), and provides an optional api for manual cleaning view.unstickit().

The blog author's problem was a brief bug that was introduced and fixed between releases for the rare use case when a data-bound view is re-rendered. We fixed this problem and the author confirmed that the patch was "working great."

https://github.com/NYTimes/backbone.stickit/issues/66

So even though the problem was fixed for the blog author before he moved onto angular, he still claims that stickit causes memory problems. I guess a false claim like that makes the story of moving to a new framework more entertaining.

Another claim from the blog author is that stickit makes it hard to use third-party plugins like Chosen. Around the same time he filed the github issue, we were finishing and getting ready to release "handlers" and a new "initialize" binding which give you the ability to create global handlers for setting these kinds of bindings up. More on handlers here:

http://nytimes.github.io/backbone.stickit/#custom-handlers

... and an example of setting up a global handler for Chosen:

http://jsfiddle.net/px6UP/28/

Trek must have been a perl monk, back in the day.

I know this is slightly off-topic, but I've asked this before in comments and at the following submission, but I never get any replies:

http://news.ycombinator.com/item?id=5182145

Is there any other companies like Valve and Github that are bossless?

Recently, I made the switch to vim from Sublime Text and I have installed some of the same tools. So far, I've committed to vim, but I have found that the plugins for file searching, linting, etc. are easier to use, more intuitive, and less painful to setup in Sublime Text.

I asked this before, but does anyone know of other companies like github?

http://news.ycombinator.com/item?id=5182145

Hold on it gets better (Angular Docs):

"To solve the issue of lack of isolation, the directive declares a new isolated scope. An isolated scope does not prototypically inherit from the child scope, and therefore we don't have to worry about accidentally clobbering any properties.

However isolated scope creates a new problem: if a transcluded DOM is a child of the widget isolated scope then it will not be able to bind to anything. For this reason the transcluded scope is a child of the original scope, before the widget created an isolated scope for its local variables. This makes the transcluded and widget isolated scope siblings."

Data-binding and re-usability should not be that hard.

> for 95% of the use cases, you are better off sticking with jQuery or ...

This is terrible advice. If you can't tell the difference between a procedural app full of jQuery callbacks and a an app modularized with Backbone objects, then I don't think you have had real experience writing apps with either of these libraries.

> I think the current scrum fashion dampens many impulses from programmers.

Wow, that gets at the very reason why I asked this question! Ever since we moved to scrum, I have felt less creative and more stressed. I think I do better in a less hyper-task oriented and hierarchical structure.

Thanks for the reply.

(This sounds ranty, but...)

I'm one of the odd developers that doesn't obsess over tools. I worked with four different editors, last year - vico, vim, sublime, and eclipse - and I can't say that I'm attached to any of them. I don't complain when I can't use my favorite vim or sublime shortcuts (I don't even know a lot), and it doesn't phase me when I have to hack some code on my 13" MBP instead of my 24" monitor at work. Contrary to what most think, a developer that obsesses over their tools doesn't necessarily make them a good developer.

"Show up and get to work."

I think a lot of the criticism in these comments is overblown. If anything, I would expect more constructive criticism and feedback from fellow HNers.

Quartz is a fairly new site with a small dev team. The site has had some kinks, but it is slowly coming together, and I think it has a lot of potential.

> One other reason we chose angular, it is backed by Google.

I like Google for many things - there is no doubt they have some solid developers and have released great products - but they have a poor track record with frontend framework adoption. For example:

- GWT (not a lot of adoption and waning)

- Closure Tools (except for the great Google products that are built with this library and closure compiler it hasn't had a lot of adoption)

- Dart (verdict is still out on this one but it doesn't look good)

It's not so small when you add up all of the obtrusive javascript/framework code that is littered throughout the html:

<li ng-repeat="todo in todos | filter:statusFilter" ng-class="{completed: todo.completed, editing: todo == editedTodo}">

... which some may consider a bigger problem than size.

"[on Steve Jobs] He wore that famous black mock turtleneck ... not to make a fashion statement"

If you hire Issey Miyake to make a custom turtleneck, then you are making a fashion statement. Also, he wore black for a reason - it's a sophisticated, serious, and confident color (or lack thereof) - which was a fashion statement.

Nesting views, along with data binding as MatthewPhillips pointed out, is not the hard part of developing frontend apps. Custom UI/UX is the hard part. Can angular fadeIn/slideDown your nested repeated/collection element? No. In angular, along with any other MV* framework, to handle this trivial UX, you have to write a special js routine (directive). Most apps will have much more custom UI/UX and you are going to have to write javascript, and you may have to fight your framework if it is too opinionated.