Disqus - Latest Comments for dmosher

Re: JavaScript Modules and Dependencies with jspm

David Mosher — Mon, 10 Nov 2014 13:43:24 -0000

Cool, I'm curious to know:

1. How large is your minified bundle of JS?
2. How many XHR's fire when you boot up the app in dev mode for the first time?

Re: JavaScript Modules and Dependencies with jspm

David Mosher — Mon, 10 Nov 2014 12:14:52 -0000

Nice post, I appreciate the brevity and sequencing of the follow-along style :)

I found myself nodding as I followed along in the terminal and trying to draw comparisons to a horrible experience I had working on an application that used RequireJS in production. What follows is just a brain dump of some questions:

1. Do you find using jspm on your _large_ project a hindrance due to the mismatch between the way assets are loaded in development (XHR) and in production (minified bundle)?
2. Are you deploying a large minified bundle to production, many small bundles, or using a remote loading strategy?
3. Does jspm allow you to manage slicing applications of significant size along appropriate lines so you can chunk things up into smaller bundles?

Re: end to end with angularjs

David Mosher — Fri, 24 Jan 2014 11:01:42 -0000

The client-side auth strategy is pretty barebones, but yes you could just invert with a !, or I might be inclined to just rename the variable to `routesThatRequireAuth` and make it a whitelist instead of a blacklist.

Re: File Watching with Fireworm and Watch'em

David Mosher — Thu, 22 Aug 2013 18:16:23 -0000

Cool stuff Toby, and good to hear about the upgrade to Testem. We'll upgrade the dependency version in Lineman asap :)

Re: my workflow with lineman - Angular Tips

David Mosher — Mon, 19 Aug 2013 16:22:03 -0000

Thanks for all the plugs Jésus, you did an awesome job describing the benefits of Lineman and how it enables you to take your rich-client web app, regardless of framework, and promote it to a first-class citizen. Nice work!

Re: http://docs-next.angularjs.org/api/angular.mock.module

David Mosher — Thu, 15 Aug 2013 19:47:40 -0000

This still occurs in 1.2.0rc1 as well.

Re: The web: less engine, more gas

David Mosher — Wed, 17 Jul 2013 12:37:28 -0000

The last few years have yielded a massive expansion in browser capabilities; the vendors and standards bodies have been pushing hard to release new APIs and features to make the browser even more viable as a deployment platform for rich web experiences. If I think back just even 6 years ago, it's not hard to remember a time when there were no new capabilities being added; when we were stuck in a sort of stagnated contraction in what was happening on the web. This sort of expanding/contracting cycle is a pretty natural thing in the evolution of technologies; but we are definitely in an expansion stage.

This puts pressure on those of us who identify ourselves as "Web" developers, because it means we have to continue to try and keep up with the rapid pace of change in the world of the browser. It also puts an order of magnitude _more_ pressure on people entering the field of web development in 2013 and I have a lot of empathy for those who take that plunge. As Paul mentioned in his comment, this appears as a real dark art to those people just coming in. The focus on performance, tooling, devops-y type things, is a response to the massive expansion we are in; but I think the danger is, as you've pointed out, that we leave the foundations of the "experience" of the web and what we build behind while we obsess over "the new shiny".

One of the incorrect assumptions I've had to correct in my own mind is the idea that a beautifully _architected_ web experience == a great web experience; this was made clear to me as I explored the amazing http://www.forecast.io app on my iOS device. I dug into the code and noticed it was just a bunch of jQuery plugins strapped together! The smarmy "architect" in me wanted to look at that and dismiss it as a horrible architecture, but then I just sat back and looked at the UX of the app and it blew me away that such an awesome experience could be created on the mobile web! That experience really made me get introspective about my preconceived ideas on "beauty" as it relates to the web; UX > Architecture, and that's the way it should be because that's what our users care about :)

I love your conclusion and I agree 100%, now that we have these awesome tools and APIs it's time to create some kick ass experiences with the platform we've been handed.

Thank you for posting your thoughts, I know they resonate with me and many more in the front-end community!

Re: ES6 Modules, Build Tools and Browser App Delivery

