Hacker News Reader

Comment by iamleppert | Hacker News Reader

Not a comment about the tool, which looks cool and well done.

It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run.

I think static analysis performance optimization tools are great but a certain part of me thinks it just raises the waterline for more shitty code and awful heavy frameworks that sacrifice the user experience for the developer experience.

"Just run it through the optimizer" so we don't actually have to think about what a good design looks like...

View on HN

Evaluating constant expressions at compile time is something any good compiler will do. It's not bad practice to write something like "60 * 60" in code instead of 3600, if the underlying computation is important. At the same time, performing a multiply at runtime is unnecessary and wasteful. This just gives you in JavaScript what any decent C compiler has been doing for ages.

Every time someone says "optimizers are harmful, just write fast code to begin with" I ask if they've written "x / 3".

Optimizers are there to help you write maintainable code instead of unmaintainable micro-optimized spaghetti. Use them.

> I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it

I'm not sure what you mean by "fancy code." I feel like it's the opposite. We often try to write code that is readable and maintainable, and has as few as possible "fancy" magical constants littered throughout it, but I'm happy if a compiler wants to optimize it.

If I have to specify some variable, e.g. `frameRate = 60` and then I have a whole bunch of other variables throughout the code that depend on it, then I'm going to reference framerate everywhere: `framePeriod = 1/frameRate; frameBufferSize = frameRate * 100` or whatever. This way if we change our specs, I have a single number to change, instead of dozens of numbers that all depends on each other.

Similarly, if I'm calculating the volume of a sphere, you bet I'm going to put `v = 4/3 * Math.PI * Math.pow(r, 3)`, because it's a meaningful statement that everyone will understand, without trying to get "fancy" by optimizing it.

But should a compiler optimize it? Heck yeah.

I disagree with the premise a little bit. A tool like this could allow you to write code which is better suited for a human to read/maintain, but then still get the performance optimizations of pre-computed results being sent over the wire.

There is some confusion in this thread about the purpose of this tool, which is targeted at generated code—specifically, code generated by other compilers. In order to get language features that don't exist in javascript, code has to be generated in a more or less context-agnostic way. This (as I understand it) brings more context to bear, to reduce the cost of the new abstractions for your specific usage.

Ah that makes sense. I was wondering why the examples all looked like Coffeescript output.

Why improve the compilers when we can have yet another tool to layer on top of our ever growing tool stack.

I take it you've never looked at a modern C++ or similar build and execution chain under the hood then?

There's a LOT of parts that do different things. They may be aliased under one command (with tons of flags) but a modern system does a lot of stuff.

For modern JS we appear to have:

- Linters (ESLint, etc)

- Transcompilation to Object Code (Babel, etc, transpile to JS)

- AoT Compilation (this & Closure Compiler, etc, do optimizations on the code ahead of running it)

- Recompilation (AST based compression - like Uglify)

- Compiling (the actual JS VM, V8, etc)

- JIT (in the actual browser)

None of these steps are alien to other build chains.

Is that right? The Scala.js compiler emits none of that "run-time metaprogramming" boilerplate that Prepack is good at optimizing away.

In general, I would expect from a compiler to JS not to emit performance killers like that. Any decent compiler to JS should be able to remove its own crap on its own ;)

Maybe someone can try it on a large AOT compiled Angular2 project?

> It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run.

I respectfully disagree :)

I stopped writing excessively terse, 'overly clever', borderline 'minified' code a long time ago when I realised it wasn't worth it - it isn't readable, and it certainly isn't maintainable by my future self, let alone others. Maintainability is generally more important than saving a few cycles. Abstraction does not necessarily === "shitty code" - abstractions help us to build a mental model and reason about what the code is doing.

Having said that, I certainly see where you're coming from - abstraction can be overused, taken to the nth degree such that it's almost impossible to work out how anything actually works, and I do rather loathe such excessively heavy frameworks. But Prepack can help optimise the good frameworks that use just enough abstraction.

On the face of it, Prepack gives us the best of both worlds - developers can write maintainable code, and Prepack can optimise it a bit for us. Others here have menioned it too, but I see it as akin to the same sort of optimisations that compilers generally do.

Reply on news.ycombinator.com