7 ms·

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 picke

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.
- ng12 7y 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.
  - TheDong 7y 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.
  - BiteCode_dev 7y 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.
est31 7y 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 https://vue-hn.herokuapp.com/item/22625556 [2]: https://ssr.vuejs.org/ https://ssr.vuejs.org/
- spyckie2 7y 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 7y 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.
abbe98 7y 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.
rhengles 7y 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 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.

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.

ng12 7y 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.
- TheDong 7y 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.
- BiteCode_dev 7y 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.

est31 7y 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 https://vue-hn.herokuapp.com/item/22625556 [2]: https://ssr.vuejs.org/ https://ssr.vuejs.org/

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

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

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