Deno: You don't need a build step

Re:Deno: You don't need a build step by pianoben on Thursday March 02, 2023 @04:19PM (#35002229)

Conceptually, I don't see how this is much different from JIT compilers in the JVM, CLR, and similar runtimes. You don't hear so much from Java devs about how they can't* see the machine code their customers are running. They talk about cold-start performance, but accept that the first few requests will be slower in exchange for the productivity and eventually-high-performance.

Now that I think about it, this is how V8 works too, for JS code itself!

Why wouldn't this principle apply to bundling?

[ Parent | on HN ]

Re:Deno: You don't need a build step by nine_k on Thursday March 02, 2023 @06:53PM (#35003772)

JIT compilers at least do the work incrementally, profile the code to provide the best (or several) versions of native code, etc. That is, they adapt to the particular invocation, doing stuff an AOT compiler cannot do (especially for dynamic languages like JS).

I wonder if running the bundler on startup, and throwing away the (identical) result of a previous invocation of the bundler, makes much sense. It at least could persist it optionally, like Python does with .pyc files.

[ Parent | on HN ]

Re:Deno: You don't need a build step by derefr on Thursday March 02, 2023 @07:05PM (#35003891)

JITs exist because 1. certain compilation can't be done at compile time, because the code is dynamically synthesized at runtime from data only available at runtime; and 2. knowing how the code is already being used at runtime through an interpreter, can help optimize the compiled code ("profile-guided JIT.")

Bundling on first request has neither of these advantages: everything that is getting compiled at runtime could have been compiled at compile-time; and no information is yet available on how the code will be used.

[ Parent | on HN ]

Re:Deno: You don't need a build step by kelnos on Thursday March 02, 2023 @08:10PM (#35004492)

The difference is that the JIT doesn't "fail". Builds and bundling can fail, and I wouldn't want to trust that all the machinery the builder/bundler depends on (especially if it needs to fetch things over the internet) are available and working properly.

Put another way, as long as the `java` command is present and working on the production machine, I can be pretty sure my service is going to run and work (aside from any bugs in my code, of course). With Deno, more moving parts on the production machine need to be working properly in order to ensure things work properly.

[ Parent | on HN ]