Page MenuHomePhabricator

Stop inlining Portal JavaScript (create a file to be requested)
Closed, ResolvedPublic3 Estimated Story Points

Description

We currently inline the portal JS, meaning that browsers that don't have JS support still have to load it, even if they're on shoddy connections. We can do better. Let's deprecate the inlining and store it as a separate, distinctly requested file. As a side-effect we will be able to measure the level of JS support our users have.

We'll need to:

  1. create the distinctly request-able JS file
  2. update the portal page to remove the inline JavaScript
  3. update the portal page to use the request-able JS file
  4. push to production

We'll need this information sooner rather than later - and we'll need to base our A/B testing on these results.

Event Timeline

Ironholds raised the priority of this task from to Needs Triage.
Ironholds updated the task description. (Show Details)
Ironholds subscribed.
debt renamed this task from Stop inlining portal JS to Stop inlining Portal JavaScript (create a file to be requested).Jan 26 2016, 7:07 PM
debt triaged this task as High priority.
debt updated the task description. (Show Details)
debt set Security to None.
debt updated the task description. (Show Details)
debt moved this task from What's Next to In Progress on the Discovery-Portal-Sprint board.

Change 266972 had a related patch set uploaded (by JGirault):
Stop inlining JS. Concatenate all JS files into a single file.

https://gerrit.wikimedia.org/r/266972

Change 266974 had a related patch set uploaded (by JGirault):
[WIP] Replace inline JS by a single bundle file.

https://gerrit.wikimedia.org/r/266974

Hey @Jdrewniak, I submitted two patches, and they resolve the same issue in a totally different way.

The first patch https://gerrit.wikimedia.org/r/266972 uses simple concatenation into a single file, and minifies the code.

The second patch is much more advanced. It uses a JavaScript module bundler (http://rollupjs.org/).
The biggest benefit for us is dependency management using ES6 module system.
This would help us to refactor the code into SRP modules that will be a lot easier to develop/improve/test/maintain...
Please take a look, and we can discuss it tomorrow.

@JGirault I just recently discovered rollup.js myself. I think it's a very interesting project.
I like how it uses static analysis on ES6 modules to only import code that is actually used.
It would let us pull in entire libraries for development, (like underscore) and then it would
bundle the production version so that it only includes the methods we use in our code.

Like you mention, this approach would require an ES6 transpiler (Babel right?), and we would
have to be careful that we maintain browser support if we use any ES6 features, but I think in general
the pros vastly outweigh the cons. :)

Change 266972 merged by jenkins-bot:
Stop inlining JS. Concatenate all JS files into a single file.

https://gerrit.wikimedia.org/r/266972

The above patch was merged. Is it deployed yet? It would be good to know since deployment of this blocks T124655.

Hi @Deskana, it's not quite done yet - we hope to get it into the beta portal site to test before releasing to production.

Hi @JGirault and @Jdrewniak - can you verify that this got into beta and is waiting for the release to production?

This will be released into portal production today.

Change 266974 abandoned by MarcoAurelio:
[WIP] Replace inline JS by a single bundle file.

https://gerrit.wikimedia.org/r/266974