I love that Walmart is so involved in open source. As one of the most demonstrably "don't do anything unnecessary" companies that exists, their participation is a great data point to support the theory that participating in open source can come from a selfish as opposed to altruistic motive (but long term selfish).
Perhaps this isn't a hard thing to prove to the hn community, but it's something that a lot of MBAs I've known have struggled with.
A more charitable way of phrasing your point: devoting resources open source provides a lot of value for a company, particularly ones not technically associated with buzztech (so either fledgling webdev shops or older/more conservative BigCos, like Walmart). It's great, actionable PR; it improves employee satisfaction; its an effective recruiting tool.
In this case, my interest is in finding the absolute least charitable, least nebulous justification for open source I possible can. Not because I agree with the non charitable interpretation, but because if I can win the argument that open source is better without imploring charity, I can win the argument with CFOs and Bankers and Lawyers.
As soon as you start mentioning intangibles like charity and reputation and recruiting, a certain group of people will stop listening to you.
I think you can justify open source based on security, quality, and cost. If you open source correctly, you get more secure, better quality, at lower cost.
My personal philosophy is one thing. The stances I employ or postulate to sway others are a sub-set.
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.
Walmart is also one of the most tech-forward companies in the world. They spent lavishly on satellite links before the web, and more recently are pushing on Rfid and other inventory management tech.
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).
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.
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.
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.
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.
This looks good. I have done a few Backbone projects and inevitably write some of this code as boilerplate. Great to see that the framework handles this for me while giving me the flexibility to fall back on standard Backbone functions when needed.
You should also check out Marionette (http://marionettejs.com/) as another Backbone-based framework. It's similar in terms of views, and provides some additional events and methods by default (onClose, onRender etc.).
IMHO, it's hard for these client side frameworks to get much steam in Angular's wake.. Though Thorax is much easier to start, I think over time Angular's power will make it the dominant front end framework out there
A better one, I think: Ember is like Django (full-featured, heavily opinionated, tightly coupled with its preferred tools), Angular is like Pyramid (powerful, but without a lot of established patterns; the Wild West with big guns), and Backbone is like Flask (micro-framework that does what it does very well and lets the user handle the rest).
I'd rather compare Angular to PHP. I keep wanting to look at it, but whenever I do, I never get past recoiling in horror at the examples that tacks attributes onto the HTML tags in a way that most reminds me of the early days of PHP development of mixing HTML and logic
It might be all beautiful when done right for big projects for what I know. But then the examples on the angularjs site are giving the wrong impression.
I disagree. I'm delighted Angular exists but I think there are many examples in history where the more general, lightweight technology sees more widespread success than the feature-rich, high concept alternative.
That's exactly why we chose Backbone over Angular earlier this year.
An imperfect analogy, but: maybe Angular is like Wave, Backbone like Email...
This looks really nice. Comprehensive, well-written tests as well. Do you integrated this with Hapi.js, just out of interest? Obviously they're both well designed to not be dependent on each other, I'm just trying to get an idea of Walmart's stack.
36 comments
[ 2.9 ms ] story [ 94.4 ms ] threadhttps://github.com/walmartlabs/mock-server
We use this extensively to develop the mobile web app.
Perhaps this isn't a hard thing to prove to the hn community, but it's something that a lot of MBAs I've known have struggled with.
As soon as you start mentioning intangibles like charity and reputation and recruiting, a certain group of people will stop listening to you.
I think you can justify open source based on security, quality, and cost. If you open source correctly, you get more secure, better quality, at lower cost.
My personal philosophy is one thing. The stances I employ or postulate to sway others are a sub-set.
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.
Note: I am just a user of Chaplin, not an author.
https://github.com/walmartlabs/generator-thorax
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.
(I'm paraphrasing slightly)
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.
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.
1: http://marionettejs.com/
Docs wise we only document the additions, you still need to refer to Backbone docs.
If you pick Backbone, you'll be inventing a lot of patterns yourself and scaling it, but I think that appeals to a lot of people.
It might be all beautiful when done right for big projects for what I know. But then the examples on the angularjs site are giving the wrong impression.
That's exactly why we chose Backbone over Angular earlier this year.
An imperfect analogy, but: maybe Angular is like Wave, Backbone like Email...