22:03:00 <KateChapman> #startmeeting  RFC: Adopt a modern JavaScript framework for use with MediaWiki
22:03:00 <wm-labs-meetbot> Meeting started Wed Feb 19 22:03:00 2020 UTC and is due to finish in 60 minutes.  The chair is KateChapman. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:03:00 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:03:00 <wm-labs-meetbot> The meeting name has been set to 'rfc__adopt_a_modern_javascript_framework_for_use_with_mediawiki'
22:03:19 <KateChapman> #link https://phabricator.wikimedia.org/T241180
22:03:59 <KateChapman> okay, let's get started. I wanted to state we'd like to focus on missing requirements in this RFC and any concerns about the current proposed solution
22:04:41 <KateChapman> Those who have doing the initial work. Any discoveries or other information you'd like to share from that?
22:05:13 <RoanKattouw> I can talk a bit about what EricGardner and I did the last two weeks
22:05:15 <KateChapman> (sorry just realized I haven't done this in a long time before we do that. Who is here for the meeting?)
22:05:26 <KateChapman> if you can give me a wave o/
22:05:28 <niedzielski> o/
22:05:30 <EricGardner> o/
22:05:50 <RoanKattouw> o/
22:05:54 <lucaswerkmeister> o/
22:06:08 <Nikerabbit> o
22:06:24 <KateChapman> okay RoanKattouw take it away!
22:06:49 <RoanKattouw> So I started with some simple things that I won't talk much about, including:
22:07:03 <RoanKattouw> Adding the vue.js library to our repo as an external resource: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/569666
22:07:16 <RoanKattouw> (thanks to James_F for cleaning up that commit and doing it properly)
22:08:20 <RoanKattouw> Adding linting for .vue files: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/569677
22:08:48 <RoanKattouw> That both covers linting JS and CSS/LESS inside .vue files, but also linting the HTML templates in .vue files using Vue-specific lint rules (through an eslint plugin)
22:09:10 <RoanKattouw> Adding a simple Vue plugin to bridge to the MW i18n system: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/570500
22:09:59 <RoanKattouw> All those things are already merged, and they're relatively straightforward. They're not 100% done, we'll probably want to tweak the lint rules a bit over time, and we might want to add more features to the i18n plugin, but there are no huge unanswered questions there or anything
22:10:24 <RoanKattouw> The biggest thing I worked on is this patch (not yet merged) that makes .vue files a first-class citizen in ResourceLoader: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/569692
22:11:04 <RoanKattouw> It allows you to include .vue files in package modules, parses them in PHP, and transforms them to JS+CSS
22:12:08 <RoanKattouw> As discussed on the task, this uses the client-side compilation strategy: instead of compiling the template to JS code on the server (which requires running the vue-cli tools), it just encodes the template as a string and sticks it in module.exports.template, which Vue then compiles/interprets on the client
22:12:43 <RoanKattouw> EricGardner made a demonstration extension that shows off these features: https://github.com/egardner/mediawiki-extensions-VueTest
22:13:01 <RoanKattouw> His extension also uses jest to run unit tests on Vue components
22:14:13 <RoanKattouw> I did some limited performance testing, and found that for a language search widget with 400+ languages, Vue was about 10x faster to initialize than OOUI (~80ms vs ~900ms, with 444 vs 588 languages), with comparable performance once initialized
22:15:06 <RoanKattouw> I haven't yet done a proper apples-to-apples comparison (with the same number of languages, and a more complete feature set) of this yet, and I will soon, but the difference is so large that I think we can say that Vue's performance appears to be acceptable and better than OOUI's for this (somewhat pathological) case
22:15:11 <milimetric> including compilation time or did you factor that out?
22:15:25 <RoanKattouw> That includes compilation time, but there wasn't a whole lot to compile
22:15:51 <KateChapman> EricGardner: anything you want to add?
22:16:21 <EricGardner> That extension repo also contains a lot of documentation that may be useful for folks getting started with Vue, and some additional config for linters, test runners, etc that I found useful
22:16:39 <KateChapman> #info EricGardner made a demonstration extension that shows off these features: https://github.com/egardner/mediawiki-extensions-VueTest
22:16:50 <EricGardner> Also, one important limitation of the approach Roan is describing is that JS still needs to be written in ES5
22:16:51 <KateChapman> #info 2:16 PM <EricGardner> That extension repo also contains a lot of documentation that may be useful for folks getting started with Vue, and some additional config for linters, test runners, etc that I found useful
22:17:04 <KateChapman> #info 2:16 PM <EricGardner> Also, one important limitation of the approach Roan is describing is that JS still needs to be written in ES5
22:17:13 <EricGardner> Vue SFCs do support things like LESS compiliation (not SASS though), CSS Janus, etc
22:17:30 <EricGardner> So they basically become a first-class citizen in the mediawiki environment
22:17:34 <KateChapman> btw if you want something in the minutes use the info tag before it. I'm also happy to extract things out by copy/pasting
22:17:47 <RoanKattouw> Yes, that's right. RL support for .vue files integrates with everything that you would expect normal JS and CSS/LESS to be able to do in MW
22:18:14 <EricGardner> For things that rely on global mw objects, Vue plugins are a good solution. We have a simple one for mw.message
22:18:16 <RoanKattouw> So that means you can use LESS variables and imports for example, RTL flipping through CSSJanus, /* @embed */, etc
22:18:32 <EricGardner> my example extension also has a basic example of how you could handle mw.Api the same way
22:18:32 <RoanKattouw> But it also means that you can't use things that aren't otherwise supported in RL, such as ES6
22:19:17 <RoanKattouw> I would like to experiment with integrating Babel with RL some time, but I didn't think that was important enough to focus on for this quick 2-week effort
22:19:33 <EricGardner> Agreed. That's a bigger task for the future
22:20:22 <Nikerabbit> Are there other things besides ES6 that aren't supported yet, but maybe in the future?
22:20:30 <EricGardner> scoped styles
22:20:41 <EricGardner> and server-side rendering of components
22:21:09 <EricGardner> a few other small things – apparently the shorthands for some directives, like @ for v-on and : for v-bind need webpack
22:21:27 <EricGardner> the linter rules in the example repo enforce "longform" usage of the directives for that reason
22:21:44 <EricGardner> But I think that once Roan's patches are merged, we will have good support for using most of Vue's features in a progressive-enhancement, client-side rendered way
22:21:46 <milimetric> aw that’s a shame, @ and : make code much more readable
22:21:47 <KateChapman> #info 2:20 PM <Nikerabbit> Are there other things besides ES6 that aren't supported yet, but maybe in the future?
22:21:53 <lucaswerkmeister> huh, that sounds odd
22:22:16 <EricGardner> I could be wrong. I assumed the vue template compiler would handle those, but I couldn't get them to work
22:23:07 <RoanKattouw> It's possible that VueComponentParser.php mangles them somehow. We'll have to look into it
22:23:26 <niedzielski> Seems like something that could be explored more in the future.
22:23:28 <RoanKattouw> I also have a TODO for seeing if functional templates are supported with client-side compilation, the documentation is unclear on this front
22:23:29 <EricGardner> Also, there are some limitations about how RL processes package files that make some in-browser debugging kind of tricky. This is not vue-specific
22:23:41 <milimetric> I was curious if you’d looked at Vue 3’s new approach using composition
22:24:26 <EricGardner> millimetric: I've been following this but have never used it. I think we can support Vue3 once it is finalized, and see no reason why these features would not work
22:24:47 <milimetric> https://vue-composition-api-rfc.netlify.com/
22:24:57 <EricGardner> supposedly Vue3 will also ship a lot of improvements to the template compiler
22:25:22 <EricGardner> this might improve performance for the kind of usage we're considering (though it already seems pretty good so far)
22:25:32 <milimetric> it might imply different infrastructure and integration with RL, but haven’t thought it through yet
22:26:07 <EricGardner> It seems like the Vue community has been saying the composition API will be there for more complex use cases, but templates should be preferred for most cases
22:26:37 <EricGardner> Similar to writing your own render functions in Vue
22:28:40 <EricGardner> Regarding the composition API, I'm hoping that by relying on Vue's own template compiler to do most of the work, integration with RL won't complicate things too much.
22:28:59 <KateChapman> anyone have any questions?
22:29:01 <milimetric> hm, my intuition is that composition would work well for core/standard extensions and templates for more stand-alone extensions and folks getting started with vue.  I saw a very similar split in the knockout community
22:29:02 <KateChapman> (so far)
22:30:06 <Nikerabbit> Is vue going to be available for gadgets and user scripts? I'd assume the module is loadable, but one couldn't create vue files in the wiki?
22:31:03 <Krinkle> Indeed. The programmatic API will be available initially.
22:31:09 <Krinkle> But that means compilation shortcuts are not.
22:31:44 <Krinkle> I don't know what Vue's normal API looks like, e.g. what <template> compiles to, is that sometimes used in demos or has examples to be human readable, or is that esoteric/internal
22:32:06 <Krinkle> I guess custom render functions would make use of that so presumably public and not too bad.
22:32:13 <EricGardner> Vue compiles templates into a render function, yes
22:32:13 <RoanKattouw> So the normal API is Vue.component( 'component-name', { .... } );
22:32:36 <RoanKattouw> Where { ... } is the module.exports that you see in the <script> tag of the .vue file, plus { template: '<div>....</div>' }
22:32:43 <EricGardner> Really the "normal" API is probably just writing SFCs that import their children, but you have a few different ways to do it
22:32:50 <Krinkle> Would be good to have an example of that on-wiki, both for gadgets, but also for casees where in core/extesion you might need to bypass <template> for perf or other reasons
22:33:24 <RoanKattouw> So the only magic that SFC processing does is stringifying the contents of the <template> tag and putting it in module.exports.template
22:33:25 <Krinkle> EricGardner: do I understand correctly that using  Vue.component() is what it means to write a custom render function?
22:33:51 <niedzielski> I think we should allow the internal solution time to mature a little before encouraging broader usage and best practice that may otherwise be challenging to migrate.
22:33:52 <RoanKattouw> Krinkle: No, a custom render function would be using { render: function ( h ) { .... } } instead of { template: '<div>...</div>' }
22:33:55 <EricGardner> not exactly. When you create a Vue component (or a basic instance that does not have sub components), you can provide template and/or render options
22:34:08 <EricGardner> a render function will supersede a string template
22:34:12 <Nikerabbit> SFC in this context means single file component, right?
22:34:16 <RoanKattouw> Yes
22:34:18 <EricGardner> yes
22:34:29 <EricGardner> There is pretty good documentation on render functions here: https://vuejs.org/v2/guide/render-function.html
22:34:44 <Krinkle> Right, so calling  Vue.component(), as a gadget woudl need to, can still leverage the template syntax.
22:34:48 <RoanKattouw> Yes exactly
22:34:53 <Krinkle> it just makes it more obvious that it is compiled client-side
22:35:02 <EricGardner> Since we are shipping the template compiler in our Vue module, developers will have a lot of options. they can provide a string template inline, use an existing dom element, write a render functions themselves, etc
22:35:02 <RoanKattouw> The Webpack build step that some people have said they want to use does the compilation server-side, and outputs a render function
22:35:36 <EricGardner> This is useful re: different ways to define templates: https://vuejsdevelopers.com/2017/03/24/vue-js-component-templates/
22:35:47 <lucaswerkmeister> and a gadget would have to write the template as 'foo\n' + 'bar\n' + ..., not using `backticks` syntax, because ES5?
22:37:03 <EricGardner> they could provide a <script type="text/x-template"> tag on a page and reference it with an ID, if they are writing a HMTL page
22:37:22 <EricGardner> I don't know a lot about what gadget authors have to work with. Can they define different types of files as part of the gadget?
22:38:18 <EricGardner> ideally they could write single file components with a .vue extension themselves
22:38:27 <Krinkle> of that, they'd have to either use createElement() or use a string literal for template indeed.
22:40:16 <Nikerabbit> I was mostly thinking how hard it will be to update vue in the future, we probably don't need to discuss vue support for gadgets/user scripts deeply yet
22:41:19 <EricGardner> my understanding is that Vue 3 has very few breaking changes and should be a pretty painless upgrade. The basic component APIs are the same, with some new additions like context API
22:41:37 <Krinkle> Yep. This is inherit to any large scale entitity with a framework-based frontend. Anything loaded on a single page needs to upgrade in lockstep. Which means you won't get stuck so long as upstream follows best practices of not making breaking changes other than removal of deprecated functionality so that gradual migration is possible.
22:41:52 <Krinkle> This is followed by jQuery, OOUI, etc. I don't know if Vue has formerly committed to that.
22:41:54 <milimetric> I agree with niedzielski that a well-considered style guide for gadget authors would be wise, perhaps looking at how the migration of gadgets to OOUI could’ve gone better
22:42:02 <RoanKattouw> I haven't explored what it would require to support .vue files directly from gadgets, but it's probably feasible
22:42:29 <EricGardner> I think that a Wikimedia-Vue styleguide should be one of our next priorities here
22:42:53 <EricGardner> since we'll be using Vue in a way that is supported but different (es5, custom module system, etc) from most of the rest of the community
22:43:03 <lucaswerkmeister> can’t different parts of the page load different versions of the framework if they want? e. g. vue2 and vue3 RL modules
22:43:12 <lucaswerkmeister> (as long as neither of them pollutes the global scope)
22:43:28 <Krinkle> #info It is required for our scale and range (core/extensions, multiple orgs/teams, community gadgets) that the framework strictly follow a no-breaking-change rule other than removal of deprecated functionality after replacements are added in a previous release.
22:43:46 <Nikerabbit> that would imply versioning at module name level, right?
22:43:46 <milimetric> is that how we plan on using vue for the medium-term?  Or are we going to tackle the server-side compile problem sooner than later?
22:44:35 <RoanKattouw> lucaswerkmeister: Yes, it looks like that will probably work
22:44:51 <Krinkle> in terms of comparison to OOUI, Vue is taking the place of plain JS and/or jQuery. OOUI as being our component library and style guide indeed needs to be ported and offered in some form or another.
22:44:54 <KateChapman> **** 15 minutes left ****
22:45:01 <lucaswerkmeister> (not something we *want* to have for a long time, of course, loading twice as much code etc)
22:45:29 <KateChapman> milimetric: we haven't gotten into the server side part yet. What does medium-term mean to you?
22:46:17 <Krinkle> milimetric: adoption beyond late/client-side interactions is blocked on a server-side which is part of FAWG's direction but indeed getting the frontend puzzle solved first is the first step.
22:47:04 <milimetric> not server side rendering, but something like a build step to prevent having to ship the compiler to the client and allow using vue for default-rendered UI, was just asking if we’ve got concrete plans to move in that direction or we’re stuck for the reasons that Roan has articulated before (down sides of checking in built artifacts, etc)
22:47:28 <milimetric> got it, thx
22:47:34 <EricGardner> One reason why Vue seemed like the best choice here is that we can start using the new framework now, sans build-step, with a small number of limitations
22:47:46 <milimetric> right, makes sense
22:47:54 <Krinkle> but yeah, I hope that in terms of perf cost that we won't be shipping the compiler for long. as-is that would likely regress performance compared to OOUI.
22:48:01 <KateChapman> I'm trying to raise the importance of the build step to understand the blockers and how we can mitigate them
22:48:27 <RoanKattouw> There's some (older) discussion about build step stuff at T199004
22:48:27 <stashbot> T199004: RFC: Add a frontend build step to skins/extensions to our deploy process - https://phabricator.wikimedia.org/T199004
22:48:46 <milimetric> I would think it’d be good to wait until you do tackle the build step problem before making too final of a style guide and other migration/plans around vue
22:49:23 <RoanKattouw> It's true that server-side complilation of templates will clearly be better for performance, but I'm not sure that it would "likely regress performance compared to OOUI" as Krinkle says
22:49:40 <EricGardner> I guess part of it depends on how long it will take to get a build step in place. If it's 1+ years, we may need something in the interim to guide folks
22:49:51 <RoanKattouw> At least in terms of script execution time that wasn't the case for the example that I tested (which was a pathological case though)
22:50:12 <Krinkle> My expectation is that in terms of bundle size, OOUI is much lower level for a given component than Vue + compiler + component file. so that'll be smaller.
22:50:13 <RoanKattouw> In terms of bandwidth cost it could be
22:50:45 <KateChapman> thanks everyone for the productive discussion. Any last minute questions before we wrap up before the end of the hour? Especially related to the current scope of the RFC?
22:51:05 <EricGardner> do we need to "vote" on anything here? is that how this usually works?
22:52:03 <KateChapman> no it is more input that TechCom will consider to put the RFC on last call and then approve it
22:52:47 <milimetric> it feels like a lot of the folks active on the RFC phab task weren’t here, makes it harder to move forward
22:53:36 <KateChapman> milimetric: I think the scope is we want to continue our experimentation and work with Vue. Comments such as "why not React" would really have to show why our current implementation path won't work at all
22:53:51 <KateChapman> do you think there are people with concerns that we aren't addressing that are different than that?
22:55:10 <EricGardner> I think the other main concern was around performance
22:55:22 <milimetric> no, but I may be biased in ways that’s missing their point(s).  I would be ok with moving to last call, and seeing what the feedback on the task looks like after that
22:55:36 <niedzielski> I agree with KateChapman. I think there are lots of details remaining to be explored but those will come with experimentation which is a part of FAWG's plan. I'm really excited to see those explorations continue.
22:56:08 <KateChapman> EricGardner: without server side rendering or for other reasons?
22:57:00 <milimetric> I think the other main point raised was Tim’s concern that developing extensions in multiple repos would be more cumbersome, but again that really depends on the build step discussion and is a bit out of scope for this phase
22:57:16 <EricGardner> I think there are always perf concerns when we talk about introducing more JS into our ecosystem. The lack of server-rendering introduces a few additional concerns (shipping the compiler, etc) but personally I don't think those are very serious.
22:58:09 <EricGardner> The other thing is that we'll need to try to port over important bits of OOUI (esp. concerning accessibility) – the more we utilize JS in our UI, the more of this work we need to do manually. But these aren't reasons to not move forward in my mind
22:59:25 <KateChapman> okay so we are going to need to wrap up. I think we have enough info to discuss last call at the next TechCom meeting and as milimetric mentioned see what other discussion happens before approving
23:01:17 <KateChapman> thanks for the discussion everyone
23:01:26 <KateChapman> #endmeeting