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

Wepack loaders in mvi.js #2

Open
abaco opened this issue Dec 11, 2015 · 5 comments
Open

Wepack loaders in mvi.js #2

abaco opened this issue Dec 11, 2015 · 5 comments

Comments

@abaco
Copy link

abaco commented Dec 11, 2015

I think it would be nice to be able to use webpack loaders in mvi.js, to do things like require('style.css'). This is currently not possible because the server loads mvi.js directly. Only the client-side bundle.js is produced by webpack.

An additional bundle for the server side would be needed for this to work. Would you consider a pull request?

@alkhe
Copy link
Owner

alkhe commented Dec 18, 2015

Sure, contributions are appreciated!

Sorry for the delay, school's been busy.

@abaco
Copy link
Author

abaco commented Dec 18, 2015

Cool, I'll try to find time for this.

@alkhe
Copy link
Owner

alkhe commented Jan 7, 2016

Any progress on this?

@abaco
Copy link
Author

abaco commented Jan 8, 2016

Sorry, I've been enjoying a long vacation away from my computer... so I only had little time to look into this.

The main problem I'm facing is that the two bundles (server- and client-side) must be generated from scratch at each modification, even though they are almost identical. The client-side includes index.js and mvi.js, and it targets browsers, while the server-side bundle only includes mvi.js and it targets node. I'm no webpack expert, but it seems to me that those small differences dictate two indipendent bundling processes, thus making hot reloading twice as slow.

Seeing the progress on hot reloading in cycle-core (cyclejs/cyclejs#46) I'm now thinking it might make more sense to work on a static (non isomorphic) app during development, and produce an isomorphic app only for production. If the state is preserved and you can even fix bugs that happened in the past, then the isomorphic side is not useful during development, and should be skipped if it slows down things (which is the case if we want to pass mvi.js through webpack).

@alkhe
Copy link
Owner

alkhe commented Mar 14, 2016

related: #15

Any news?

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

No branches or pull requests

2 participants