19 ms·

RFC: Adopt a modern JavaScript framework for use with MediaWiki

309 points by aliveupstairs 7y ago

lwansbrough 7y ago
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.
noodlesUK 7y ago
Just in time for v3.0!
- deleted 7y ago
  [deleted]
eknkc 7y ago
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 7y ago
  +1 on Svelte. Seems like the better/faster option.
  - MaxBarraclough 7y ago
    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 7y ago
      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 7y ago
        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/
  - wildpeaks 7y ago
    I was tempted by Svelte for a while, but in the end Preact remained the best fit for our needs because the output filesize grows slower with Preact than Svelte. 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.
- woutr_be 7y ago
  To me the difference is that Svelte is a lot more pure JavaScript than Vue. I haven't had the chance to use it in any larger project, but in my small playgrounds, I've definitely enjoyed it more than Vue.
  - NetOpWibby 7y ago
    If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page https://webb.page I’m glad to see Svelte growing in popularity here.
    - benbristow 7y ago
      That page could literally just be a static web page or built using a static site builder like Jekyll/Hugo etc?
      - NetOpWibby 7y ago
        Of course it could but once you have a starter template setup it becomes an easy to jump right in.
    - leadingthenet 7y ago
      What exactly are you using Svelte for? It seems to literally be one HTML page...
      - NetOpWibby 7y ago
        To put it simply, I like it. Plus, I have a starter template project that makes it easy to just code and go.
    - cmroanirgo 7y ago
      Viewing the source shows an html page without a closing body nor html tag: it's probably not the best case for showcasing it seems. The layout it all over the place too using FFox, (it's fine on Chrome and Safari) so it also seems to be lacking in some basic cross browser testing, which again, is not good news when show-casing a framework, as a frameworks' prime responsibility is to ensure cross browser/platform uniformity. Hopefully this all boils down to a simple 'oopsie' in your project, rather than svelte.
- omnimus 7y ago
  But react and vue are underneath much closer to each other than Svelte. Sure vue and svelte use templates and react doesn't but that's about it. 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.
  - twsted 7y ago
    > 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.
    - omnimus 7y ago
      So how do i extend component in mediawiki without having to recompile its source? How would i reuse that <mediawiki-table/> distributed in core and reuse it in user installed plugin?
- darkcha0s 7y ago
  Why would the WM foundation use a relatively unknown framework? They don’t just care about the actual coding itself, the have to concern themselves with community, support and longevity. You said yourself you wish it would gain more traction, and that’s something an Org like that doesn’t take a gamble on to be fair.
- KaoruAoiShiho 7y ago
  Actually using Svelte its main downside is the giant file size. I consider it unusable for that reason alone. Any minor speed advantages is entirely negated.
- Can_Not 7y ago
  Svelte lacks the robust and reliable error handling that Vue and React have.
112 7y ago
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.
- izelnakri 7y ago
  ember with typescript should be an option for you
- z0mbie42 7y ago
  I would love to know why are you saying this. I use Vue2 + Typescript, and for me it works great! Even Auto-completion works.
  - fraktl 7y ago
    Because he never used Vue with TS. It's a blatant lie and utter bullshit.
  - 112 7y ago
    It's OK for the most common scenarios, I didn't comment on the regular "build a web app" case, but more complicated ones. I think @vue/cli is very nice, but I've had many issues dealing with the magic behind it, so much that it became easier to swap vue-cli-service with rollup and custom setups. I'm sure Vue3 will fix all this, and it will be awesome. Very much looking forward to it
- mcny 7y ago
  I've only used angular but I'm curious, why has angular never been an option for you? 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?
jeswin 7y ago
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.
- martin_a 7y ago
  Right now, Corona made some time for that, I'm rewriting something I tried to do in Vue. I don't work with Vue daily and that makes it real hard to do even the simplest things. I'm back to vanilla JS, few sprinkles of jQuery and HTML5. Works well for me.
  - shirshak55 7y ago
    exactly. React works so well with js. And vue claims to be simple but tbh its hard. working with async await function, promises are so weird. And you need packages for simple stuff also.
    - Can_Not 7y ago
      Really? async/await just works by in Vue. And React doesn't need packages for simple stuff? Really??? Are you sure you've ever used Vue?
