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].
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.
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.
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:
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.
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.
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."
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:
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.
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.