David Mosher — Tue, 16 Jul 2013 14:02:38 -0000

> Shipping globals is the easiest thing for the author

Yup, I think we're in agreement here, although I would add "with .noConflict" to differentiate slightly.

> , but the worst scenario for the application developer.
> If you have dependencies for your script, the user has to go download those files and manually put them by yours

There are a couple of competing ideas here:

1. the pain associated with having to go download a script manually (minor, imho)
2. the pain associated with having to determine the correct order for scripts to load in (also minor, imho)
3. the pain of programmatically creating a build by solving 1 and 2

As a user, I'm happy with dealing with the pain points of 1 and 2 because they are pretty minor and they usually involve thinking about things once upfront. Most of the rich-client apps I build for the browser have a pretty small list of ordering constraints thanks to file globs; typically jQuery first, MV* lib second, other vendor deps third, and my app code 4th.

Right now none of the module formats and tools out there is sufficiently simple enough to warrant moving away from this approach, but I realize this is a personal thing.

Trying to make things easy is a noble goal, but I'm not sure it's the right one. Web developers should be considering the impact of their actions every time they add a dependency; IME the current mindset enabled by existing module loaders and formats seems to be "fire and forget", which I have frequently seen spiral out of control into performance nightmares and messes of transitive dependency hell.

There should be no "easy" replacement for thinking hard about things in software development.

Re: ES6 Modules, Build Tools and Browser App Delivery

David Mosher — Mon, 15 Jul 2013 18:29:00 -0000

Right, I think "globals" + .noConflict is the easiest way to ship a library that can be easily used by the rest of the world and not require any configuration. Excluding advanced techniques like lazy-loading, the lowest common denominator is including _script_ elements in order in your HTML; obviously that itself doesn't scale very far but for the majority of web developers and applications it works just fine. Once you hit the point of needing to scale beyond that, the next logical step is concatenation to avoid extra HTTP requests, and minification to reduce the over-the-wire cost of the payload, which is also well understood IME.

My experience with the "other" module formats is that they impose restrictions on how I get to my concatenation/minification baseline, which I think many other web developers hit a wall with before saying "screw it, I don't understand all this module crap, I'ma stuff this js all in one file and call it a day".

Is the point of UMD to support "globals" + .noConflict as a baseline while also supporting AMD/CommonJS/[insert whatever other module scheme comes before ES6 modules here] ?

Edit:** also, if we are authoring in ES6 now the transpilation step imposes a build step in the pipeline which, as you mentioned, is a pretty big barrier to many web developers.

Re: ES6 Modules, Build Tools and Browser App Delivery

David Mosher — Mon, 15 Jul 2013 17:50:14 -0000

I like how cleanly you summarized the current state of app construction in your "app delivery graph"; the thing I struggle with in this entire debate is how relevant this discussion is to the majority of web developers? All of the best practices we hear about as web developers come from huge companies (google, fb, yahoo, etc...) or people working at huge companies who are solving problems at a scale that the vast majority of web developers would never experience.

I believe in lazy loading, and in performance optimization, and all the good "front-end ops" type things that have been written frequently about over the last 18 months, but I firmly believe those discussions are lost on most web developers. Perhaps I'm in the wrong forum for this type of discussion, but it seems like this is focused on module authors and not end-users; who is advocating for the users and (to use a horrible metaphor) gathering feedback from people working in the 99% instead of the 1%?

I just want something to win so end-users of libraries don't have a bad experience when they go to use a library and find out the author chose AMD (or CommonJS, or whatever else) and _only_ supports that module format. Right now IMHE, globals is the lowest common denominator for 99% of web developers [citation needed :P] which is why I usually optimize for that path in the tools (Lineman) I use and work on.

Thanks again for writing up the summary, it's the best article I've read to date that hits all of the high-level technical details and app architecture strategies; I need to go spend some time thinking and talking to end-users of modules about what they really need.

Re: AngularJS with JayData– the Todo example with the ItemStore API

David Mosher — Mon, 08 Jul 2013 12:29:51 -0000

