I'm writing a web app, using jsp to create the page content. I need a pretty good amount of javascript to make the app work. Does anyone have any recommendations on how to structure my project, such that it doesn't become a mess?
This is a broad question, but the basic problem is that I'm insert javascript code directly into my jsp content. Then I might have some external js files. Ids and such are strewn between multiple files. I'm not really sure what a best practice is for keeping this type of project organized. Do you always keep your javascript in separate files? There has to be a few hooks in the jsp pages though for them, right?
I tried using GWT because I'm really a c/java developer, and I was hoping it would help keep my project more organized (definitely helps) - but GWT is a pain to use with jsp, it really wants you to do all UI generation client side after the page is done loading, doesn't work for what I need to do.
Again, broad question, any tips would be great,
Thanks
JavaScript should be unobtrusive. That means that you use your JavaScript like CSS - target selectors on the page. The only 'hooks' you need are HTML classes and ids.
So keep all your JavaScript in separate files. It doesn't matter if you have it all in one file or in separate files, whatever works for you. This isn't quite true, there are technical reasons why you might choose one JavaScript file or lots of separate ones, but probably for now organise the files so they make sense. You can always use a tool to compile all your JavaScript into one file and minify it at the same time.
Put page-specific code (event handlers) inside the .jsp files, at the bottom, in an unobtrusive way (like Skilldrick) suggested.
Put general purpose methods (those reused in several .jsp files) in one (or more) javascript file(s) that you will link using . Try to find patterns in javascript code and create reusable library methods/components.
Use Enterprise Architect, Visio or some other software to architect your application (you might already be familiar with the MVC concept from the Java world). Make sure you put your JS functions into logical components. Each of these components will be a JavaScript file. Takes a little bit more time upfront, but you'll save a headache further down the line.
Related
I was just wondering about some good practices when it comes to external files specifically with javascript and CSS.
For javascript, should you make an external file for every module/added feature so that it's easy to locate and find the code in one spot for the module?
Also is it bad to have too MANY external files connected to one page, to the point where it affects load time and general bad practice?
Same question appllies for css..
Thanks
You always want to your files to be organized and well structured in a project like manner during development time. It's okay to have many css,js files during development, but that's very costy and expensive in production or real-life phase due to the fact that each file load adds an overhead to the exact file size making the file fetching slower and increasing your page load times. So, when you are ready to deploy your application, it's a good idea to merge and minify all your css files into 1 css file, the same goes with your javascript files too. Just remember that if you are doing CSS overrides, you will have to maintain the file order while merging not to mess up your css logic.
You can merge and minify using that tool http://www.shrinker.ch/ ;)
Person I use external files for every code so they are all separate. One for my CSS, and one for my JavaScript. I wouldn't say it's bad practice, It keeps things organized.
Is it bad to have too many?
I don't see the point on have multiple external JavaScript or CSS files when you can use a comment line to separate it if you are really OCD about it being organized. If for some reason you want to have multiple files you could create a folder specifically for the group of files.
Overall
I organize a lot with external files, helps me keep track of things. So I would say it's good practice, just trying to not go overboard with it, keep it like at 2-3 of CSS, JavaScript, Or jQuery each.
Edit*
I think it's primarily for organization, so, yes it is good practice to use external files.
Best case scenario is to have a master css file for the high level layout, and then different css files for the sub layouts that are only called when the module is loaded (not sure what framework your using, but I suppose your modules can have independent layouts). However you would want to use a minifier:
code.google.com/p/minify/
This compiles your css to a smaller format / single file, which helps keep the size down by merging all called css files into 1 master css file.
At the same time you want to get an adequate balance between load time and maintainability, if lumping some layouts together makes the code easier to maintain and the load time trade off is minimal then there's no real harm in this.
I guess what I'm asking is that if grouping JavaScript is considered good practice, why don't more websites place the JavaScript and CSS directly into one HTML document?
why don't more websites place the JavaScript and CSS directly into one HTML document
Individual file caching.
External files have the advantage of being cached. Since scripts and styles rarely change (static) and/or are shared between pages, it's better to just separate them from the page making the page lighter.
Instead of downloading 500kb of page data with embedded JS and CSS, why not load 5kb of the page, and load from the cache the 495kb worth of JS and CSS - saves you 495kb of bandwidth and avoids an additional 2 HTTP requests.
Although you could embed JS and CSS into the page, the page will most likely be dynamic. This will make the page load a new copy all the time, making each request very heavy.
Modular code
Imagine a WordPress site. They are built using a tom of widgets made by different developers around the world. Handling that many code stuffed in one page is possible, but unimaginable.
if some code just short circuited or just didn't work on your site, it's easier to take out that code linking the external file, rather than scouring the page for the related code and possibly accidentally remove code from another widget.
Separation of concerns
It's also best practice to separate HTML from CSS and JS. That way, it's not spaghetti you are dealing with.
When you have a lot of code in a single document, it's harder to work with the code because you need more time to find the necessary string to change.
That is why it's good practice to divide code into separate files, with each of them solving its own special task, and then include them in code where it's necessary.
However, you can a write script which will join your files from the development version, which has many files, to a release version, which has fewer files, but this brings two problems:
People are often lazy to do additional coding to create this script and then change it when the structure of your project becomes more complex.
If you find a bug or add a small feature, you will need to rebuild your project again both in developed and release versions.
They separated them so that multiple webpages can use the same file. When you change a single file, multiple pages can aromatically updated also. In addition, big HTML file will cause a long time to download.
In my project each page has a bunch of dependent Javascript and Css. Whilst developing I just dumped this code right into the page but now I'm looking to clean it up...
it appears that the general approach out there is to package all the Javascript/CSS for an application into two big files that get minimised.
This approach has the benefit that it reduces bandwidth since all the front-end code gets pulled in just once from the server... however, I'm concerned I will be increasing the memory footprint of the application by defining a whole ton of functions for each page that I don't actually need - which is why I had them on a per-page basis to begin with.
is that something anyone else cares about or is there some way to manage this issue?
yes, I have thought of doing conditional function creation since I need to run code conditionally for each page anyway - though that starts to get a bit hackish in my view.
also, is there much cost to defining a whole ton of Css that is never used?
Serving the javascript/CSS in one big hit for the application, allows the browser to cache all it needs for all your pages. If the standard use case for your site is that users will stay and navigate around for a while then this is a good option to use.
If, however, you wish your landing page to load quickly, since there is a chance that the user will navigate away, consider only serving the CSS/javascript required for this page.
In terms of a performance overhead of a large CSS file - there will be none that is noticeable. All modern browsers are highly optimised for applying styles.
As for your javascript - try not to use conditional function creation, conditional namespace creation is acceptable and required, but your functions should be declared only in one place.
The biggest thing you can do for bandwidth is make sure your server is compressing output. Any static document type should be compressed (html, js, css, etc.).
For instance the jQuery Core goes from approx. 90KB to 30KB only because of the compressed output the server is sending to browsers.
If you take into account the compression, then you have to create some mammoth custom JS includes to really need to split-up your JS files.
I really like minifying and obfuscating my code because I can put my documentation right into the un-minified version and then the minification process removes all the comments for the production environment.
One approach would be to have all the shared javascript minified and compressed into one file and served out on each page. Then the page-specific javascript can be compressed/minified to its own files (although I would consider putting any very common page's javascript into the main javascript file).
I've always been in the habit of compressing/minifying all of the CSS into one file, rather than separate files for each page. This is because some of the page-specific files can be very small, and ideally we share as much css across the site as possible.
Like Jasper mentioned the most important thing would be to make sure that your sever is GZIPing the static resources (such as javascript and css).
If you have a lot of javascript code you can take a look on asynchronous loading of js files.
Some large project like ExtJs or Qooxdoo have build in loaders to load only required code, but here is a lot of libs which simplify this, and you can use in your project (e.g. head.js, LAB.js).
Thanks to them you can build application which loads only necessary files, not whole javascript code which in case of big apps can be a heavy stuff for browser.
I'm very new to the JavaScript library world. I have used JS by itself before to create a mini social network but this is the first time I use a JS library and I really don't know how to go about this.
I'm planning to use Google Closure and I'm really not sure how I should go about organizing the code. Should I put everything in one file since it's a web app and should have one screen? Should I separate the code to many chunks and put them in different files? Or should I put different dialogs (like settings) in a separate page and thus a separate file?
Like all programmers I'm a perfectionist so please help me out with this one, thanks.
If you're using Closure, you can use the closure compiler. I'd recommend multiple js files that are compiled into a single resource by the compiler. You'd reference that single js file in your html, so you wouldn't have to link to all of them.
Then, since you have multiple JS file, you can organize them in a logical way that will help you separate logic from UI from communications, etc. Also, if you're writing unit tests (JsUnit) it will be easier to write one test file per js file.
Depends...
What I do is add all my code in one file(librarys are always in different files) and then even though some of it wont be used, there will be no need to add multiple scripts to the page. If you have 20 files with script, it can be very confusing knowing which one to use.
These days I find myself shifting out more and more work to the client side and hence my JS files tend to get bigger and bigger. I have come to the point where most HTML pages have half a dozen or more JS imports in the header and I realised that this is hurting loading times.
I have recently discovered this script which lets you download several JS files with one HTTP request. It is written in PHP and being a Django fan I'm planning to rewrite it in Python. I'm planning to use a HTTP redirect to the pre-minified and concatenated file and was wondering what the cost of a 301 would be. Please let me know if that is a stupid idea.
On the other hand, am little worried about introducing scripting logic into the serving of static files and I was wondering if there is a viable build alternative like, say, an ant task that concatenates and minifies JS files and replaces multiple JS downloads in a HTML header with one big one, like the script does.
For PHP I certainly favour doing it dynamically just because if you introduce a build step you're losing one of the main benefits of using PHP. In fact, at the risk of self-promotion I've written Supercharging Javascript in PHP about this very issue.
Of course other technologies may vary.
Again it is PHP but it's not just a lump of code for you to use (although you can jump straight to Part 6 if you just want some fully working code) and may have value to you in terms of identifying the issues and doing things the right way and why you do them that way.
I favour having bundles of Javascript files (maybe only one for the entire application) and then each page simply activates the behaviour it needs through standard means but all the code bodies are in the larger cached and minified JS file. It works out fastest this way and is a good way to go.
If you do want it as part of a build process, which is a reasonable solution if you have a build process anyway, then I suggest you minify your code. There are lots of tools to do this. Have a look at YUI Compressor.
If you do a static combine of JS files, the other stuff mentioned above such as gzipping and associated issues is still relevant.
YUI compressor is a good choice. If you want to learn how to set up an Ant-based build process, have a look at this Tutorial: http://www.javascriptr.com/2009/07/21/setting-up-a-javascript-build-process/
As a Ruby-based alternative, I would recommend Sprockets