[nahname]

I have to build my entire project every time I want to update my client side code? That is an enormous tax to charge the developer just to add static typing to your client side code. I can't see this doing anything but slowing a team down.

[Me1000]

Anyone building large projects do this anyway, using minifiers to reduce the download size. Sometimes the code has inline documentation which gets built too.

A build step is already a reality for many people writing JS today.

[asher_]

This isn't really a fair comparison. You can use unminified, commented javascript in development for testing without a build step, and just build for production.

Even so, a build step can be a single keypress, so its no big deal.

[MatthewPhillips]

I don't know about you, but to me once a code file is larger than say a couple hundred lines it becomes exponentially less readable. So any non-trivial amount of JavaScript already includes a concatenation build step anyways, even for development. As long as the TypeScript compiler is reasonably fast on larger (10k LOC) projects, it wouldn't be any issue at all.

[oinksoft]

This is a moot point. The Closure Compiler supports dependency resolution so that you can unit test your code without building the full project. So, if I am testing foo.bar.Baz, I can create a file that only includes `base.js' and a goog.require('foo.bar.Baz'); call, and `base.js' will include all of its dependencies, in most cases fairly quickly.

Unless you are performing integration tests, there is no reason to compile each time. Doing that is just the legacy of limited build systems.

[MatthewPhillips]

Does goog.require() resolve at run time or compile time?

[oinksoft]

You're realistically only going to deploy a compiled script. The compiler supports goog.require/provide() without requiring any JS inputs, and core tools like closurebuilder.py (which has superseded calcdeps.py) build your dependency graph for you. The compiler uses the require/provide statements to ensure that all necessary symbols are indeed provided, and are only included once in the script.

For debugging purposes, `base.js' implements goog.require() in JavaScript. The implementation is naïve, it just turns foo.bar.Baz into foo/bar/Baz.js and tries to include it. This is good enough for running unit tests or fiddling around with experimental code, which are the two times you're going to use `base.js'.

http://code.google.com/p/closure-library/source/browse/trunk...

[Me1000]

If there doesn't already exist a tool that watches your working directory for file changes and automatically recompiles, it will soon.

There are plenty of people who actively have build steps for web development: SASS, Less, CoffeeScript, CSS.

[mullr]

Not an issue in practice with coffescript, due to various server- and client- side tooling. My current setup will actually recompile and refresh the browser for me whenever I save. Typescript should be just the same, workflow-wise.

[taude]

Pretty sure this will be addressed (likely sooner than later) in much the same way Mindscapes Web Workbench plug-in compiles SCSS & less files when you save the file...

Edit: I'm currently using Chirpy to compress and unify all my JavaScript, anyway. So this isn't even really a concern.

[oinksoft]

I agree 100%. You won't see type-check warnings/errors from the Closure Compiler (which I noted yesterday supports far more detailed type-checking than TypeScript) until you re-compile, but this doesn't prevent you from running your code in a development context at all, as it's just plain JavaScript and `base.js' can handle goog.require() calls at runtime. The same things of course apply to unit testing via the Closure test runner or any other test framework.

And you can use plovr to recompile on every reload (takes 5-10s) if you need these warnings in your workflow at every step.

[MartinCron]

I have to build my entire project

With good tools (IDE and build automation) coupled with continuous integration/deployment, this doesn't have to feel like a tax.