When you are considering how two things are alike, don't forget to also think about the ways in which they are not. Unlike with HTML, content producers who write Markdown, don't need their documents to be parsed correctly by many different engines. They only have to target the one they are using.
To be clear, "Standard Markdown" is only trying to address the ambiguity of the syntax. Sites are still going to implement Standard Markdown plus some ad hoc extensions, so it will still be the same practically in that regard.
In a fair world, the time and energy that went into Bower would have been spent making npm just a little bit better for front-end stuff. `npm dedupe` is halfway there. Now I have to deal with two arbitrary sources of dependencies.
The problem I have with apt, yum, etc... is that the packages for development are so old that you're going to be compiling from source and managing your own updates, which is exactly the problem a good package manager should solve.
The big difference is that packages that land in the official apt repositories have been heavily tested by the apt repository maintainers. Anyone can push a package to PyPI for example. There is a clear trade off between using packages from apt/yum and your toolchain's package managers.
In practice, I do find it much easier to pin dependencies and install from my toolchain's package manager (pip/PyPI).
For the small number of dependencies any of the projects I work on have, I find it easier to download the dependencies in a browser, and just copy them to the projects I'm using. I understand this is heresy.
Have you used Bower? I haven't but I watched a video of some guy speaking of Bower who pretty much said the same thing you did but changed his mind after trying it out.
I haven't tried Bower yet but kept that anecdote in mind and plan to try it to see what all the fuss is about.
From my understanding, a single command will take away all those intermediary steps between deciding to use a library and actually using it. No need to navigate to the project's page, looking for download link, downloading it, extracting and copying to the project directory.
Sounds good in theory to me; just haven't the chance to try it yet myself. Mostly because npm happens to have everything I would have used Bower for.
"Small number of dependencies" being the operative phrase.
Try managing a complex single page app with deep dependency graphs and each node in that graph versioning up independently. Not sure how your approach would scale there.
Yeoman makes it quicker and easier to generate boilerplate code, but I think the goal should be to eliminate boilerplate and abstract it away. Yeoman keeps spaghetti organized, but it's still spaghetti.
This is useful in a pinch, but transitioning a 100px high element from max-height 9999px to 0 means there's going to be a huge delay while it's transitioning between 9999px and 100px followed by a very fast transition between 100px and 0, which is usually worse than having no transition at all.
I really want to like this, but I can't get behind Sprockets when RequireJS and Browserify exist. Code in comments, obtuse file extensions, `require_tree`, etc. make code modularization an inelegant kludge.
