4 ms·

You don't have to parse every single module at page load. You can defer, or only load code the first time it's used. This 10-15% of time saved is only on first

by z3t4 9y ago

You don't have to parse every single module at page load. You can defer, or only load code the first time it's used. This 10-15% of time saved is only on first load. If you have a web "app" it's not like the user will reload it over and over again like the old school server rendered apps, which still works fine btw, they are even faster now with faster computers and better network latency. So if this is not the problem of classic web apps, nor the problem of modern web apps, who's problem will it solve !? Make cache-friendly modules, only abstract code that can be reused, keep the rest of the code in-line.

Yoric 9y ago
I wrote https://news.ycombinator.com/item?id=14908903 https://news.ycombinator.com/item?id=14908903 in answer to a different question. Does it answer your points, by any chance?
- z3t4 9y ago
  JavaScript is a fun language because it does not require a build step. Developing JavaScript is easy and you want to make it harder just to shave off a few milliseconds !? Show me some stats and graphs on how long it actually takes to parse JS to AST. I care a lot for performance, if you want to make me happy, make text rendering in the canvas faster. And if you could also make eval faster I would be very happy.
  - Yoric 9y ago
    Most professional development I have seen in the past few years already uses a build step, either to pack dependencies, to run linting or to polyfill language features, so this Binary AST will not really change that. Indeed, I hope that Babel, Webpack & co will eventually ship with an option `--binary-ast` and that the only change for developers will be to add this option to their toolchain. However, if you wish to write JavaScript without build step, you will of course be free to continue doing this. I don't think that anybody has ever thought of making the Binary AST compulsory. It's just a build target that you can use for decreasing file size and parse time. For stats, see the proposal. We'll add more stats once the advanced prototype is complete. > I care a lot for performance, if you want to make me happy, make text rendering in the canvas faster. And if you could also make eval faster I would be very happy. I'm sure both are in progress, but entirely orthogonal to this proposal.

by z3t4 9y ago

Yoric 9y ago

I wrote https://news.ycombinator.com/item?id=14908903 https://news.ycombinator.com/item?id=14908903 in answer to a different question. Does it answer your points, by any chance?

z3t4 9y ago
JavaScript is a fun language because it does not require a build step. Developing JavaScript is easy and you want to make it harder just to shave off a few milliseconds !? Show me some stats and graphs on how long it actually takes to parse JS to AST. I care a lot for performance, if you want to make me happy, make text rendering in the canvas faster. And if you could also make eval faster I would be very happy.
- Yoric 9y ago
  Most professional development I have seen in the past few years already uses a build step, either to pack dependencies, to run linting or to polyfill language features, so this Binary AST will not really change that. Indeed, I hope that Babel, Webpack & co will eventually ship with an option `--binary-ast` and that the only change for developers will be to add this option to their toolchain. However, if you wish to write JavaScript without build step, you will of course be free to continue doing this. I don't think that anybody has ever thought of making the Binary AST compulsory. It's just a build target that you can use for decreasing file size and parse time. For stats, see the proposal. We'll add more stats once the advanced prototype is complete. > I care a lot for performance, if you want to make me happy, make text rendering in the canvas faster. And if you could also make eval faster I would be very happy. I'm sure both are in progress, but entirely orthogonal to this proposal.