[EvanYou]

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

- This does not mean Wikipedia is becoming an SPA. One of the reasons they picked Vue is because Vue can be used to progressively enhance a statically rendered page (just like jQuery, but with a declarative development paradigm), and it allows you to do so without a build step (while keeping the going-full-build-step option open).

- Wikimedia is not just Wikipedia. There are many other use cases across the Foundation where heavy interactivity is needed. Even within Wikipedia, there are cases like the editor / edit mode which can be considered non-trivial JavaScript applications.

- Adopting a new framework !== More JavaScript. Wikimedia already has an in-house framework which has become outdated and difficult to maintain. Adopting Vue allows the team to implement the same features with less code. It will shave off instead of adding to the bloat.

[BiteCode_dev]

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]

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

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.

[ng12]

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

I won't argue that bootstrapping a React project is more complicated than a Vue project. I will argue that React's developer ergonomics are much better.

> Everybody has a boilerplate one of course. Nothing is standardized, so the ecosystem is not reusable.

Not sure what you mean. We use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.

> Simple things like placing a setInterval()/clearInterval() at the right place

This doesn't make sense to me. The pattern for setting/clearing an interval with the class-based React API is identical to Vue. With React's hook API it becomes even easier.

> or conditionally settings classes on stuff is not straightforward

How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript. I get really tired of the "how do I do task X in Framework Y". I want to ask that question as few times as possible.

My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.

[BiteCode_dev]

> I will argue that React's developer ergonomics are much better.

Depends for what. For industrial size project, a little, because of the better typescript support. But that's it. You have the same vscode and browser extensions otherwise.

> we use CRA at my company and I can comfortably drop into projects I've never seen before with complete confidence.

First, on this part I'm talking about JS in general. Only a minority of projects use react.

Of course, not all projects use CRA. Many projects use different versions of react with different things you can do with it. Many projects will chose different convention for adapting components, passing children rounds, talking to parent, binding function, etc.

And I _never_ see two react projects with the same me directory tree. There is no strong convention on it.

Then you must chose.

One project is using an inhouse store with useContext, on other use manual redux with that convention, on use redux with that other convention, one use redux-toolkit, one use manual mobx with that convention, one use mobx react, etc. None of them work the same. None of them integrated the same.

And that's just for one lib. One project as many of such libs, all integrated manually.

And yet, the CRA experience is supposed to be one of the best integration you can have.

When you come from another world like Ruby or Python, it's a mad house.

In fact, I'll argue than only experienced programmers manage to get a consistent experience in the JS world.

> Simple things like placing a setInterval()/clearInterval() at the right place

Nope, in react you can use lifecycle OR hooks. You have to choose. And they don't work the same at all.

In vue, for a simple hello world, you can even place the setInterval outside of the component and hapily modify the model, it will update. You don't have to figure out the lifecycle for small app, only for a reusable component.

>How? It's just JavaScript, write a conditional. This is exactly what I'm talking about: you don't need to know how to conditionally set a class in React, you just need to know how to conditionally set a value in JavaScript.

C strings are just an arrays of char, so you don't have to learn those pesky high level string objects in those modern language with all their new fancy API.

> My go-to example to explain why I find React so much simpler is Vue's slots. It's an entire API that many people find confusing to replicate something that comes for free in React.

In both case the user will google "how to get a reference on children components". There is now way you can guess that it's passed as props.

And then, you will want to have several children at different places. And now the illusion breaks, because props.children doesn't work, you have to manually pass each children as props, and you can use them nested as before. And because it's not a "feature", but a convention, you have to know that you need to do that for components that use it. So it's no more natural that slots.

While in vue, you still use slots, you just give them names. The feature is congruent from the simple use case, to the advanced one.

So maybe for the simple case it took 5 minutes in react, and 6 in vue, and the same time for the complex case. For a rarely used feature.

[iaml]

>no Django/RoR equivalent in JS

Both angular and ember are pretty close in my opinion.

[BiteCode_dev]

They are client side, not server side.

They have a very, very limited scope.

They don't have to deal with the DB, the authentication, the permissions, the deployment, the creation of a REST API, the migration, the mix of several run times, uploads, logging, sending emails, session management, etc.

And yet.

Their support for i18n, validation, routing, caching, pagination, data formating and presentation - what they should be good at - is abysmal compared to what you can do with django/ror.

The only thing they are better at is templating and creating a hierarchy of components. Which is the least they can do given they are literally there to render the UI.

[iaml]

Ah, for some reason I thought you meant clientside alternatives. For backend, there is sails and now nestjs.

[TheDong]

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]

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

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]

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]

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]

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.

[rhengles]

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