This article is pretty focused on the build type of k8s developer tools. There are other types as well that can fit into specific places in your workflow. Joe Beda does a fantastic high level overview of the different types in last week's #tgik8s: https://www.youtube.com/watch?v=QW85Y0Ug3KY .
Here's a couple tools that try to tackle this problem in different ways:
Would anyone know if there's audio/video of these lectures? I keep seeing amazing classes like this and wishing that everyone could enjoy them instead of just the local students.
The reason that cross-domain requests are disallowed has to do almost entirely with cookies. The concern is that since almost everyone uses cookies for identity, it is possible (without the cross-domain barrier) for a random web page to tell the browser to go fetch all their secret data and then return it to the malicious page.
This whole thing isn't an issue any longer if the server containing the secret data is expecting random people to access it and implements auth with something more than cookies. Take a look at Twitter and Facebook. They both allow cross-domain requests.
janky.post will only work if the server is expecting the request (it won't allow arbitrary requests to anything on the remote server) and then, it's up to the remote site's engineers to make these endpoints secure.
I've not done much profiling/performance (especially on older browsers) yet. My use case for the whole thing was to do a fire and forget POST to a separate domain.
Honestly, flash might be the best solution for something like you're talking about. I was just going for something with almost no dependencies that was stupidly simple.
Right now, I'm just using qunit + sinon.js. I'm not super happy with it (I'd really like to get to the point where all my development is done via. writing unit tests), but so far it works. Honestly, one of the big advantages of backbone is that because of the structure it forces on your code, unit testing is easier.
Everything ends up being in a small testable chunk that you can stub out the interfaces for and test (see sinon.js, can't say enough good stuff about that). I've also got a small Backbone.sync implementation that just loads test fixtures and returns data from that, allowing me to have a db to test against that's fake and synchronous. With couchdb, all I have to do is take a DB dump of what I want to test, put it into a file in my test directory and I've got instant fixtures.
I've done some interesting applications with Backbone.js over the last 2 months or so (for anyone that uses uTorrent, here's one: http://apps.bittorrent.com/ucast/ucast.btapp all in about 800 lines of code, just unzip the btapp file if you'd like to see the source). After trying other things like SproutCore, Cappuccino or Evently, I'll never go back.
I actually ended up being surprised by how backbone changed what I do with javascript. With backbone, you can create views that are really just widgets. For example, if you have a list item, you can create a view specific to that list item. Then, all the events and state for that list item are encapsulated right there. No need to store state in the DOM, you can just fetch it from the model when it happens. This then allows you to bubble events up through the parent views to change the entire page's state. Because of the separation, you really end up having little pieces of javascript that only know about themselves and the whole picture ends up being considerably less fragile and easier to debug.
I'm also a big CouchDB fan. Since backbone models are just documents, the integration with CouchDB is very minimal and you get instant serialization of user state (it really is that easy, to pimp one of my projects: https://github.com/pyronicide/backbone.couchdb.js). There are no server handlers you need to write (hell, don't forget you don't even need to run a web server, Couch'll do that for you!) and you end up with less complexity overall.
I'd suggest not actually using a bug tracking system. They tend to be separate from actual planning and the fact that they're separate means that planning is harder.
I've been using mixpanel's platform for a couple weeks now and have been super pleased with it overall. Being able to deliver stats to my end users has been a big success.
Once you get down to it, all code is written on top of a platform. Why not use the wisdom of crowds and open it up to everyone so that they can contribute their ideas?
How are you planning on managing the publishing workflow for non-devs? Marketing and docs teams tend to struggle quite a bit with git specific flows.