I think you're missing a lot of the core concepts around visualisation. d3 aside (for now) you need to consider what visualisation is. Your focus is on charts alone will prevent this from getting any traction. d3 is a framework but it is also in a way, a visualisation kernel. This means that it gives the individual flexibility to create and design interactive information visualisations without being hindered by whatever is enforced by some charting library (only limited by the DOM or whatever scene graph it is working with).
d3 can also be viewed as an extension of the concept of 'grammar of graphics' (for a reference implementation of the grammar of graphics see vega (http://trifacta.github.io/vega) or ggplot2).
If you're plan around this is to build a system in which angular handles a lot of the data binding work, I would recommend re-implementing something like vega in angular. Because this would be more compelling than creating yet another charting library that is just built using some combination of d3's data manipulation and angular DOM style. nvd3.js, chart.js, yui-chart, etc. all run into this point where the libraries are simple tools for developers to use but do not have the extensibility of a framework like d3 that allows more freedom in the design.
Now lets say you create a competitor to vega, the key differentiator would be animation, assuming transitions are trivial as you've explained in this post, I have very minimal experience aside slides and videos in angular to comment. While vega will have: canvas scene graph support, potential to build on top of systems like WebGL, native iOS, or native Android. You will then be tasked to figure out the 'grammar of interactions' (https://github.com/trifacta/vega/issues/28) in order to allow attributes to differentiate yourself from vega which is going to be a very hard (but fun!) task.
Aside: d3's line function isn't refreshed as new data is inputed (meaning that you would either have to do this inside of some custom directive (towards the vega style implementation) or do some hack-ish 'tick' style system (the reason force directed is being updated is due to the fact that it has it's own very small physics model which you are leveraging on tick, (also 'ticks' do not harness angular's or d3's data binding concept well))).
I do think there is space for a true competitor to d3.js that takes a more OOP and stateful approach (what the root of your annoyance with d3 seems to be). While there may be room for this, I also feel (note emotion not backed with fact) like these concepts are also what will build too many limitations that will hinder the project itself. This competitor will likely live within the web components community once it's no longer dependent on angular.js, but will likely hit walls (just different walls than the ones you're currently frustrated with d3.js) that are going to be hard to get through.
I have thought about this stuff in the past (http://bl.ocks.org/milroc/5519819http://youtu.be/Hd2rye9a9kk) and recommended a wrapped directive approach for angular.js (and other MV*) but as I said above the next steps are going to be MUCH more difficult than we expect.
hey Zjonsson, I think this is awesome, have you considered having a webworker run in the background to send the data to the browser and then switch once it has finished? The time to interactivity (and visibility) of crossfilter is a problem, and I think you did a great job solving that problem, I just don't find the interactivity to be as great as I was expecting (then again I'm on a slow connection currently).
I don't understand why there is so much talk of this article being so very materialistic. It's kind of the mentality of a good number of individuals who did or are wanting to try a very minimalistic style of travel (others exist obviously: ignore certain needs (for me: don't bring a computer; for others: only the clothes on your back); buy and throw away each time you're somewhere new (only works in certain areas of the world with certain high budgets); etc. This however is the majority view point for vagabonding. Invest in key items that meet your exact needs (knowing your needs is an important aspect of this). If you do this beforehand you won't be stuck in some country without a passport because it fell out of the hole in your siblings old backpack.
If you ignore the anecdote about flatware you realize that the article describes minimalism at it's core. Ensuring all your needs are met with the minimal amount of goods. There is one flaw with this concept of "The Best" that individuals who follow this mantra tend to lose sight of another very important aspect - time. While Daniel Curtis clearly showed his obsession by buying 20 different sets to determine which is the best for him. I imagine that others don't have that amount of time to invest in this decision.
I am this way with most purchases; if you have something that will significantly improve the quality of life you have or something that while not necessarily a need but has moved to a desired addition to your lifestyle, spend the time to find the best fit for you. If it is not worth the time to look for what is the best fit for you; don't purchase it because you merely want it.
Advice on how to live is simple:
1) Learn (travel, fail at something, shadow someone)
2) Prune (decide what is worth learning (e.g does learning another programming language add much value compared to learning about the behaviors of a market or larger ones like learning about a girl))
I'm definitely going to look into this book because it seems like it helps people work on pruning which I believe is the hardest part of life.
However I feel that you (Jason) may have taken away some wrong things from the book because: "This is how most successful people I know have built their careers, and it always starts small." While this may be one of the largest pipes that create your definition of success, it is not the only one. People may need the life experience of working as a barista before starting their career for several reasons; or they may want to work at a hostel while traveling for several years to learn more about the world. The rate in which careers develop vary greatly from person to person and at what point; why base it on the average successful individual?
Concepts like this seem very specific to obtain a certain desired lifestyle rather than advice on how to live.
1) Don't put off your career: While I agree it mainly correlates to two things.
a. Spend as much time as you can doing what you have a drive to do. (e.g: setting yourself to be financially above or where you were when you grew up, trying to start a band, or trying to create the next major startup).
c. Make sure to live below your means. (i.e: Ensure if you make 100 dollars after tax regardless of pay 25 of it is being saved. This gets harder and harder as there is a asymptote decided by the market (cost of living) and situation (whether or not your parents basement is available) you live in).
2) Children: There is a lot of qualifications here that were taken in place in the article. While the clock is ticking and I agree, people look at children as a chore taken to ensure a certain lifestyle later in life; or just want them and are willing to sacrifice whatever else to enjoy having children. Both are generally the case but I feel the set of things that people choose to give up is too large. You should ensure that your finances should be in place to support them but the amount in which you should support them should vary based off of your financial situation (by this I do not limit it to the children's wants (less toys) but rather also the child's needs (why pay for a private school if you can't afford it? because it's worth the difference in learning experiences? What about no private school and finding other means of educating the child?))
3) Brain Finishes Forming: Fight it if you think that this is going to be the case (and care; I know a very large set of people who enjoy being close minded. It means that their life is less complicated by relatively asinine decision making, when they would prefer the action portion of the work (I can't understand this but have debated it with individuals)).
This is more of a choice of how the creator wanted to display the usefulness of C2. That can just as easily be done with C2.
[:div {:class "hist-bar-default"}] would likely be the way to do it.
Also d3.js examples are riddled with bars.attr("style", "height: " + 30px) just because sometimes it's easier to think about it while developing there. It's not maintainable and very problematic in large designs but I would recommend not judging a library based off of design choices like that with examples of d3 or c2.
I'm glad you're passionate about visualization though, you should definitely start using these libraries, and after a while (d3.js has been said to "melt your brain initially) you'll realize the benefits of working at a lower level with the data.
Just a little info on this, this is not a charting library, it's probably closer to a graphics or visualization library.
It pulls a lot of it's ideas from d3.js, allowing CSS to dictate a lot of your style choices, but also allowing the data to change the style (a typical example is a chart where you have different categories of data, coloring those categories depending on the data).
This is low level for a reason, most charting libraries take a specific stance on how to visualize something. d3 and c2 let that be dictated entirely by the developer. It may take more effort to get a bar chart working in either of these libraries but generally the control you have allows you to fit it into your design rather than your design molding around the charting library you use.
Where I spent most of my undergrad (Georgia Tech), we had a system called threads. Giving students tracks in which they could focus their study of computer science.
These tracks were generally all theoretical (the exceptions being some classes in platforms and devices), even my friends who had a love for software engineering ended up learning the thoughts behind each process rather than blindly learning the process itself in order to master said process that is currently practical.
The way I treated academic learning is very similar to the process described above by 10098. The learning you experience in college should be some form of aggregate information about past ideas/trials and tribulations. This is the process by which I (as a customer) have found most universities treat their undergraduates. Rather than tailoring them to become masters of a specific problem they try (albeit not successfully, and there are a vast number of people in universities today that don't enjoy, want to have, or have this mindset) to build the next generation of people to find flaws in our current society, in hopes that they have motivation to fix it.
That being said you are making the argument that software engineering is a vocational skill. While I'm not denying that the majority of the process that I've found in my limited time in the industry tends to be filled with skills that are akin to any other vocational profession, I don't believe increasing vocational skills help the students. It might in a short term give them a strong basis for obtaining a software related position. It might also give them the ability to perform really well in their jobs at that time being. It does however not enable them to question the process they've learned. It also does not help them find problems within a process.
It should also be noted that most companies aren't looking for a master software engineer. They test for intelligence and social skills rather than how strict the student is on testing practices or which design cycle they prefer. These biases also lead towards limiting employment because they'll end up fighting rather than adapting to the new work environment that is already established by the companies views on the subject.
A lot of top schools are taking interest in teaching up to date languages, maybe not clojure or even javascript but python is the language that I've seen most Georgia Tech students prefer to program in after taking several courses in it.