Live data from Hacker News

Show HN: Faster.js – a micro-optimizing JavaScript compiler

github.com

11–20 of 37 posts

Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler

#11

This is cool, but array methods are so rarely the bottleneck; Even in the highly-specialized demo, the difference is near-negligible. It's a fun project and might have application in specialized situations (and maybe for Node, where time spent in synchronous iteration blocks all other requests?). But I feel like this does more harm than good in most cases (larger bundle, extra build step, less readable output code ca…

Agreed for the most part - this realistically does not have a good generalized use case. IMO the only real harm is the slightly larger bundle, though - I think the extra build time is negligible and you could just disable this optimization when developing.

My main motivation for building this was to make a better way to use an optimization library like fast.js (https://github.com/codemix/fast.js), which inspired faster.js. A huge issue with the fast.js library is that you have to rewrite your entire codebase in order to use it, whereas enabling or disabling faster.js is a one line change.

Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler

#14

Prepack, https://prepack.io , is also in the same realm of an optimizing Javascript compiler.

Prepack is somewhat different though in that it precalculates what can be. That's much less problematic than what the linked library does.

Of course prepack also isn't even close to production ready yet either.

Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler

#17
post #4

Prepack, https://prepack.io , is also in the same realm of an optimizing Javascript compiler.

Prepack is rather nice. It allows you to execute part of your code at compile time, like a macro.

Incidentally, http://www.scala-js.org compiler has constant folding too.

Also if you need faster numeric calculations https://github.com/non/spire (has scala.js support)

Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler

#19

This is cool, but array methods are so rarely the bottleneck; Even in the highly-specialized demo, the difference is near-negligible. It's a fun project and might have application in specialized situations (and maybe for Node, where time spent in synchronous iteration blocks all other requests?). But I feel like this does more harm than good in most cases (larger bundle, extra build step, less readable output code ca…

I agree, while this is a cool idea it doesn't seem to be useful beyond being a proof of concept of an optimization technique. For example, my browser rendered the faster.js version 50ms slower at this point: https://i.imgur.com/G5b10Ns.jpg. It does appear to perform better in the long run (https://i.imgur.com/u3ApYYl.jpg) but it's an improvement of less than 1%, and when your renders are taking 30+ms there are probably other things you should be looking at :P

Also, unless I'm misunderstanding the README, using the plugin introduces the huge caveat of breaking code that uses "restricted names" (certain names of Array functions) - the example given is a class that defines a map() function, which apparently would cause some kind of failure. In larger codebases where you don't control all code used in production this seems like a big problem.

Re: Show HN: Faster.js – a micro-optimizing JavaScript compiler

#20
post #18

This is a good example of premature optimization.

I think this is an example of _optimization_. An optimization that is easily applied as a transform for Babel, but that's just it.

Whether it is premature or not, it would depend on if you apply it carelessly without knowing whether you need it, or if you apply it when you know you need. Right?

Post reply on HN