Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable faster development loop #197

Open
milesfrain opened this issue Aug 22, 2020 · 15 comments
Open

Enable faster development loop #197

milesfrain opened this issue Aug 22, 2020 · 15 comments

Comments

@milesfrain
Copy link
Contributor

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.

@milesfrain milesfrain changed the title Enable fast incremental rebuilds Enable faster development loop Aug 22, 2020
@natefaubion
Copy link
Contributor

A few things to consider:

  • 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.

@milesfrain
Copy link
Contributor Author

Could someone point me to the compiler option to skip DCE? I'm not seeing it under purs compile --help or purs bundle --help.

This is 15 seconds on master (technically on #198, but that's close to equivalent and halogen-free).

@natefaubion
Copy link
Contributor

Could someone point me to the compiler option to skip DCE? I'm not seeing it under purs compile --help or purs bundle --help.

Maybe I'm remembering a bygone era, or maybe I'm remembering a pulp option. If it's not in the help for purs bundle then it does not exist.

@hdgarrood
Copy link
Collaborator

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.

@thomashoneyman
Copy link
Member

thomashoneyman commented Aug 23, 2020

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.

@hdgarrood
Copy link
Collaborator

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
Copy link
Collaborator

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.

@thomashoneyman
Copy link
Member

@milesfrain Do you have an opinion? Would that enable the faster development loop you're envisioning?

@milesfrain
Copy link
Contributor Author

The options:

  1. ES Modules with Snowpack.
    • My favorite.
    • Least amount of throw-away work.
    • Farthest-away option, but I can wait.
  2. Skip DCE with purs bundle
    • Unknown how much faster this will be.
    • Requires additional tinkering for automatic refresh and incorponating non-purs changes.
    • Not available today. Requires compiler changes and another release.
    • Doesn't seem like there's much demand for this.
  3. Webpack
    • Available now.
    • I don't like webpack either, and it caused me a lot of grief with this project too.
    • Dues are already paid for setting it up in this project though, so it should be smooth sailing to use.

@hdgarrood
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Contributor

Is this still an issue? Running npm run serve:dev starts a web browser in ~6 seconds.

@thomashoneyman
Copy link
Member

I think Miles was looking for something more like hot module replacement while doing development, supported by webpack, vite, etc.

@hdgarrood
Copy link
Collaborator

Now that ES modules have shipped, maybe it’d be worth looking into snowpack?

@thomashoneyman
Copy link
Member

Snowpack is no longer maintained and they recommend Vite as an alternative

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants