Hacker News Reader

Comment by peterhunt | Hacker News Reader

Js packing performance (including compilation) is probably the slowest part of the iteration cycle for frontend devs today. When combined with Babel’s and ecmas extensive test suites I think something like this could be wildly successful.

View on HN

Can you elaborate more on this? I've worked with very large codebases in React and Angular and have not seen this issue. I'm guessing it's either because all of my applications were able to hot-reload or we're not thinking of the same thing.

I don’t know if we’re doing something wrong but initial startup time on sentry’s webpack setup is something like 30 seconds and iterative changes around 5 seconds. Still beats our rust or python iteration times though :)

Have you looked into why the Sentry Django app takes so long to boot? Are you doing queries on app init or something?

a lot of codebases don't support hot reload, but even the ones that do often require multi-second incremental compile times during hot reload if they're big enough [1].

[1] current project is very slow w/ 250kloc (2.5mm kloc w/ dependencies). even seen it be slow on my last project which was only 40kloc.

Just using tsc to compile a hello world with 7 tokens takes over a second in my experience. Sure, most of that is initialization, but compare that to the C and C++ world, where GCC spends tens of milliseconds at most compiling hello world.

Hot reloading _helps_, but it's definitely an issue that javascript tooling spends seconds on tasks other languages' tooling spends tens or hundreds of milliseconds on. (The issue isn't just limited to tsc either; just starting the build system can take a decent amount of time with webpack, while make or cmake starts in milliseconds.)

Reply on news.ycombinator.com