It's cool to see more data adapters appearing for Angular JS! I do have a minor suggestion on how to improve your adapter to be more "Angular" like; when I first read the post I was confused about where $data was coming from because the "Angular Way" often involves utilizing the built-in dependency injection to provide all dependencies in your controller.

I didn't see the $data injected as a dependency, which is what confused me. My suggestion is to create a Service abstraction around $data using Angulars Provider mechanism, you could then use the .configure block to setup the specific configuration options in your $data.define block and inject the Todo as a dependency into your controller.

Here are some resources that showcase how to do this well:

http://www.egghead.io/video...

http://blog.jdriven.com/201...

https://github.com/davemo/f...

Re: frontend workflows with grunt and angularjs

David Mosher — Mon, 08 Jul 2013 10:41:08 -0000

Yes token based auth is one strategy that can work if you want to have a completely separate API and clients in production. :)

Re: frontend workflows with grunt and angularjs

David Mosher — Sun, 07 Jul 2013 08:00:11 -0000

You don't want to mess with index.php; Laravel requires that file in order to work. I would take the contents of my Lineman index.html file and put them into a Laravel view, as I covered in the end-to-end video.

Re: yes man

David Mosher — Wed, 26 Jun 2013 14:47:03 -0000

Thanks! This is an old post but I left it in the archive when I migrated my blog from posterous because it still rings true for me :)

Re: AngularJS vs Ember: It's not even close

David Mosher — Sun, 16 Jun 2013 17:35:28 -0000

It's a fundamentally different philosophy, if what you are proposing is that the people that built Ember have all of the best-practices nailed down then I heartily disagree; in my experience, history has shown that accepted use patterns often emerge from the community more than from a handful of visionaries.

I think this is where both Angular and Ember are at the moment: neither has all the answers, and neither is mature enough to be able to emphatically say "this is how you do x,y and this is the best because of z". The fact that the Ember developers and users seems to indicate that it has all the answers is somewhat of a disappointment.

Re: AngularJS vs Ember: It's not even close

David Mosher — Sun, 16 Jun 2013 17:29:05 -0000

How long did it take Rails to answer the same question: what is idiomatic Rails? How many times has the answer to this question changed since 2004? (I'd posit quite a few times, especially when given Steve Klabniks excellent post) http://words.steveklabnik.c....

Angular hit 1.0 almost a year ago, it doesn't have enough real world use under its belt to answer the question: "what is idiomatic Angular?" and neither does Ember.

Re: AngularJS vs Ember: It's not even close

David Mosher — Sun, 16 Jun 2013 17:21:34 -0000

Regardless of the framework, the quality of the documentation, or the existence/lack of conventions there will be always be developers who do things the way they want to. Ember might propose conventions in the same way that Rails did, but that doesn't mean there won't be egregious missteps by developers using the frameworks.

What I'm trying to say is that you shouldn't fault Angular for not providing a set of common conventions; creating effective documentation is hard regardless of the tech involved.

Re: AngularJS vs Ember: It's not even close

David Mosher — Sun, 16 Jun 2013 16:55:32 -0000

At a high level, I don't think either has "won", they are different; not bad, not good, just different. Both Angular and Ember are pretty close in terms of functionality. I'd like to highlight a couple of areas the author talked about for further discussion.

**Models**

I think the Angular teams decision to avoid the use of framework built-in model objects to extend from is advantageous when considering testing and simplicity (which the author covered). Choosing to inherit from `Ember.Object` adds the overhead of needing to know what is going on under the hood when it comes to model objects, much the same way that extending ActiveRecord or any other ORM does.

Having worked with Backbone (and Backbone.Model) extensively for the last 18 months I actually longed for a simpler abstraction; when I encountered Angular controllers and their use of JavaScript primitives as models it was a breath of fresh-air. No overhead to understanding what I was getting by extending some built-in, extreme ease of testability (just inject primitives in tests), and the flexibility to craft my own higher level abstractions if necessary.

**Reuse**

> "One of the great advantages of long lived browser applications is you can reuse objects as the user navigates around. AngularJS doesn’t follow this philosophy; it encourages you to throw away what you already had and find it again (probably from the server!)"

I don't think Angular encourages you to throw anything away; in fact, creating services that are reusable is a core framework feature. Due to simple dependency injection, creating injectable services that, for example, cache results of fetches would be pretty trivial. If anything the general principle of abstracting remote and local data away into injectable services is a huge win for Angular, especially when you contrast it with the relative lack of stability in Ember.Data. ($resource isn't quite up to par, but you can get a long way already with $http and good things are coming in the impending 1.2 release that will help solidify it as a great utility when working with RESTful web services.)

