Running METEOR@1.7.1-beta.18 like
12 Likes
The future is bright.
1 Like
How much faster is it in your app?
In a small app that I have the improvement was 22% on rebuild.
1 Like
Ours is around 6 to 8 seconds, but it’s a large react project with many modules/pages, how fast is yours? And yes METEOR@1.7.1-beta.18 is faster by around 4 to 5 seconds due to delaying legacy compilation and more caching I think.
1 Like
Are pre-deploy build times (“meteor build”) reduced too ?
In the various “build time in 1.7” threads people seem to be complaining mostly about slow reload times on file changes when developing, but oddly enough for our app I didn’t really notice a dramatic slowdown there after moving from 1.6 to 1.7.
“meteor build” times, on the other hand, roughly straight up doubled, from 2.5 min to 5 min (bringing our total deploy time - self hosted, no Galaxy - to 7 minutes, which is beginning to be a bit of a pain)
The “modern browser” build is supposed to involve less babel transpilation, right ?
So it really looks weird that it adds roughly the same amount of time it took 1.6 to build both server + (legacy) browser ?
There are multiple performance KPIs being discussed here that are impacting the developer experience. Different people are using different terminologies which is causing confusion I think.
Here is an attempt to define the terms:
- Build Time: the time it takes to build both client/server at the stat
- Startup Time: the time to start a meteor app (build time + startup logic)
- Rebuild Time: the time it takes to rebuild both server, client modern, client legacy
- Refresh Time: the time it takes to refresh client only changes (that is when you see client modified)
- Deployment Time: the time it takes to build the app production package and deploy to the server
With the 1.7 early betas I think both 3,4 increased (perhaps everything else increased as well) increased since we’re building two packages now, thanks to Benjamin effort, latest 1.7 betas solved that by delaying the legacy build after rebuild/refresh. Some folks complain about 3,5, but I think the most important KPI to optimize (especially for large react projects is 4, the refresh time, since this what impacts the developer experience the most, ours is not optimal it’s around 9~11s, and it seems whenever a large large CSS framework (Bootstrap, SemanticUI, Foundation etc…) is used along wit large number of NPM modules the refresh time end up with 10s+, even when using webpack the same thing is observed it seems…but it could be something else going on with our dev app structure, not sure yet.
1 Like
Wow, recently I have been working on modifying existing projects, the rebuild and refresh times are killing me. Also the rebuild crashes/freezes on the most recent project.
I get more stress than I can handle.
Use create-react-app for your front-end, then connect it to a meteor backend with apollo/graphql.