3 ms·

The benefit of this would be at runtime when implementing interpreters: > experiment with JavaScript features by tweaking a JavaScript engine written in JavaSc

The benefit of this would be at runtime when implementing interpreters: > experiment with JavaScript features by tweaking a JavaScript engine written in JavaScript, all hosted just in a browser; think of it as a "Babel VM", realizing new JavaScript features that cannot just be compiled away I've been playing with making toy languages inside of Javascript, and I believe there's lots of untapped power there. The paradigm battles don't have to be: we can run all sorts of paradigms in the same VM, with data executing as code. This means that you can decompose expressions to see where they came from (e.g. the steps in a state machine that yielded an evaluation result). If you believe (as I do) that invisibility-by-default is one of the greatest pain points in the history of computing, then these sorts of approaches are essential. The problem with doing that is that some things will be slower than they would in "native" JS. I've been proceeding anyway and thinking that could be dealt with later. So I'm bookmarking this, because it attacks that exact problem: runtime-compilation of generated AST's. The name is a little unfortunate, in that respect, though, especially since it will make people think it's a build tool like Webpack. Webpack is for dead fish. This is incomparably more powerful. edit so to answer your original question, this would piggyback on the optimizations of the VM (V8 or SpiderMonkey, or whatever), taking for granted that JS which is not needlessly verbose (as generated code must sometimes be), can be run nearly optimally.

jamescostian 9y ago
> Webpack is for dead fish. I haven't used webpack but I have used many similar tools, and I've heard a lot of praise for webpack. Can you elaborate on why you dislike webpack so much?
- gavinpc 9y ago
  I'm using "dead fish" in the Bret Victor sense.[0] It's a static tool by nature. By the time you're in a live environment, webpack is gone. [0] https://vimeo.com/64895205 https://vimeo.com/64895205
  - jamescostian 9y ago
    Oh. Isn't prepack also a "dead fish" then? Like you said, "It's a static tool by nature. By the time you're in a live environment, [prepack] is gone." There isn't any sort of prepack runtime
    - gavinpc 9y ago
      I was assuming that the intention was to eventually provide runtime support. If that's correct, then I think we'd be in agreement about what "static" means? Babel and all sorts of other compilers can run in the browser. Whereas webpack is mainly concerned with the text that you transmit and could not "by nature" be made to do its job in the browser (because then it would be too late). That's the difference I had in mind.

jamescostian 9y ago

> Webpack is for dead fish. I haven't used webpack but I have used many similar tools, and I've heard a lot of praise for webpack. Can you elaborate on why you dislike webpack so much?

gavinpc 9y ago
I'm using "dead fish" in the Bret Victor sense.[0] It's a static tool by nature. By the time you're in a live environment, webpack is gone. [0] https://vimeo.com/64895205 https://vimeo.com/64895205
- jamescostian 9y ago
  Oh. Isn't prepack also a "dead fish" then? Like you said, "It's a static tool by nature. By the time you're in a live environment, [prepack] is gone." There isn't any sort of prepack runtime
  - gavinpc 9y ago
    I was assuming that the intention was to eventually provide runtime support. If that's correct, then I think we'd be in agreement about what "static" means? Babel and all sorts of other compilers can run in the browser. Whereas webpack is mainly concerned with the text that you transmit and could not "by nature" be made to do its job in the browser (because then it would be too late). That's the difference I had in mind.