[jeroenhd]

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 running super basic browsers? Will screen readers support all elements created by the Javascript framework?

I have seen too many sites collapse into an empty white page because whatever javascript they were running couldn't access a resource and the shitty JS framework just stopped, leaving me with an empty page. I hope the Wikimedia foundation can stay clear of unnecessary javascript development as long as possible.

[joshwcomeau]

A lot of the questions you're rhetorically asking are answered in the RFC you're commenting on.

Specifically, they had real problems with their current system, which they documented here: https://phabricator.wikimedia.org/T225453. Then they explored the available options in the ecosystem and came up with the one they thought would best fit their needs.

If you're gonna be critical, at least take the time to understand what they're doing and why.

[jeroenhd]

I understand them wanting to rewrite their old javascript code. After all, in the frontend world, the toolset currently used is ancient.

However, almost all of my experience with any Javascript framework describing itself as "modern" is a white page with no content of {{ placeholder }}a everywhere text should be.

Several comments on the RFC already seem to state the intention to slowly change Wikimedia into a more "interactive" experience. What I fear is that a framework such as Vue will make it _too_ easy to make everything flashy and modern and suddenly you end up with another SPA where a website should be.

The RFC talks about this shortly and mentions server side rendering but not much about what should be rendered server side and what shouldn't. The overview of problems seems more like a lack of structure than a need for a heavy JS library.

I am very cautious of anyone claiming they need JS for a web page. Applications such as the editors and turning into javascript programs is not something I worry about, but several annoyances new Wikipedia features have already brought me (especially on mobile) make me cautious of any suggestion to add even more javascript.

[spyckie2]

At a certain level of complexity of web application, it becomes impossible to not have javascript without compromising on your user experience.

I'd argue the opposite - I'm extremely cautious of anyone claiming they don't need JS. People can very easily forget the terrible, terrible experience that a full page refresh brings, and having only full page refreshes as the option greatly limits the kinds of experiences you can give users.

[t0astbread]

The proposal stresses the need for Server-Side Rendering so I suppose they're thinking about this.

[otterlicious]

Yeah it's very clear that they still plan to have the website work without JavaScript.

In the longer term, adding support for a frontend build step in deployment and for server-side rendering (SSR) of UI components are two tasks that would be particularly useful here...

Until such features are in place, use of Vue.js would be limited to cases where server-rendered elements can be progressively enhanced within the user’s browser.

[marcus_holmes]

No idea why you were downvoted - this is the answer to that question

[hombre_fatal]

> but Wikimedia is a website and not a web application

Check out the /edit mode for any page. It's already a non-trivial JS app.

[est31]

I'm ok with their interactive editor being written in SPA style. Most of Wikipedia's billions of users aren't editing pages though. For them, WP should focus on rendering speed which means lowest complexity possible, which means keeping the serialized DOM technology.

[bawolff]

The edit view that most power users use is definitely not an spa.

There are multiple "editors" in use on wikipedia et al. Visual editor and mobile edior are more SPA-ish, however the old fashioned <textarea> full of code, editor is still very popular among users.

Disclaimer: work for wikimedia, but not on stuff related to this. My opinions are my own.

[mch82]

Another interesting note is that Parsoid, the nodejs service that turns wikitext into the Visual Editor, is being ported from js to PHP.

[folmar]

The texarea is also currently the default, at least on English edition.

[k__]

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?

[ivanfon]

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.

[marcus_holmes]

One of their criteria is widespread adoption. Svelte isn't there yet. One day it probably will be, but today is not that day.

[slantyyz]

I think that's a chicken egg thing. If Wikimedia adopted it, adoption rates would skyrocket.

[rk06]

Really, what makes you believe so?

IMO, to drive adoption rates, you would need dev evangelists

While the RFC states that they are taking cautious route here.

They also mention that they are not making an SPA which all the cool kids look up to.

[slantyyz]

The best type of evangelism is adoption by one of the most heavily used sites in the world.

[rk06]

nope, the best type of evangelism is evangelism. adoption by most heavily used sites jsut proves technical feasibility.

Unless the devs of "most heavily used sites" evangelize, it makes no matter which sites use svelte. As a matter of fact, Vue's adoption increased after Taylor Otlwell (Laravel's creator) and other started _telling_ people that they are planning to use Vue, instead of react.

Wide range adoption followed next.

[aww_dang]

>I have seen too many sites collapse into an empty white page because whatever javascript they were running couldn't access a resource and the shitty JS framework just stopped, leaving me with an empty page.

It is even worse when these pages are basically images and text. SPAs have their place and people can develop them as they wish, but I fail to understand why these frameworks have become the go to solution for every page.

[nwsm]

>Will Vue and React work on 2G cell phones running super basic browsers?

Yes

>Will screen readers support all elements created by the Javascript framework?

Yes

[untog]

React won’t work well on 2G cell phones with slow CPUs. It’s a giant library both to download and parse and most of it is entirely unnecessary.