Breeze roadmap? [closed]

I can appreciate your manager's concerns. We are all trying to make sound bets on technology. It isn't easy. The moment you start to think that the size of the vendor is a good guide ... they abandon a major technology (Microsoft's Silverlight and Google Reader come to mind but the examples are too numerous to mention). There are no guarantees.

What do we know?

Business Viability

• IdeaBlade (makers of Breeze) have been in this data management business since 2002 (I'm a founder so I know). That doesn't prove we'll be here tomorrow. It does prove we have staying power and know how to run a business.

• Breeze is over a year in the making and saw its first release about 6 months ago. As important, the design and implementation are the fruit of more than 10 years building and selling a commercial product (DevForce) to address the same set of challenges. This speaks to the maturity of the product. We've learned many lessons under the constant pressure of real world customers. There is an excellent chance we've made and recovered from mistakes you haven't seen yet.

• It speaks to commitment when a for-profit company of our size pours most of its best engineering and product marketing resources into Breeze. That's a huge bet and huge investment for us. We can't walk away from it lightly. Your manager will know that.

• Breeze is MIT licensed and open source. We can't change that and don't want to. In principle, we could spin off a commercial release and abandon further development of the open source branch. But (a) that would have to make commercial sense which it doesn't at a time of predominantly free JavaScript libraries and (b) anyone can fork the current code and maintain it.

• Breeze is developed in the open. You see what we're doing as we're doing it.

• The Breeze documentation is more extensive than you'll find in most paid products. It's way ahead of what you'll find in most JavaScript libraries ... including one you mentioned. Does that matter? We've had long experience building a commercial product ... long enough to understand that the "bits" are only one part of a technology product. You decide.

• Microsoft though well enough of Breeze to feature it on their Single Page Application web page and to work with IdeaBlade on development of Breeze-based application templates that work with Visual Studio. Breeze is not a Microsoft product. But it has crossed a threshold sufficient for Microsoft to present it comfortably in this way. That counts for something.

• We should publish our roadmap. It's partially driven by your suggestions through User Voice and Stack Overflow questions. Angular support was very popular in these forums. It's also driven by our reading of market opportunity ... where, once again, Angular appeared as a smart strategic choice.

• We have an excellent relationship with the Angular product team, working on ways to advance the development of Single Page Applications ... together. Some fruits of that relationship: the Breeze/Angular Template and a talk I gave at the Google Mt. View Campus on Angular and Breeze.

Technology

• Put me in your spot and I want to know what my alternatives are too. Ember.Data is another benchmark. Doesn't work with Angular as far as I know. But it does tell you a lot about the challenges of complex data management and what it takes to address them adequately.

• "Build it myself" is always a possibility. Look around if you want to know what that's like. Or use your head and your experience. How often have you been able to do better writing your own framework than a team dedicated to it for ten years? Maybe you can. All you have to do is convince the boss.

• Let's suppose you can. Just because you can doesn't mean you should. You could write your own "Angular" too. Is infrastructure development the most productive use of your talent? Or should you redirect your time and energy to the application development with perceived customer value?

• Perhaps the most prudent thing to do is encapsulate the Breeze stuff inside a service layer with an API that has the abstraction you'd want your application components to talk to. If something goes wrong, you've isolated the problem to your service layer. All of our samples take this approach: look for modules called "datacontext" and "dataservice".

• At the moment our Angular support does not extend to browsers that lack ECMAScript 5 support for getter/setter properties ... as FastReload observes. We do not have plans to address that. Our research tells us that most people building Single Page Apps (SPAs) are targeting mobility scenarios in which EC5 browsers are a given. I seriously doubt that such JavaScript-centric apps will perform adequately on older browsers. But you should discuss with your manager exactly why you are going down this road and who you are trying to reach. If you need to run on older browsers, I wouldn't bet on Breeze to help you with an Angular app. You could consider switching to our Hot Towel/Knockout/Breeze stack which does work on older browsers; see John Papa's "Single Page Application Jumpstart" course on Pluralsight.

• Angular relies on dirty checking for change detection and Breeze relies on events internally. These are different approaches; they are not incompatible. For example, Angular hooks itself into DOM events and XHR callbacks. The Angular team understands what we're doing and they don't think we're incompatible either. You do have to pay attention to the rules (e.g., calling $scope.$apply at the appropriate times). This is not news to Angular developers.

• Do you need the Breeze features? Depends on what you're doing. Here are a few things Breeze does that you won't find in Angular: client-side query language, object graph navigation, change-tracking (not same as change detection), model validation, client caching, temporary key generation/resolution, and bundled/transactional saves. This isn't a criticism of Angular. It means we have different and complementary areas of focus. Angular concentrates on application logic and presentation while Breeze concentrates on matters relating to a persistent data model.

It seems that the authors are developing this project for 6 months in public, this first release version was 0.53. If we assume that they do have an iteration of 2 days (kinda correlated to the iteration length after the release), the application is about 1 year old.

The 2 main authors are CTO and VP Tech in their company Idea Blade.

The company is around since 2004.

Apart from that, I do not see any roadmap, or a promise on the project that would be continued. I assume that they will develop it as long as it is being used, as long it their company gets profit. This be noted that this company sells "enterprise" products; so they might change their idea to stop the open source project, maybe not but no promises.

There are 2 main concerns for me,

Todo-Angular runs in modern browsers such as IE9, IE10, and recent Chrome, Safari, Firefox, and WebKit browsers. Breeze does not support AngularJS apps running in older browsers that lack ECMAScript 5 property getters and setters.

While, I do appreciate NOT supporting <IE9, if you are going to explain to your boss, then it is going to be a problem. Also another thing, breeze relies on getters and setters, aka change listeners, angular does the opposite: dirty checking. They work on completely different schemes therefore it is likely that there will be compability issue here and there.

My strictly personal conclusion would be not to use it. Mostly because when using angular, you don't need most of the features anyway. It might be a burden than a support in the project as it grows.