Ongoing discussion of switching to gulp/webpack from browserify

[himanshuc3]

Please describe the problem (or idea)

What happened just before the problem occurred? Or what problem could this idea solve? Feature Request.

Gulp is way more convenient, easier to maintain and faster than grunt because of being working on streams. Webpack is a highly configurable tool which I think is more flexible and has more room to work with going forward. Open to all suggestions. I would be trying to develop on this if given a green light.

What's your PublicLab.org username?

himichhabra14

Thank you!

Your help makes Public Lab better! We deeply appreciate your helping refine and improve this site.

To learn how to write really great issues, which increases the chances they'll be resolved, see:

https://publiclab.org/wiki/developers#Contributing+for+non-coders

[welcome[bot]]

Thanks for opening your first issue here! Please follow the issue template to help us help you 👍🎉😄 If you have screenshots to share demonstrating the issue, that's really helpful! 📸 You can make a gif too!

[rexagod]

Hi @himanshuc3! I had this on my mind too, and would love to collab with you in any way I can in this, after all, this is what's in the talks right now. Let's see what @jywarren has to say on this. Very thoughtful of you!

Also, welcome to the community!

[himanshuc3]

Coolio. Rooting for webpack, though.

[Rishabh-Kumar-Bothra]

Hey, I was also thinking that a switch can be made from browserifyto webpack. Browserify recursively concatenates the all modules to a single file. This results in 24k line of code with around 700Kb in size which can be hard to debug and heavy on browser. Other than bundling JavaScript code, webpack can also be used for bundling other static assests like stylesheets. Main advantage of webpack over browserify are the optimization it offers. Like the 24k LOC and all the minified CSS can be broken into various bundles(bundle splitting), which can be loaded concurrently or some only on-demand. Other than this webpack's dev-server is awesome, with built-in live reload and devleopment source maps. Fast/cheap source maps can also be included in production builds. We can integrate webpack configuration with grunt or completely eliminate a task runner in favour of npm scripts with webpack.

The whole process can be quite tedious. And choice has to be made whether a minimal set of well documented API, as in browserify, is better for the project or a configuration based feature rich tool like webpack. As webpack configurations can becomes hard to understand as it grows and it has a weird syntax for loaders, real weird.

Let's continue the discussion about this topic here.

Lets see what @jywarren suggest us and i would love to collaborate on this. thank you

[jywarren]

Hi, thank you for opening this, and for talking a bit about the pros and cons. Perhaps this is a good topic on which to hear from others in the Weekly Check-in? I'd love to hear some different responses. Thanks again!

https://github.com/publiclab/plots2/issues/4607

On Mon, Jan 14, 2019 at 11:56 AM Rishabh Bothra [email protected] wrote:

Hey, I was also thinking that a switch can be made from browserifyto webpack. Browserify recursively concatenates the all modules to a single file. This results in 24k line of code with around 700Kb in size which can be hard to debug and heavy on browser. Other than bundling JavaScript code, webpack can also be used for bundling other static assests like stylesheets. Main advantage of webpack over browserify are the optimization it offers. Like the 24k LOC and all the minified CSS can be broken into various bundles(bundle splitting), which can be loaded concurrently or some only on-demand. Other than this webpack's dev-server is awesome, with built-in live reload and devleopment source maps. Fast/cheap source maps can also be included in production builds. We can integrate webpack configuration with grunt or completely eliminate a task runner in favour of npm scripts with webpack.

The whole process can be quite tedious. And choice has to be made whether a minimal set of well documented API, as in browserify, is better for the project or a configuration based feature rich tool like webpack. As webpack configurations can becomes hard to understand as it grows and it has a weird syntax for loaders, real weird.

We can continue the discussion about this topic here.

Lets see what @jywarren https://github.com/jywarren suggest us and i would love to collaborate on this. thank you

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/publiclab/PublicLab.Editor/issues/227#issuecomment-454078109, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ4fQNcXUryD3K-Ktb5tSDFWPvP22ks5vDLaQgaJpZM4Z9pf_ .

[sashadev-sky]

@geekychaser Thanks for the post! I personally use Webpack, but it was very informative to learn about alternatives and pros and cons.

I agree Webpack definitely has a complicated API, so if we choose to go with it I would be willing to help write documentation explaining every aspect of the webpack config file we would create and use. It looks like we have a lot of webpack users so I'm sure they would like to get involved with this too. Although it can be complicated, all of the configurations go into one file which is a plus.

As someone who has only used webpack, though, I don't want to explicitly make my own recommendation

[sashadev-sky]

@jywarren I was looking over this again and I am curious, what was your initial reason for choosing browserify? I didn't see any responses in favor of it so I now I feel like my knowledge on it is lopsided. If you have a minute to share with me I would appreciate :) thank you!

[jywarren]

Well, it was not a major vote in favor of browserify, just that we tried it and it worked pretty well. I have not used webpack much! If it is more complex, I guess my only concern is keeping things as easy as possible for newcomers, and wondering if the benefits of its simplicity outweigh those of webpack's advantages... but happy to keep considering this and keeping it an open discussion, since I don't know much about webpack!

[jywarren]

I'm also interested in hearing more about gulp and don't quite understand the streams part of:

Gulp is way more convenient, easier to maintain and faster than grunt because of being working on streams.

If it is convenient and easy maybe we should consider it! I haven't used it though!

[sashadev-sky]

@jywarren The simplest solution for newcomers could be using whatever technology they are already most familiar with. Do you think it would be interesting to run a poll to gain insight on what most of Public Lab's contributors are using in their own projects?

[sidntrivedi012]

I think we can use we pack for bundling our files. It's better than browserify. I have just used it in one of my projects though the work was only to bundle a npm module. And we can't neglect the fact that latest technologies like Angular 7 use webpack internally to bundle the files and make the project production ready. So, imo webpack would be a good option.

On Mon, 4 Feb 2019, 7:39 am Sasha Boginsky, [email protected] wrote:

@jywarren https://github.com/jywarren The simplest solution for newcomers could be using whatever technology they are already most familiar with. Do you think it would be interesting to run a poll to gain insight on what most of Public Lab's contributors are using in their own projects?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/publiclab/PublicLab.Editor/issues/227#issuecomment-460112276, or mute the thread https://github.com/notifications/unsubscribe-auth/AdvcXU12oEsNjz-514BYlNaL8YlO9o5cks5vJ5Y-gaJpZM4Z9pf_ .

[jywarren]

I'm open to a poll but we should wait until the current community survey is complete, so perhaps another few weeks. Good thought.

Another question would be how much work it would be to change. Would we want to consider changing all our JS libraries to maintain consistency? And do we gain enough in final filesize and speed of compiling to justify the changes? I'm especially wary of what @geekychaser has mentioned:

The whole process can be quite tedious. And choice has to be made whether a minimal set of well documented API, as in browserify, is better for the project or a configuration based feature rich tool like webpack. As webpack configurations can becomes hard to understand as it grows and it has a weird syntax for loaders, real weird.

So, again, not against this, just cautious! Thanks for all the viewpoints!

[sidntrivedi012]

@jywarren I have not yet used webpack for a large codebase. But, for a small project it worked blazingly fast. Though I have found a nice read here to compare browserify and webpack.

[sashadev-sky]

@jywarren good thinking! Then we can also focus on the pure logistics for now as you're doing. I could try implementing Webpack on a local repository for the development environment and report back the results as I don't know the answer to those questions right now. What do you think of that idea? Any specific repo you would prefer?