6 ms·

As much as I'd love to explore require.js more, the documentation web site just doesn't seem to be compatible with my mind. I don't have a lot of time to test

As much as I'd love to explore require.js more, the documentation web site just doesn't seem to be compatible with my mind. I don't have a lot of time to test it out and there's something about the docs that just isn't making me feel like I'd know how to use it.

SanderMak 13y ago
I found this gist while modularizing our medium sized Angular application. It was a day's work to get the requireJS basics going for our app. That was a pleasant surprise. The additional r.js optimization step cost a bit more time, and that was indeed partly due to documentation issues.
- arianvanp 13y ago
  Care to elaborate? As far as i know. Angular has modularization built into its API and recommended paradigms? Why use require.js if angular already supports creating and importing modules?
  - SanderMak 13y ago
    Sure. True, Angular has modules and dependency injection which we use (both before and after RequireJS). However Angular modules are more namespace than true modules. When you split your Angular app over multiple files you'll still have to manage these dependencies by yourself. The real trigger for introducing RequireJS was our need to optimize our JS by concatenating and minifying it. And to do that in the right order, you need to know your dependencies very well. That's when I decided I didn't want to do that by hand. Not now, and not in the future. So I took https://github.com/tnajdek/angular-requirejs-seed https://github.com/tnajdek/angular-requirejs-seed as an example and started defining modules and dependencies. Now I can easily run the r.js optimizer as a build step before releasing and now I'll get a correct and concatenated/minified JS for production. The nice thing is that RequireJS not only manages our Angular modules (defined in separate files), but also their dependencies on vendor scripts (JQuery, Hammer.js etc.) I really have the feeling I'm in control again.
jaxytee 13y ago
I don't mean to troll, but isn't exploration and figuring things out a huge part of creating software. There are require.js examples apps on github , Q and As on Stackoverflow, and open source code that's available for digging deep. It only took me ~2 Days to get the gist of require. Is it no longer good enough that the open source community builds great free things for us to use? Do they now have to upload the know how of these tools to the users brains in a Matrix like fashion?
- eksith 13y ago
  Getting things done in a timely manner and under budget is an even bigger part of it. Having to learn "new" things (this is distinct from "different" things and "better" things) leaves significantly less time to achieve productivity. In terms of developer time, 2 days is rather expensive. If this is your own pet project, then by all means spend the time necessary to learn it. Or if you intend to "Move Fast and Break Things", then spending time to learn things is also good. But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary.
  - jasonlotito 13y ago
    > But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary. You are using words like efficiently and phrases like "isn't broken" without quantification. Having only done things one way, and it doing it's job does not mean it's efficient or not broken. Only that you don't know a more efficient way or it hasn't been proven to break yet. While getting things out the door is important, it's also just as important to not base assumptions without actually quantifying. And you can't do that if you assume the mantra of "if it ain't broke, don't fix it." It's a balance that, as a professional, you have to manage.
    - eksith 13y ago
      On the contrary, efficiency is quantifiable. As is determining whether or not something is broken or prone to breaking. I.E. Brittleness becomes obvious under heavy load. This isn't a "if it ain't broke, don't fix it" either. You push things to the breaking point and see if that's projected in your growth (maybe a bit beyond what's projected), but maintainability and efficiency don't hinge on what's new. It hinges on what works and if what works is what you have, you don't waste time with new things. But back to the point... You learn "new" things when you figure existing things aren't up to the task or you try to see if amending x will get you further. y Is still not necessary if it will.
willurd 13y ago
I think I can explain how to get started with require.js pretty quickly. I've attempted to do so with a short gist: https://gist.github.com/willurd/6054834 https://gist.github.com/willurd/6054834 (much shorter than the OP and a higher code/text ratio).
- martin-adams 13y ago
  Thanks, that actually helps. Also having a demo helped me clarify that I can still use the Chrome debugger on require.js sources. I used Dojo a couple of years ago and lost a lot of debugging capabilities due to the way it evals the loaded scripts.
  - willurd 13y ago
    No problem at all :) Glad I could help you out.
badman_ting 13y ago
I used requireJS for a project about a year and a half ago, and I agree that the documentation is not good. The error messages are also not good. When I couldn't figure out the right way to configure something, I had to use trial and error. Basically, everything about using it kinda sucked, but we wanted the dependency resolution for our scripts. I haven't looked into alternatives (mainly Browserify) and don't know if I will use JS modules in my future development. The idea seems neat, but it really adds a lot of pain in my opinion. Perhaps there is a threshold of webapp complexity, past which the pain is worth it.
- AdrianRossouw 13y ago
  this is my main problem with it. it's an astounding amount of complexity to introduce into a project, just to be able to get the bare minimum of functionality. if something breaks, and something always breaks, I simply don't want to be responsible for debugging it.

