Why do you see that has a disadvantage? From a production perspective, I don't think it would matter much, since you'd most likely compile your app to JS ahead of time no matter what, for performance reasons. From a development perspective, I guess it could be annoying from the compile-debug-refresh cycle. But I could also imagine a tool to watch your app for any changes, recompiling on demand.
The compile-debug-refresh cycle is exactly the problem. Tools that watch the file system are no substitute for servers that can guarantee you get the latest version when you hit f5.
Quickly and reliably seeing your code in action is one of the more important things you do when coding, and anything that messes with that makes your life less fun, more painful and less productive.
> Tools that watch the file system are no substitute for servers that can guarantee you get the latest version when you hit f5.
How are these mutually exclusive? If you want a server that automatically runs the most recent (working) build of a piece of code, it's rather straightforward to implement.
I don't want the most recent (working) build of a piece of code, I want to see in my browser exactly what I have on my disk, and I want to see it every time without worrying about caching or whether my build loop has finished or not.
ClojureScript is not yet self-hosting. That is, the compiler does not run in the browser, although quite a few people want it to, so it's being worked on a bit.
That said, I haven't found it to have any serious impact on my development experience. There is no compile-debug-refresh cycle because I can evaluate forms against the browser REPL remotely. Compilation occurs server side and the JavaScript code is eval-ed on the client.
Yes, when you can update parts of the code on the page with a streaming connection it's a little bit different. I guess I'll give ClojureScript a pass on that one, but it's not a feature that nonlisp systems seem very keen on integrating so far.
Ought to be easy to serve the code from a script that compiles on demand. I assume you'd want a cache, but a simple modification date check will ensure that it's always up to date. Of course, having to build this is worse than not having to.
That is why debugging JS that was written in some ridiculous language that compiles to JS becomes quite difficult. The other problem is trying to figure out the fix in the original language which may not be obvious. But this is not a popular opinion. Not that I care that today's programmers would rather require that a web app be written in 10 languages rather than 4 (Serverside, JS, CSS, HTML).
Adding complexity is the opposite of the software development goal. Too bad most people don't get this. Other than shipping your software on time and sometimes even above that goal, is reducing complexity. Too bad most people go the other way because it's "cool."
Source maps go some way to making debugging code written in another language less painful. I more or less agree on the language side though. For real web development anything other than javascript should be providing you with a massive benefit to offset the disadvantages of adding a build step to your workflow and having to debug in a language different to the language you're coding in. I've not found anything that I think gives me a big enough benefit yet to make it worth it.
It's missing the whole point of interpreted languages. I hate JS as much as the next person, but in the end, if you don't know JS well, these languages will only hinder your progress.
Personally, I quite like roy http://roy.brianmckenna.org/.