Hacker News Reader

Comment by combataircraft | Hacker News Reader

both RequireJS and Browserify are not good options. Browserify's implementation is awkward, incomplete and pollutes global scopa a lot.

Check out OneJS: http://github.com/azer/onejs

It's the only tool that lets you structure your client-side project as a CommonJS package and produces unobtrusive code mixable with anything in same global scope.

View on HN

There is another comment on this thread, by a separate user that reads:

"both RequireJS and Browserify are not even good options. Browserify's implementation is awkward, incomplete and pollutes global scope a lot. Check out OneJS"

I think there may be an agenda behind these comments.

I'm the owner of both comments and wrote it for two times because I can't see the other one and have very strong opinions about this topic.

(That other account has apparently been hell-banned, seemingly due to a downvotes during a political conversation about Kim Jong-il that you were involved in; you should probably stop using that account, as users can only see your posts if they turn on showdead. FWIW, thank you very much for this comment about OneJS, despite the flak you got for it due to the post from your hell-banned account.)

What's specifically wrong with RequireJS? I haven't heard much discussion of it, and you only addressed Browserify in your comment.

I've been following the work on RequireJS for two years and think that it's an evil project that sabotages the rise of CommonJS, NodeJS and NPM by leading client-side Javascript coders to follow a non-standard, awkward way of JS development. From the very beginning, it forces coders to cover their code with awkward code and maintain it manually. It's completely insane. I even think that I'm wasting my time by talking about it.

> it forces coders to cover their code with awkward code and maintain it manually

Friendly request for proof via examples. A gist would be fair.

here; http://requirejs.org/docs/

you can see all the smelling shit of requirejs there.

That's not really an answer. What _about_ their way of doing things do you consider to be wrong and why?

Can you expound please?

A unbaised post comparing the two would be nice. Sounds like a post Addy Osmani would write. I found this post(http://blog.millermedeiros.com/amd-is-better-for-the-web-tha...) talking about why the author thinks AMD is more flexible (better). Though a biased article(though I think the CJS approach to defining an AMD method is reasonable), it does show the syntax of the two approaches. I CJS syntax has less boilerplate, but is that due to fact that CJS loads synchronously? YES, I know processors like Onejs can make so CJS modules can be used in a browser(wonder is the processed result looks similiar to Requirejs?). Just wondering if Requirejs is designed the way it is because it took loading modules asynchronously into account from the begining.

Their (RequireJS's) website claims the following; I would be interested in an argued response/critique.

> CommonJS defines a module format. Unfortunately, it was defined without giving browsers equal footing to other JavaScript environments. Because of that, there are CommonJS spec proposals for Transport formats and an asynchronous require.

that's not true. They didn't even experiment CommonJS on browsers properly.

Reply on news.ycombinator.com