I'm in the process of helping a client migrate a large data set (5m users) off parse due to the issues they've had. They had a fairly consistent rate of 1 in 100 requests return a ECONNRESET error in node. After over a year of haggling with the parse support team the errors finally disappeared about a month ago. They needed at least 10 fetches so you can imagine that 1 in 100 not returning doesn't bode well.
I don't have all of the specifics as to how or why the errors went away, but no changes in the client's codebase were made that relate to this.
Summary: seems brittle, tech support was useless, customer wrote huge checks to parse every month and didn't get traction fixing the problem. Even though things have improved we're continuing with the effort to help migrate the client away from parse.
Thorax author here again. A few non charitable things have come out of the development of Thorax. On the developer happiness / retention front, I still work on projects for Walmart because I got to help open source Thorax. I'm now extremely happy there due to other closed source projects, but when I've been less happy it's kept me there.
On the code quality front, we haven't actually gotten a ton of contributions from the OSS community, but it's a niche framework and not the next Rails, Angular, etc. But what I believed happened when we open sourced it is that we held ourselves to a higher standard of documentations, versioning, testing, etc. Now that we use it across multiple departments with teams that don't really interact with each other directly, having something more stable becomes extremely important. If there is no external accountability I think it's much easier to decide to break an API.
I'm not familiar with Chaplin's memory management strategy, but in Thorax we automatically manage the lifecycle of child views. If you need to manually manage the lifecycle of views, we've implemented `retain` and `release` methods ala obj-c. It's not an easy subject to tackle in a paragraph, but we've solved the problem enough that we aren't leaking memory in a huge app in a sensitive environment (mobile devices).
It's built on top of Backbone. It primary adds to Backbone.View, leaving models, collections and routers almost untouched. Earlier versions extended those more, but most of the functionality we were looking for ended up in Backbone 1.0.
Docs wise we only document the additions, you still need to refer to Backbone docs.
Hey hacker news, I'm one of the primary authors of Thorax. Was rather surprised to find this on the front page as we are in the middle of revamping our docs and developer tools and weren't quite ready for press yet. We are working on a yeoman generator that sets you up with a Grunt + RequireJS project here:
I would recommend cloning that repo, running npm link then using it if you want to give Thorax a try. We'll be doing some more press about Thorax in a month or two.
For context, Walmart currently uses Thorax in production on mobile.walmart.com and we are working on a few other web apps that aren't public yet. It's not as sexy as Ember or Angular in many ways but it's a framework that grew directly out of building a very large Backbone application.
We've been ploughing through a redesign recently, and Thorax was on our shortlist of frameworks, along with Ember and vanilla Backbone, being "opinionated" and "battle-hardened. However, we found the documentation outdated in parts and it made it really hard to get things going in a short amount of time (Ember's documentation was an order of magnitude worse, however).
In the end we decided on vanilla Backbone, due to our needs and the possibility that Thorax was suffering bitrot (documentation is always the first thing to go). However, we'd like to give Thorax another try provided we can get what we need working.
Either way good work. Thorax is a sensible addition on top of Backbone.
Could you talk a bit more about production deployment?
I did a backbone project a year back and had lots of pain with things like require with CDNs, etc.
There was a post just 1-2 days back about performance tuning in Angular. I wonder if you recommend any best practices in your own from a performance/production perspective.
Hi Preem, this is Ryan one of the mentors at Forge. $550 is just for one weekend. This is our first go round at the workshops in this format. I've taught similar material internally for some corporations and Colin (my primary collaborator on this project) has been teaching JS for several years full time. We aren't totally green but this is a new venture.
What specific workshop or class did you feel you got burned on? I wasn't aware Codecademy offered offline courses.
I don't have all of the specifics as to how or why the errors went away, but no changes in the client's codebase were made that relate to this.
Summary: seems brittle, tech support was useless, customer wrote huge checks to parse every month and didn't get traction fixing the problem. Even though things have improved we're continuing with the effort to help migrate the client away from parse.