Silkenweb Example: Hackernews Clone

RFC: Adopt a modern JavaScript framework for use with MediaWiki

309 points by aliveupstairs 5 years ago | 277 comments

katabasis 5 years 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
- trynewideas 5 years ago
  For context about OOUI and OOjs: https://www.mediawiki.org/wiki/OOUI/Using_OOUI_in_MediaWiki, 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
EvanYou 5 years 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.
- BiteCode_dev 5 years 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.
  - ng12 5 years ago
    > 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!").
    I tend to have the opposite reaction. I want a framework with a small API I can keep cached in my head. I don't want to worry about finding the magic switches to get it working the way I want.
    - BiteCode_dev 5 years ago
      I see that a lot in the JS world, "libraries over frameworks" and all that.
      The result is that when you go from project to project, people solve the same problems, again and again, in a different way. And create their own custom abstractions, badly tested and documented.
      Eventually, the API you could "keep cached in your head" lead to a system you MUST keep in your head because it's very hard to follow how things work and you need to remember it all to be productive. Debugging, extending and onboarding suffers.
      Another consequence is that there is still no Django/RoR equivalent in JS. Building any medium size app is a total waste of time, doing the same boiler plate over and over for problems solved 10 years ago.
      Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable. Any pluggable library must carefully chosen, then be manually integrated in your own Frankenstein creature, not to mention you end up with a TON of dependencies.
      Vue doesn't have a big API. I learned the entire of vue in an afternoon.
      It took me 2 weeks to understand react, and much more to actually write decent code with it. Practically, react is very unproductive without something like create-react-app because you have to take so many decisions about it for every new project. Simple things like placing a setInterval()/clearInterval() at the right place, or conditionally settings classes on stuff is not straightforward, anything more complicated must be meticulously though.
      Because of this, when I give a training in react and one in Vue, the people from the vue training will immediately be 3 times more productive: their projects move faster, it rarely hit a read block later. I also get way, way less questions in the vue training.
      Let's not confuse "barebone API" and "easy API". It's not the same.
    - TheDong 5 years ago
      Unfortunately, javascript web frameworks build on top of the javascript APIs browsers expose.
      If you're starting from a set of APIs that are too complex for someone to keep in their head, it's hard to end up with a much simpler API.
      Especially since people do use a large portion of the web's APIs.
      For example, "prevent", the thing in the parent comment, is needed if you use javascript to submit your forms, but isn't needed if you have a form that is expected to be submit by the normal browser mechanism.
      Webframeworks rarely are prescriptive to the point where they can default in one direction or the other on that point.. and thus we end up with another option.
      That repeats many times over and we end up with a large API surface.
- cptskippy 5 years 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.
- abbe98 5 years ago
  Exactly this. Currently MediaWiki and many of its extensions have its interactive parts (editor/maps, etc) written in jQuery and the in-house developed framework OOUI. These are the pieces which might slowly be replaced by Vue.
  Hopefully this will also make it easier for new contributors to get started with MediaWiki development.
- est31 5 years ago
  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
  [2]: https://ssr.vuejs.org/
  - spyckie2 5 years ago
    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.
  - EvanYou 5 years ago
    AFAIK there is currently no plan to replace existing php rendering with Vue SSR. They just wanted to make sure the framework they went with supports SSR so they are not locking themselves out of the possibility.
    The HN implementation renders the comments on the client side because it was using the Firebase HN API which doesn't provide a friendly API for fetching the entire comment tree. Notably, some other HNPWA implementations were using a custom API endpoint. We didn't switch to it because the Vue HN was built as an educational demo rather than a benchmarking subject.
  - 5 years ago
