4 ms·

I wouldn't choose to use requirejs on a project where I was making choices about the architecture for reasons mentioned here [1], but the current project I'm on

by davemo 13y ago

I wouldn't choose to use requirejs on a project where I was making choices about the architecture for reasons mentioned here [1], but the current project I'm on was setup similarly and loads over 350 .js and .tpl files via AJAX in development mode pushing the DOMReady to a staggering 7.5s. (This is inside of Rails 3.2 using the requirejs gem). Every time I've encountered requirejs in an application this has been representative of my experience with the tool and the pain of having to wait that long every time I reload a page simply doesn't seem worth it to me. There's also somewhat of a mismatch between async loading assets in development and sync loading them in production which I've seen responsible for bugs that show up in one environment but not the other, and/or vice versa. A couple of questions for you: do you think the r.js optimizer taking 2.5s to compile is related to the complexity of the dependency tree in your application or just the number of files being loaded? Also, considering the previously mentioned mismatch between dev/prod and async loading, do you think it is appropriate to use something like SPDY to obviate the pain of a lengthy DOMReady event in development? [1] - http://searls.testdouble.com/posts/2013-06-16-unrequired-love.html http://searls.testdouble.com/posts/2013-06-16-unrequired-lov...

ssafejava 13y ago
Yes, I've run into issues with things running differently in an async environment (dev) and a sync environment (prod). To mitigate the issue I now throw events at key points in initialization and wait for those events to continue. Has solved my problem so far. Using r.js in development isn't the worst idea. It's worth seeing how long it takes in order to make that decision. Compiling tpls is much faster (grunt-contrib-jst) and adding that to your grunt watch & including it directly is a good way to save time. I think it takes a long time on my end due to the complexity of the dependencies. I only include exactly what each module needs so some dependencies may be as many as 6 levels deep, or more (haven't really checked). SPDY makes a big difference for me (big enough to ignore the problem for now) and I don't mind using a self-signed cert in dev. EDIT: I hadn't been compiling tpls using JST in dev until I wrote this post - a great side effect is, it actually shows me now where the errors in my tpls are! Previously any tpl's stack terminated at the code that ajaxed in the tpl. This is far better for debugging and brought my DOMReady time down to about 1.75s.

by davemo 13y ago

ssafejava 13y ago

Yes, I've run into issues with things running differently in an async environment (dev) and a sync environment (prod). To mitigate the issue I now throw events at key points in initialization and wait for those events to continue. Has solved my problem so far. Using r.js in development isn't the worst idea. It's worth seeing how long it takes in order to make that decision. Compiling tpls is much faster (grunt-contrib-jst) and adding that to your grunt watch & including it directly is a good way to save time. I think it takes a long time on my end due to the complexity of the dependencies. I only include exactly what each module needs so some dependencies may be as many as 6 levels deep, or more (haven't really checked). SPDY makes a big difference for me (big enough to ignore the problem for now) and I don't mind using a self-signed cert in dev. EDIT: I hadn't been compiling tpls using JST in dev until I wrote this post - a great side effect is, it actually shows me now where the errors in my tpls are! Previously any tpl's stack terminated at the code that ajaxed in the tpl. This is far better for debugging and brought my DOMReady time down to about 1.75s.