Comment by ddevault | Hacker News Reader

Comment by ddevault | Hacker News Reader

Parent Full thread

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/front-end build tools

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

A non-trivial change to the architecture of MediaWiki, such as, for example, overhauling the frontend JavaScript with Vue.js? 90%+ of all software has a build step, this is a well-understood problem and has been since before Wikimedia existed in the first place.

They also mentioned that they want a framework which "has a thriving community (and we anticipate this will continue to be the case for years to come)", then picked the framework which has been the underdog since its inception (not that I think any of the other choices they evaluated would have been wise, either). They wanted to use Vue, so they're going to use Vue.

For a website like Wikipedia, it would have been better to consider the alignment with their core mission. A lot of new technology doesn't work in older browsers whose collective market share is still ~5%. A project like Wikimedia is used by effectively 100% of the population, which means that designs which eschew 1% of the population are eschewing tens of millions of people. That's not to mention that these technologies, even when supported, require more computational resources to work, which will make Wikimedia harder to use on low-end or older devices. They considered performance - but only as far as the libraries they "evaluated" compare to each other, not to their baseline.

These kinds of kangaroo court evaluations of technologies for use in a software engineering team make me sick, especially because I'm guilty of having done this before.

I'm happy to see another big project commiting to Vue, but found the rationale funny to say the least, having seen the same kind of analysis multiple times. For example, these requirements:

- UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default - The framework is heavily optimized for performance

should automatically exclude React itself, but it seems to have been the second option. Despite appearances React is not very reactive, especially with hooks where you do dependency management yourself. Performance is not a given either, nothing is memoized by default and it's all up to the implementer (or the state management system) to actually optimize rendering at all.

The 'large community' mindset which automatically dismisses Svelte and Preact all the time is the most heartbreaking. If we worked with the herd mentality five years ago, neither or React or Vue would have been born and some variant of Backbone would still be the most used view library.

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.

They expect to have server side rendering, so end user will get just HTML (except the parts that require js even today), so older browsers should still work

Server-side rendering isn't a panacea. I would be surprised if they were using it to do more than bootstrap an interactive frontend web component, which would then inherit all of the problems I'm referring to. That's how everyone else does server-side rendering, at least.

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

> But given that, how do we move forward? We shouldn't be stuck in the past forever.

Wikipedia is essentially a public utility now. It's not their responsibility to move technology forward by forcing their users to upgrade their machines. There's loads of other players that do that already.

> If their site requires heavy client-side code

It doesn't.

It's our collective responsibility to decide what user agents work with what platforms.

The beauty of the internet is that any website is free to decide as they see fit - if they don't want to support IE/Edge/etc then that is their choice.

No website is a 'public utility' bound by laws which dictate what browsers must be supported - that remains a free and open decision.

IE11 is a dead browser, and the sooner it breaks for good, the better.

You seem to completely have missed what the foundation is about.

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.

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

Hmm, in principle I would agree but in practice, I think it wouldn’t make a difference here. Even if it were more even-handed the contenders they would be choosing among are acceptable substitutes for one another. Like, I couldn’t see this being a failure with React but succeeding with Vue. In a lot of these sort of situations, you just need to pick something. I agree that those criteria sound contrived, though.

Personally, I work in React all day and I’m comfortable with it, but I could just as easily use another. There would be minor differences that may annoy to some degree, but it wouldn’t make a huge impact. They all do basically the same thing.

Reply on news.ycombinator.com