SanderMak 13y ago

I found this gist while modularizing our medium sized Angular application. It was a day's work to get the requireJS basics going for our app. That was a pleasant surprise. The additional r.js optimization step cost a bit more time, and that was indeed partly due to documentation issues.

arianvanp 13y ago
Care to elaborate? As far as i know. Angular has modularization built into its API and recommended paradigms? Why use require.js if angular already supports creating and importing modules?
- SanderMak 13y ago
  Sure. True, Angular has modules and dependency injection which we use (both before and after RequireJS). However Angular modules are more namespace than true modules. When you split your Angular app over multiple files you'll still have to manage these dependencies by yourself. The real trigger for introducing RequireJS was our need to optimize our JS by concatenating and minifying it. And to do that in the right order, you need to know your dependencies very well. That's when I decided I didn't want to do that by hand. Not now, and not in the future. So I took https://github.com/tnajdek/angular-requirejs-seed https://github.com/tnajdek/angular-requirejs-seed as an example and started defining modules and dependencies. Now I can easily run the r.js optimizer as a build step before releasing and now I'll get a correct and concatenated/minified JS for production. The nice thing is that RequireJS not only manages our Angular modules (defined in separate files), but also their dependencies on vendor scripts (JQuery, Hammer.js etc.) I really have the feeling I'm in control again.

jaxytee 13y ago

I don't mean to troll, but isn't exploration and figuring things out a huge part of creating software. There are require.js examples apps on github , Q and As on Stackoverflow, and open source code that's available for digging deep. It only took me ~2 Days to get the gist of require. Is it no longer good enough that the open source community builds great free things for us to use? Do they now have to upload the know how of these tools to the users brains in a Matrix like fashion?

eksith 13y ago
Getting things done in a timely manner and under budget is an even bigger part of it. Having to learn "new" things (this is distinct from "different" things and "better" things) leaves significantly less time to achieve productivity. In terms of developer time, 2 days is rather expensive. If this is your own pet project, then by all means spend the time necessary to learn it. Or if you intend to "Move Fast and Break Things", then spending time to learn things is also good. But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary.
- jasonlotito 13y ago
  > But if you're running a business with "x" which has worked efficiently for years and isn't broken, "y" is not necessary. You are using words like efficiently and phrases like "isn't broken" without quantification. Having only done things one way, and it doing it's job does not mean it's efficient or not broken. Only that you don't know a more efficient way or it hasn't been proven to break yet. While getting things out the door is important, it's also just as important to not base assumptions without actually quantifying. And you can't do that if you assume the mantra of "if it ain't broke, don't fix it." It's a balance that, as a professional, you have to manage.
  - eksith 13y ago
    On the contrary, efficiency is quantifiable. As is determining whether or not something is broken or prone to breaking. I.E. Brittleness becomes obvious under heavy load. This isn't a "if it ain't broke, don't fix it" either. You push things to the breaking point and see if that's projected in your growth (maybe a bit beyond what's projected), but maintainability and efficiency don't hinge on what's new. It hinges on what works and if what works is what you have, you don't waste time with new things. But back to the point... You learn "new" things when you figure existing things aren't up to the task or you try to see if amending x will get you further. y Is still not necessary if it will.

willurd 13y ago

I think I can explain how to get started with require.js pretty quickly. I've attempted to do so with a short gist: https://gist.github.com/willurd/6054834 https://gist.github.com/willurd/6054834 (much shorter than the OP and a higher code/text ratio).

martin-adams 13y ago
Thanks, that actually helps. Also having a demo helped me clarify that I can still use the Chrome debugger on require.js sources. I used Dojo a couple of years ago and lost a lot of debugging capabilities due to the way it evals the loaded scripts.
- willurd 13y ago
  No problem at all :) Glad I could help you out.

badman_ting 13y ago

I used requireJS for a project about a year and a half ago, and I agree that the documentation is not good. The error messages are also not good. When I couldn't figure out the right way to configure something, I had to use trial and error. Basically, everything about using it kinda sucked, but we wanted the dependency resolution for our scripts. I haven't looked into alternatives (mainly Browserify) and don't know if I will use JS modules in my future development. The idea seems neat, but it really adds a lot of pain in my opinion. Perhaps there is a threshold of webapp complexity, past which the pain is worth it.

AdrianRossouw 13y ago
this is my main problem with it. it's an astounding amount of complexity to introduce into a project, just to be able to get the bare minimum of functionality. if something breaks, and something always breaks, I simply don't want to be responsible for debugging it.