Converting an existing Backbone.js project to Require.js • Hacker News Board

Re: Converting an existing Backbone.js project to Require.js

#31

Post by nilliams » Mon, Aug 26, 2013, 1:10 AM UTC

ktt wrote: post #9

CoffeeDregs wrote: post #5

I'm really puzzled by the enthusiasm around RequireJS. I've read up on it, I've built several large JS applications (~100 models, views, whatevers in ExtJS and Knockout), have been involved with a large BackboneJS/RequireJS application and am currently rebuilding a large site in AngularJS. AFAICT, RequireJS did not solve any problems that I had more easily solved with proper namespacing (yes, the feared global , e.g.…

Use this syntax, IMHO it's a LOT more readable: define(function(require) { var $ = require('jquery'), Handlebars = require('handlebars'), Backbone = require('backbone'), MyModel = require('mymodel'), MyControllerAnimals = require('mycontrolleranimals'); Also require.js comes with an optimizer that automatically concatenates all required files (and no more!) minifies them and you don't have to worry about script order…

Agree, I've used this syntax on my last 2 projects. It is so much better, and closer to Node/CommonJS, I don't know why anyone uses the alternative.

Re: Converting an existing Backbone.js project to Require.js

#32

Post by codeonfire » Wed, Aug 28, 2013, 5:25 AM UTC

jafaku wrote: post #25

possibilistic wrote: post #22

Perhaps someone can clue me in, because I'm still at a loss for why there's so much hype built around Require.js. I develop JS primarily for the frontend, and I use Grunt, a global namespace, and concat (or similar tooling) to piece things together. Doesn't r.js execute dependency resolution code at run time? Can all references to r.js be fully compiled out? Even a wrapper like Almond seems to leave behind this kind…

I was thinking the same thing. Why would anyone want this?

Because it's more costly to maintain 10000 line javascript files, you can start to reuse code at something smaller than the package level, you can have better cohesion and less coupling.

The god-file approach to development leads to things like lots of search and replace when something needs renamed, name collision, and duplicated utility code everywhere.

Re: Converting an existing Backbone.js project to Require.js

#33

Post by jafaku » Thu, Aug 29, 2013, 8:02 AM UTC

codeonfire wrote: post #32

jafaku wrote: post #25

Earlier quoted context omitted.

I was thinking the same thing. Why would anyone want this?

Because it's more costly to maintain 10000 line javascript files, you can start to reuse code at something smaller than the package level, you can have better cohesion and less coupling. The god-file approach to development leads to things like lots of search and replace when something needs renamed, name collision, and duplicated utility code everywhere.

Wtf, who said anything about a 10k LoC js file?

"possibilistic" said dependency resolution must be done at compile time:

> I don't want any dependency resolution code in the production build, because that's a problem that needs to be solved at compile time.

Re: Converting an existing Backbone.js project to Require.js

#34

Post by codeonfire » Sun, Sep 01, 2013, 2:41 PM UTC

jafaku wrote: post #33

codeonfire wrote: post #32

Earlier quoted context omitted.

Because it's more costly to maintain 10000 line javascript files, you can start to reuse code at something smaller than the package level, you can have better cohesion and less coupling. The god-file approach to development leads to things like lots of search and replace when something needs renamed, name collision, and duplicated utility code everywhere.

Wtf, who said anything about a 10k LoC js file? "possibilistic" said dependency resolution must be done at compile time: > I don't want any dependency resolution code in the production build, because that's a problem that needs to be solved at compile time.

The tool that is mentioned, grunt, appears to resolve dependencies at the package level, not at the module/file level. Dependencies at the package level with no module level resolution tend to cause very large source files because no one is going to make a new package for each unit of code.