- rhengles 5 years ago
  > One of the reasons they picked Vue is because (...) it allows you to do so without a build step
  I think it's great that Vue is capable without a build step; however, this implies one restriction, which is that you must have all the components loaded before the application starts. And Async components don't help here because you would have to mantain a list of components names, which without a build step become cumbersome.
  I would like that my proposal for lazy loading components (https://github.com/vuejs/vue/pull/8807) would be accepted, then we would have the ability to load components on demand without a build step.
jeroenhd 5 years 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.
- joshwcomeau 5 years ago
  A lot of the questions you're rhetorically asking are answered in the RFC you're commenting on.
  Specifically, they had real problems with their current system, which they documented here: https://phabricator.wikimedia.org/T225453. Then they explored the available options in the ecosystem and came up with the one they thought would best fit their needs.
  If you're gonna be critical, at least take the time to understand what they're doing and why.
  - draw_down 5 years ago
    HN will never pass up an opportunity to shit on JS or especially web frameworks, without fail. It’s actually sort of entertaining.
  - jeroenhd 5 years ago
    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 5 years ago
      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.
- t0astbread 5 years ago
  The proposal stresses the need for Server-Side Rendering so I suppose they're thinking about this.
  - otterlicious 5 years ago
    Yeah it's very clear that they still plan to have the website work without JavaScript.
    In the longer term, adding support for a frontend build step in deployment and for server-side rendering (SSR) of UI components are two tasks that would be particularly useful here...
    Until such features are in place, use of Vue.js would be limited to cases where server-rendered elements can be progressively enhanced within the user’s browser.
  - marcus_holmes 5 years ago
    No idea why you were downvoted - this is the answer to that question
- hombre_fatal 5 years ago
  > but Wikimedia is a website and not a web application
  Check out the /edit mode for any page. It's already a non-trivial JS app.
  - est31 5 years ago
    I'm ok with their interactive editor being written in SPA style. Most of Wikipedia's billions of users aren't editing pages though. For them, WP should focus on rendering speed which means lowest complexity possible, which means keeping the serialized DOM technology.
  - bawolff 5 years ago
    The edit view that most power users use is definitely not an spa.
    There are multiple "editors" in use on wikipedia et al. Visual editor and mobile edior are more SPA-ish, however the old fashioned <textarea> full of code, editor is still very popular among users.
    Disclaimer: work for wikimedia, but not on stuff related to this. My opinions are my own.
    - mch82 5 years ago
      Another interesting note is that Parsoid, the nodejs service that turns wikitext into the Visual Editor, is being ported from js to PHP.
    - folmar 5 years ago
      The texarea is also currently the default, at least on English edition.
- k__ 5 years 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?
  - ivanfon 5 years ago
    Svelte is my favourite framework right now (it's really reignited my love for web development after using React for a long time), but unfortunately one of their criteria/use cases was "build step as well as no build-step", which doesn't work since Svelte is a compiler.
    While I thought dropping the "no build-step" requirement wouldn't be a big deal nowadays, they later say:
    > We should still explore introducing a full build step in the future (including full support for module bundling, ES6+ transpilation via Babel, etc), but this is a non-trivial change to the architecture of MediaWiki.
    I can see why going with something that doesn't need a build-step could be appealing.
    There's also the other factor (mentioned below) about community. If MediaWiki chose Svelte, they would definitely have to invest a lot into the framework and it's community, and I'm not sure if that's something they want to or are capable of doing. The biggest pain point with Svelte right now (at least for me) is the tooling, it's real bad.
    This is the only mention about Svelte:
    > Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever).
    I'd be interested in seeing a bit more discussion about it.
  - marcus_holmes 5 years 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 5 years ago
      I think that's a chicken egg thing. If Wikimedia adopted it, adoption rates would skyrocket.
- aww_dang 5 years ago
  >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.
  It is even worse when these pages are basically images and text. SPAs have their place and people can develop them as they wish, but I fail to understand why these frameworks have become the go to solution for every page.
- nwsm 5 years ago
  >Will Vue and React work on 2G cell phones running super basic browsers?
  Yes
  >Will screen readers support all elements created by the Javascript framework?
  Yes
  - untog 5 years ago
    React won’t work well on 2G cell phones with slow CPUs. It’s a giant library both to download and parse and most of it is entirely unnecessary.
ddevault 5 years 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.
- ricardobeat 5 years ago
  I'm happy to see another big project commiting to Vue, but found the rationale funny to say the least, having seen the same kind of analysis multiple times. For example, these requirements:
  - UI elements created within the framework are reactive (update automatically in response to changes in data or user input) by default - The framework is heavily optimized for performance
  should automatically exclude React itself, but it seems to have been the second option. Despite appearances React is not very reactive, especially with hooks where you do dependency management yourself. Performance is not a given either, nothing is memoized by default and it's all up to the implementer (or the state management system) to actually optimize rendering at all.
  The 'large community' mindset which automatically dismisses Svelte and Preact all the time is the most heartbreaking. If we worked with the herd mentality five years ago, neither or React or Vue would have been born and some variant of Backbone would still be the most used view library.
- spyckie2 5 years ago
  no offense but it sounds like you're doing a kangaroo court evaluation of their evaluation by making assumptions to what they did and didn't consider and not looking deeper into the context of the RFC.
- unionpivo 5 years 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 5 years 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.
- azangru 5 years ago
  > 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 5 years ago
    > 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 5 years ago
      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.
  - ddevault 5 years ago
    Wikipedia is just hyperlinked documents. The WWW has been suited for this from the start. Not everything needs to be new and shiny forever.
    - azangru 5 years ago
      > Wikipedia is just hyperlinked documents.
      Wikipedia at the very least has the editor for all those documents.
- tln 5 years ago
  I agree that no build step is a false economy. With a build step writing Vue and react are better... Use up to date JS, minified and split bundles, single file components, etc
  Points 2 and 3 I agree with though. Vue is more complete than react the library and the Vue stack has had less churn.
  I see your point about potentially leaving behind very old devices. I don't know Wikipedia's compatibility stance. It may not be fair to say it's overlooked as the decision within this RFC is only about modern JS frameworks. The decision to adopt could take that into consideration
  I have to disagree about the Kangaroo court accusation, that seems unfair
- draw_down 5 years ago
  Hmm, in principle I would agree but in practice, I think it wouldn’t make a difference here. Even if it were more even-handed the contenders they would be choosing among are acceptable substitutes for one another. Like, I couldn’t see this being a failure with React but succeeding with Vue. In a lot of these sort of situations, you just need to pick something. I agree that those criteria sound contrived, though.
  Personally, I work in React all day and I’m comfortable with it, but I could just as easily use another. There would be minor differences that may annoy to some degree, but it wouldn’t make a huge impact. They all do basically the same thing.
112 5 years 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.
- manigandham 5 years ago
  Vue 3 will change all that. It's written in typescript with first-class support and the composition API is like React hooks but better for most cases.
  Vue's templating is standard HTML which means it can be delivered by any server-side language/framework. This is where Vue shines in adding interactivity to many typical apps without going fully SPA.
  - williamdclt 5 years ago
    It is standard HTML in the sense that it's valid HTML, which React JSX isn't, of course. But without the JS runtime it won't do anything, so in the end what's the advantage over React? You can add interactivity without going full SPA with React too after all
    - manigandham 5 years ago
      It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page.
      With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.
      This lets you render the page using existing web frameworks, it's faster because the server puts it together, it's progressive enhancement and works without JS and on slow devices, and Vue can seamlessly add on top with nothing more than a single JS tag and no compilation step.
  - keithnz 5 years ago
    you can use the composition api already in Vue2, which is what I have been doing, and I'm using typescript for everything. There is a chance the api may change, but it seems pretty stable. I combo this with using tailwindcss and I think that makes for a pretty productive combo.
  - StreamBright 5 years ago
    >> This is where Vue shines in adding interactivity to many typical apps without going fully SPA.
    That is good to know. I wasn't aware. Most of the apps we are working on cannot be SPAs easily, so it matters if the JS framework supports operating without it.
  - DanielBMarkham 5 years ago
    Apologies, I a bit confused. SPA stands for Single-Page Application, does it not? So if you have a single page that works as an application, it is a SPA, no?
    I understand the desire to use webkit, Typescript, and so forth to develop modern apps, I'm just confused at why Vue in a stand alone page delivered by ftp or usb drive isn't a "full" SPA
    - oefrha 5 years ago
      You can mix and match traditional server-rendered content and JS framework (in this case Vue)-rendered components on the same page (not considering SSR here). Going full SPA means using the latter exclusively.
  - sebazzz 5 years ago
    Vue 3 is getting delayed, isn't it? Not weird for a community project, but still something to note.
    - manigandham 5 years ago
      I don't know, there's no hard deadline but you can check the official roadmap: https://github.com/vuejs/vue/projects/6
- baybal2 5 years ago
  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 5 years ago
    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 5 years ago
      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.
  - chvid 5 years ago
    I agree with this.
    TypeScript makes Java and .NET developers think they understand the language and platform and causes a lot of irrelevant design to be copied over into the JS world where it mutates and becomes absolutely poisonous.
    Just look at Angular where the boilerplate and crazy dependency injection completely surpasses anything seen in the Java / .NET world.
    - dynamite-ready 5 years ago
      It's especially apparent when Java / C# developers are introduced to a simple idea like a Flux pattern store.
      Store structures, despite the initial difficulty in learning the pattern, simplify things enormously, but can somehow become nightmarishly complicated in the hands of a developer who expresses API/client relationships in terms of Factories and Services... When it's not hell to work with, it's actually quite interesting to observe.
  - manigandham 5 years ago
    Why? Typescript just compiles down to JS, and type definitions are used IDEs so they still help when writing JS.
    How does removing typescript help you?
    - baybal2 5 years ago
      > How does removing typescript help you?
      https://github.com/microsoft/TypeScript/issues
      Please count the number of open bugs
      JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness.
      Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.
      On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day.
      Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.
      Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it.
      No, it does not pay off at all
  - ThePhysicist 5 years ago
    Why do you have to de-typify Typescript dependencies? You can mix typed and untyped code with a gradual typing approach, and tools like webpack make this very easy?
  - bregma 5 years ago
    To be fair, cargo-cult programming is a scourge in any domain. Since the cult many folks started with when they took their college (or free online) programming course was Java, all cargo looks like Java.
  - Vinnl 5 years ago
    > we have a problem of having to "de-typescript" a lot of 3rd party code.
    What do you mean by this? npm packages at least are already "de-typescripted", in the sense that they're just .js files with accompanying .d.ts files describing the former to people using editors with TypeScript support.
    (Also, it feels like you've experienced a weird subset of TypeScript code. It also happens to be an enormous help when doing things "the Javascript way", which is what it's actually designed for. But I can imagine that encountering bad apples can sour the experience for you.)
  - 112 5 years ago
    Every language comes with its own culture, and with its own stereotypes. Java's over-engineering and boredom, JavaScript's throwing shit on the wall and see what sticks, PHP's developers that do stackoverflow-driven development.
    There are experts, average people, and bad people in every field. TypeScript brings sanity that is valuable for both experienced developers and less experienced developers.
    The peace of mind that you get with types when doing refactoring is invaluable. I would never be able to go back and write vanilla JavaScript, because it's broken.
    You can over-engineer and write crap code in any language.
    Also a comment on anyone that says experienced devs get no benefit from types: you think you're good, but you're not. As good as you think you are, if you seriously deny the benefits of static typing, you're probably shit as a developer. If you understand static typing and it's benefits then you agree it's a good trade, if you don't understand it and still have a strong opinion against it, then you're just a lazy human.
  - 5 years ago
  - Kiro 5 years ago
    Sorry, but that's just crazy. I would avoid your company like the plague.
    - W4ldi 5 years ago
      I've worked with both. And I have to say: It depends. Mostly I feel like typescript slows me down A LOT. In my opinion, the better your code style, guidelines, linting, infrastructure, error reporting and tests - the less you need typescript. I worked in a team that had about 150 micro-apps and services, it was maintained by roughly 15 devs. Each microservice had it's very small scope and it was very very easy to work with it. Everything was very predictable, which made it easy to work without having types.
- se7enzer0 5 years ago
  Vue 3 is not too far off and has first class TypeScript support.
- z0mbie42 5 years 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.
  - 112 5 years 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
  - fraktl 5 years ago
    Because he never used Vue with TS. It's a blatant lie and utter bullshit.
- mcny 5 years 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?
  - 112 5 years ago
    React with TypeScript is a joy. I have the utmost respect for Angular, and for the way it pushed forward progress on frontend. Vue itself has taken many great ideas from Angular.
    It hasn't been an option for me because I found it quite opinionated for personal projects, and in my work context I didn't enjoy / respect the people that were working on Angular projects. This is not about Angular, it's about where I was working and the people there.
    It's easy to judge a tool by it's users, but we mustn't.
- marcus_holmes 5 years ago
  I use Vue without a compile step (I abuse Go's templating engine to achieve this). Mostly to avoid the security nightmare of Webpack's 434583593e4735683 dependencies (and most of the other options are not much better) so Typescript is not an option. I love that I can do this with Vue (I can't with React).
  - STRiDEX 5 years ago
    so what you're saying is you avoid vue's poor typescript support by not using typescript
    - marcus_holmes 5 years ago
      more like I'm prevented from enjoying Typescript's advantages by the fact that using it would require me to sign up for a vast dependency network
- izelnakri 5 years ago
  ember with typescript should be an option for you
- fraktl 5 years ago
  What you wrote is blatant lie, particularly the part with creating a typed component library. I've created 7 components as of yesterday, using TS, zero hacks and zero problems.
  It's so annoying when a person with clear lack of understanding decides they're competent to critique a tool and then they literally - lie.
  Keep using React, it's awesome you like it but please - do some fact checking. I know you want to believe that Vue and TS don't play together, but that's just not true.
  - nullc 5 years ago
    Would it be so hard to start with an assumption that the person you're responding to is working with outdated information or that they're just confused?
    Even if they were intentionally lying (why??) it would hurt no one to humor it and be polite, and it would do a lot towards making this a more enjoyable place to read.
    Your post was informative, too bad it made me just want to close this tab.
    - fraktl 5 years ago
      > Would it be so hard to start with an assumption that the person you're responding to is working with outdated information or that they're just confused?
      Yes.
      > Even if they were intentionally lying
      Never wrote anyone lied intentionally.
      > it would hurt no one to humor it and be polite, and it would do a lot towards making this a more enjoyable places to read.
      I'm a programmer used to relay information in least words possible, so I just refer to factual observation. Whether I used word "lie" or had I masked it in a wall of text to spare feelings of flowers - meaning is the same. I consider all people my peers so I don't do to them what I don't want done to me - saying pretty words to hide the meaning.
      > Your post was informative, too bad it made me just want to close this tab.
      But you had to type what you have before you closed it. I mean, you're calling me out for being impolite by being impolite. I get the whole hypocrisy move and SJW reflex, but my stance is that IT and developers need to relay truth to one another in form of information, not prettify the stuff so people's feelings don't get hurt.
      Your feelings got hurt? You didn't get coronavirus because of my text, you'll be ok.
      Take care :)
MatthewPhillips 5 years 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.
- EvanYou 5 years 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).
  - MatthewPhillips 5 years ago
    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.
- brabel 5 years 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 5 years ago
    > a static site generator
    You really think 140,000 people are going to learn git all of a sudden?
    - Fnoord 5 years ago
      Learning Git (there are GUIs for it as well) can aid one in so many additional ways though.
tannhaeuser 5 years 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.
pmarin 5 years ago
Most of Wikipedia works perfectly without Javascript I hope it will continue to do so.
- k__ 5 years ago
  Modern JavaScript runs on the server just fine, they will probably use server side rendering and build time rendering.
  - vorpalhex 5 years 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__ 5 years ago
      Static site generation is very cheap in terms of generation and delivery.
    - karatestomp 5 years 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.
HumblyTossed 5 years 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 5 years 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 5 years 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 5 years 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.
    - sequoia 5 years ago
      Go look at the lighthouse score on my blog: https://sequoia.makes.software/
      Also a 100 on performance & time to interactive 0.9 seconds. What are the key features of React that you use to set your blog apart from mine?
  - 5 years ago
- Richicoder 5 years ago
  That's because the issue they're trying to solve is being slowed down by existing JavaScript tooling and infra. This is very explicitly to improve Dev UX. And they already called out the most important concern when switching to a new lib:
  > The framework is heavily optimized for performance.
eknkc 5 years 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.
- darkcha0s 5 years 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.
- woutr_be 5 years 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 5 years ago
    If you wanna see Svelte in production, I’m using it for my homepage: https://webb.page
    I’m glad to see Svelte growing in popularity here.
    - cmroanirgo 5 years 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.
    - benbristow 5 years ago
      That page could literally just be a static web page or built using a static site builder like Jekyll/Hugo etc?
    - woutr_be 5 years ago
      Is it open-source? Otherwise it just looks like any other website, the code would be a lot more useful.
    - leadingthenet 5 years ago
      What exactly are you using Svelte for? It seems to literally be one HTML page...
- sdan 5 years ago
  +1 on Svelte. Seems like the better/faster option.
  - wildpeaks 5 years 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.
  - MaxBarraclough 5 years 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 5 years 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.
- Can_Not 5 years ago
  Svelte lacks the robust and reliable error handling that Vue and React have.
- KaoruAoiShiho 5 years 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.
- omnimus 5 years 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 5 years 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 5 years 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?
belval 5 years 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 5 years 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
  - vorpalhex 5 years ago
    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
    - majewsky 5 years ago
      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.
  - enriquto 5 years ago
    Whatever, but if wikipedia somehow becomes unusable without javascript, it will be a real tragedy.
    - jdlrobson 5 years 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.
  - 5 years ago
- whycombagator 5 years 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 latter seems an overreaction given the former.
  - belval 5 years ago
    It is absolutely an overreaction, and I don't see myself going through with something like that. I use the site probably daily and feel like I have to donate.
lwansbrough 5 years 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.
jeswin 5 years 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.
- manigandham 5 years ago
  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 5 years ago
    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 5 years ago
      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.
    - manigandham 5 years ago
      Yea, the 1% of the time you need that extra control then you can easily use JS render function or JSX. The documentation covers all of this: https://vuejs.org/v2/guide/render-function.html
    - keithnz 5 years ago
      I haven't found it very limiting, however, because it is very well defined, in Vue3 they are looking to actually use this to make massive optimizations in rendering that you simply can't make when you use javascript anyway you like to assemble things.
  - shirshak55 5 years ago
    and using promises with vue is nightmare.
    - manigandham 5 years ago
      Using promises where? And what's difficult about them?
    - Can_Not 5 years ago
      [Citation Needed]
- boobsbr 5 years 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 5 years 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).
    - boobsbr 5 years ago
      That feels like JSP to me, and I don't have fond memories of JSP.
