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

Should we add a variant built by non-webpack module bundler? #102

Closed
tetsuharuohzeki opened this issue Mar 13, 2023 · 9 comments
Closed

Comments

@tetsuharuohzeki
Copy link
Member

Webpack is still one of the popular module bundler in JavaScript ecosystem. But some other tools also emerges.

For example, there is a rollup. Rollup is not only used as standalone tool, it' also used as vite's backend.

rollup emit a code that all modules are flatten by analyzing a module graph deeply. This is contrast to webpack wraps each modules by function as a emulate a module scope.

I'm not sure about that whether JSVM has already optimized about that this kind of a code emitted by rollup. However, in today's web application size, their flatten code including many variables might have some impacts related to web browser's page initialize performance.

I don't think we should drop webpack variant but I also think it might be better to add more module linker variants to get a chance to improve more workloads.

@flashdesignory
Copy link
Contributor

This is a great discussion point.
The initial goal of the todoMVC workload updates is to introduce some consistency between the workloads, to be able to determine impact of frameworks / libraries on performance.

Currently the todoMVC workloads use a variety of module bundlers and it makes it harder to compare.
I do agree that it would be useful to determine if bundlers have impact, for example a react workload built with webpack vs a react workload built with rollup, parcel or any other bundler.

This could potentially also be an iteration, once the initial updates have landed?

cc: @kara @housseindjirdeh

@rniwa
Copy link
Member

rniwa commented Mar 13, 2023

Note that we specifically don't want to able to compare different frameworks' performances. That is specifically a non-goal.

@tetsuharuohzeki
Copy link
Member Author

Note that we specifically don't want to able to compare different frameworks' performances. That is specifically a non-goal.

Yes. I opened this issue to discuss about to complement more variants of typical web application workload in today.

@bgrins
Copy link
Contributor

bgrins commented Mar 13, 2023

FWIW the new rich editor workloads from #81 are using Vite/Rollup. Also when prototyping some changes to todo workloads I found Parcel helpful (though this isn't part of the actual work that's going to land).

I would be curious to learn if the compiled code from these different tools actually have a strong Speedometer-measurable effect. Given that we start measuring after the page and all scripts are loaded my assumption is no - and that we shouldn't create permutations of workloads just to isolate that component - but it wouldn't hurt to check.

@julienw
Copy link
Contributor

julienw commented Apr 12, 2023

The new svelte implementation also uses rollup.

@julienw
Copy link
Contributor

julienw commented Apr 18, 2023

The proposed charting workload uses vite/rollup as well.

@rniwa
Copy link
Member

rniwa commented May 19, 2023

Sounds like this is taken care of now. Is there anything else we should discuss before closing this issue?

@tetsuharuohzeki
Copy link
Member Author

I don't have any additional topic. Thank you for your discussion.

@rniwa
Copy link
Member

rniwa commented May 19, 2023

Closing the issue as complete since we have workloads that use vite/rollup now.

@rniwa rniwa closed this as completed May 19, 2023
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