- boobsbr 7y ago
  That feels like learning Angular template syntax, and I really dislike it. React has its warts, but I find JSX very readable, much more flexible.
  - ptrwis 7y ago
    I dislike both. Most readable template syntax for me is PHP's "alternative syntax for control structures" (the one with colons instead of braces and closing keywords).
    - 7y ago
speedgoose 7y ago
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 7y ago
  className vs class is a non issue when you use CSS modules or CSS-in-JS.
Kiro 7y ago
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.
tjpnz 7y ago
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 7y ago
  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.
rutierut 7y ago
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.
TekMol 7y ago
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 7y ago
  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.
  - otabdeveloper2 7y ago
    How in seven hells is moving imperative loop constructs from Javascript to HTML supposed to be "declarative"?! If anything, it's the opposite - you're now polluting HTML with imperative programming features where there previously were none.
  - TekMol 7y ago
    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.
pmarin 7y ago
Most of Wikipedia works perfectly without Javascript I hope it will continue to do so.
- k__ 7y ago
  Modern JavaScript runs on the server just fine, they will probably use server side rendering and build time rendering.
  - vorpalhex 7y ago
    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__ 7y ago
      Static site generation is very cheap in terms of generation and delivery.
      - vorpalhex 7y ago
        Yes, SSR and static are not the same.
    - karatestomp 7y ago
      Weird, most of the fastest-feeling sites I use are server-side rendered. Though I doubt they use any JS in that path. Maybe basic html Gmail does but probably it’s Java or something.
longtermd 7y ago
A warm Welcome to the Vue family! :)
Alex_P13 7y ago
Top 20 free and premium dashboard template in 2020 To track all the performance on your website, these free dashboard templates come very helpfully for your website. With a dashboard template, you’ll know exactly how well your online project is doing. For example, track sales, new members, likes, profits, tickets, you name it, it can all be done inside your ultimate dashboard. https://is.gd/P7BmMm https://is.gd/P7BmMm
maps7 7y ago
Isn't Vue 3 vastly different to Vue 1 and 2? Also why not Svelte?
- rk06 7y ago
  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 7y ago
    Ah good to know!
tannhaeuser 7y ago
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.
pier25 7y ago
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.
oleskiewicz 7y ago
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 7y ago
  The intent of this RFC is to improve the places where JavaScript is already used like management tools and editing.
jeroenhd 7y ago
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.
- k__ 7y ago
  I'm a React fanboy, but I have to admit, the Svelte performance and code size is impressive. Maybe that would be a feasible way to get a modern developer experience without the bloat?
  - marcus_holmes 7y ago
    One of their criteria is widespread adoption. Svelte isn't there yet. One day it probably will be, but today is not that day.
    - slantyyz 7y ago
      I think that's a chicken egg thing. If Wikimedia adopted it, adoption rates would skyrocket.
      - rk06 7y ago
        Really, what makes you believe so? IMO, to drive adoption rates, you would need dev evangelists While the RFC states that they are taking cautious route here. They also mention that they are not making an SPA which all the cool kids look up to.
layoutIfNeeded 7y ago
Please don't make Wikipedia a JS monstrosity :(
- k__ 7y ago
  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 7y ago
I think you should have supported Web components
a_imho 7y ago
It reads as a solution looking for a problem.
MatthewPhillips 7y ago
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.
- brabel 7y ago
  It's not just a bad idea... it's a horrible, dangerous idea. All of their points can be easily addressed with a static site generator or just some CMS that lets you write pages using templates instead of just pure HTML. That's absolutely declarative, a lot more than a JS-framework based app. The only point that would be missing is the reactive part as you mention: but who the hell expects a wiki to be reactive?! I expect it to be as close as possible to the printed version! A Wiki is NOT a web app!
  - otterlicious 7y ago
    > a static site generator You really think 140,000 people are going to learn git all of a sudden?
    - Fnoord 7y ago
      Learning Git (there are GUIs for it as well) can aid one in so many additional ways though.