**Encapsulation/Modularity**

Another area where Angular shines is `angular.module` and the idea of encapsulation and modularity built into the framework. It provides some very simple constructs you can use to structure your code to achieve encapsulation, and in 1.2 much of the core framework will all be extracted further into modules that you can pick and choose.

**Performance**

The performance card is often played in posts like these, but I have yet to run into a scenario using Angular where the dirty checking algorithm (and even the use of custom $scope.$watch) has lead to significant overhead.

Overall I think the reason Angular has more developer mind-share at the moment boils down to the things it places importance on abstracting; treating interacting with the DOM as a core framework feature, Angular acts like middleware to relieve developers having to do manual updating we've become so used to in the world of simple jQuery, and the manual "wiring" of those updates that we do when using Backbone.View and Backbone.Model. The separation of `declarative` markup and `imperative` application code that Angular implies is, in my opinion, the best way to separate concerns when building rich-client applications.

Re: Improving Backbone App Performance

David Mosher — Thu, 06 Jun 2013 08:52:40 -0000

Great to see some _practical_ advice and outcomes from your investigation into front-end performance, Pamela. Thanks for posting this :)

Re: explicit vs. implicit knowledge

David Mosher — Mon, 28 Jan 2013 09:50:42 -0000

In my experience the Rails documentation does a poor job of covering "proper" rubyisms, and does a of mediocre job explaining the conventions. It might just be the way I learn, but I've found the best way to ramp up on a project is to pair with somebody :)

Re: explicit vs. implicit knowledge

David Mosher — Tue, 22 Jan 2013 00:32:52 -0000

As I ramped up on a project earlier this year I made a mental note about how long it took me to ramp up on implicit knowledge like rails conventions, "proper" rubyisms, and the acronyms and nouns that were implicit to understanding the business logic of the project.

It was probably a good month before I felt like I had a good handle on all of that stuff. I don't know if that's above or below average; I suspect the former given my context shift to a language and environment I didn't have much experience in.

Your post is a good reminder that there are always things we can do when we write code to avoid encoding things implicitly which will yield benefits with new and longstanding team members. :)

Re: Dear Open Source Project Leader: Quit Being A Jerk

David Mosher — Fri, 14 Dec 2012 13:37:12 -0000

Good stuff Derick. The solution to this problem has a lot to do with letting go of ego and embracing empathy; Derek Sivers recently published a really great post that aligns with this as well: http://sivers.org/my-fault

Re: A Backbone.js Render Method Explained for Beginners

David Mosher — Wed, 21 Nov 2012 13:03:55 -0000

The only issue with the way your render is returning is that you explicitly return the jQuery/Zepto wrapped DOM element, this is problematic because you sometimes just want the non-wrapped view.el property. The idiomatic "backbone way" to achieve this is to have your render function return this as its final statement. ie:

render: function() {
  var output = this.template({ model: this.model });
  this.$el.html(output);
  return this;
}

Re: A Backbone.js Render Method Explained for Beginners

David Mosher — Wed, 21 Nov 2012 12:10:59 -0000

A good article that breaks down what happens for beginners step by step. I would just add one minor addition to your "Putting it all together" heading that explains a common convention for render functions: from the backbone docs (http://documentcloud.github...

"A good convention is to return this at the end of render to enable chained calls."

Re: Game On: Backbone and Ember

David Mosher — Fri, 31 Aug 2012 21:04:43 -0000

Testem [1] is a pretty kickass testing framework that supports headless (PhantomJS) and in browser testing. It is framework agnostic but has support for popular frameworks like Jasmine and Mocha. I was surprised to see that Testem even supports IE7, 8, and 9 (7/8 through compatibility mode).

[1]: https://github.com/airporty...