- untog 5 years ago
  > Couldn't see the value there.
  When you're choosing a JS framework you need to factor in the experience the user has along with the experience you have. I don't know much about Vue but React comes with a huge amount of bulk. A lot of JS that has to be parsed before anything can even be done on the page.
  If you're choosing React because it allows you to fall back on what you know rather than learn something new you're making an ill-informed choice.
- martin_a 5 years 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 5 years 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 5 years 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?
- rk06 5 years ago
  do you want to see the value? if so, here it is:
  By itself, there is no inherent value in either v-for or Array::map(). However, these choices do not exist in a vacuum, they are other decisions in place, which do provide significant value:
  - React, allows full power of js when writing template. and easy to express and decompose components into functions. while Vue does not allow the fine-grained in template unless you go into Vue's JSX) - Vue, via template-based approach, enables Developers to deploy apps without a build step, while React forces devs to add a build step(and a compelx one at that) to pipeline
  - Can_Not 5 years ago
    React: supports JSX and vanillajs render function.
    Vue: supports JSX, vanillajs render function, pug, and its default HTML templates.
    You: "React allows full power of js"
    Ok
oleskiewicz 5 years 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 5 years ago
  The intent of this RFC is to improve the places where JavaScript is already used like management tools and editing.
superkuh 5 years 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.
a_imho 5 years ago
It reads as a solution looking for a problem.
user34234 5 years 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/, and alternatively Turbolinks + Stimulus.
Most applications do not need Vue or React there is a HUGE abuse of client side JavaScript these days.
tjpnz 5 years 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 5 years 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.
austincheney 5 years ago
Do they really need a large framework? It is possible to write fast elegant applications in JavaScript without a framework.
speedgoose 5 years 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 5 years ago
  className vs class is a non issue when you use CSS modules or CSS-in-JS.