- EvanYou 7y ago
  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).
torgian 7y ago
This looks like a backwards solution to a modern problem.
cheapsteak 7y ago
>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
ddevault 7y ago
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.
- unionpivo 7y ago
  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
  - ddevault 7y ago
    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.
belval 7y ago
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 7y ago
  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
  - enriquto 7y ago
    Whatever, but if wikipedia somehow becomes unusable without javascript, it will be a real tragedy.
    - jdlrobson 7y ago
      You dont need to be worried about this. Our morales and principles are not changing. I built the Wikipedia mobile site and there's a reason our hamburger menu, lazy loaded images and editor actually work without JS. We are for everyone regardless of internet connection speed, device value and internet stability. That's a a hill at least I as an employee am prepared to die on.
      - enriquto 7y ago
        I cannot express how reassuring your words are, and how happy I am to hear them. Thank you very much! Well; it turns out that I can: just made a donation.
      - belval 7y ago
deleted 7y ago
[deleted]
otabdeveloper2 7y ago
Good, I needed a reason to stop using Wikipedia. Good bye.
heinrichhartman 7y ago
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.
deleted 7y ago
[deleted]
HumblyTossed 7y ago
> 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 7y ago
  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 7y ago
    > 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 7y ago
      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.
EvanYou 7y ago
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.
- cptskippy 7y ago
  > 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). 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.
- BiteCode_dev 7y ago
  This is IMO one of the killer features of vue. 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.
lwh 7y ago
Not needing JS is a key feature of MediaWiki. It would be great if the old CSS+HTML skins still worked with this.
austincheney 7y ago
Do they really need a large framework? It is possible to write fast elegant applications in JavaScript without a framework.
alphachloride 7y ago
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.
katabasis 7y ago
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 7y ago
  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
user34234 7y ago
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.
superkuh 7y ago
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.
b34r 7y ago
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.
aliswe 7y ago
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?
sufyanadam 7y ago
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.

309 points by aliveupstairs 7y ago

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.

noodlesUK 7y ago

Just in time for v3.0!

deleted 7y ago
[deleted]

eknkc 7y ago

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 7y ago
+1 on Svelte. Seems like the better/faster option.
- MaxBarraclough 7y ago
  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 7y ago
    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 7y ago
      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/
- wildpeaks 7y ago
  I was tempted by Svelte for a while, but in the end Preact remained the best fit for our needs because the output filesize grows slower with Preact than Svelte. 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.
woutr_be 7y ago
To me the difference is that Svelte is a lot more pure JavaScript than Vue. I haven't had the chance to use it in any larger project, but in my small playgrounds, I've definitely enjoyed it more than Vue.
- NetOpWibby 7y ago
  If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page https://webb.page I’m glad to see Svelte growing in popularity here.
  - benbristow 7y ago
    That page could literally just be a static web page or built using a static site builder like Jekyll/Hugo etc?
    - NetOpWibby 7y ago
      Of course it could but once you have a starter template setup it becomes an easy to jump right in.
  - leadingthenet 7y ago
    What exactly are you using Svelte for? It seems to literally be one HTML page...
    - NetOpWibby 7y ago
      To put it simply, I like it. Plus, I have a starter template project that makes it easy to just code and go.
  - cmroanirgo 7y ago
    Viewing the source shows an html page without a closing body nor html tag: it's probably not the best case for showcasing it seems. The layout it all over the place too using FFox, (it's fine on Chrome and Safari) so it also seems to be lacking in some basic cross browser testing, which again, is not good news when show-casing a framework, as a frameworks' prime responsibility is to ensure cross browser/platform uniformity. Hopefully this all boils down to a simple 'oopsie' in your project, rather than svelte.
