Page tree
Skip to end of metadata
Go to start of metadata

Table of Contents

Background

Note: this document is a work-in-progress...

The front end ecosystem has been expanding rapidly over the past few years, and the number of new tools can be overwhelming.

Outcomes

  • Open edX Front End Developers
    • Ability to use more modern JavaScript technologies
    • Industry standard front end tools rather than Django's custom solutions
    • Faster ramp up time for new developers
  • edX Learners
    • Faster performance

Recommendations

  • Server-side - Django Templates (except for edx-platform which uses Mako)
  • Language - ES2015 (using Babel)
  • Linter - ESLint
  • Front End Framework - Backbone + React (incrementally)
  • Dependency Management - npm + RequireJS 
    • Note: Webpack can consume RequireJS dependencies
  • Build Tool - WebpackGulp
  • Test Framework - Jasmine
  • Test Runner - Karma

See Also



  • No labels

6 Comments

  1. Andy Armstrong, this is an awesome list! 

    I have a question about isomorphic javascript — how does that fit in our python-backend world? Are we moving to a world of giving up on server-side rendering altogether? Or does our inability to render equivalently on client and server make us more hesitant to adopt a client-side rendering paradigm, since we'll always take that performance hit on initial page load? 

    1. Thanks! I'm really happy to hear that you've found this page useful.

      It is a great question about where server-side JavaScript might fit in for us. In the long term, I could see us moving to the point where we use Python to build the REST APIs, and then we consume those APIs in a Universal JavaScript application. There are many nice benefits to this:

      • our web applications would now be built the same as our mobile apps which ensures more consistent behavior
      • it ensures that our REST APIs our fully capable, which in turn would allow the community to build new front ends in whatever technology they like
      • it would give us the kind of performance improvements that Netflix sees, where they render just enough of a page server-side to get the user started, and then complete the rendering on the client.

      I don't see a world where we do all our rendering client-side, because that is so much slower for the user. They are stuck with a blank page until all the JS loads, then all the AJAX calls are made, and only then the page can be rendered. This is why David Ormsbee is moving the CAPA rendering server-side, so I think moving everything client-side would be a step backwards.

      In the short term, I would like to see us move toward technologies that enable server-side rendering (such as ES2015 and React), but I would leave the Python rendering in place to ease the transition. Then when we are primed to support it, we could consider building a small IDA using server-side JavaScript to prove out the concept internally.

      1. In the short term, I would like to see us move toward technologies that enable server-side rendering (such as ES2015 and React), but I would leave the Python rendering in place to ease the transition. Then when we are primed to support it, we could consider building a small IDA using server-side JavaScript to prove out the concept internally.

        I was thinking about this too — but I imagine we're going to run into an annoying problem of keeping the html in react components and the html in the initial django template in sync with each other.

        1. That's a good point. I was thinking we'd keep the separation like we do now, where the server renders empty divs, and then the client renders into them. Today we do this with Underscore templates, but we could instead let React own the contents. This doesn't utilize the full power of React, but it would be an incremental step that would help us to get started.

          1. One of the drawbacks of rendering an empty divs on the server side is that it becomes very hard to manage state on the front-end especially when a component needs to interact with another component on the page.

            As someone who has worked on large scale apps, rendering those empty divs at the start to get going faster later proved that we were not able to utilise the full power of React as you mentioned. Managing states became one of the main issue, we kind of augmented it with our own solution.

            Another benefit we lose with rendering empty divs is SEO juice.

            A suggestion I would like to make is consider using Redux.

  2. For new projects that don't already implement requireJS, we may not need it if we're using Webpack as well - Webpack can import dependencies as es6 modules with no extra libraries.

     

    Some reading here: http://benmccormick.org/2015/05/28/moving-past-requirejs/