Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC: Adopt a modern JavaScript framework for use with MediaWiki

phabricator.wikimedia.org

Post reply on HN
Print view View original

181–190 of 293 posts

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#181

Post by anchpop »

untog wrote: post #166
HumblyTossed wrote: post #158

> The need to evolve our platform is very evident when it comes to how we design, develop, and deliver experiences to users in the browser. > Requirements: > The framework allows UI elements to be defined in a declarative way > UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default > The framework is open-source, widely used, and has a thri…

To be blunt, this is an extremely common thing in web development and it makes me very sad. But whenever I raise it I’m rebuffed with the vague argument that “developer productivity = more features = better user experience”. Which sounds great in theory but a crappy experience is a crappy experience no matter how many features you put on top. Go look at the lighthouse scores for pages that use React + Redux + whateve…

> Go look at the lighthouse scores for pages that use React + Redux + whatever + blah blah and tell me the user experience isn’t sub par

I looked at the Lighthouse score for my blog (written in React and all that blah blah). It got a 100 for performance, 100 for accessibility, 100 for best practices, and 100 for SEO. So I am happy to tell you the user experience is not sub par.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#182

Post by untog »

anchpop wrote: post #181
untog wrote: post #166

Earlier quoted context omitted.

To be blunt, this is an extremely common thing in web development and it makes me very sad. But whenever I raise it I’m rebuffed with the vague argument that “developer productivity = more features = better user experience”. Which sounds great in theory but a crappy experience is a crappy experience no matter how many features you put on top. Go look at the lighthouse scores for pages that use React + Redux + whateve…

> Go look at the lighthouse scores for pages that use React + Redux + whatever + blah blah and tell me the user experience isn’t sub par I looked at the Lighthouse score for my blog (written in React and all that blah blah). It got a 100 for performance, 100 for accessibility, 100 for best practices, and 100 for SEO. So I am happy to tell you the user experience is not sub par.

Serious question: why are you using React for a blog? What interactive elements are there on the page that require it?

EDIT: Saw the link in your profile. I see lower numbers than you, though not by much. But I also see 2.6 seconds time to interactive with 3.1 seconds of main thread work.

Broadly speaking, that's fine for your blog. But if it was a site that you expect to add more and more features to over time that number is only going to go up. 3.1 seconds of main thread work to render an entirely static page isn't good. It's acceptable at best.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#183

Post by TekMol »

aliveupstairs wrote: post #94
TekMol wrote: post #44

Can someone give a quick code example for the follwing? The framework allows UI elements to be defined in a declarative way How can you use Vue so that what you do is more declarative then when using a template engine like handlebars?

I believe the templating is what's declarative, here. For instance, in Vue you can insert logic such as for loops, conditionals, event listeners, two-way data binding and so on right in the template with directives (HTML attributes). Instead of an imperative JavaScript for loop.

