I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?
>Just curious what the use case for not doing compilation is?
I'll add another one - the code that comes out is the code that goes in. Remember the days of Coffeescript and minimization before sourcemaps?
When most of your work comes from maintaining a codebase being able to effectively debug your code is crucial and hitting an error in production that is only painfully traced back to development will quickly offset any advantage that framework gives you.
I think this is the the big reason to prefer plain old JavaScript. Compilation is ok in Java etc. where you can still debug your Java-code. But with many of these JavaScript frameworks I don't think that is possible, is it?
I would add that "debugger" is not mostly a tool for finding and fixing bugs. It is tool for code-understanding, giving you a "live view" of your code, for READING your (or someone else's) code in the order it executes.
>I would add that "debugger" is not mostly a tool for finding and fixing bugs. It is tool for code-understanding, giving you a "live view" of your code, for READING your (or someone else's) code in the order it executes.
Absolutely! I couldn't agree more.
From the discussion about forking sub-processes from the shell:
The compiler/assembler/disassembler/debugger should be built into the shell, just like ITS DDT at the MIT-AI Lab in 1969! ;)
Some folks simply don't want to use a build system, whether it be for experimentation or not wanting to deal with the overhead of tooling.
Others are looking for options that might minimize overall script / JS size (which is a hallmark of Jason Miller, author of both Preact and HTM).
Another might be to make this easier for beginners. For example, the React docs link to an example HTML page that uses the `babel-standalone` build [0] as a way to try out JSX syntax. However, that's a hefty piece of JS, and it's not at all advisable for real use. HTM might be a good alternative to that.
I think you have answered your own question: it's one less thing to worry about in your stack.
If you're targeting modern evergreen browsers you already have a lot of modern features at your disposal, including ES6 modules, async/await, string interpolation, but we're not using them.
In fact, I'd say that it's way more than "one thing" that you can stop worrying about: you won't need Webpack/Rollup/etc, Babel, NPM/Yarn, Node.js itself, etc.