omnimus 7y ago
But react and vue are underneath much closer to each other than Svelte. Sure vue and svelte use templates and react doesn't but that's about it. 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.
- twsted 7y ago
  > 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.
  - omnimus 7y ago
    So how do i extend component in mediawiki without having to recompile its source? How would i reuse that <mediawiki-table/> distributed in core and reuse it in user installed plugin?
darkcha0s 7y ago
Why would the WM foundation use a relatively unknown framework? They don’t just care about the actual coding itself, the have to concern themselves with community, support and longevity. You said yourself you wish it would gain more traction, and that’s something an Org like that doesn’t take a gamble on to be fair.
KaoruAoiShiho 7y ago
Actually using Svelte its main downside is the giant file size. I consider it unusable for that reason alone. Any minor speed advantages is entirely negated.
Can_Not 7y ago
Svelte lacks the robust and reliable error handling that Vue and React have.

112 7y ago

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.

izelnakri 7y ago
ember with typescript should be an option for you
z0mbie42 7y ago
I would love to know why are you saying this. I use Vue2 + Typescript, and for me it works great! Even Auto-completion works.
- fraktl 7y ago
  Because he never used Vue with TS. It's a blatant lie and utter bullshit.
- 112 7y ago
  It's OK for the most common scenarios, I didn't comment on the regular "build a web app" case, but more complicated ones. I think @vue/cli is very nice, but I've had many issues dealing with the magic behind it, so much that it became easier to swap vue-cli-service with rollup and custom setups. I'm sure Vue3 will fix all this, and it will be awesome. Very much looking forward to it
mcny 7y ago
I've only used angular but I'm curious, why has angular never been an option for you? 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?

jeswin 7y ago

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.

martin_a 7y ago
Right now, Corona made some time for that, I'm rewriting something I tried to do in Vue. I don't work with Vue daily and that makes it real hard to do even the simplest things. I'm back to vanilla JS, few sprinkles of jQuery and HTML5. Works well for me.
- shirshak55 7y ago
  exactly. React works so well with js. And vue claims to be simple but tbh its hard. working with async await function, promises are so weird. And you need packages for simple stuff also.
  - Can_Not 7y ago
    Really? async/await just works by in Vue. And React doesn't need packages for simple stuff? Really??? Are you sure you've ever used Vue?
boobsbr 7y ago
That feels like learning Angular template syntax, and I really dislike it. React has its warts, but I find JSX very readable, much more flexible.
- ptrwis 7y ago
  I dislike both. Most readable template syntax for me is PHP's "alternative syntax for control structures" (the one with colons instead of braces and closing keywords).
  - 7y ago

speedgoose 7y ago

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 7y ago
className vs class is a non issue when you use CSS modules or CSS-in-JS.

Kiro 7y ago

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.

tjpnz 7y ago

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

rutierut 7y ago

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.

TekMol 7y ago

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 7y ago
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.
- otabdeveloper2 7y ago
  How in seven hells is moving imperative loop constructs from Javascript to HTML supposed to be "declarative"?! If anything, it's the opposite - you're now polluting HTML with imperative programming features where there previously were none.
- TekMol 7y ago
  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.

pmarin 7y ago

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

k__ 7y ago
Modern JavaScript runs on the server just fine, they will probably use server side rendering and build time rendering.
- vorpalhex 7y ago
  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__ 7y ago
    Static site generation is very cheap in terms of generation and delivery.
    - vorpalhex 7y ago
      Yes, SSR and static are not the same.
  - karatestomp 7y ago
    Weird, most of the fastest-feeling sites I use are server-side rendered. Though I doubt they use any JS in that path. Maybe basic html Gmail does but probably it’s Java or something.

longtermd 7y ago

A warm Welcome to the Vue family! :)

Alex_P13 7y ago