It is the same with handlebars. You put your todo element between {{#.}} and {{/.}} which means "do this for all elements" and then pass only the "Todos" array to the template. No loop in Javascript either.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#184

Post by azangru »

ddevault wrote: post #162
azangru wrote: post #152

Earlier quoted context omitted.

> A lot of new technology doesn't work in older browsers But given that, how do we move forward? We shouldn't be stuck in the past forever. We shouldn't probably even be stuck in 2013, when IE11 was released. If their site requires heavy client-side code, and if they want to build it in a fast and reliable way, they have almost no other choice but to think of frameworks.

Wikipedia is just hyperlinked documents. The WWW has been suited for this from the start. Not everything needs to be new and shiny forever.

> Wikipedia is just hyperlinked documents.

Wikipedia at the very least has the editor for all those documents.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#185

Post by BiteCode_dev »

EvanYou wrote: post #169

Team lead of Vue.js here. Clarifying a few points being raised in this thread: - This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open). - Wikime…

This is IMO one of the killer features of vue.

Sure, you can plug react components in a progressive way, but you still have to move the HTML into the JS file. And you certainly won't ship the babel behemoth to the client so, no JSX.

With Vue, you have a friendly migration path, with a style close to angular 1, if you need.

It's also awesome for prototyping or making quick and dirty projects.

Evan, every time I use Vue I can see how you pondered seriously those things. The docs are amazing. The API is full of little details that show you care (I smile every time I see you can do '.prevent" - "oh right, they though of that!").

It's not just a great product. It makes you feel the authors are your friends.

Thank you.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#186

Post by spyckie2 »

ddevault wrote: post #128

This thread reads to me like the engineers went into it already knowing they wanted Vue.js, and retroactively doing the necessary mental gymnastics to come up with a rationale. A better justification would have started with "these are our pain points, and this is our evaluation of how these options address our problems." Instead, it's full of weird things like this: >Better support for usage without Webpack/Babel/fro…

no offense but it sounds like you're doing a kangaroo court evaluation of their evaluation by making assumptions to what they did and didn't consider and not looking deeper into the context of the RFC.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#187

Post by est31 »

EvanYou wrote: post #169

Team lead of Vue.js here. Clarifying a few points being raised in this thread: - This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open). - Wikime…

As long as there is no accepted non-vue replacement for the server side rendering technology, one has to assume that WP will replace php based rendering with Vue templates on a large scale, even for the static content. However, Vue templates require usage of node.js. I couldn't find any standalone serverside vue template parser/renderer written in something like C++, Rust or Go. So if they adopt Vue, they'd still be locked into a project ran by a single company, namely v8, which they listed as one of the things they wanted to avoid.

Also, why does the hn clone that claims to be statically rendered using vue still display spinning icons during page load [1]? I'm asking because it's not just any vue js app, but one mentioned in the official server side rendering docs of vue [2]. Edit: doing view-source on the hn clone shows that it's really just loading the comments from the network. Not sure what definition of server side rendering the docs are working with, but that demo doesn't give confidence.

Will I get spinning icons on wikipedia pages in the future? Will it be like discourse where the scroll bar is hijacked?

[1]: https://vue-hn.herokuapp.com/item/22625556

[2]: https://ssr.vuejs.org/

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#188

Post by ivanfon »

k__ wrote: post #93
jeroenhd wrote: post #87

What does this mean for Wikimedia? Will they extend file uploaders and such with some fancier animations and code or will Wikimedia turn into another one of these God-awful Javascript applications running an HTML renderer inside the browser's HTML renderer? Don't get me wrong, Javascript web applications have their place, but Wikimedia is a website and not a web application. Will Vue and React work on 2G cell phones…

I'm a React fanboy, but I have to admit, the Svelte performance and code size is impressive. Maybe that would be a feasible way to get a modern developer experience without the bloat?

Svelte is my favourite framework right now (it's really reignited my love for web development after using React for a long time), but unfortunately one of their criteria/use cases was "build step as well as no build-step", which doesn't work since Svelte is a compiler.

While I thought dropping the "no build-step" requirement wouldn't be a big deal nowadays, they later say:

> We should still explore introducing a full build step in the future (including full support for module bundling, ES6+ transpilation via Babel, etc), but this is a non-trivial change to the architecture of MediaWiki.

I can see why going with something that doesn't need a build-step could be appealing.

There's also the other factor (mentioned below) about community. If MediaWiki chose Svelte, they would definitely have to invest a lot into the framework and it's community, and I'm not sure if that's something they want to or are capable of doing. The biggest pain point with Svelte right now (at least for me) is the tooling, it's real bad.

This is the only mention about Svelte:

> Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever).

I'd be interested in seeing a bit more discussion about it.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#189

Post by abbe98 »

EvanYou wrote: post #169

Team lead of Vue.js here. Clarifying a few points being raised in this thread: - This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open). - Wikime…

Exactly this. Currently MediaWiki and many of its extensions have its interactive parts (editor/maps, etc) written in jQuery and the in-house developed framework OOUI. These are the pieces which might slowly be replaced by Vue.

Hopefully this will also make it easier for new contributors to get started with MediaWiki development.

Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki

#190

Post by spyckie2 »

est31 wrote: post #187
EvanYou wrote: post #169

Team lead of Vue.js here. Clarifying a few points being raised in this thread: - This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open). - Wikime…

As long as there is no accepted non-vue replacement for the server side rendering technology, one has to assume that WP will replace php based rendering with Vue templates on a large scale, even for the static content. However, Vue templates require usage of node.js. I couldn't find any standalone serverside vue template parser/renderer written in something like C++, Rust or Go. So if they adopt Vue, they'd still be…

I don't get the impression that WP will replace php templating. That just doesn't make any sense to do. First the code is already written (no need to rewrite), probably well tested, php is extremely fast already, and I'd imagine their php development does not have dated tooling that makes development painful. There's little to no reason to switch php code out.

However, it does make sense to replace JQuery snippets or custom in house dated JS frameworks, especially if they lack modern tooling surrounding it like pipelines, code splitting, etc. In that sense, vue and vue's paradigm is a perfect fit because of it's ability to play well with the primary goals at any level of JS-ification, from simple JS actions to full SPA.

Post reply on HN