* Wikipedia is not becoming an SPA
* Wikipedia is not dropping support for non-js users
* This proposal is not about changing our current browser-support matrix[1] (which includes IE11 as a first-class target; Vue.js ecosystem still supports IE 11)
* This proposal is about changing the way we develop enhanced, JS-only features across our projects; many such features exist already, but they are written in jQuery and an in-house framework called OOUI
* These features will continue to be delivered in a progressively-enhanced way on top of the PHP-rendered baseline for the forseeable future. We are interested in how server-side rendering of JS components can integrate with this but we're still looking into how this might work
* We will continue to prioritize accessibility, internationalization, and performance in everything we ship
I don't think that Vue is "better" than React, but I think it has some features which are especially helpful in our progressive-enhancement, ES5 (for now, anyway) use-case. But it's great to have so many amazing tools to choose from.
Previously we've been using a framework we created in-house for complex JS features, but it's a product of an earlier era of the web and is increasingly out of step with the current paradigms in UI development. We think that one big benefit of moving in this direction is lowering barriers to contribution (both for new developers at the foundation, as well as folks in the wider community).
A deeper dive presentation into the move into OOUI (which started meaningfully plotting and happening ca. 2013) from storing state in DOM elements, and challenges implementing it: https://www.youtube.com/watch?v=T_CUN2o4faw
- 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).
- Wikimedia is not just Wikipedia. There are many other use cases across the Foundation where heavy interactivity is needed. Even within Wikipedia, there are cases like the editor / edit mode which can be considered non-trivial JavaScript applications.
- Adopting a new framework !== More JavaScript. Wikimedia already has an in-house framework which has become outdated and difficult to maintain. Adopting Vue allows the team to implement the same features with less code. It will shave off instead of adding to the bloat.
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.
I tend to have the opposite reaction. I want a framework with a small API I can keep cached in my head. I don't want to worry about finding the magic switches to get it working the way I want.
I was not aware of this. That's actually really cool. I've dabbled a little in Vue and Angular but haven't taken the plunge and deployed an actual App because I prefer to have sites that degrade gracefully.
Hopefully this will also make it easier for new contributors to get started with MediaWiki development.
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?
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.
The HN implementation renders the comments on the client side because it was using the Firebase HN API which doesn't provide a friendly API for fetching the entire comment tree. Notably, some other HNPWA implementations were using a custom API endpoint. We didn't switch to it because the Vue HN was built as an educational demo rather than a benchmarking subject.
I think it's great that Vue is capable without a build step; however, this implies one restriction, which is that you must have all the components loaded before the application starts. And Async components don't help here because you would have to mantain a list of components names, which without a build step become cumbersome.
I would like that my proposal for lazy loading components (https://github.com/vuejs/vue/pull/8807) would be accepted, then we would have the ability to load components on demand without a build step.
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.
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.
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.
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.
Check out the /edit mode for any page. It's already a non-trivial JS app.
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.
Maybe that would be a feasible way to get a modern developer experience without the bloat?
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.
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.
Yes
>Will screen readers support all elements created by the Javascript framework?
Yes
>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.
- 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.
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 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.
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
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.
If I were to use something that lacks TypeScript support, it would be Svelte, because it brings unique advantages. By adding hooks, React became the winner for me.
Angular has never been an option for me.
Vue's templating is standard HTML which means it can be delivered by any server-side language/framework. This is where Vue shines in adding interactivity to many typical apps without going fully SPA.
That is good to know. I wasn't aware. Most of the apps we are working on cannot be SPAs easily, so it matters if the JS framework supports operating without it.
I understand the desire to use webkit, Typescript, and so forth to develop modern apps, I'm just confused at why Vue in a stand alone page delivered by ftp or usb drive isn't a "full" SPA
Typescript has a lot of adoption within with ex-Java devs, and with that comes a lot of "Java-think." It's hard for these people to adapt to not doing things "the Java way" and vice versa.
And another part of the problem is that people have burnt themselves badly with Coffeescript, Clojurescript, and few other *scripts that were coming and going trends, and were an enormous LTS burden because of tooling that breaks as fast as you fix it.
Instead I'm stricly using ClojureScript as the tooling is really solid in everything Clojure, backwards compatibility is a huge selling point in everything Clojure and projects using Clojure/Script tends to be just of the right size and think more about the data structures themselves instead of what many refer to "proper engineering" (SOLID patterns and other nonsense)
TypeScript makes Java and .NET developers think they understand the language and platform and causes a lot of irrelevant design to be copied over into the JS world where it mutates and becomes absolutely poisonous.
Just look at Angular where the boilerplate and crazy dependency injection completely surpasses anything seen in the Java / .NET world.
How does removing typescript help you?
What do you mean by this? npm packages at least are already "de-typescripted", in the sense that they're just .js files with accompanying .d.ts files describing the former to people using editors with TypeScript support.
(Also, it feels like you've experienced a weird subset of TypeScript code. It also happens to be an enormous help when doing things "the Javascript way", which is what it's actually designed for. But I can imagine that encountering bad apples can sour the experience for you.)
There are experts, average people, and bad people in every field. TypeScript brings sanity that is valuable for both experienced developers and less experienced developers.
The peace of mind that you get with types when doing refactoring is invaluable. I would never be able to go back and write vanilla JavaScript, because it's broken.
You can over-engineer and write crap code in any language.
Also a comment on anyone that says experienced devs get no benefit from types: you think you're good, but you're not. As good as you think you are, if you seriously deny the benefits of static typing, you're probably shit as a developer. If you understand static typing and it's benefits then you agree it's a good trade, if you don't understand it and still have a strong opinion against it, then you're just a lazy human.
I use Vue2 + Typescript, and for me it works great!
Even Auto-completion works.
I'm sure Vue3 will fix all this, and it will be awesome. Very much looking forward to it
I've never used react but I think you can use typescript with react if you wanted to, right? it just isn't the default but if you're in react land, you probably don't care much for defaults?
It hasn't been an option for me because I found it quite opinionated for personal projects, and in my work context I didn't enjoy / respect the people that were working on Angular projects. This is not about Angular, it's about where I was working and the people there.
It's easy to judge a tool by it's users, but we mustn't.
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 could take a half-measure and move away from the brittle jQuery based front-end they are currently using by adapting those to use something like Preact, while leaving the rest of the page alone. This would give you more dynamic and more maintainable page widgets without the sacrifices that inevitably occur when you move the entire site to being front-end rendered.
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.
You really think 140,000 people are going to learn git all of a sudden?
Is this for internal Wikimedia apps or intended as a long-term replacement for Wikipedia/MediaWiki? If the latter, a prime requirement surely would be to support MediaWiki markup wouldn't it?
The problem with this kind of assessment starts with the deliberate decision that you need a JavaScript "framework" at all in the first place (that isn't just motivated by a junior dev seeking to pad his/her resume). Going from there, since you desperately want to persuade yourself that today's frontend landscape isn't just a result of big media influence (Fb, Google), you necessarily choose Vue (I know several companies who settled on Vue because they couldn't stand the React hype).
In other words, decisions for a particular JavaScript framework are as generational as ever, and the hope for a choice with a long-term perspective is futile, because a new generation of webdevs will soon re-invent their generation's framework since maintaining daddy-o's web framework isn't fun, and because every developer wants to carve out a niche for creativity.
> 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 thriving community (and we anticipate this will continue to be the case for years to come)
> Flexibility: the framework supports the widest-possible range of use-cases (client-side as well as server-side rendering, progressive enhancement as well as full "SPA" usage, build step as well as no build-step etc.)
> The framework is heavily optimized for performance.
Only ONE of those has anything at all to do with the user.
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. Especially for an organisation like MediaWiki page load time is absolutely critical. I really hope they are sensible enough to choose something lightweight.
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.
> The framework is heavily optimized for performance.
However I feel like while React is just fantastic on its corner, Svelte seems like a better built Vue than Vue. It lacks the community but technically feels like a refinement and enhancement of Vue’s ideas. I wish it would gain more traction.
I’m glad to see Svelte growing in popularity here.
I like keeping things small because it delays having to add complexity (and simple is easier to maintain, especially when you have better things to do) and saves on bandwidth.
Of course I'll keep evaluating new versions as they come (given nothing is sacred in my pipelines), so that might change in the future.
I know Svelte does clever things to avoid a virtual DOM, but is the difference in practice really appreciable?
Anyway since svelte must be compiled i dont think it's good choice for something like mediawiki where you might have plugins and addons that want reuse core components and connect to each other in runtime.
Compiled Svelte components are highly reusable and cross-framework like few others.
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 idiocy.
- 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
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 simple infrastructure to help their budget.
[^1]: See Gwern.net for an example of an easy pure JS hovercard - https://www.gwern.net/DNB-FAQ
> 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.
I’ve used React extensively but I agree with their assessment that the API is a moving target, which ends up being horrific DX when you’re using third party libraries.
Couldn't see the value there.
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 by React.
As for JSX with Vue, it's clearly a second class citizen. For instance, last I checked, JSX + TypeScript was broken, though both are officially documented with Vue.
When you're choosing a JS framework you need to factor in the experience the user has along with the experience you have. I don't know much about Vue but React comes with a huge amount of bulk. A lot of JS that has to be parsed before anything can even be done on the page.
If you're choosing React because it allows you to fall back on what you know rather than learn something new you're making an ill-informed choice.
By itself, there is no inherent value in either v-for or Array::map(). However, these choices do not exist in a vacuum, they are other decisions in place, which do provide significant value:
- React, allows full power of js when writing template. and easy to express and decompose components into functions. while Vue does not allow the fine-grained in template unless you go into Vue's JSX) - Vue, via template-based approach, enables Developers to deploy apps without a build step, while React forces devs to add a build step(and a compelx one at that) to pipeline
Vue: supports JSX, vanillajs render function, pug, and its default HTML templates.
You: "React allows full power of js"
Ok
Wikipedia is a unique project because of how reliable it is -- in both its merit and its tech. It would be sad to see it go.
They can say whatever they want about how this won't happen but likely it's not up to them (because it's a corporation and because they won't control the decisions of the JS framework they pick). Wikipedia isn't broken. Fixing it is bad.
For every other application, my favourite tool is https://unpoly.com/, and alternatively Turbolinks + Stimulus.
Most applications do not need Vue or React there is a HUGE abuse of client side JavaScript these days.
Turns out HTML over HTTP is GREAT way to deliver encyclopedic content.
That said, ES5 is going to die at some point and big projects like Wikipedia need to prepare for that. Making long term decisions that do not take that into account will be essentially flawed. It would be better to adopt TS than to keep writing ES5 in 2020.
It looks like it's reasonably easy to setup run-time JSX compilation by using a service worker with babel to intercept and transpile .jsx files. I imagine the performance tradeoffs would be similar to using Vue with string templates? Could be faster actually since you could memoize/cache in the service worker
Also why not Svelte?
The framework allows UI elements
to be defined in a declarative way
<Todo v-for="(todo, index) in Todos" :key="index"/>
If anything, it's the opposite - you're now polluting HTML with imperative programming features where there previously were none.
As a joke, why not wait for the hype to go full circle and then pick vanilla javascript/es6?
Too much file separation, “magic” in the templates, etc.
Good bye.
Sure, you won't get 100% of the goodies, if you disable JS, some stuff simply can't be done with HTML/CSS, but at least the important parts would still work.
Also, solutions like Svelte are rather fast and small, compared to Vue/React but also compared to previously known small frameworks like HyperApp.