Page MenuHomePhabricator

[Proposal: WikiEducation Dashboard] Reduce the bundle size and setup the foundation for error boundaries.
Open, Needs TriagePublic


Profile Information

Name: Amit A Joki
IRC: amitjoki
Github: AmitJoki
StackOverflow: Amit Joki
Location: Madurai, Tamil Nadu, India.
Typical working hours: On weekdays, I will be working from 6.30 PM to 12.30 AM and on weekends, I will be working from 9 AM to 5 PM. All the timings are in Indian Standard Time.


Wiki Education Dashboard is an excellent tool for students to learn how Wikipedia operates and promotes collaborative, team-based learning with Wikipedia as the medium.
I have been in touch with core collaborators and have been corresponding on Slack, Zulip, and through GitHub comments and occasionally by Mail. The suggestions given by them have been helpful in getting my PRs done.
Mentor: @Ragesoss

Final Summary

  • The bundle size will be substantially reduced which would result in faster page loads and improved user experience for those on low bandwidth connections.
  • Bloated and deprecated packages will be replaced by leaner alternatives.
  • Initial work for better error capturing will be done.


Phase 0 (April 27 to May 18): Community Bonding Period. Research on the techniques of code-splitting, tree-shaking, React.lazy and Suspense. Look for alternative, actively-contributed, leaner packages to replace the currently bloated ones. Research on how Error Boundaries could be worked on so a foundation for better error capturing and reporting can be laid.

Phase 1 (May 18 to June 15):

  • Using lodash-es instead of lodash. The lodash package uses CommonJS modules which makes it impossible for Webpack to optimize the bundle size via tree-shaking. lodash-es makes use of ES6 import/export modules which support tree-shaking.
  • The current lodash package size in the bundle is around 250KB. This can be drastically cut down by only importing specific functions that are used in the codebase.
  • Replacing raven-js with @sentry/browser package. The raven-js package is bloated, and is officially deprecated. The raven-js occupies 119.38KB which could be drastically reduced by using the now officially supported @sentry/browser package.

Phase 2 (June 19 to July 13):

  • Using leaner alternatives for Moment.js. Moment.js takes up a whopping 574.32KB of the bundle size. Moment.js too doesn’t support tree-shaking which means we would be importing a whole lot of dead code.
  • There are several leaner packages as can be seen here - You Don't Need Moment JS
  • The best alternatives are date-fns and dayjs, the latter only clocking up 2.6KB when gzipped. Also, MomentJS dependency from Chart.js can be removed.
  • Dynamically load main.js modules. It seems that the main.js file has some modules which should be in practice, loaded dynamically. It is in the DOMContentLoaded event listener, but the Webpack doesn’t really load them dynamically. All the require() will be replaced in place as it encounters it, leading to a > 1.4 MB chunk size.

Phase 3 (July 17 to August 10):

  • Replace TinyMCE with a lean alternative: TinyMCE isn’t tiny anymore. It occupies nearly 50% of the bundle size clocking at nearly 2.17MB. There are several cookie errors associated with it and they seem to be heading towards API Key model.
  • Pell is a lightweight alternative clocking at just ~4kb and has no external dependencies. It’s UI is clean and there’s no major difference in the working between TinyMCE and Pell.
  • Initial groundwork for Error Boundaries.


The current bundle size is around 4.3 MB. The aim is to reduce at least 40% to 50% of that size using various code-splitting techniques.

Phase I Evaluation

  1. Lodash-ES instead of Lodash.
  2. @sentry/browser instead of raven-js.

Phase II Evaluation

  1. Removal of Moment.js
  2. Dynamic loading of relevant modules.

Final Evaluation

  1. Replace TinyMCE with Pell.
  2. Foundation for Error Boundaries.


  • Following the contribution guidelines, creating new branches on Git, adding the features to the forked repo and issuing a pull request once done with the feature.
  • Online on Slack, IRC in my working hours.
  • Updating the progress on Phabricator.
  • Update the progress after the completion of task each week on my blog.

About Me


I am in my second year of my college. I am an Information Technology student currently undergoing 4th semester in my 8-semester course.

Where did you hear about GSoC?

I heard about GSoC from my senior who was a GSoC 17 Student with Haiku organisation. I had been a long time FOSS user, raising issues occasionally but always had the guilt of not contributing via code. Hence I have been working on WikiEduDashboard for quite some time now and would now like to be a part of GSOC ‘19.

What other commitments do you have during the course of this program?

I don't have any other commitments in the foreseeable future. The college works usually take an hour or so and I can easily manage that. Even that will be gone when the summer vacation starts; my only priority this summer would be to work on this project, have it completed and tested thoroughly.

What will working on this project mean to you?

Working on this project will mean a lot to me in terms of personal satisfaction. There's pride in knowing that my code will be part of something as amazing as Wikimedia. On the technical front, working on this project will acclimatise me to the ways of how real-time applications are built, tested and deployed.Also, this particular project will help me understand the need to choose packages in a way that won’t hamper the user experience.

Past Experience

I have been solving lots of issues in the WikiEduDashboard Github repository and I am proficient in Ruby on Rails and JavaScript. I’ve had fair amount of experience working on ReactJS while I contributed to the WikiEduDashboard. It would be fair enough to say that I’ve been with the project quite long enough to be able to work on each aspect of it efficiently.


I have had nearly 45 Pull Requests merged. My contributions can be seen here -

Event Timeline

Amitjoki renamed this task from [Proposal: WikiEducation Dashboard] Reduce the bundle size and setup the foundatio for error boundaries. to [Proposal: WikiEducation Dashboard] Reduce the bundle size and setup the foundation for error boundaries..Apr 9 2020, 6:39 AM

Google-Summer-of-Code (2020) is over! I believe you have already documented your project here If not, I would encourage you to do so. Also, is there anything else remaining in this task to address? If not, please consider closing this task as resolved.