tag:blogger.com,1999:blog-7864620098107200252024-02-06T18:40:23.875-08:00Tim DohertyAnonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-786462009810720025.post-70729672725710052042015-12-08T15:07:00.001-08:002015-12-08T15:07:42.965-08:00JSConf Last Call 2015<iframe width="560" height="315" src="https://www.youtube.com/embed/Fk_WbNrZmgA?list=PL37ZVnwpeshG7ThPHHHRvPFTeU1_F_tcP" frameborder="0" allowfullscreen></iframe>
<p>
I gave a 1/2 hour talk at JSConf Last Call 2015 on December 6, 2015 title "Treating Framework Fatigue With JavaScript. The gist of the talk is that in today's world of never ending new frameworks, it's critically important to have a solid foundation in the JavaScript language in order to cut through the hype and understand how these frameworks do their thing.</p>
<p>I've been speaking at my local meetup group, of which I'm now the organizer, for the past year or so but this was my first time speaking at a conference. I'm looking forward to doing more conference speaking, as I really enjoyed the experience and had some very positive feedback on my talk! If you're a conference organizer, or know someone who is, please feel free to put my name on the radar.</p>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-21288692769028803982015-12-01T17:20:00.000-08:002015-12-01T17:21:28.780-08:00Organizing a Meetup Group<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu05yXmclniQl4huE-blzgKK1qevE2qQsSSxjIdPnRPgongvvDvtFSCLBeR-Zi66YKbsER510-jR6d2ETwZSM5rZNw9l9QztubbzCrjacH3_cHsmXBu89r_dPzXgo-GfGJGRqZFC1jXg/s1600/IMG_7339.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu05yXmclniQl4huE-blzgKK1qevE2qQsSSxjIdPnRPgongvvDvtFSCLBeR-Zi66YKbsER510-jR6d2ETwZSM5rZNw9l9QztubbzCrjacH3_cHsmXBu89r_dPzXgo-GfGJGRqZFC1jXg/s320/IMG_7339.jpg" /></a></div><p>I recently took over as organizer of the Santa Barbara JavaScript Meetup after functioning as acting organizer for the past year. It's a great way to network and meet like-minded people in the local tech community.</p> <p>I've had a good run of increasingly successful and well-attended events, and am looking forward to keeping the momentum going in the coming year.</p> <p>I've reached out to my my employer about sponsoring the Meetup, and will reach out to other local tech companies also, in hopes that we can afford to bring in visiting speakers and host more elaborate events in the future.</p> <p>Exciting times, to be sure, and I'd love feedback and suggestions from other Meetup organizers on what makes for a successful group!</p> Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com1tag:blogger.com,1999:blog-786462009810720025.post-5811931313623040062015-12-01T17:11:00.001-08:002015-12-01T17:11:34.421-08:00ECMAScript 6 In Depth: Part III<script async class="speakerdeck-embed" data-id="4f7cec0ad4d64994a859c734ab5b7313" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
The conclusion of the epic trilogy of talks I gave at the <a href="http://www.meetup.com/Santa-Barbara-JavaScript-Meetup/events/222301599/">Santa Barbara JavaScript Meetup</a> on August 18th, 2015.<br />Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-31901878805573910252015-06-25T16:15:00.001-07:002015-06-25T16:16:12.061-07:00ECMAScript 6 In Depth: Part II<script async="" class="speakerdeck-embed" data-id="7f6dc4f3f32c447f8335cd81ad13bfa2" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
Part two of a planned three-part talk I gave at the <a href="http://www.meetup.com/Santa-Barbara-JavaScript-Meetup/events/222301599/">Santa Barbara JavaScript Meetup</a> on June 23rd, 2015.<br />
<br />
The recorded presentation is available <a href="https://www.dropbox.com/s/bm5tws4zabshc5r/ES6_In_Depth_Part_II.mp4?dl=0">here</a>. (you'll need to download it to watch past the first 15 minutes) Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-29900520775359455972015-06-20T16:17:00.002-07:002015-06-20T16:17:44.610-07:00ECMAScript 6 In Depth: Part I<script async="" class="speakerdeck-embed" data-id="3f9af573663e464496a6df6c8e869289" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
<br>
Part one of a planned three-part talk I gave at the <a href="http://www.meetup.com/Santa-Barbara-JavaScript-Meetup/events/222301599/">Santa Barbara JavaScript Meetup</a> on May 21st, 2015.
<br><br>
The recorded presentation is available <a href="https://www.dropbox.com/s/096x8u5icp828px/ECMAScript%206%20In%20Depth%20-%20Part%20I_0.mp4?dl=0">here</a>. (you'll need to download it to watch past the first 15 minutes)
<br><br>
<a href="http://www.meetup.com/Santa-Barbara-JavaScript-Meetup/events/222720045/">Part II</a> is coming up Tuesday, June 23rd:Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-5706192913488027192015-05-01T14:18:00.000-07:002015-05-01T14:19:38.842-07:002015 Fluent Conference Recap<script async class="speakerdeck-embed" data-id="f53f7e131be44388b8aa43d0765a4c0a" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<hr>
A talk I gave April 30th, 2015 to the Santa Barbara JavaScript Meetup, based on my experience at Fluent and the sessions I attended. There were so many more that I couldn't attend.Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-3767536169179886452014-08-08T19:51:00.000-07:002014-08-08T19:51:50.402-07:00Slide Deck From Santa Barbara JavaScript Meetup August 5th<iframe src="//www.slideshare.net/slideshow/embed_code/37818370" width="476" height="400" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com8tag:blogger.com,1999:blog-786462009810720025.post-9700185897231039422014-08-07T09:54:00.000-07:002014-08-07T09:54:32.830-07:00Santa Barbara JavaScript MeetupI gave a well-received talk on <a href="http://yeoman.io/">Yeoman</a> to the <a href="http://www.meetup.com/Santa-Barbara-JavaScript-Meetup/" target="_blank">Santa Barbara JavaScript Meetup</a> crowd on Wednesday night, hosted by <a href="http://www.agilysys.com/">Agilysys</a>. Based on the positive feedback, we'll definitely host more.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh57-dLh9praezxkRllkGQ4VGxH2cZL5znl741HHEOQ9XdqH_JdFB2-L1FVmPvrbwHaBGd8OhKoyw8pSi7w9BSPc4VJI9QaPAVuBarN2HbmIaw9VAmd6YfbIQtqlRNSitlF3hOa5FLIw/s1600/IMG_5987_sm.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh57-dLh9praezxkRllkGQ4VGxH2cZL5znl741HHEOQ9XdqH_JdFB2-L1FVmPvrbwHaBGd8OhKoyw8pSi7w9BSPc4VJI9QaPAVuBarN2HbmIaw9VAmd6YfbIQtqlRNSitlF3hOa5FLIw/s320/IMG_5987_sm.jpg" /></a>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2qXpBcCj_g3IE2Ahltf4itdEJcmM7zq_MRajhBSIHy8CxQwxbiMeJg3f4CO9Ilx9NHbFs2gw0618M5ho2LCNHxY8pfrOORywufR5pFTEjK4PX6PH_MRhgWdcJBWTEz2-1gTjeWLLNJQ/s1600/IMG_5985_sm.jpg" imageanchor="1"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2qXpBcCj_g3IE2Ahltf4itdEJcmM7zq_MRajhBSIHy8CxQwxbiMeJg3f4CO9Ilx9NHbFs2gw0618M5ho2LCNHxY8pfrOORywufR5pFTEjK4PX6PH_MRhgWdcJBWTEz2-1gTjeWLLNJQ/s320/IMG_5985_sm.jpg" /></a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-19022671329187764082013-09-04T09:55:00.000-07:002013-09-04T09:55:42.573-07:00Ember 1.0<p>Earlier this year I was evaluating Ember.js along with several other frameworks/libraries for some projects at work. At the time, pre-1.0, I found Ember promising but frustrating due to its steep learning curve, frequent breaking changes and documentation that was inadequate and out-of-sync with the codebase. Still, I found much to admire in Ember's approach, as I noted in a <a href="http://www.timdoherty.net/2013/03/client-side-javascript-mv-with-emberjs.html">previous post</a>.</p>
<p>One thing that struck me almost immediately was a strong push back from the Ember principals against <a href="https://github.com/amdjs/amdjs-api/wiki/AMD">AMD</a>. The most prominent example was Tom Dale's blog post <a href="http://tomdale.net/2012/01/amd-is-not-the-answer/">'AMD is Not the Answer'</a>, which drew some impassioned responses including <a href="http://geddesign.com/post/15994566577/amd-is-the-answer">this one</a> and <a href="http://tagneto.blogspot.com/2012/01/reply-to-tom-on-amd.html">this one</a> from <a href="http://requirejs.org/">RequireJS</a> creator <a href="http://jrburke.com/">James Burke</a>. Having incorporated AMD into my toolbox early on, I find the necessary boilerplate a very reasonable tradeoff in return for concise modules with explicitly stated dependencies, available in the browser.</p>
<p>You can imagine my <strike>surprise</strike> <strike>confusion</strike> amusement then, when I read the Ember 1.0 <a href="http://emberjs.com/blog/2013/08/31/ember-1-0-released.html">announcement</a> the other day and found this gem:</p>
<blockquote>
<p>Today, tools like require.js and module systems like AMD, Node, and ES6 Modules continue to gain traction. Increasingly, people are using named modules and module loaders rather than storing their code in globals.</p>
<p>To prepare for this future, all of the code lookup and naming conventions in Ember.js now go through a single Resolver. The default Resolver still looks for code under global namespaces, but Ember App Kit already provides an alternative resolver that looks for code in AMD modules.</p></blockquote>
<p>
This quote from the Ember official blog is actually a little misleading. A closer look at the Ember App Kit reveals that it supports <a href="http://wiki.ecmascript.org/doku.php?id=harmony:modules">ES6 module</a> syntax, which is then "transpiled" to AMD syntax via the <a href="https://github.com/square/es6-module-transpiler">ES6 module transpiler</a>. Still, this is a far cry from Tom's blog post and likely reflects the widespread adoption of AMD in the developer community around Ember.
</p>
<p>
With Ember reaching 1.0 status as of August 31, I'm taking another look to see if the stability, module support, and documentation have improved. I'll build out a demo app with the same Youtube emulator domain as other recent demos for side-by-side comparison of a fairly simple but non-trivial example application across frameworks/libraries. I'll post the source on github and link here when it's done.</p>
<div class="UIShareStage_BottomMargin">
<a href="https://plus.google.com/103111703863182774756/about" target="_blank" rel="author"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a> </div>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com1tag:blogger.com,1999:blog-786462009810720025.post-76137359339844814592013-09-03T12:43:00.000-07:002013-09-03T12:43:43.335-07:00Nexus 7<p>So I finally bit the bullet and bought a tablet. After hanging back looking at various offerings I decided to get the new Nexus 7 from Google/Asus, mainly for its combination of low price point and excellent reviews/features.</p>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj00oJpnOA1vGtXLyFo49VGOKnxzM-jQNM5KMWdS1NELjHkmQkycTIJFOkoFLBNq4XvxCWnhcypzBiVvx_sK0X1-9Ok9XjQeLcd_IOLOjvobJeKeCc59BYhkqMfoEVPLlGUXKSBkTze2A/s1600/photo.JPG" imageanchor="1"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj00oJpnOA1vGtXLyFo49VGOKnxzM-jQNM5KMWdS1NELjHkmQkycTIJFOkoFLBNq4XvxCWnhcypzBiVvx_sK0X1-9Ok9XjQeLcd_IOLOjvobJeKeCc59BYhkqMfoEVPLlGUXKSBkTze2A/s320/photo.JPG" /></a>
<p>
I bought it mainly for fun/casual use but want to tinker a little also, so I paired the Nexus 7 with a Microsoft Wedge bluetooth keyboard and mouse, and installed the <a href="https://play.google.com/store/apps/details?id=org.xeustechnologies.android.kws&hl=en">kWS Android web server</a> and <a href="https://play.google.com/store/apps/details?id=com.aor.droidedit&hl=en">DroidEdit</a> so I can do bare-bones web development right on the tablet.
</p>
<p>
I've only had the device for a few days and am still finding my way around, but so far I'm pretty happy. I'll try to post a detailed review soon.
</p>
Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-11624486001428363762013-08-16T11:52:00.003-07:002013-08-16T15:22:48.952-07:00Aura.Backbone.YouTubeContinuing with my theme of demo projects built on a common problem domain - a bare-bones YouTube emulator - I decided to dive into Aura.js <a href="http://aurajs.com/">http://aurajs.com</a>. Aura is a "clean and scalable architecture for complex JavaScript applications" that evolved from ideas put forth by Googler <a href="http://addyosmani.com/largescalejavascript/" target="_blank">Addy Osmani</a> and former Yahoo <a href="http://www.slideshare.net/nzakas/scalable-javascript-application-architecture" target="_blank">Nicholas Zaka</a>s . It provides a high-level component-based abstraction with focus on sandboxing and inter-component communication via publish/subscribe. Aura is framework-agnostic, so you can plug in popular tools like Backbone, Angular, Ember, etc. For the demo I plugged in the ever popular Backbone library.<br />
<br />
View the demo here <a href="http://tdoherty.github.io/aura.backbone.youtube/" target="_blank">http://tdoherty.github.io/aura.backbone.youtube/</a><br />
<br />
View the source on github:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://fbexternal-a.akamaihd.net/safe_image.php?d=AQCujY3ge-QFx-vn&w=100&h=100&url=https%3A%2F%2Fgithub.global.ssl.fastly.net%2Fimages%2Fgravatars%2Fgravatar-user-420.png&cfs=1&upscale" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://fbexternal-a.akamaihd.net/safe_image.php?d=AQCujY3ge-QFx-vn&w=100&h=100&url=https%3A%2F%2Fgithub.global.ssl.fastly.net%2Fimages%2Fgravatars%2Fgravatar-user-420.png&cfs=1&upscale" /></a></div>
<a class="UIShareStage_InlineEdit inline_edit" href="https://github.com/tdoherty/aura.backbone.youtube/tree/master" role="button" target="_blank">aura.backbone.youtube</a><br />
<div class="UIShareStage_Subtitle">
https://github.com/tdoherty/aura.backbone.youtube</div>
<div class="UIShareStage_BottomMargin">
aura.backbone.youtube - An Aura.js demo using Backbone.js and YouTube APIs</div>
<div class="UIShareStage_BottomMargin">
<br /></div>
<div class="UIShareStage_BottomMargin">
<a href="https://plus.google.com/103111703863182774756/about" target="_blank" rel="author"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a> </div>
Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-32632019357004200042013-04-19T05:13:00.000-07:002013-08-16T10:31:18.192-07:00<blockquote>
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them."</blockquote>
<br />
~Alan Kay<br />
<br />
So my colleagues and I were having a discussion about object oriented programming (OOP) and exactly what it means today versus when the term was first coined by Alan Kay in the late 60’s. Specifically, whether prototype-based languages are truly object oriented as compared to class-based languages which are the mainstream. It’s very interesting to read Kay’s own take on the subject, and realize that what most of us consider to be OOP today resembles but little the original conception.<br />
<br />
<div style="clear: both; padding-top: 10px;">
<br />
<a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a><br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-42468782696814133142013-04-02T06:16:00.000-07:002013-08-16T10:05:33.104-07:00Backbone Boilerplate<span class="userContent">I wrote a rough demo with Tim Branyen’s Backbone Boilerplate using YouTube data feeds. It’s a work in progress as I’m learning Backbone Boilerplate and its bundled LayoutManager.<br /><br />Check out the demo <a href="http://tdoherty.github.com/bbb.youtube" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank">here</a></span>
<br />
<br />
<img alt="" class="img" src="https://fbexternal-a.akamaihd.net/safe_image.php?d=AQDAacwkOhqzeWDH&w=155&h=114&url=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F481d556f479c71e5cc06f1493d4f6613%3Fs%3D420%26d%3Dhttps%253A%252F%252Fa248.e.akamai.net%252Fassets.github.com%252Fimages%252Fgravatars%252Fgravatar-user-420.png" style="float: left;" />
<a href="https://github.com/tdoherty/bbb.youtube" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank" title="bbb.youtube">Backbone-Boilerplate.YouTube</a><br />
<a href="https://github.com/tdoherty/bbb.youtube" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank">github.com</a><br />
<span class="share-desc">A Backbone Boilerplate demo using YouTube feed data. Contribute to Backbone-Boilerplate.YouTube development by creating an account on GitHub.</span>
<br />
<a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-17346542769298176922013-03-13T06:36:00.000-07:002013-08-16T14:30:41.822-07:00AngularJS<span class="userContent">I wrote a rough demo with Google’s AngularJS using YouTube data feeds. It’s a work in progress as I’m learning Angular.<br /><br />Check out the demo <a href="http://tdoherty.github.com/angular.youtube" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank">here</a></span>
<br />
<br />
<img alt="" class="img" src="https://fbexternal-a.akamaihd.net/safe_image.php?d=AQDAacwkOhqzeWDH&w=155&h=114&url=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F481d556f479c71e5cc06f1493d4f6613%3Fs%3D420%26d%3Dhttps%253A%252F%252Fa248.e.akamai.net%252Fassets.github.com%252Fimages%252Fgravatars%252Fgravatar-user-420.png" style="float: left;" />
<a href="https://github.com/tdoherty/angular.youtube" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank" title="Angular.YouTube">Angular.YouTube</a><br />
<a href="https://github.com/tdoherty/Angular.YouTube" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank">github.com</a><br />
<span class="share-desc">An AngularJS demo using YouTube feed data. Contribute to<br /> Angular.YouTube development by creating an account on GitHub.</span><br />
<a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a><br />
<div style="clear: both; padding-top: 10px;">
<br /></div>
Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-54011834156510539662013-03-08T00:57:00.000-08:002013-08-16T14:31:24.719-07:00jQuery.SpinJS<span class="userContent">I created a jQuery plugin wrapping Felix Gnass’ excellent spin.js. The plugin adds a background div with configurable color and transparency, and supports AMD. Check it out and let me know what you think.</span><br />
<br />
<br />
<div style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;">
<img alt="" class="img" src="https://fbexternal-a.akamaihd.net/safe_image.php?d=AQDAacwkOhqzeWDH&w=155&h=114&url=https%3A%2F%2Fsecure.gravatar.com%2Favatar%2F481d556f479c71e5cc06f1493d4f6613%3Fs%3D420%26d%3Dhttps%253A%252F%252Fa248.e.akamai.net%252Fassets.github.com%252Fimages%252Fgravatars%252Fgravatar-user-420.png" />
</div>
<a href="https://github.com/tdoherty/jQuery.SpinJS" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank" title="jQuery.SpinJS">jQuery.SpinJS</a><br />
<a href="https://github.com/tdoherty/jQuery.SpinJS" style="color: grey; font-weight: bold; text-decoration: none;" target="_blank">github.com</a><br />
<span class="share-desc">jquery plugin for spin.js. Contribute to <br /> jQuery.SpinJS development by creating an account on GitHub.</span>
<br />
<br />
<a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a><br />
<br />Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-86119211897722849082013-03-04T02:42:00.000-08:002013-08-16T14:31:41.678-07:00Client Side JavaScript MV* With Ember.jsMy team at work is evaluating the suitability of several tools for client-side application development. We’re looking at building out some non-trivial applications on the client and wanted to make the best collective, educated decision on the best tool(s) for the job.<br />
<br />
The tools we’ve been looking at include:<br />
<br />
<ul>
<li>Backbone</li>
<br />
<li>Knockout</li>
<br />
<li>Angular</li>
<br />
<li>Ember</li>
</ul>
<h3>
<b>Backbone</b></h3>
<br />
I’ve already grown pretty familiar with Backbone, having spearheaded its adoption into our tools set a year or so ago. We’ve built out a few non-trivial applications with Backbone and admire it’s simplicity and elegance. Backbone is lean and non-prescriptive, it’s a minimalistic library that gives you the most basic structure and tools for event-based model management. <br />
<a name='more'></a>Backbone is view-agnostic, meaning it gives you a basic wrapper for an event-based view and leaves rendering, model binding and plumbing up to you. It’s designed to work with a REST API out-of-box but can be easily customized. A router is provided but is optional<br />
<br />
<h3>
<b>Knockout</b></h3>
<br />
I built out a fairly simplistic but non-trivial demo application with Knockout a few months back. Microsoft is bundling it with VS 2012 so I thought it was worth taking a look under the hood. Knockout’s focus is on the UI, and it’s primary selling point is declarative two-way model binding. It’s a pretty slick library, but the DOM-based templating and mixture of behavior with markup leave me a little concerned with regard to maintainability at a large scale. My takeaway was that Knockout is best suited for smaller applications or “islands of richness” in traditional web applications.<br />
<br />
<h3>
<b>Angular</b></h3>
<br />
Angular is currently being evaluated by one of my colleagues. It’s a research project from Google, which they describe as a “Superheroic JavaScript MVW Framework.” The “W” stands for Whatever, so you have models, views, and “whatever” you need to get the rest done. It uses declarative DOM based templating and a modular approach that is non-prescriptive. I’ll have to look under the hood myself before I can give an educated opinion on Angular.<br />
<br />
<h3>
<b>Ember</b></h3>
<br />
Last but not least, I’ve been building out a demo with Ember.js. Ember takes a different approach in that it’s designed as a full-fledged application framework. It was designed by Rails and SproutCore contributors Yehuda Katz and Tom Dale, and is essentially a ground-up rewrite of SproutCore. It’s an impressive piece of work, there’s much to admire here, though there are some non-trivial concerns also.<br />
<br />
<i>Initial thoughts:</i><br />
<br />
<ul>
<li>The learning curve is fairly steep, mostly getting your head around the core concepts of the framework. The Rails heritage of Ember is apparent: the framework is URL-centric - with the router front-and-center - and has a strong preference for convention over configuration. This made it a little difficult to get started at first, coming from a C#/.NET background where configuration is preferred.</li>
<br />
<li>The documentation is still in-progress. The “Ember Guides” are somewhat vague and inconsistent, making it hard to get up to speed.<i><br /></i></li>
<br />
<li>The framework is nearing a 1.0 release, after which the core team intends to stabilize and lock it down. Until then, it is very much in transition, with regular breaking changes.</li>
</ul>
<i>Ember.Application</i><br />
<br />
Ember is designed for SPA (single page application) development, and controls your entire document. It requires a global application variable, to which you assign the result of Ember.Application.create(). The Application object is responsible for:<br />
<br />
<ul>
<li>Acting as your application’s namspace</li>
<br />
<li>Event delegation: adds listeners to your document and delegates them to your views</li>
<br />
<li>Automatically renders your topmost application template</li>
<br />
<li>Creates a router and starts routing with the current URL</li>
</ul>
I have been using RequireJS/AMD as part of my tool set for a while now, and had hoped to create an Ember application without introducing a global application variable. Ember co-creator Tom Dale is not a fan of AMD - <a href="http://tomdale.net/2012/01/amd-is-not-the-answer/" target="_blank"></a><a href="http://tomdale.net/2012/01/amd-is-not-the-answer/" target="_blank">http://tomdale.net/2012/01/amd-is-not-the-answer/</a> - but I’m among a growing number of JavaScript developers embracing it as a stepping stone to native modules.<br />
<br />
I created all my Ember entities as AMD modules, and used the undocumented (as yet) Application.createWithMixins() function to pass in a hash of the resulting module return values, rather than adding instances to the created application.<br />
<br />
<i>Routing</i><br />
<br />
Routing is the primary focus in Ember. Every state in an Ember application is represented by a URL. Your models, views, and controllers all stem from a URL route and are associated by naming convention to that route. If you follow Ember conventions, and don’t require custom code, Ember will provide a router handler and controller “automagically,” dramatically reducing boilerplate code for common scenarios.<br />
<br />
<script src="https://gist.github.com/tdoherty/6251954.js"></script>
Routes with a dynamic segment, like our “agent” resource above for example, have a common hook that is implemented automatically if not specified by a route handler:<i><br /></i><br />
<br />
<script src="https://gist.github.com/tdoherty/6251989.js"></script>
What’s happening here is: the route handler is specifying a model that represents the current state (route) of the application; the default hook is to call a find() method on the corresponding model (named “Agent” by convention after the route) and passing in the dynamic segment of the URL. The next method, setupController() sets the resulting model as the ‘content’ property of the associated controller. (“AgentController”, again by convention)<i><br /></i><br />
<br />
<i>Templates</i><br />
<br />
Ember has deep integration with the <a href="http://handlebarsjs.com/" target="_blank">Handlebars</a> templating library, by Ember co-creater Yehuda Katz. Handlebars is a string-based templating library that supports conditionals and iterators. Ember some framework-specific semantics to its lexicon.<br />
<br />
<script src="https://gist.github.com/tdoherty/6252001.js"></script>
The canonical approach is to embed templates in your markup using <script> tags with a name attribute matching the template’s associated route. Using this approach it is largely possible to write Ember applications without writing View objects. However, since I’m using AMD and prefer to load my templates from separate files I’m creating View objects and specifying the compiled template as a property of the View:<br />
<br />
<script src="https://gist.github.com/tdoherty/6252017.js"></script>
<i>Controller</i><br />
<br />
Ember controllers present application state to templates. They are a representation of a model (or array of models) suitable for rendering by the template. Ember provides ObjectController and ArrayController “classes” for this purpose, which act as proxies to their underlying models.<br />
<br />
<i>Ember Data</i><br />
<br />
The Ember Guides on the EmberJS website discuss Ember Data as the de facto persistence provider. From the website:<br />
<br />
<blockquote>
<br />
“It provides many of the facilities you’d find in server-side ORMs like ActiveRecord, but is designed specifically for the unique environment of JavaScript in the browser.”<br />
<br /></blockquote>
<br />
However, Ember Data does not ship with Ember, it is available via its GitHub repository, which clearly states that it is alpha quality and not production ready. Also, in order the get an current version of Ember Data, you have to clone the repository and build it with Ruby. While this makes sense given the Rails heritage, it’s off-putting for non-Ruby developers.<br />
<br />
Anyway, I installed Ruby and built Ember Data so I could do a little investigation. Once nice feature is the FixtureAdapter, which lets you use in-memory data structures (an array of objects) to develop against prior to building out a server persistence layer.<br />
<br />
Ember Data has a lot of promise, but I feel the Ember website shouldn’t be promoting it as the de facto solution when it’s clearly not finished.<br />
<br />
<i>Pros</i><br />
<br />
<ul>
<li>Good abstraction, lots of “nuts and bolts” operations are handled for you</li>
<br />
<li>If you follow Ember conventions, you’ll write less boilerplate code than with other tools in this sector</li>
<br />
<li>The newest version of Ember Router provides robust routing/state management</li>
<br />
<li>Automatic memory management: Ember automatically binds and unbinds event listeners for garbage collection</li>
<br />
<li>Global event delegation: event handlers are bound once to the application’s root element (typically the document) and events are delegated downwards for greater efficiency/smaller memory footprint</li>
<br />
<li>Batch DOM updates: Ember gathers potential DOM updates and periodically applies them in batch for better performance. DOM updates are expensive.</li>
</ul>
<i>Cons</i><br />
<br />
<ul>
<li>Ember is prescriptive. It’s a very opinionated framework, you have to build an application that fits the Ember architecture vs. building an architecture for your application<i><br /></i></li>
<br />
<li>Difficult to debug: abstraction and “automagical” housekeeping comes at the cost of complexity. Errors can be very hard to track down, so much so that Yehuda Katz authored an <a href="https://github.com/tildeio/ember-extension" target="_blank">Ember Inspector</a> extension for Chrome to aid in debugging Ember apps</li>
<br />
<li>You write “Ember code” and not much normal JavaScript, which is a quirky language to begin with</li>
<br />
<li>Ember has an odd capitalization convention: capitalized properties are assumed to be global variables in Handlebars conditionals/iterations, etc. Not only does this not fit the JavaScript community convention (capitals for Constructors only) but it’s very problematic for persistence layers with capitalized fields (i.e, enterprise)</li>
<br />
<li>Documentation is still a work in progress, the guides are vague and inconsistent, making it hard to get up to speed</li>
<br />
<li>The community is nascent, mostly Ruby or Rails oriented, many plugins have to be built with Ruby</li>
<br />
<li>Nearing a 1.0 release, when hopefully the core will stabilize. Yehuda and Tom’s (admirable) approach has been to let the community drive development, but this comes as the cost of instability</li>
</ul>
<i>Conclusion</i><br />
<br />
<ul>
<li>Ember.js is a powerful framework, showing tremendous promise. There is much to admire here.</li>
<br />
<li>Ember is well-suited to Single Page Applications (SPAs) with longer user interactions, where memory management is a concern.</li>
<br />
<li>If you subscribe to the “Ember way” it provides good abstraction, reduces boilerplate code, and handles a lot fo plumbing for you.</li>
<br />
<li>with great power comes great responsibility… all this power comes at the cost of flexibility and ease of debugging.</li>
<br />
<li>There are some non-trivial concerns, especially the framework’s transitional state as it moves towards a 1.0 release</li>
</ul>
I think we will take a “wait and see” approach on Ember, as I think it’s still just a little too early… it’s not quite ready for prime time until a 1.0 release is stabilized and Ember Data moves to a 1.0 release and/or gets bundled with the core. Still, it’s hard not to admire Yehuda and Tom’s work here. This is a well thought out, robust approach to client side application development.<br />
<br />
<a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img alt="image" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-35190225823017088082012-02-27T05:27:00.000-08:002013-08-16T14:08:45.366-07:00Twirl Your Mustache<b>Reuse Templates On The Client And Server With CouchDB, CouchApp, and Mustache</b><br />
<br />
In my <a href="http://blog.dohertycomputing.com/post/17731104378/relax-or-adventures-with-couchdb-for-fun-and-profit" target="_blank">last post</a> I talked about my introduction to building applications with Apache CouchDB and CouchApp. I’ve been refactoring the app to use Backbone.js and RequireJS on the client, and to take advantage of templating to make presentation logic more DRY. This post shows how to reuse Mustache templates on the client and server using CouchDB and CouchApp. I’ve left out the Backbone/RequireJS code for simplicity, and illustrate the client code using jQuery’s shorthand ‘$.get’ AJAX method.<br />
<br />
<a href="http://mustache.github.com/" target="_blank">Mustache</a> is a logic-less templating language available for a variety of languages. It ships with CouchApp, and Backbone is agnostic, so it seemed a no-brainer. Mustache supports partial templates, for portions of a page’s markup, and I’ll show how to reuse a partial template to do a partial page refresh on the client.<br />
<br />
Say we have the following extremely simplistic template:<br />
<br />
/templates/page.html:<br />
<script src="https://gist.github.com/tdoherty/6253469.js"></script>
<br />
Partial templates are indicated with the greater than (‘>’) symbol, so here we’re indicating that a partial template named ‘content’ should be rendered in the <div id=”content”> element. Now let’s say we have the following partial template:<br />
<br />
/templates/partials/content.html:<br />
<script src="https://gist.github.com/tdoherty/6253487.js"></script>
<br />
For the server side, we can render HTML pages via CouchDB ‘shows’ and use Mustache in the show code, i.e.:<br />
<br />
/_shows/page.js:<br />
<script src="https://gist.github.com/tdoherty/6253501.js"></script>
<br />
Here, this.templates refers to the current design document’s ‘templates’ property, and this.templates.partials to its ‘templates.partials’ property. These correspond to your CouchApp’s directory structure prior to push.<br />
<br />
We can then hit the page at: /dbname/_design/docname/_show/page, and use a combination of rewrites.json and a proxy or virtual host to pretty up the URL.<br />
<br />
For our purposes, we’re considering reusing a template from the ‘partials’ directory for a client-side partial page refresh. We can serve the template markup from a show also, passing the template name in the URL, i.e., /dbname/_design/docname/_show/templates/page.html:<br />
<br />
/_shows/templates.js:<br />
<script src="https://gist.github.com/tdoherty/6253510.js"></script>
<br />
Here, we first look for the template name in the design doc’s templates, then in templates.partials.<br />
<br />
On the client, we’ll use the jQuery plugin for mustache, which ships with CouchApp:<br />
<br />
<script src=”vendor/couchapp/jquery.mustache.js”></script><br />
<br />
First we’ll make a GET request for the template:<br />
<br />
<script src="https://gist.github.com/tdoherty/6253514.js"></script>
<br />
Then for a partial refresh, we’ll GET our updated data and apply the same partial template on the client:<br />
<br />
<script src="https://gist.github.com/tdoherty/6253519.js"></script>
<br />
This is an extremely simplistic example, the point being to illustrate the considerable DRY we can achieve through template reuse. Write the template once, and use it on both the client and server.<br />
<br />
Nice!<br />
<br />
<a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img alt="" height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" /></a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-43270916820225075162012-02-16T06:44:00.000-08:002013-08-09T14:09:17.537-07:00Relax, or, adventures with CouchDB for fun and profit.<p>My employer is pretty cool about allowing devs freedom in choosing tools. They also support R&D-based “play time” to explore new technologies as they pertain to our problem domains. I’ve had a great time over the past year and half specializing in JavaScript development using tools like Backbone.js, RequireJS, Node, etc., while continuing full-stack development for the enterprise.</p><br/><p>Recently I got the opportunity to use CouchDB for a customer-facing project. Before he left to pursue greener pastures, our former Development Director authored a conference registration site using CouchDB and CouchApp. Since I’ve earned the “JavaScript Guy” moniker here, I was presented the opportunity of taking over the app for this year’s conference.</p><br/><p>Apache <a href="http://couchdb.apache.org/" target="_blank">CouchDB</a> is a document-oriented database that can be queried and indexed using JavaScript in a MapReduce fashion. CouchDB provides a RESTful JSON API than can be accessed from any environment that allows HTTP requests. <a href="http://couchapp.org/page/index" target="_blank">CouchApps</a> are JavaScript and HTML5 applications served directly from CouchDB. Assuming your application can fit into those constraints, then you get CouchDB’s scalability and flexibility “for free” (and deploying your app is as simple as replicating it to the production server).</p><br/><p>CouchDB represents a significant paradigm shift coming from a relational SQL background. It is extremely flexible as a document store, it is ad-hoc and schema-free, and provides powerful incremental peer-based replication for distributed storage. Like all NoSQL databases, it is not intended as a panacea, nor intended as a substitute for relational databases. It is simply another available tool to evaluate based on a project needs basis.</p><br/><p>This project also gave me some exposure to <a href="http://nginx.org/en/" target="_blank">nginx</a>, which is used as a proxy to CouchDB, and <a href="http://python.org/" target="_blank">Python</a>, which is used for some administrative features behind the scenes.</p><br/><p>It’s been pretty awesome getting to know CouchDB, and adding it to my tool belt for consideration on future projects. I’ll try to post more specifics as time permits.</p><br/><p><a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img height="16" src="http://www.google.com/images/icons/ui/gprofile_button-16.png" width="16" alt="" /></a></p>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-79896178856781615672011-10-31T03:42:00.000-07:002013-08-16T11:11:48.566-07:00<div class="figure">
<br />
<figure><br /> <img alt="" height="491" src="http://31.media.tumblr.com/tumblr_ltxyj7t9Ax1qhn0j6o1_1280.png" width="640" /></figure></div>
<br />
<br />
Freddy vs. JSONAnonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-87925483061308357342011-10-26T01:17:00.000-07:002013-08-16T11:11:48.572-07:00RequireJS 1.0 ReleasedLink: <a href="http://tagneto.blogspot.com/2011/10/requirejs-10-released.html">RequireJS 1.0 Released</a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-31112553252643675722011-10-25T09:33:00.000-07:002013-08-09T14:09:17.565-07:00On ParenthoodLink: <a href="http://www.codinghorror.com/blog/2011/10/on-parenthood.html">On Parenthood</a><br/><br/> <p>Great post by Jeff Atwood, founder of <a href="http://stackexchange.com/" target="_blank">Stack Exchange</a>, on becoming a parent. Well said.</p>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-67221737448940450122011-10-13T06:41:00.000-07:002013-08-09T14:09:17.573-07:00Programming Motherfucker! Do you speak it?Link: <a href="http://programming-motherfucker.com/">Programming Motherfucker! Do you speak it?</a><br/><br/> <p>Not for the easily offended, and I don’t agree with all of it, but it’s hilarious when you picture Sam Jackson saying it! ;)</p>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-7122429724678753382011-10-07T09:58:00.000-07:002013-08-09T14:09:17.583-07:00Future-Proofing Your JavaScript Applications for Improved ScalabilityLink: <a href="http://addyosmani.com/futureproofjs">Future-Proofing Your JavaScript Applications for Improved Scalability</a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-20376988270313831302011-09-29T05:18:00.000-07:002013-08-09T14:09:17.590-07:00What? You Tattooed Code on Your Arm?Link: <a href="http://www.sangwine.net/jim/index.php/2011/09/what-you-tattooed-code-on-your-arm/">What? You Tattooed Code on Your Arm?</a>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0tag:blogger.com,1999:blog-786462009810720025.post-8393338269888109122011-08-15T06:50:00.000-07:002013-08-16T11:11:48.568-07:00RequireJS PresentationLink: <a href="http://www.slideshare.net/tim_doherty/requirejs-8858167">RequireJS Presentation</a><br/><br/> <p><a href="http://www.slideshare.net/tim_doherty/requirejs-8858167" target="_blank"><img src="http://cdn.slidesharecdn.com/requirejs-publish-110815153042-phpapp01-thumbnail-2" align="top" height="90" width="120" alt="" /></a></p><br/><p>RequireJS - Adventures with an asynchronous script loader</p><br/><p>A presentation I created for the dev team at work, published with the blessings of our director of development…</p><br/><p><a href="https://plus.google.com/103111703863182774756/about" target="_blank"><img src="http://www.google.com/images/icons/ui/gprofile_button-16.png" height="16" width="16" alt="" /></a></p>Anonymoushttp://www.blogger.com/profile/12722785636766807334noreply@blogger.com0