Earlier quoted context omitted.
Page Previews is a great example of leveraging "web app" that solves many problems at once: - quickly inform on a topic without clicking through (lower latency) - increase scanability (hence readability) - decrease expensive whole page loads - eliminate need to open many tabs https://www.mediawiki.org/wiki/Page_Previews
Page Previews, specifically Hovercards can be implemented in a very simple way with plain JS [^1] and is clearly an enhancement - everything works just fine if hovercards don't load. But most features on Wikipedia aren't like that, and would be really hurt if you had to a JS bundle or otherwise deal with the usual bloated webapp nonsense. Wikipedia primarily needs to load quickly and be semantic with preferably simpl…
RFC: Adopt a modern JavaScript framework for use with MediaWiki
191–200 of 293 posts
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#192Earlier quoted context omitted.
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 understan…
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 "i…
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.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#193This 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…
Points 2 and 3 I agree with though. Vue is more complete than react the library and the Vue stack has had less churn.
I see your point about potentially leaving behind very old devices. I don't know Wikipedia's compatibility stance. It may not be fair to say it's overlooked as the decision within this RFC is only about modern JS frameworks. The decision to adopt could take that into consideration
I have to disagree about the Kangaroo court accusation, that seems unfair
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#194Earlier quoted context omitted.
Why? Typescript just compiles down to JS, and type definitions are used IDEs so they still help when writing JS. How does removing typescript help you?
> How does removing typescript help you? https://github.com/microsoft/TypeScript/issues Please count the number of open bugs JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness. Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing…
It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#195Earlier quoted context omitted.
These directives take less than a day to learn. 99% of the time it's far easier to write HTML tags with data and event binding directives than hack around with JSX and passing all those props. You can also use JSX with Vue if you want. Just add a render() function to the component. That's what happens anyway when you use a normal template, the Vue compiler turns it into a render function the same way JSX is compiled…
and using promises with vue is nightmare.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#196Earlier quoted context omitted.
It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page. With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.…
> In React, using JSX means you can create components and mount them on top of the existing elements on the page. I am not sure this analysis is entirely correct. In case of server-side-rendered React pages, React takes the html that arrives from the server and makes it interactive ("hydrates" it, according to the common React community parlance), provided that that DOM generated from that HTML corresponds to the vir…
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#197Earlier quoted context omitted.
It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page. With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.…
I think you're talking about universal or isomorphic rendering, but each of these allow for it.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#198I'm not a frontend dev, in fact I know little about the current "cool" JS framework. That being said, I donate to Wikipedia/Wikimedia every year and I will reconsider if this goes through. This is exactly the kind of bloat that no one needs. The Wikimedia sites should be seen as a public library where accessibility is the most important thing. Creating a web app with apparently no measurably good impact is pure idioc…
> That being said, I donate to Wikipedia/Wikimedia every year and I will reconsider if this goes through. This is exactly the kind of bloat that no one needs.
The latter seems an overreaction given the former.
Re: RFC: Adopt a modern JavaScript framework for use with MediaWiki
#199This is a bad idea. If you look at the list of advantages to doing this only 1 is user-centric (things would be reactive). The rest are all related to how it makes development easier. When you choose a developer-centric workflow your users will suffer. You only have to look at the numerous server to SPA conversions to see how consistently bad of a choice this tends to be; Reddit is a big and obvious example. They cou…
Who said they are going to make the entire page SPA? They picked Vue specifically because Vue allows them to progressively enhance parts of the page with interactivity without going full SPA (AND without hard reliance on a build step).
Every framework allows only rendering to part of the screen, but all of them also allow and encourage the building of SPAs, including Vue. Building SPAs is the overwhelming norm when using any of these frameworks.
If they are bucking the trend here, that's great, I encouraged using a declarative library for the truly dynamic parts in my above post. However this post contains a lot of red flags such as the term "Server-Side Rendering" that are unnecessary if using it not for a SPA. So it's worth pointing out the risk.