Open edX 2017: The future of front-end development in Open edX (‘FedX’)
Articles,  Blog

Open edX 2017: The future of front-end development in Open edX (‘FedX’)


So thanks everyone for
coming out to my talk. Today, we’re gonna be talking about
the future of front end development in Open edX also know as FedX. I ask that you please hold
questions till the end. Gonna leave about ten minutes for
discussion. I’m also running a session
tomorrow morning, 9 AM in the breakfast area,
would love to chat with all of you. All right.
So little bit about myself. My name is Ari, I am a senior front
end engineer on the edX core team. I work in accessibility,
which by necessity is front end. And so FedX itself is a working group within edX meaning, it’s not a particular team it’s more a collection of
people with shared interests. And our mission, as a group, is to
empower the edX development community by continually defining, evangelizing and
and supporting front end best practices. edX development community, that means
edx.org but also all of you, all right. So I’m gonna go over the existing
state of the front end, some of the pain points inherent there. Talk kind of at a high level about
our approach for cleaning that up and making it easier to work with. And sneak preview at some of the new
technologies that we’re starting to adopt All right, so
let’s jump right into prior art. So the Open edX platform
is a Django application and as such it does a lot of
rendering on the server side. This is just basic HTML rendered into
template files because it’s django, a lot of it is done through Django
templates as well as mako templates. And if you’ve modified
the Open edX front end at all, I’m sure you’re very familiar with these. Client side,
we’ve got a little bit more going on. We’ve got Sass which we use
to build our style sheets. We have a healthy dose of jQuery, both old style kind of
ad hoc jQuery classes, as well as sprinkle throughout other
views Backbone and Underscore. And although it’s technically deprecated, we still do have a decent amount
of CoffeeScript left to clean up. Some of you may also be familiar
with the UX pattern library, which is an initiative that the edX
front end team took on awhile back. It’s our attempt at a CSS framework and
UX style guide and HTML style guide, kind of all in one approach to best
practices for front end development. And that defines official brand colors, styles, fonts, there is a couple of
patterns in their specific patterns. Adoption is on the low side. It’s only within at the out
of the box at edX platform. It’s only in a few views. And you can see more details
on that at ux.edx.org. [LAUGH] And asset management, so
it’s all done through Django. Everything is built via
Django’s asset pipeline. This means our Sass & CSS as well
as our JavaScript compilation, CoffeeScript compilation. And if you’ve worked with it
before particularly on a DevStack. You might be familiar
with how slow it can be. All right, so that’s a great
jumping off point, I think, for some of the pain points involved with
working on the Open edX front end. Performance is a big one and
performance matters because it’s not just developers that have to deal with it,
it’s also our users. Our users see bad performance, it can really affect someone’s
experience on the platform. Our pages are somewhat heavy. We have a decent amount of static
assets that got served with every page, our style sheets, our big cached. It’s usually not such a big deal,
but on a fist page load, especially on a mobile device,
it’s pretty slow. This also most of the time spent displaying a page is in the rendering in
the painting that happens in the DOM. And this becomes much, much worse,
exponentially worse on a mobile browser or a slow network connection which are both
use cases that we hear a lot about. So this is a standard average
page view load time for all the pages across the Open
edX platform on edx.org. And you can see the numbers
might be a little small but it hovers around six seconds which isn’t
terrible but it’s not great either. But if you look most of that time is spent
in DOM processing and page rendering. There’s a lot going on in every page load. Take a look at this, though. This is the native Android
browser look at those numbers. 15 seconds to load a page would
any of you wait around for that? I don’t think I would. And again that DOM processing and
page rendering is much, much greater here. Queuing and web application,
those still are pretty low but the rendering is really
the pain point there. Also slow network connections. So in the US and most of Europe,
we’re all in the green here. We get decent page load speeds for
all of these pages. But if you look at some of
the slower areas most of Africa, a good amount of South America. Those are areas that don’t necessarily
have access to the fast Internet connections that we’re used to and
we kind of take for granted and that we develop for
because that’s what we use. So this is kind of
a problematic map I would say. Accessibility is another big concern. edX as an organization is very committed
to providing accessible software both to, learners and then as Shelby mentioned
earlier, on the studio side as well. But accessibility is
kind of a hard problem. Solving it requires a lot
of domain knowledge. You really have to know what you’re doing. You need a deep understanding
of the ways users, disabled users may or
may not use the platform. So, this is a big developer pain point. And as there’s code duplication
throughout the codebase, say, a big one for us is multiple,
modal dialog widgets. The more modal dialog widgets we have, the more we have to confirm that
all of them are accessible. And when you only have one
person on staff who has that domain knowledge,
it can really, really add up. Maintenance. So, this is a chimera. It is a mythical creature made of
multiple different animals in one body. Multiple heads, all very angry,
all very dangerous. And I feel like for the Open edX frontend,
this is kind of an apt metaphor. We’ve got our CoffeeScript,
we’ve got our jQuery, we’ve got our backbone,
we’ve got a lot going on there. And not everyone understands all
of that right out of the box. There are areas of the codebase,
I’ve been with edX about six months. There are several areas that I
still don’t fully understand. And imagine what that’s like for someone
who’s just starting off with a platform, it’s not super developer friendly. And this is not a problem
that’s unique to Open edX. It happens really with any large codebase, but it tends to be particularly
bad with the frontend. Cuz frontend technology moves so
fast, it’s hard to sort of keep up, but we wanna fix this. So, how are we gonna do it? So our goals within edX are changes
to the Open edX frontend. We want an optimal experience for
all of our users. This means slow network connections,
this means mobile devices, this also means users with disabilities. We wanna develop with maintenance in mind. Like I said, frontend moves super fast. And if we think about things
less in terms of this one particular framework, and
more as separate concerns, it becomes easier to build
an application that’s easy to maintain. And last but not least,
we wanna make it easy and enjoyable for developers to contribute
to the Open edX frontend. Internally, that applies to our staff
developers, but it also means all of you. All right, so, here’s our approach. I don’t know if any of you are as
much fans of trash pop culture American news as I am. But if you are, you’ll recognize
Gwyneth Paltrow’s conscious uncoupling. I’d like to think of it more as conscious
decoupling, and more of a software sense. So what does this mean? Instead of an all-in-one solution
to the frontend, we wanna decouple the concerns that don’t necessarily
need to depend on each other. So, we’ve got multiple components to this. We’ve got data, we’ve got business logic,
and we’ve got the appearance of the pages. And those three things definitely overlap. They definitely relate to each other, but they don’t all need to
depend on each other. So, how do we make this work? We think of it more as less
as an all-in-one application, and more as loosely coupled services, kind of like a mini-distributed system. We maintain integration points in between
the three of them so that each service internally can change independently
without breaking everything else. So, what does that mean? So, the data side of things,
that’s the content of the UI. This is stuff you might get from
the server or from user input. It informs the business logic. And our integration points there,
our web APIs, the data might get sent over from the server or
user input, that is data as well. If you type into a form that’s
data that we have to store. The business logic layer is how does the
frontend behave and how is it organized. This is generally handled in
the JavaScript and the HTML. It’s very important for
this layer to be well-maintained. It has to be consistent, so that it lines up well with
the data side and appearance side. Accessibility lives here as well, and best practices largely live
in the logic layer as well. And our integration points here,
again, the data layer, the web APIs, and the way the DOM is organized so
that CSS selectors work consistently. And appearance, this is how the UI looks,
this is pretty much all CSS. It needs to be extensible, and we want it to be themable too cuz a lot
of people theme their Open edX instances. And this is just selectors, CSS only really relates to the rest
of the DOM with its selectors. And here’s kind of a complex diagram,
how it all works together. You can see the data flow up from
the server into the data layer. Business logic kind of handles, generating the page,
which then gets styled by appearance. Then user actions form submissions, etc. Those flow back down
through the logic layer, to the data layer, over onto the server. All right, so,
this is probably why you’re all here. We’re gonna talk about what’s
coming next for the edX frontend. So, lot of good stuff here. The primary goal right now is
to modernize our frontend. We want to bring it up-to-date, we wanna
be using the cool new technology that frontend developers care about,
wanna attract those open source contributions, that are going
to make a difference in our platform, and we wanna keep our own
developers happy as well. So, ES2015 is the big one. If you’re not familiar with it, it is the current working
specification of ECMAScript. It’s super cool, you should all
check it out if you haven’t already. Basically, it is a very sane
way to write JavaScript. We have classes, we have imports,
all kinds of cool object, and array operations, it’s wonderful. Bootstrap and React,
as Joel mentioned earlier, and then, webpack for bundling. Also, I wanna call
attention to web fragments, which some of you might have used. Web fragments are a way to
generate pluggable user interfaces via Django application. And so this is Django code that renders
some chunk of UI into your application. These are currently used within
the current working XBlock specification. Some of you may have used them. They can also be embedded directly
into the open edX platform itself. And those passed via OEP-12. There’s also for all of these things
I’m talking about there’s a lot of great documentation on
the Confluence Wiki. I can send out a link to that later
on if any of you are interested. Webpack is another big one. And this is really exciting. It’s probably the most excited I’ve ever
been about an asset management system. Webpack is the de facto standard for frontend asset management right now. It bundles JavaScript as well as Sass or
Less if you’re using that instead. The great part is it does
not depend on Django, so you can run it independently,
you don’t have to depend on the Django asset pipeline
itself to bundle Webpack code. You can run it in a separate
service if you like. Let’s chat more about that tomorrow
morning if you’re interested in how to do that. And it enables us to write that lovely
modern ES2015 code through babble. Babble is a transpiler that makes this ES2015 code work in all browsers. Bootstrap, so bootstrap for CSS,
some of you might be familiar with it. Some of you might have used it. It’s kind of divisive among
the development community. A lot of people are thinking it
has to generic of a feel to it. Bootstrap four is coming out very soon,
it’s currently still in alpha. But there’s a lot of great stuff in there. It contains a lot of mixins for
not accessibility, responsiveness, so working on mobile. It makes it extremely easy
to style on application. But the best part is it is themeable. It is built to be themeable. And bootstrap themes are widely used. And there’s a ton of community support for
bootstrap. So the beta of version four is
coming out soon until then, we’re working off the alpha. If you’ve been paying any attention to
our Open edX proposal about Bootstrap, you may have noticed there’s a bit of
debate ongoing on about RTL styling. We’re planning on handling
that via a plug-in, a community plug-in and then RTL is
in bootstrap roadmap for release. So once they figure it out then
we’ll just then get that for free. And if you are curious about this,
please check out OEP- 16. It is supposed to emerge this week. So if you haven’t put in on this,
please do it now. React. Yeah.
React is happening. OEP-11 emerged a couple months ago. Meaning that future
front-end development for the Open edX platform will
be done by a React JS. I encourage you to check out that OEP for
a little bit of the reasoning behind that. How we arrived at the React conclusion? Basically, it’s encourages modularity and
code reuse. React is built by a components
which can then be extended or improved upon and
everything is encapsulated. JavaScript and HTML, all of that that
business logic lives in one place. It’s easy to test in isolation. You can render individual components. You don’t have to worry
about the whole page. And the best part is it interoperates
very well with legacy code. This could be kind of
a double edged sword. Because the easier it is to
interoperates with legacy code. The less motivated people
are to remove that legacy code. But for a platform the size of edX platforms front-end, we really need that. It’s state managers can work
well with legacy code as well. I personally have used React
alongside Bootstrap and it works better than you think. So that’s React. And this is the thing I’m most
excited about is we are testing out a React component library. This means these are kind of
like building blocks for UI. Reusable chunks of user interface to
handle the kinds of UI challenges that may crop up at multiple
points throughout the front-end. So the example earlier, the modal dialog. The goal there is to have one
modal dialog that we use where all of the accessibility concerns
are just bundled together in one place. You don’t have to worry
about accessibility. You don’t have to wait for
an accessibility code review. You just drop it in and it works. And those are gonna be versions
semantically, and available via MPM. We are still in the progress of figuring
out exactly how we want to do that. We are planning on proving
it out first via studio and then if all goes well there
moving it into the LMS, but we are gonna be very transparent about
the development of this library. We definitely want your feedback. Definitely wanna hear from the community. We wanna know what
components you wanna see? What components you would change? And we wanna make sure that these
are as themeable as possible. They should work with existing themes,
future themes, potential Bootstrap themes. Yep. All right, so we want to hear from you. I have talked to a handful of people here
so far about what they’re doing with the Open edX front-end and
I wanna hear from more people. Tomorrow morning Birds of a Feather
session downstairs 9:00 AM. There’s a lot of people here, so I don’t know really how well
a group this large would work. But yeah, come chat with us about
front-end as well as accessibility. Mark Sadecki will be there as well. There’s a front-end channel
in the Open edX Slack. Check that out. Voice your concerns. I will post some links
to relevant wiki pages. The edX code mailing list is
another good place to get involved. PRs are welcome although not
required at the OF [INAUDIBLE] is a good place to watch if
you’re curious about upcoming things going on with front-end or
elsewhere in the platform to. And yeah, come chat. All right. Thank you. [APPLAUSE] Questions? Over there.>>In several places in the US
there’s a explicit prediction And we can all go>>[INAUDIBLE]
>>Yes.>>Have you come to a [INAUDIBLE] and
asked whether they support ETL or [INAUDIBLE]
>>Not that I’m aware of.>>What will be the reference then?>>For Mako versus Django templates,
versus Ginga? [INAUDIBLE]
>>Mm-hm>>[INAUDIBLE]>>I am not aware of one at this time, if I find out I will tell you,
>>[INAUDIBLE]>>Yeah.>>I remember it was discussed, but I don’t know if there’s
any plan to support that.>>Yes.
>>I’m asking about the react and the web fragments. Because I don’t think they will work well,
right.>>Reacting web fragments. Yeah.>>Web fragments could be, web fragments
could render react components. React lives entirely on the front end.>>Yep.>>A web fragment is more
a way to plug something in to an existing Jango workspace. So, in your view that’s rendered by
the web fragment you could use components. You could use whatever you want,
it’s not prescriptive in terms of exactly how it renders
that front end, it just renders it. Okay.>>Did that answer your question?>>Well, I sense that there
are some complications in practice. So, I guess that if we have
to go with a fragment and react we will face some
complications in the future, right?>>With the react code?>>So yet, it’s no longer in control
of the whole rendering process, right?>>Yeah, it entirely runs on the client, whereas web fragments
are rendered more on the server. You could render a page on the server
that when it loads on the client, makes use of react components. But, there’s no reason why you couldn’t
use react components, or anything else. J-quary, regular components,
if that’s how you want to do it. Withing a fragment as well.>>Alright, then I think I’ll wait and
see how it works.>>Cool.
>>Thank you.>>Right there.>>What are the immediate plans
around optimization for mobile. From what I could understand from
the presentation was, that okay, bringing an asset management system
will save some save you some time of, from the delivery of starting a search. But there is an inherent
slowness in all the views.>>That needs some native development
of the mobile front end to deal with. So, any immediate plans
to reduce the pain? Because on a browser,
it’s fine if you look at something for eight, nine seconds and it doesn’t load,
because there’s so much real estate. You can, switch windows,
you can go to some other window.>>Absolutely.>>But something.
But on a mobile you are so focused, that even waiting for three,
four seconds and the attention is lost.>>Yep, totally. So, that’s a great question. The way it works now is we’ve got
this huge CSS bundle and JS bundle, and that’s site wide or
platform wide- IDA wide. We want to bundle these
things more intelligently. So that when you request a page, you only get the JavaScript
that that page cares about.>>Or the CSS that that page cares about. With the common stuff,
abstract it out into another bundle. So that would then get cached. The common shared stuff throughout
all the pages would get cached, and specific page specific
code bundled separately. We haven’t done enough with that yet
within the jango asset pipeline. Webpact just landed in LMS in studio, I think within the past month. So, there’s still definitely
some work to do there, but it comes with a lot of great Plugin’s
that enable, use cases like this. So yeah, we want to cut down that
file size as much as possible. Yep.
>>Yeah, so you talked about how react has this double-edged sword of
interoperability with existing components, and the existing technologies
What’s the plan for actually getting rid of those existing
legacy technologies in the code base?>>[LAUGH] That’s a really good question. So the plan is, future development
will take place with react. I believe we have a react roll
out plan within confluence. I will damp that into Slack as well. The plan is to deprecate Bootstrap and
encourage React by July of this year, not deprecate bootstrap, but
move to React by July, deprecate bootstrap in previous technologies
by the end of 2017. And then, in the future, anytime someone touches like an old view. The encouragement is to
re-implement it using React. Now, that does add a bit
of developer overhead. Sometimes it’s just easier to just
patch one line out of Bootstrap view. But, the hope is that React,
React is really easy to use. If you’ve used it before,
it’s really easy to ramp up with. And we’re hoping that as well, with
the addition the reusable components it will make it a lot easier for developers
to go in and do the right thing.>>Time for one more question.>>Okay, right there. Thank you. I love the emojis. And also, just a big shout out to Tina. I think that’s a fantastic step forward. So just thinking a little
about accessibility, in sort of the grander real estate sense. What sort of browsers
are you looking to support? And fun joke, I still get asked for. [LAUGH]
>>We officially support the last two versions of every browser as well as IE11. So, last two plus IE 11 is our
official support right now.>>[INAUDIBLE]
>>We don’t have a subset of supported
mobile browsers right now. Probably, if we did come up with
one it would be based on Usage, statistics for our platform. But, again,
we want to hear from you about that. What browsers do we
absolutely need to support. Cause there’s as many browsers
almost as there are phones. [INAUDIBLE]>>Mm-hm is that a public resource?>>Yeah.>>All right.>>[INAUDIBLE]
>>Open edge.>>[INAUDIBLE]
>>Yeah, we’ll have to check that out.>>[INAUDIBLE]
>>Yeah well we’re working on it. All right, we good?>>Yeah so. I think just announce the BOS again
>>Yeah.>>The BOF I’m sorry.>>BOF 9 am tomorrow
downstairs breakfast area. Come find us, come chat with us,
we wanna answer your questions. Thank you so much.>>[APPLAUSE]

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *