search

samccone / The-cost-of-transpiling-es2015-in-2016

Investigating the overhead cost of compiled es2015
1.34k stars 37 forks source link

A larger app example #43

Open paulirish opened 8 years ago

paulirish commented 8 years ago

A few conversations have concluded that this project would benefit from also testing an app that's larger than TodoMVC.

We are looking for an opensource webapp authored in vanilla ES6 with ES6 modules.

If anyone has any suggestions, please drop a comment.

paulirish commented 8 years ago

cc @guybedford - I feel like if anything, the SystemJS community may have a good candidate or two.

nstepien commented 8 years ago

This has potential to become the h5bp of ES2015+.

samccone commented 8 years ago

@nolanlawson do you know off of the top of your head if pouchdb would work? But that might not be what we want since it is not a real "app"

nolanlawson commented 8 years ago

Yeah, PouchDB is not really an "app" per se, so may be a bad choice. However, I'd be happy to convert pokedex.org's code to ES6 modules and test it out. A tool like cjs-to-es6 could also potentially be used to upgrade just about any CommonJS codebase.

samccone commented 8 years ago

pokedex would be a pretty good candidate.. The Marionette v3 branch is all written with es6... but again a lib not really an app.

I think we would have to do quite a bit of work to get pokedex to actually work with property mangling.. but... willing to help :)

https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/commit/cbe39967390aae0b4b9c3eae2229465ababb6fcb

paulfalgout commented 8 years ago

I definitely see value in trying a larger project that includes some external dependencies, but I think we should leave property mangling out of it. Granted I'm sure it's something you could consider from a library perspective, but that seems like a lofty requirement for any sort of standard project, and so I think it just skews the results away from most people's reality.

elibdev commented 8 years ago

The way I understand it, one of the awesomest things about tree shaking / dead code elimination is that you can import just a few functions from a library and instead of including the whole dependency, the compiler will include only the functions you imported.

This is a big win for the simple reason that you can include a large library as a dependency, and only the parts of it that you use will end up in the compiled Javascript.

If one of the intentions of including a larger app is to demonstrate this ability, maybe even just adding some library dependency to the TodoMVC app and importing one function from the library would do it. Any build process that use tree shaking will include only that one function in the compiled output, while build processes that don't will just include the whole thing. For a big dependency, the difference should be dramatic.