Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Javascript best practices?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Ask HN: Javascript best practices?

#11

Post by diN0bot »

thingsilearned wrote: post #3

Many frameworks have some tools for dealing with multiple javascript files. I use django-compress for example and love it. It allows you to have many different javascript files to separate your code logically, and it automatically compresses them into one file for you for deployment. In this way you don't have to compromise speed for clarity. If you're interested in advanced JS I highly recommend this book. http://js…

i just had a look (thanks for the link). i downloaded some code--good stuff, no doubt better with the full explanations.

for various reasons i'm not buying the book. i do strongly recommend reading resig's blog posts. some excellent gems there. i've incorporated some great util functions from these posts, for example.

nothing is as good as working with coders who are better than you, tho ;-)

Re: Ask HN: Javascript best practices?

#12

Post by physcab »

alexitosrv wrote: post #10
mindviews wrote: post #2

I like to use separate files for organization during development and then merge and minify for deployment. Just make sure you have an automated process because you don't want to make mistakes doing it by hand.

Any tool suggestions for the job of minifying and deployment?

Gzip?

Re: Ask HN: Javascript best practices?

#13

Post by Dylanfm »

wenbert wrote: post #4
thingsilearned wrote: post #3

Many frameworks have some tools for dealing with multiple javascript files. I use django-compress for example and love it. It allows you to have many different javascript files to separate your code logically, and it automatically compresses them into one file for you for deployment. In this way you don't have to compromise speed for clarity. If you're interested in advanced JS I highly recommend this book. http://js…

I have been eyeing books for months now. Pro Javascript Techniques has been one of them. Living in a country where shipping costs as much as a book is hard.

Checkout Better World Books http://www.betterworldbooks.com . Cheap worldwide shipping. Another option is to buy second hand.

Re: Ask HN: Javascript best practices?

#14

Post by gz »

alexitosrv wrote: post #10
mindviews wrote: post #2

I like to use separate files for organization during development and then merge and minify for deployment. Just make sure you have an automated process because you don't want to make mistakes doing it by hand.

Any tool suggestions for the job of minifying and deployment?

http://developer.yahoo.com/yui/compressor/

Re: Ask HN: Javascript best practices?

#15

Post by tyrmored »

tptacek wrote: post #7
thingsilearned wrote: post #3

Many frameworks have some tools for dealing with multiple javascript files. I use django-compress for example and love it. It allows you to have many different javascript files to separate your code logically, and it automatically compresses them into one file for you for deployment. In this way you don't have to compromise speed for clarity. If you're interested in advanced JS I highly recommend this book. http://js…

Thanks, I totally forgot about the Resig book since it was announced. Just bought. I really liked _Javascript: The Good Parts_: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... Particularly because it's purely about style and code organization, and not about the best way to get consistent DOM access between Gecko, WebKit, and IE.

That book is outstanding. Crockford's JSLint validator is also superb. Highly recommended for any script of more than a few lines in length.

Re: Ask HN: Javascript best practices?

#16

Post by n8agrin »

Always use "var" to define a variable, unless you know exactly what you are doing. e.g.:

  var foo = 'bar';
When you don't use "var" the Javascript interpreter breaks out of the current scope and continues to do so all the way until it hits the final global scope (generally the window object in browsers). If it does not find the variable, it then defines it. If it does find it, it will trample the found variable with the new value. For example:

  var foo = 'bar';

  function baz() {
    foo = 'baz';
  }

  baz();

  // now foo == 'baz';
  console.log(foo);
  >>'baz'
Google "Javascript var keyword" for more info.

EDIT: I'll add that this functionality, which is part of a general language feature known as a "closure", is incredibly powerful when used successfully, but that's out of the scope of my comment.

Re: Ask HN: Javascript best practices?

#17

Post by whalesalad »

Can anyone elaborate on when one giant JS file (benefit here is of course reducing HTTP requests) becomes too large? Right now I am splitting up JS files in a fairly simple manner: a single site-wide file with common methods and utilities, and then a handful of smaller files for various aspects of the site. I think that they are each small enough to all be combined into one single one... but when is that single file too large?

Re: Ask HN: Javascript best practices?

#18

Post by tyrmored »

alexitosrv wrote: post #10
mindviews wrote: post #2

I like to use separate files for organization during development and then merge and minify for deployment. Just make sure you have an automated process because you don't want to make mistakes doing it by hand.

Any tool suggestions for the job of minifying and deployment?

JSMin is also good.

Re: Ask HN: Javascript best practices?

#19

Post by dasil003 »

whalesalad wrote: post #17

Can anyone elaborate on when one giant JS file (benefit here is of course reducing HTTP requests) becomes too large? Right now I am splitting up JS files in a fairly simple manner: a single site-wide file with common methods and utilities, and then a handful of smaller files for various aspects of the site. I think that they are each small enough to all be combined into one single one... but when is that single file…

Most of the time never. Additional files means additional connection overhead. Browsers typically won't open more than 2 simultaneous connections to the same host, so too many assets can quickly lead to noticeable delays.

The one exception I can think of is if you have a lot of JS code, but some of it needs to load faster. In that case you may want to split the code into several files based on load priority. If you go that route you may want to also use multiple asset subdomains or ideally a CDN to minimize latency.

Re: Ask HN: Javascript best practices?

#20

Post by kls »

I tend to create a page controller js file that my html file loads. I do not embed any JavaScript in the page rather, I grab any dom elements that I need via JavaScript so that way there is a clean separation between code and HTML. I tend to prefer Dojo as far as frameworks, so i will use dojo.byId or dijit.byId to grab references to my nodes in my page init function.

I intentionally make my controller file procedural and then I have a custom life-cycle event controller that fires off events for page init, reload, load data, page unload, etc.. so my developers can just fill in the blanks. Any data access is done by calling methods on a service facade which again is purposefully procedural. The service facade then calls any server side services we need (we don't do form posts any more, JSON is far more robust for submitting data). Finally, we use Dijit for any of our widget and any of our model / utility / OO needs.

I know it's no purely JavaScript best practices, and it is more related to project file layout and architecture, but I find it gives me the best architecture for my team size (100+). It helps me on-board people quickly and graduate their skill set while maintaining clean code and allowing advanced features.

I can start a junior on pure html layout, then we can train them to do controller modification, then to work on service facades and then when they have a good foundation in prototype base OO we can graduate them into building reusable widgets and subsystems for the controller and service facade developers. It works well and allows developers to work proficiently at their skill set without mucking up the whole system.

As well the service facades make it easy to contract out entire web projects while my internal team builds server side services to support the effort. This allows us to expand our work force, to a larger pool, without having to vet new developers to deep into business rules to get them up and running.

Post reply on HN