
RFC: Adopt a modern JavaScript framework for use with MediaWiki - aliveupstairs
https://phabricator.wikimedia.org/T241180
======
katabasis
Hi HN – I'm one of the authors of this proposal. I'd like to clarify a few
points here:

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

[1]:
[https://www.mediawiki.org/wiki/Compatibility#Browsers](https://www.mediawiki.org/wiki/Compatibility#Browsers)

~~~
trynewideas
For context about OOUI and OOjs:
[https://www.mediawiki.org/wiki/OOUI/Using_OOUI_in_MediaWiki](https://www.mediawiki.org/wiki/OOUI/Using_OOUI_in_MediaWiki),
[https://www.mediawiki.org/wiki/OOjs](https://www.mediawiki.org/wiki/OOjs)

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](https://www.youtube.com/watch?v=T_CUN2o4faw)

------
EvanYou
Team lead of Vue.js here. Clarifying a few points being raised in this thread:

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

~~~
est31
As long as there is no accepted non-vue replacement for the server side
rendering technology, one has to assume that WP will replace php based
rendering with Vue templates on a large scale, even for the static content.
However, Vue templates require usage of node.js. I couldn't find any
standalone serverside vue template parser/renderer written in something like
C++, Rust or Go. So if they adopt Vue, they'd still be locked into a project
ran by a single company, namely v8, which they listed as one of the things
they wanted to avoid.

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?

[1]: [https://vue-hn.herokuapp.com/item/22625556](https://vue-
hn.herokuapp.com/item/22625556)

[2]: [https://ssr.vuejs.org/](https://ssr.vuejs.org/)

~~~
spyckie2
I don't get the impression that WP will replace php templating. That just
doesn't make any sense to do. First the code is already written (no need to
rewrite), probably well tested, php is extremely fast already, and I'd imagine
their php development does not have dated tooling that makes development
painful. There's little to no reason to switch php code out.

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.

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

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

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

~~~
TeMPOraL
> _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.

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

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

------
112
I've loved Vue for a long time, worked two years with it almost daily, but
right now I avoid it as much as I can, as I can't stand working with
JavaScript without TypeScript. The TypeScript support in the current version
of Vue is crap, and the simplest things, such as creating a (typed) component
library, are hard and require numerous hacks.

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.

~~~
baybal2
A reverse situation here. I deal with strict no typescript policy, so besides
a problem of finding typescript devs, we have a problem of having to "de-
typescript" a lot of 3rd party code.

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.

~~~
capableweb
I'm also avoiding typescript as much as I can, but not because typescript
itself, but because of how typescript projects tends to be outlined. Lots of
the projects are way over-engineered for where they are on the timeline and
typescript makes people reach for classes too early. Seeing the same with
vanilla JS projects now too when `class` been introduced.

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)

~~~
christophilus
I’m spinning up a few new projects at the moment, and was sooo close to doing
them in ClojureScript. I ended up going with JavaScript, Preact, and Rollup
just because of familiarity allowing me to move faster. That, and my build
times are sub-second, something that was not true of my previous Webpack and
typescript projects. My total application bundle size is still smaller than
React alone.

ClojureScript is really good, though, I gotta say. How are your production
bundle sizes? Are you using shadowcljs? If not, what tooling are you using?
Also, what editor? I’m a VSCode guy, and last time I used Clojure (a year or
more ago), Calva wasn’t up to snuff. I wonder if that’s changed.

~~~
capableweb
> How are your production bundle sizes?

Application I'm working on is not that complex, 20 something different pages
with multiple sub-sections themselves, bundle ends up being 1.5MB or something
like that, 300kb gzipped. Main weight comes from using multimethods which
pulls in a lot of cljs.core, so not using that would make it a lot smaller.

Also gonna start splitting the bundle per page but haven't yet.

> Are you using shadowcljs? If not, what tooling are you using?

No, using figwheel-main, project was started before shadowcljs starting to
look as good as it looks today. Starting a project today I would probably look
into shadow-cljs first. But we're not using any npm dependencies, but shadow-
cljs seems to have better introspection properties than figwheel-main (like
seeing partitions of bundle size easier, we're currently doing it by looking
at the sourcemaps...)

> Also, what editor?

Using vim + fireplace which been working really well for me.

> Calva wasn’t up to snuff. I wonder if that’s changed

Haven't used Calva myself but tons of people in the community swear by it, so
I'm thinking it's been improving since the last time you tried it.

I'm not sure when was the last time you tried Calva but Calva been in at least
two Clojurists Together
([https://www.clojuriststogether.org/](https://www.clojuriststogether.org/))
funding cycles, so if you tried it before mid-2019, give it a try again (and
report back :) )

~~~
LandR
IntelliJ with Cursive is a very good Clojure IDE.

~~~
capableweb
Tried it out before (and your comment actually triggered me to try it out
again just to see) but I'm struggling to find anything it does that vim +
fireplace doesn't do while vim is way faster and takes less screen-estate so I
can have my browser + editor side-by-side.

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

~~~
EvanYou
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).

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

------
tannhaeuser
The requirements listed for a "modern JavaScript framework" are completely
generic. Of course, if you include requirements such as "declarative" and
"broad mindshare", you can only arrive at React, Angular, or Vue - at the
moment that is.

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.

------
pmarin
Most of Wikipedia works perfectly without Javascript I hope it will continue
to do so.

~~~
k__
Modern JavaScript runs on the server just fine, they will probably use server
side rendering and build time rendering.

~~~
vorpalhex
Server side rendering is _slow_ and _expensive_. Wikipedia needs to be fast
for all of it's users, and needs to be very cost centric.

~~~
k__
Static site generation is very cheap in terms of generation and delivery.

~~~
vorpalhex
Yes, SSR and static are not the same.

------
HumblyTossed
> The need to evolve our platform is very evident when it comes to how we
> design, develop, and deliver experiences to users in the browser.

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

~~~
untog
To be blunt, this is an extremely common thing in web development and it makes
me very sad. But whenever I raise it I’m rebuffed with the vague argument that
“developer productivity = more features = better user experience”. Which
sounds great in theory but a crappy experience is a crappy experience no
matter how many features you put on top.

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.

~~~
anchpop
> 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

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.

~~~
untog
Serious question: why are you using React for a blog? What interactive
elements are there on the page that require it?

EDIT: Saw the link in your profile. I see lower numbers than you, though not
by much. But I also see 2.6 seconds time to interactive with 3.1 seconds of
main thread work.

Broadly speaking, that's fine for your blog. But if it was a site that you
expect to add more and more features to over time that number is only going to
go up. 3.1 seconds of main thread work to render an _entirely static page_
isn't _good_. It's acceptable at best.

~~~
anchpop
There are no interactive elements, I just enjoy using React more than the
alternatives, even for static content. Instead of asking "what requires
react", a better question is "what are the tradeoffs of using react in this
situation". In my case React allows me to use Gatsby, a wonderful static site
generator, and it also makes it easy for me to add any interactive content I
want in the future.

My site will load fine without javascript, so it's hard to imagine react is
slowing things down much (although if you've visited before the PWA will mess
it up if you try to turn JS off).

For something like Wikipedia, time to interactive isn't that important (which
is good, because lighthouse tells me that this page [1] has a TTI of 7.4s).
First meaningful paint matters much more. I really disagree with the narrative
that anything written with React is going to have a much worse user experience
compared to the "old" stack.

[1]:
[https://en.wikipedia.org/wiki/Matthias_Hansen_House](https://en.wikipedia.org/wiki/Matthias_Hansen_House)

~~~
untog
I’d say your use case isn’t really all that applicable to how React is
normally used. Zero interactive elements and doesn’t require JS... that really
isn’t typical for a React deployment.

> I really disagree with the narrative that anything written with React is
> going to have a much worse user experience compared to the "old" stack.

Why only compare to the old stack? When you’re evaluating a brand new solution
would should be looking for the best one, not any solution that improves your
current situation.

------
eknkc
Well I guess you can not go wrong with either React or Vue at this point as
they have mature communities.

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.

~~~
sdan
+1 on Svelte. Seems like the better/faster option.

~~~
MaxBarraclough
Is it really faster for real-world uses?

I know Svelte does clever things to avoid a virtual DOM, but is the difference
in practice really appreciable?

~~~
kreetx
The bigger the virtual dom the larger the performance gap is supposed to be.
But, true, would like to see some benchmarks from the real world, i.e rewrites
and such.

~~~
MaxBarraclough
Perhaps not a great comparison, but here are the Svelte and Vue HackerNews
feeds. Not a great deal of difference, but perhaps it's too simple for
performance to really matter.

[https://hn.svelte.dev/top/1](https://hn.svelte.dev/top/1)

[https://vue-hn.herokuapp.com/top](https://vue-hn.herokuapp.com/top)

 _Edit_ This site says the Svelte one wins on load times:
[https://hnpwa.com/](https://hnpwa.com/)

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

~~~
tantalor
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](https://www.mediawiki.org/wiki/Page_Previews)

~~~
vorpalhex
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 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](https://www.gwern.net/DNB-FAQ)

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

------
lwansbrough
We adopted Vue for the same reason. We had a large ASP.NET + jQuery code base
which we were able to enhance with Vue.js over time. Eventually we built an
SPA code base and porting over our existing components was a breeze.

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.

------
jeswin
I looked at Vue.js and came away with the impression that it requires me to
learn a lot of framework-specific implementation details. For instance, a list
requires that you know the v-for directive, while in React it's just
JavaScript's Array::map().

Couldn't see the value there.

~~~
manigandham
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 by
React.

~~~
idoubtit
Using Vue's pseudo-HTML directives might be easier for many cases, but it is
less powerful than JavaScript. In some cases, these restrictions leads to
workarounds or rewrites. I agree with the grand-poster that the added value is
controversial.

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.

~~~
mmis1000
I actually found make it restricted (compare to js) improve general code
quality as you don't have too much items to abuse. Probably not ideal for
personal project because it won't let you fly as you want. But it is awesome
for collaboration because you can't really write something way too off with
it.

------
oleskiewicz
I have been donating to Wikimedia for years, but have sent an email to let
them know that I will stop the day Wikipedia becomes inaccessible without
JavaScript.

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.

~~~
Richicoder
The intent of this RFC is to improve the places _where JavaScript is already
used_ like management tools and editing.

------
superkuh
Reminds me of when archive.org "improved" their site with javascript a year or
two back and it stopped working entirely if you don't run JS and don't use a
modern commercial browser.

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.

------
a_imho
It reads as a solution looking for a problem.

------
user34234
I have the opinion that Vue and React are ideal when you do need a SPA
(example: when you want to make something that works offline, uses a lot of
browser side storage, etc).

For every other application, my favourite tool is
[https://unpoly.com/](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.

------
tjpnz
Not knocking Vue but what exactly is meant by modern? I work on the backend
and hardly (if ever) see frameworks described in those terms.

~~~
aliveupstairs
Needless to say that this is subjective, but I think Single Page Applications
and components-based UI in webdev is fairly modern as opposed to imperative,
jQuery-esque Front-end development.

------
austincheney
Do they really need a large framework? It is possible to write fast elegant
applications in JavaScript without a framework.

------
speedgoose
I have used react and vue and I prefer vue. React is fine but it has a few
issues such as having to write className instead of class in the html
templates (yes I know why). It's not a big difference between all these new
frameworks though, and it will be a huge improvement over html generated from
PHP with some jQuery.

~~~
arvinsim
className vs class is a non issue when you use CSS modules or CSS-in-JS.

------
layoutIfNeeded
Please don't make Wikipedia a JS monstrosity :(

~~~
k__
Contemporary framworks all allow for server side rendering and build time
rendering.

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.

------
jcarlosweb
I think you should have supported Web components

------
heinrichhartman
At least the content is freely available, so I can stand-up my HTML-only
Wikipedia clone if they render the official version unusable with this
reactive JS madness.

Turns out HTML over HTTP is GREAT way to deliver encyclopedic content.

------
pier25
So I've been working with React/Vue/etc since 2015 and I agree that if you are
looking for an ES5 jQuery replacement Vue is the best candidate of the most
popular options. You can work old school, just import it via a script tag and
start writing ES5 .js files.

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.

------
sufyanadam
Developer experience in React is orders of magnitude better than in Vue. Also,
the React community settles on great conventions and patterns to help you be
really productive early on. This is great because you end up with projects
that are a pleasure to code in and easy to maintain. Debugging experience is
far superior in React, finding the root cause of an issue is much quicker than
with vuejs. Working in a vuejs project, I continuously wish we could just
abandon it and rewrite everything in React.

------
cheapsteak
>Better support for usage without Webpack/Babel/front-end build tools

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

------
maps7
Isn't Vue 3 vastly different to Vue 1 and 2?

Also why not Svelte?

~~~
rk06
It is not. The devs initially wanted to make some drastic changes. But
Community feedback was very vocal and very negative. Since their main source
of income is the community(not FAANG), they reverted their stance

~~~
maps7
Ah good to know!

------
lwh
Not needing JS is a key feature of MediaWiki. It would be great if the old
CSS+HTML skins still worked with this.

------
TekMol
Can someone give a quick code example for the follwing?

    
    
        The framework allows UI elements
        to be defined in a declarative way
    

How can you use Vue so that what you do is more declarative then when using a
template engine like handlebars?

~~~
aliveupstairs
I believe the templating is what's declarative, here. For instance, in Vue you
can insert logic such as for loops, conditionals, event listeners, two-way
data binding and so on right in the template with directives (HTML
attributes).

    
    
        <Todo v-for="(todo, index) in Todos" :key="index"/>
    

Instead of an imperative JavaScript for loop.

~~~
TekMol
It is the same with handlebars. You put your todo element between {{#.}} and
{{/.}} which means "do this for all elements" and then pass only the "Todos"
array to the template. No loop in Javascript either.

------
rutierut
As someone who has been using Vue for a long time and recently fell in love
with Svelte, I really hope they wait for a bit and go with the Vue 3 version.
It brings a lot of huge advantages to Vue that make it much much more
maintainable.

------
aliswe
Technology isn't an argument IMO. I know that is misrepresenting the rfc a
bit.

As a joke, why not wait for the hype to go full circle and then pick vanilla
javascript/es6?

------
torgian
This looks like a backwards solution to a modern problem.

------
alphachloride
What's wrong with plain old JS? Wikipedia is not a software company that it
needs to use <insert-word-of-the-day> framework just to look hip.

------
b34r
The developer experience of working with Vue is significantly worse than React
in my personal experience...

Too much file separation, “magic” in the templates, etc.

------
otabdeveloper2
Good, I needed a reason to stop using Wikipedia.

Good bye.

------
Kiro
Vue is just like Angular 1 but with less boilerplate. As your app grows you
will run into the same issues. Never had the same feeling with React.

------
noodlesUK
Just in time for v3.0!

------
longtermd
A warm Welcome to the Vue family! :)