jcarlosweb 5 years ago
I think you should have supported Web components
heinrichhartman 5 years 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.
pier25 5 years 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.
sufyanadam 5 years 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.
cheapsteak 5 years 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
maps7 5 years ago
Isn't Vue 3 vastly different to Vue 1 and 2?
Also why not Svelte?
- rk06 5 years 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 5 years ago
    Ah good to know!
lwh 5 years ago
Not needing JS is a key feature of MediaWiki. It would be great if the old CSS+HTML skins still worked with this.
5 years ago
TekMol 5 years 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 5 years 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.
  - TekMol 5 years 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.
  - otabdeveloper2 5 years 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.
rutierut 5 years 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.
aliswe 5 years 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?
torgian 5 years ago
This looks like a backwards solution to a modern problem.
alphachloride 5 years 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.
b34r 5 years 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.
5 years ago
otabdeveloper2 5 years ago
Good, I needed a reason to stop using Wikipedia.
Good bye.
Kiro 5 years 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.
noodlesUK 5 years ago
Just in time for v3.0!
- 5 years ago
longtermd 5 years ago
A warm Welcome to the Vue family! :)
layoutIfNeeded 5 years ago
Please don't make Wikipedia a JS monstrosity :(
- k__ 5 years 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.
Alex_P13 5 years 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