You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current development workflow with spago bundle-app adds a 15-second delay (on my system) between making changes and seeing the results in your browser.
There are other strategies to achieve near-instant page refreshes with saved changes, such as with webpack in #187 and #192.
Most of bundle time is going to be spent in DCE. There should be a compiler option to skip DCE, which would make it much faster.
Is it 15-seconds on master, or 15-seconds against Halogen (which transitively pulls in most of the universe)? Do we need to prioritize dependency sizes and final bundle size?
I think that trypurs should always be buildable and shippable with stock-tooling, but I don't think it's necessarily bad that there's an alternative workflow for development if you want it.
I think you might be thinking of a pulp option; purs bundle doesn't have an option to run without DCE, but pulp does give you the ability to make a bundle without performing DCE via browserify, by running pulp browserify without the --optimise flag.
I think that trypurs should always be buildable and shippable with stock-tooling, but I don't think it's necessarily bad that there's an alternative workflow for development if you want it.
I agree. I think it's acceptable to use Webpack for the development workflow -- as far as bundlers go it's damn near standard and it's not going anywhere. We can still build and ship via stock tooling.
What about adding that option for purs bundle to skip DCE? That would be useful for everyone else developing an app in a similar way who has this problem.
I would really love ES modules with no bundler at all, although we can discuss the merits of that approach versus ES modules with Snowpack when that's closer to being a reality. I suppose that since we do have a clear path to getting rid of Webpack (i.e. wait until ES modules are a thing) and that the initial work has already been done, using Webpack in the meantime should probably be fine.
Activity
[-]Enable fast incremental rebuilds[/-][+]Enable faster development loop[/+]natefaubion commentedon Aug 23, 2020
A few things to consider:
milesfrain commentedon Aug 23, 2020
Could someone point me to the compiler option to skip DCE? I'm not seeing it under
purs compile --helporpurs bundle --help.This is 15 seconds on master (technically on #198, but that's close to equivalent and halogen-free).
natefaubion commentedon Aug 23, 2020
Maybe I'm remembering a bygone era, or maybe I'm remembering a pulp option. If it's not in the help for
purs bundlethen it does not exist.hdgarrood commentedon Aug 23, 2020
I think you might be thinking of a pulp option;
purs bundledoesn't have an option to run without DCE, but pulp does give you the ability to make a bundle without performing DCE via browserify, by runningpulp browserifywithout the--optimiseflag.thomashoneyman commentedon Aug 23, 2020
I agree. I think it's acceptable to use Webpack for the development workflow -- as far as bundlers go it's damn near standard and it's not going anywhere. We can still build and ship via stock tooling.
hdgarrood commentedon Aug 23, 2020
Webpack is damn near standard, but at the same time it's the source of a huge amount of grief. I'm still not sure how I feel about this.
hdgarrood commentedon Aug 23, 2020
What about adding that option for
purs bundleto skip DCE? That would be useful for everyone else developing an app in a similar way who has this problem.thomashoneyman commentedon Aug 23, 2020
@milesfrain Do you have an opinion? Would that enable the faster development loop you're envisioning?
milesfrain commentedon Aug 23, 2020
The options:
purs bundlehdgarrood commentedon Aug 24, 2020
I would really love ES modules with no bundler at all, although we can discuss the merits of that approach versus ES modules with Snowpack when that's closer to being a reality. I suppose that since we do have a clear path to getting rid of Webpack (i.e. wait until ES modules are a thing) and that the initial work has already been done, using Webpack in the meantime should probably be fine.
thomashoneyman commentedon Aug 24, 2020
That sounds like a good plan: use Webpack for now, with an issue and the understanding that we will remove it when the compiler supports ES Modules.
JordanMartinez commentedon Jun 18, 2022
Is this still an issue? Running
npm run serve:devstarts a web browser in ~6 seconds.thomashoneyman commentedon Jun 18, 2022
I think Miles was looking for something more like hot module replacement while doing development, supported by webpack, vite, etc.
hdgarrood commentedon Jun 18, 2022
Now that ES modules have shipped, maybe it’d be worth looking into snowpack?
thomashoneyman commentedon Jun 18, 2022
Snowpack is no longer maintained and they recommend Vite as an alternative