In case you haven't already, go checkout the awesome project (and organization) over at AngularUI!

In the vein of Paul Irish's "10 Things I Learned from jQuery Source" I decided to write this blog post. Lets just jump right into it.

Concerns about Bootstrap in AngularJS seem to come up a lot lately (especially on Google+) that I feel are causing problems.

We have 2 projects: the AngularUI Bootstrap project which is recreating everything in pure AngularJS code, and removes the Bootstrap.js dependency. Then we have the new Angular-Strap which simply wraps the existing Bootstrap.js creating additional dependencies and imposing a fairly opinionated templating scheme.

If you go with AngularUI's version, then you are using a project that won't break if Bootstrap's API changes, that doesn't have additional JS dependencies, and is tightly integrated into AngularJS (meaning triggering events from controllers, etc is more seamless). On the flip side, if you end up including the bootstrap.js regardless, you don't see any real benefits. All of the components may not work as perfectly / smoothly and you will have to wait (or contribute) until the project gets up to speed.

If you go with Angular-Strap, you are essentially getting a few directives that are not necessarily specific to bootstrap, and some bootstrap plugins wrapped in a AngularUI-Passthrough pattern with very specific configurations. This means you MUST have bootstrap.js, and if their API changes, the lib may break. In addition, any option that hasn't specifically been coded for is completely inaccessible. But this starts to run parallel to the AngularUI's version of waiting for the features to be developed. Overall, since the existing plugins are simply being wrapped, it becomes easy to push out new versions or components when he decides to add wrappers.

Personally, I have reservations about either approach. I believe it's better to provide the basic building blocks and have developers create their own DSL and internal directives/templates (instead of creating a template around a template around a template).

To prove how simple this is, I've put together this gist and plunker which demonstrates how easy it is to implement just about every bootstrap JS component without creating any new JS or custom directives. Unlike Angular-Strap, the code is 100% transparent and you have complete access to all options, 0 API breakage, and 0 template opinion. It's true that you lose the ability to call methods programmatically, but if we focusing on enhancing the pass-thru (or if you don't want to wait and decide to roll a proprietary directive) then this becomes irrelevant.

You should bookmark the original GIST as I will try to continue it as I flesh out more Bootstrap functionality and features over time.

Conclusions

If you want an Angular-Bootstrap project to streamline a few things for you, go with AngularUI's Bootstrap.

If you don't mind a tiny bit of elbow grease, just use Bootstrap.js natively and AngularUI's Passthrough to grease the wheels when you get stuck.

They FINALLY uploaded the video of my talk on AngularUI at Google SF! Sorry for the low resolution, but go check out the project!

This is the most concise list of things you must know in order to upgrade your app to AngularJs v1.0 (subject to change). Read this list and upgrading should be as painless and easy as possible. REMEMBER: You should still refer to the docs for new syntax changes.

SUPA SIMPO UPGRADE TUTORIAL:

• The accepted convention is now ng-whatever instead of ng:whatever
• Widgets have been dropped and folded into directives.
• Directives provide way more control and optional complexity if necessary.
  • You can now set an execution priority over other directives on the same element
  • You can now store a template inline or use a partial, both of which are automatically compiled
  • You can now extend an existing directive's "controller" (read the docs, I'm still figuring this one out)
  • ng-transpose lets you relocate and output the original element's innerHtml to a new location in the template which will continue compiling normally*
• ng:autobind has been dropped in favor of modules
• Your app must have a module now (read the docs)
  • Specify your module name in ng-app (usually goes on <html> tag).
  • Modules can include other modules.
  • Routes are done inside of modules
  • You can do app-wide crap from modules like .run(fn) which would hold init-code and .value() for globals or constants
  • Directives, services and filters are attached to modules now (read the docs)
  • Refer to angular-ui as a good example of how to structure your app (source code)
• There is no html filter, it's now a ng-bind-html-unsafe="{expression}" directive
• You probably want to output debugging variable through the {{myVar | json}} filter
• $watch callback is now fn(newVal, oldVal) instead of fn(scope, newVal, oldVal)
• this is no longer a reference to scope, it is now a $scope service that is passed instead.
• Scopes still inherit, controllers do not. Consider using your module + $rootScope for global stuff.
• ng-model now fires on blur, you're probably looking for ng-model-instant. Removed in RC5
• $xhr is now $http and the syntax is slightly different

The popular item today for designers are CSS pre-processors (a 'light-syntax' version of CSS allowing for functions, variables, nesting and other nifty features). The two big names are LESS and SASS, although there are quite a few others out there too.

At my latest company, I've learned (and wielded quite mightily) SASS. However when looking at new projects in NodeJs, a question of wether or not I should switch to LESS has come up. I have collected four key differences that I feel make the answer quite plain:

As my company brings in new frontend designers for me to work with (and occasionally train) I find that I tend to live by the mantra: "Less is More". Apparently it's possible developers to be minimalists too.

Minimalism

In most of the CSS-related bugs, the first attempt to fix a problem or behavior should NEVER be to simply compensate for the symptom. Instead, learn to understand how the rules work together and try to find the source of the problem. Then evaluate if this source is necessary, or if a better alternative can be found. I have come to find that roughly half of the CSS bugs I find in other people's code can be fixed by just using the delete key. Those are good days.

Learn to take a minimalist approach with your code. Don't simply add rules if you're unsure if they're necessary or if you don't EXACTLY know how they behave. In fact, try to remove rules you know to be unnecessary if you can. Such as left/top properties on elements that are positioned static. And one more thing: don't add redundant rules for defaults or inherited properties.

Here's a collection of nifty shortcuts and tricks you can do when you're working with Photoshop and the web. I picked up at work while working with our designer, who's exceptionally skilled at graphic design. He's putting together some of the most amazing looking skins our products will ever get to bare. If you want some examples of his work just take a look at some of the screenshots from the Jobvite Share project.

Since working at Jobvite on our new facebook platform, I've been dealing a LOT with client-side apps. Unfortunately we weren't smart enough to start using something like Sproutcore or Backbone, but I'm working to amend that at the moment.

One of the things I've developed for the team is a special Factory class geared specifically to handling our unique structure. In our app there are quite a few components that must load before certain bodies of code can execute, and this creates a long load time:

• Dom Ready (obviously) when the html page is finished loading
• $.load() - We actually use this for client-side includes, and there are a LOT of em
• Facebook App API
• Facebook App Authentication (and installation)
• Internal Role Permissions

So I just finished spending quite a few hours trying to debug an iPad specific bug for FB code. why when building a FB app (in iFrame) if you use the FB.ui() function to create a message dialog, you get a gray overlay and no content. I mean come on. So I created a blank test page and confirmed that it wasn't any code in our app. Tried disabling auto-polling of the canvas, explicitly setting its dimensions, yadda yadda yadda.

Surprisingly, it was my designer who found the solution. I thought that the entire generated content is inside an iFrame, therefore I would not have been able to control the CSS, but I was wrong.

To fix this problem, simply provide the following CSS:

#fb_dialog_ipad_overlay {
    width: 600px !important;
}

TADA! All centered and shiny. You are free to tweak the CSS to your own discretion.

Here is the bug ticket I opened at facebook.

Long title, but you should recognize the motto. I was working on adding features to BakingPlate when I realized something. I've always worried when I would actually be able to start contributing to the core of OpenSource projects like CakePHP when it dawned on me. All of this could go into Cake2.

Although I have no longer been working on this plugin since I left ISV, however I was recently contacted on github by someone who may be interested in picking up this project.

Update: It seems I have not heard back from the guy so he may have moved on to other projects.