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].
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.
> 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 cards on the main page don't even have additional links in them. And for those with the save/cooked buttons (I assume that's what you mean by "links inside them"), why can't the main elements be linked? The bar with save/cooked would cover them up on hover? What am I missing (Touch interfaces?)?
There's quite a few interactions that don't work right now, even with JS enabled:
Middle-click? broken. (and if you add JS-handling, I hope that doesn't mess it for people that have middle-click assigned to other functions)
CTRL-click? broken.
"Right-click -> open in new window"? doesn't exist, because not really a link.
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.
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
Your point is well taken, but I think it has value. Compile-time error checking is useful because it gives you flexibility to make changes in a big program. It's kind of like a big suite of automatic tests that make sure all the parts of your program talk to each other correctly.
Does it catch everything? Can you stop thinking critically? No, but it's still nice to have.
This sort of goes hand in hand with IDE tools (e.g. "change method name" sorts of things), so I don't think we necessarily disagree.
> I've never seen a bug in production that could have been prevented with static analysis.
That seems unlikely to me.
I do application penetration testing for a living, and I'll often use static analysis tools in my work. (Both robust, established tools and ad hoc scripts.) For example, check out Brakeman for Rails apps. These tools find actual bugs in actual production software.
Do they find everything? No, you can't rely on them completely. But they're still nice to have.
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 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.
Circular dependencies ARE a problem with your architecture. You've got two modules that are strongly coupled. They should either be in one module or you should rethink things. It is impossible to need one without the other in that case, so including one without the other makes no sense, so just merge them.
> Circular dependencies ARE a problem with your architecture
This whole thread reminds me of the PHP days before namespaces. If you have circular dependencies within your own codebase, you have an architecture problem. If they are introduced by third-party libraries, maybe the usage of the library should be questioned.
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.
You want to use inversion of control in your Utility class. Just pass function, which will operate on Modal class instance (not Modal class instance itself but function) as argument to its utilities that show Modals.
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.