Live data from Hacker News

RFC: Adopt a modern JavaScript framework for use with MediaWiki

phabricator.wikimedia.org

191–200 of 293 posts

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

#191

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…

Each such feature individually can be implemented in a very simple way with vanilla JS. All such features taken together create a horrible unmaintainable mess. Speaking from experience.

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

#192

Earlier 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…

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.

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

#193

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…

I agree that no build step is a false economy. With a build step writing Vue and react are better... Use up to date JS, minified and split bundles, single file components, etc

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

#194
post #29

Earlier 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…

Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.

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

#195

Earlier 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.

Using promises where? And what's difficult about them?

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

#196

Earlier 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…

This is only if you use SSR and is the opposite of being able to render with any existing web framework.

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

#197
post #143

Earlier 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.

No, I'm talking about using hundreds of existing server-side web frameworks that output HTML, not Node/React SSR which is far more limiting.

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

#198
post #133

I'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…

> I'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 latter seems an overreaction given the former.

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

#199

This 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).

They listed SPA capabilities as a requirement when choosing a framework.

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.

Post reply on HN