Top 20 free and premium dashboard template in 2020 To track all the performance on your website, these free dashboard templates come very helpfully for your website. With a dashboard template, you’ll know exactly how well your online project is doing. For example, track sales, new members, likes, profits, tickets, you name it, it can all be done inside your ultimate dashboard. https://is.gd/P7BmMm https://is.gd/P7BmMm

maps7 7y ago

Isn't Vue 3 vastly different to Vue 1 and 2? Also why not Svelte?

rk06 7y ago
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 7y ago
  Ah good to know!

tannhaeuser 7y ago

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.

pier25 7y ago

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.

oleskiewicz 7y ago

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 7y ago
The intent of this RFC is to improve the places where JavaScript is already used like management tools and editing.

jeroenhd 7y ago

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.

k__ 7y ago
I'm a React fanboy, but I have to admit, the Svelte performance and code size is impressive. Maybe that would be a feasible way to get a modern developer experience without the bloat?
- marcus_holmes 7y ago
  One of their criteria is widespread adoption. Svelte isn't there yet. One day it probably will be, but today is not that day.
  - slantyyz 7y ago
    I think that's a chicken egg thing. If Wikimedia adopted it, adoption rates would skyrocket.
    - rk06 7y ago
      Really, what makes you believe so? IMO, to drive adoption rates, you would need dev evangelists While the RFC states that they are taking cautious route here. They also mention that they are not making an SPA which all the cool kids look up to.

layoutIfNeeded 7y ago

Please don't make Wikipedia a JS monstrosity :(

k__ 7y ago
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 7y ago

I think you should have supported Web components

a_imho 7y ago

It reads as a solution looking for a problem.

MatthewPhillips 7y ago

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.

brabel 7y ago
It's not just a bad idea... it's a horrible, dangerous idea. All of their points can be easily addressed with a static site generator or just some CMS that lets you write pages using templates instead of just pure HTML. That's absolutely declarative, a lot more than a JS-framework based app. The only point that would be missing is the reactive part as you mention: but who the hell expects a wiki to be reactive?! I expect it to be as close as possible to the printed version! A Wiki is NOT a web app!
- otterlicious 7y ago
  > a static site generator You really think 140,000 people are going to learn git all of a sudden?
  - Fnoord 7y ago
    Learning Git (there are GUIs for it as well) can aid one in so many additional ways though.
EvanYou 7y ago
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).

torgian 7y ago

This looks like a backwards solution to a modern problem.

cheapsteak 7y ago

>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

ddevault 7y ago

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.

unionpivo 7y ago
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
- ddevault 7y ago
  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.

belval 7y ago

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 7y ago
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
- enriquto 7y ago
  Whatever, but if wikipedia somehow becomes unusable without javascript, it will be a real tragedy.
  - jdlrobson 7y ago
    You dont need to be worried about this. Our morales and principles are not changing. I built the Wikipedia mobile site and there's a reason our hamburger menu, lazy loaded images and editor actually work without JS. We are for everyone regardless of internet connection speed, device value and internet stability. That's a a hill at least I as an employee am prepared to die on.
    - enriquto 7y ago
      I cannot express how reassuring your words are, and how happy I am to hear them. Thank you very much! Well; it turns out that I can: just made a donation.
    - belval 7y ago

deleted 7y ago

[deleted]

otabdeveloper2 7y ago

Good, I needed a reason to stop using Wikipedia. Good bye.

heinrichhartman 7y ago

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.

deleted 7y ago

[deleted]

HumblyTossed 7y ago

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

EvanYou 7y ago

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.

cptskippy 7y ago
> 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). 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.
BiteCode_dev 7y ago
This is IMO one of the killer features of vue. 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.

lwh 7y ago

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

austincheney 7y ago

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

alphachloride 7y ago

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.

katabasis 7y ago

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 7y ago
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

user34234 7y ago

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.

superkuh 7y ago

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.

b34r 7y ago

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.

aliswe 7y ago

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?

sufyanadam 7y ago

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.