Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am thinking through how I will use JavaScript for a project which is just in its beginning of coding. I am not an expert in JavaScript, but I recognize it as a very important part of the site so I have a few questions:

  1. I often see projects have 1 huge javascript file which handles everything. Is that for the purpose of making things faster?
  2. Is it ok to have javascript functions coded inside html pages? Or is it considered bad design?
  3. Are most people still using jQuery? I have been seeing a proliferation of other .js frameworks. I know Yahoo made one and there are many others. Is jQuery still the defacto standard for most js frameworks needs? (sorry this question is subjective).
  4. How should I approach/test various browser compatibilities? Should I be very concerned about that?
share|improve this question

3 Answers 3

  1. As Mike said, HTTP requests are expensive, and an easy way to minimize them is to minimize the number of files. Usually, there's one "custom" file, and one link to a library, such as jQuery. Ideally, the library is linked from a CDN, such as Google's Javascript library repository, which allows browsers to cache the library once and use it on multiple sites.
    Also, like Wyatt said, that "one huge file" is often multiple files at development, which are then combined and minified for production.

  2. It's considered bad design to mix code and markup (as well as markup and styling), regardless of the languages. Separation of these aspects makes maintenance significantly easier for a whole host of reasons. For more information, check out the MVC pattern and why it's so popular.

  3. jQuery is arguably one of the most popular frameworks out there, however, YUI is also quite popular, as is MooTools. There'd be a ton to compare, so I can't go into that here, but Wikipedia has a table of features for them and several other frameworks. I'd personally go with jQuery or MooTools, if for no other reason than they're in active development and updated recently, which suggests they're keeping up with the latest standards and compatibility issues.

  4. Compatibility is something you should definitely be concerned about, especially when doing custom JS stuff. Using a framework like jQuery or MooTools does make this a lot more trivial, though, since they take care of a lot of the base compatibility issues that might arise. You still need to test in your target browsers, though, to make sure there's no unexpected behavior. The simplest way to test the browsers is to open your project in whatever ones you can get a hold of. All the major browsers have developer tools available to them that can help you in all stages of debugging.

share|improve this answer

In general, there isn't one single way in doing javascript. That is kind a the beauty of it really.

1) Yes and no. In many cases, that "one huge javascript" is actually a bunch of files at development time that get combined for effencies in delivery.

2) Sure, they work right? Really this decision depends on some serving/delivery concerns. You've gotta get the bytes there somehow, but what hurts the least.

3) Lots. Probably more now that it is pretty much baked into ASP.NET MVC. And actually, I think we are starting to see a backlash against these "browser helper" sort of frameworks as browser support is improving directly and people grok JS itself more.

4) Testing is the big nightmare with javascript IMHO. There are a few unit-testing frameworks but those tend to fall flat to some extent as the real issue isn't the unit-testable bits but rather the strange interactions between browser, user and network that are difficult to pin down without sitting and looking over someone's shoulder as they use your site in a 1992-era 486dx running a homebrew browser their 2nd cousin wrote. Anyhow, perhaps the best tool in your arsenal is selenium as that at least lets one run automated tests with a full javascript stack and a full browser.

share|improve this answer
  1. HTTP has a lot of overhead. Loading one big file is almost always more efficient than loading several small files. But with JavaScript, the downside is that it makes it harder to keep your code organized and debug it. On a project that I'm working on right now, I set it up so that the page can be loaded in either production or debugging mode: in debugging mode, all the .js files are loaded individually, just the way that I wrote them. In production mode, they're all run through YUI Compressor, then concatenated into one big file.

  2. Generally speaking, it is bad design. You should try to keep everything modular, otherwise you end up with one giant tangle that nobody understands. Another thing: if you embed JavaScript or CSS into a dynamically-generated web page, then the browser won't be able to cache them.

  3. JQuery is still pretty popular, and under active development. But I won't try to compare it with the other competing libraries, because I don't know enough about them.

  4. Be concerned. Be very concerned.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.