My attempt to understand the dark side… err… AMD/RequireJS

Yes, it’s true. I’m finally building a full app with RequireJS, on my own. I’ve worked with it plenty in the past, but always on other people’s projects. I don’t have very many nice things to say about RequireJS, because of my experience with it and with solving the same problems in other manners. But, I need to get this under my belt, as a large-ish project that is built from the ground up with RequireJS. 

My intent to is to better understand RequireJS, it’s use cases and patterns, and form a more insightful and educated opinion. I am doing my best to open my mind about it and even allow my opinion to be changed. A lot of the problems I had with RequireJS back in my consulting days have been addressed. Shims, for example, make it easier to get non-AMD code in to RequireJS (though this isn’t without problems, still). There are still things I don’t like, though. We’ll see.

So far, the experience has been painful, frustrating, and left me with a continued sense of “WHY?!?!??!!!!!”. I realize that some of this is just me and my opinions, though, and I’m doing my best to learn through it, and see how RequireJS wants things to work instead of how I want things to work. 

I already have a few blog posts lined up for things I’m running in to and doing… none of which are meant to be a “do it this way” kind of post. In my typical style, I’ll be posting what I’m learning, as I’m learning it. That means a lot of what I say will be stupid, wrong and a bad idea. But that’s the point. Getting this stuff out there will bring feedback and help me learn faster.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in requirejs. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • To be fair – the problem you linked to about shimming isn’t really requireJS’s fault, as it’s more everlive/reqwest’s fault. :-)

    • right – i should have been more clear about that. it’s not requirejs fault. it’s that this isn’t a solved problem, even with AMD and requirejs’ shim capabilities. people still have to build code smart when it handles both AMD and non-AMD setups.

  • For 4.5 years I was insulated by developing almost exclusively with ExtJS, with which I’ve had an infamous (in ExtJS circles) love/hate relationship. So I too have struggled with facets of what to me is a new toolchain, particularly Backbone (much weaker than ExtJS when it comes to inherent support for forms) and Require. As to the latter I’ve blogged at codrspace dot com slash dexygen “Does require.js introduce more problems than it solves?” and of course have been lambasted by the religionists. My latest gripe is that developing on Windows the module names are treated case-insensitively such that modules can fail to load in our production-like case-sensitive Linux environments. This is probably more of an issue with the implementation of script/onload in that it does not appear to provide access to the name/path of the loaded resource in the arguments to the callback you implement (which could/should allow a comparison between the name of the module provided, and that actual resource loaded)