10 ms·

Vue.js is Wikimedia Foundation's future JavaScript framework

353 points by Volker-E 5y ago

timdorr 5y ago
Most of the discussion behind this decision, including feedback directly from Evan You (author of Vue), is here: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180 It's pretty interesting to read through.
- skybrian 5y ago
  This discussion is from early 2020 and the decision seems to have been mostly made by then, but they’re announcing it now. I guess everyone’s been busy, what with a pandemic and all. :)
  - katabasis 5y ago
    Various teams have been using Vue on a more experimental basis over the last year. The new Media Search tool on Commons is Vue.js-based, for example: https://commons.wikimedia.org/wiki/Special:MediaSearch https://commons.wikimedia.org/wiki/Special:MediaSearch But this announcement makes things more official.
threatofrain 5y ago
Previous big discussion: https://news.ycombinator.com/item?id=22625556 https://news.ycombinator.com/item?id=22625556 (March 2020)
- the__alchemist 5y ago
  For anyone alarmed about moving towards a SPA, and potential performance impacts etc, read the comments towards the top of this link from the Vue Team Lead and proposal co-author. They address the most obvious concerns.
- seumars 5y ago
  Thanks for the link. A lot of people went out of their way to criticise Vue which makes me wonder how the general opinion of Vue has changed in the last year.
  - wolverine876 5y ago
    > A lot of people went out of their way to criticise Vue ... For almost every topic on HN, a lot of people will go out of their way to criticize it.
ferdowsi 5y ago
Congratulations to the Vue team, this is definitely a big win for them. Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM. And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices have shifted so drastically in the last few years.
- vmception 5y ago
  I agree with that. Its been like a twilight zone interviewing for anything frontend in Silicon Valley the last couple years as they "me too" for React, while I use Vue on my own projects. Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.
- ggregoire 5y ago
  Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years). Oh boy I was wrong. Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core. At the end of the day it makes me more productive, so I guess that big shift was also a big win.
  - flowerlad 5y ago
    > you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug... What kind of application are you developing? Do you have complex UI? Or just lots and lots of pages where you reuse components a lot?
deleted 5y ago
[deleted]
ggregoire 5y ago
Can I see the code for the TypeaheadSearch component somewhere? (I followed some links but didn't find it)
- katabasis 5y ago
  That currently lives here: https://github.com/wikimedia/wvui/tree/master/src/components/typeahead-search https://github.com/wikimedia/wvui/tree/master/src/components.... This is WVUI, the component library created to serve the needs of the Desktop Improvements case study mentioned in the post here. Some of this code may change or get moved around based on the outcome of these tasks: https://phabricator.wikimedia.org/T286946 https://phabricator.wikimedia.org/T286946
  - ggregoire 5y ago
    I had no idea that a Vue component is basically a big JS object. Reminds me of Backbone.js' views: https://backbonejs.org/#View https://backbonejs.org/#View
gherkinnn 5y ago
A solid choice and well reasoned. It was a joy to read all of the discussions. Been following Vue and Evan’s work since 2015, before it even reached 1.0. I think it strikes a good balance between the freedom of React and the rigidity if Angular. (Interpret the terms “freedom” and “rigidity” as you please.) My only problem with Vue 2.x was the bad TS support, but I trust 3.x solves that.
- seph-reed 5y ago
  "The freedom of React" is a hard statement for me to digest. I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.
  - Spartan-S63 5y ago
    In my experience, React is very particular at how you present your view logic. For state management, though, it has very few opinions and that freedom can be paralyzing. Do you use Redux? Do you just use built-in component state and props? Do you use the Hooks API? React solves one slice of problems in front-end development, but has few opinions outside of the view layer.
    - seph-reed 5y ago
      I stopped using it a while ago (2-3 years). I had central state management, and a few other bells and whistles. I was the "go to" guy for when React didn't want to do something. Most of my wrestling came in the form of: - recycling html-elements - "tweening" state. a friggin nightmare to have inbetween states - performant animation stuff - stateless node-to-node communication for stuff that would have not fit well in state - keyboard navigation (think game ui) Ugh. The more I learned about how it actually works, the more I came to hate it. And it kills me to see so many people who love it... like I'm an alien amongst the people (developers) who I once felt understood me.
      - Aeolun 5y ago
huuggjkkkk 5y ago
Good luck getting any libraries working. Good luck using graphql. Good luck getting the tooling stable. Good luck getting a PR on the main code base done. Vue in production is a minefield of nightmares. Rather have Facebook as a single point of failure than some random dude who has other things that consume his interest.
- codefreakxff 5y ago
  Are you trolling? I’ve used Vue in a couple of projects and honestly have no idea what you are talking about. Feel free to expand on your statements. Otherwise this message doesn’t fit in hn
  - avaldes 5y ago
    The shift to Vue3 and a new paradigm (composition API) left the community in a state of confusion of where/how/when to migrate. The old paradigm is still supported but more like a legacy layer than the way to go. It reminds me of the python 2-3 schism.
    - mariocesar 5y ago
      I'm part of the community, several big production projects, several migrations from v2 to v3. I was never confused. The backward compatibility has a clean plan. For the bits that were complex changes, it was possible to do partial upgrades. From the beginning, the partial upgrade was in consideration. There was always early documentation, and you have access to v3 in alpha and beta all the time with complete documentation and complete guides. You also have standalone packages to start testing migrating bits of v3 to v2, like the composition API, class components, etc. It was one of the most seamless transitions I experience.
- Rapzid 5y ago
  I'm not sure a lot of people realize just how much a lot of the ecosystem relies on and is constrained by Evan
animanoir 5y ago
Beautiful. Vue is the future, any other framework, specially React, isn't
- arcturus17 5y ago
  > Beautiful. Vue is the future, any other framework, specially React, isn't Without making any judgement as to which is better, I'm afraid that's all in your head, bro.
dzonga 5y ago
react is api stable, but not api stable if you know what I mean. with react, the ground is always shifting underneath you, which something like wikimedia probably don't have the resources to keep up with. even, as someone who has done react professionally, I can advise any small nimble teams, out there react ain't for ya. it don't love ya. however, for the big enterprisey apps, yeah react is good.
- ng12 5y ago
  I cannot relate to this experience at all. Can you specify examples of what you're talking about?
  - mdoms 5y ago
    I'm not the guy you asked but I'm guessing he's referring to the "blessed way" of doing React, which seems to change every couple of years. Class components one year, pure components the next, functional components the next. A couple of years after that you're mad if you use React without Redux, the next year you'd be crazy to do Redux. State management a year later should be done with hooks, as should everything else. So what's going to be the next piece of guidance that will make our apps perfect?
    - barbarbar 5y ago
      This comment summarizes the fashion trends in a very elegant way.
  - mickael-kerjean 5y ago
    not OP but 4 examples I've faced recently: - facebook used to maintain CSSTransition for animation but dropped support for it and gave it to a dude who broke not only the public API but also some features I was relying on. I'm left having to recreate all the animation in a different lib, meh - lifecycles related deprecation: componentWillMount, componentWillReceiveProps, componentWillUpdate. My app used to have a lot of these but that's the easy part to migrate, the problem comes when third party libraries use those and nobody support those anymore - method deprecation which brake third party libraries: findDOMNode. The 2 one I've used that relied on it: dnd and csstransition. There's no clear path forward that would take less than a few days to migrate my code, meh - upgrading webpack to whatever your config should look like in 2021 and what new plugin for x is named Nothing very specific to react in particular but for simple use case jquery or plain javascript tends to create less problems to maintain things over longer period of time As far as the community is concerned, hooks has been a positive change when used correctly but it's not because you can do something using hooks that you should, some of those abstraction are over-engineeringly absurd (eg: https://react-native-aria.geekyants.com/docs/useCheckbox#example https://react-native-aria.geekyants.com/docs/useCheckbox#exa..., https://react-table.tanstack.com/docs/api/useExpanded https://react-table.tanstack.com/docs/api/useExpanded, ...)
qmmmur 5y ago
Not even a consideration of svelte?
- goodoldneon 5y ago
  Picking Svelte is risky, given its low adoption. I'm not saying Svelte won't ever be widely adopted, but there's a risk that it fades away and you're stuck using a dead framework.
- paulddraper 5y ago
  Svelte is very new (a year and half of meaningful adoption). React, Angular, Vue.js are the most popular, in that order. I hate to say might=right, but for a project like Wikimedia, choosing a mature, popular framework is important.
  - avaldes 5y ago
    What happened to emberjs? It was poised to become the next big thing after react and angular and suddenly nobody talks about it anymore.
    - finiteseries 5y ago
      It’s still around a bit. It was a hulking, omakase, MVC? based framework at a time when the oppo was Angular 2.0 & Backbone.js and people still used Bower, then React threw everything on its head in favor of component libraries while NPM came into the mix. They eventually refactored in components and I think repackaged everything for the new js fe ecosystem, but the battle was already lost.
      - kyawzazaw 5y ago
        LinkedIn uses it
    - paulddraper 5y ago
      It was the 3rd most popular in 2016, and 4th most popular in 2017-2018. It didn't go anywhere. Vue.js just became more popular for whatever reason.
russellbeattie 5y ago
Huh. They're still deciding on whether to use Vue 2 or Vue 3... To me that's a definitive sign that Vue chasing after React's insane hooks system was a bad idea. I hope they figure out how to heal the rift before it's too late before we get another Python 2/3 situation.
sativallday 5y ago
Love Vue. Polymer 2.0 with its HTML imports still offered a better DX in my opinion. Svelte offers a better DX than both of those frameworks. I don't even bother with FE anymore, more focused on BE/infra - but Svelte is always a pleasure to work in.
- sebasslash 5y ago
  Agreed, Svelte is by far the most productive FE I’ve used. Coming from a jQuery/templating background, at first felt Vue was the most intuitive to use (React felt alien, Angular overly verbose)… Until I met Svelte…Vue, minus the BS. A clean template system, less boilerplate, no Virtual DOM, nice Typescript support, intuitive state mgmt. 10/10 my goto for any frontend project.
- hardwaresofton 5y ago
  Btw if you liked Polymer 2.0/3.0 you may also like Lit (formerly lit-element)[0]. It has a less "proven" ecosystem around state/async action management and some other concerns (i.e. there's no redux/vuex), but the controller paradigm[1] looks pretty fresh and interesting. I'm of the belief that most of the time doing an async request or two and some caching and good architecture is enough for most app (not everyone needs the flux pattern). Lit is by the best implementation and standards-compliant component-centric library IMO. Tried a bunch of them back when I was trying to figure out if there's a better way to handle state in a component-centric world[3]. [0]: https://lit.dev/ https://lit.dev/ [1]: https://lit.dev/docs/composition/controllers/#building-controllers-from-other-controllers https://lit.dev/docs/composition/controllers/#building-contr... [3]: https://mrman.gitlab.io/services-as-dom-elements https://mrman.gitlab.io/services-as-dom-elements
  - sativallday 5y ago
    Lit doesn't have HTML imports. This is why lit-element is nothing compared to Polymer with HTML imports: https://lit-element.polymer-project.org/guide/templates https://lit-element.polymer-project.org/guide/templates DOM in JS is an anti-pattern from a DX perspective.
h_anna_h 5y ago
I guess soon enough I will not be able to have open more than a few pages of wikipedia at the same time.
Scarbutt 5y ago
Sprinkle all the Vuejs you need, but please don't make Wikipedia a SPA.
- katabasis 5y ago
  That's the idea. Various tools and power-user features benefit from the things that modern JS frameworks give you. But the basic experience of reading articles should support the lowest-common denominator. Most JS frameworks consider the SPA use-case to be the "happy path". There are a few outliers like the Stimulus family or Alpine (which I don't think existed at the time of the RFC) that expect to be sprinkled in to server-rendered HTML, but scaling these tools to full-blown apps may prove difficult. I think Vue can operate in between these two use-cases better than some of the alternatives. Being able to compile templates at runtime is also a useful feature in a legacy environment, where you can't just transpile all the things ahead of time. You have to ship some extra code for this, but it's nothing compared to the cost of shipping (and running) all of Babel, which you'd need to compile JSX.
  - su8898 5y ago
    Glad to see Alpine mentioned here! Hope it gets more adoption.
zkldi 5y ago
I feel like I'm in an alien world when it comes to Vue - it has this weird pattern of making strings do loads of heavy lifting. The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me. Things like v-for="record in commits" to loop over something is insane to me - this isn't code, this is a string inside a html attribute! How can you get any sort of good type analysis/variable checking/syntax highlighting inside this? Similarly, accessing properties like :href="record.html_url" has the exact same issues - what if there's a typo here? My IDE can't highlight that this is wrong because it's *not code* and is just a string. Maybe I'm just the odd one out here, but vue (and angular) love to use strings as a makeshift programming language, which to me is a major smell. ^[1]: https://v3.vuejs.org/examples/commits.html https://v3.vuejs.org/examples/commits.html
- AbuAssar 5y ago
  This is not a regular string, it is a template. And the tooling handles it just fine. You get type checking, linting, syntax highlighting etc.
  - zkldi 5y ago
    If it's a template then it's a very complex one, and under closer inspection it reads almost like storing code in a string and evalling it. Let's say we want to iterate over commits in reverse. A google shows that we can do something like this: v-for="item in items | orderBy 'field' -1" So, there's pipes now, and Vue has essentially re-invented a programming language inside HTML attributes. But then comes this example below it: v-for="item in _.reverse(items)" And this line is terrifying! If this string is able to use lodash, then that means it's able to access the JS global scope, and therefore is very powerful - yet the resulting template is nonsense js, but still at some point involves JS evaluation? Maybe I'm missing something though - I don't use Vue and if something is this big with this approach, I'm definitely missing something. EDIT: A search for *new Function(` calls in the vue github repository shows quite a lot of code that essentially evals strings.
    - 5y ago
Exuma 5y ago
An excellent choice
adevx 5y ago
I really enjoyed working with Vue 2 until I started using TypeScript. Vuex, the goto state manager just wasn't built for it (I ended up using vuex-module-decorators). Type safe templates were only partially possible with Vetur (vs code extension) but it was slow and resource hungry. I'm sure in Vue 3 this is much better now, but while evaluating to migrate to v3 this wasn't the case. I became interested in React, because I was looking for a way to generate type safe email templates. Started using .tsx files with a library called typed-html and loved it so much that I end up migrating to React (now rendering email templates with ReactDOMServer.renderToString(element). Still miss Vue's simplicity at times but having rock solid TypeScript support is something I value more.
- rk06 5y ago
  Vue 3 has composition api which is more typeo friendly. And Pinia is a vuex alternative which has good typescript support. Vuex 5 will have similar api as pinia
  - Rapzid 5y ago
    I'm curious how Pinia works. I actually use MobX with VueJS and the way it has to hack itself into VueJS is a bit of a shame. I wish there would have been a more official integration point for third party reactive libraries.
vagrantJin 5y ago
I'd clap harder if Vue weren't so desperate to become React and focus on their own strengths. React certainly appealed to a lot of devs who at best disliked working with HTML & CSS, but Vue welcomed everyone with an excellent gentle slope to gently move devs away from direct Dom manipulation and embrace reactive paradigms. Folks with small shops could now refactor their codebases with relative ease. If only the Vue team could understand, we don't want React features. We'll use React when we want them. We want Vuejs.
- manigandham 5y ago
  All JS frameworks will share some features. What specifically about Vue do you think is unnecessary or shows that the Vue team doesn't understand?
  - nsonha 5y ago
    I'm guessing hooks, even react devs are not sure about the fake functional programming nonsense.
    - leetrout 5y ago
      Hooks today are like CSS utility classes a few years ago. "It's not semantic" They will stay or they will go but I think they are useful more than they are not but I don't think its the final form we'll all adopt.
    - scotty79 5y ago
      Hooks are way easier to use than everything that came before them.
    - rk06 5y ago
      Vue3's composition api is literally a better version of hooks. Which actually answers vue2's pain points. And is strictly better than mixins. In fact, many Vue projects are using composition Api in Vue2 via a plugin because it is so good.
rank0 5y ago
Am I the only one who still has a preference for vanilla js? Maybe it’s just my use cases, but every time I try to use a high level framework like vue or react I am immediately bogged down by unnecessary abstraction and complexity. Again, I’m no UI dev so please correct me if I’m wrong! I have pretty simple needs for web app UI usually…I’m not trying to build Facebook. Why do I need react/vue/whatever?
- jansan 5y ago
  You don't if your User Interfaces are basic. But for web applications theses frameworks with the ability to quickly define your own web components are incredibly useful. It can still be frustrating sometimes, but when the app gets more complex, doing this without a web framework is probably insanity. BTW, Vue 3.0 uses Typescript, but you can still programm with plain Javascript. That it what I am doing (I may be part of a minority).
  - rank0 5y ago
    Yeah I never really make crazy interfaces so maybe I’m not the target audience for these frameworks
- tarsinge 5y ago
  Have you tried Vue? It’s very different than React because you can just augment your HTML with what you need, it’s not all or nothing. What’s complex and usually overkill for small projects is the "modern" build tool chain, but you can ignore that and just add the <script src> and be done with it (same with React BTW). You can get familiar with AlpineJS which is kind of a minimalist Vue.
  - rank0 5y ago
    That’s for the tips! I’ll take a look at alpineJS. I tried vue a long time ago but would definitely give it another look. My complaints really come from using react and I assumed vue had similar issues
- danielbarla 5y ago
cyberpsybin 5y ago
Wish Vue would just adopt JSX. Any web framework that invents another templating language force users to learn a whole new thing with it's own gotchas. So much unnecessary mental overload.
- zekica 5y ago
  Vue.js works fine with render functions and JSX although it is not recommended.
geenat 5y ago
No obvious advantage or win for wikimedia? * More complex, slower build process. * Increased barrier for development. * ECMAScript has been evolving so quickly lately that it will probably supersede Vue in the near future anyway. The true "futureproof" choice is to continue evolving with the latest ECMAScript spec. * https://htmx.org/ https://htmx.org/
- ZeikJT 5y ago
  "htmx is small (~10k min.gz'd)" Maybe I'm crazy, but that sounds huge based on the list of features in the docs. Would be interesting to see a breakdown of the features and how much of that size they take up.
Daedren 5y ago
From reading the RFC, I do feel like the choice for Vue.js was already made from the get-go. A few of the concerns laid out were brushed aside without much pondering (At least pondering within the thread, I don't know about the IRC channel) Vue's deprecation process is still a big problem in my view. Migration from Vue 2 to 3 is a painful one, while React doesn't have this problem. You can argue that component writing practices have changed over the past years in React, but the old ones all still work, while Vue 2 components just don't work in 3. EvanYou's comments about a future "compatibility build" for 3 that works with 2 is honestly still a bit worrying. I'm glad it exists but it just so easily convinced them. Is there going to be a performance penalty? Will it all work out of the box?
nojvek 5y ago
Over more than a decade I have gone through Adobe Flex, jquery, vanilla js, angular 1 & 2, vue 1 & 2, React, a bit of svelte, web components, my own custom state mgmt libraries. The fundamental idea behind most modern FE frameworks remain the same. View is a function of state. The hardest problems in FE are state management and CSS/dom layout. So as long as someone knows what they are doing any of the modern frameworks do a decent job. I have seen bad code in every framework. So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them. Use the framework your team knows best. It’s really about the players more than the instrument. I personally like React. It solves many of the pain points I’ve experienced over 10+ years. I’ve invested a lot of time learning it in depth. If someone told me to write react from scratch with hooks api, I know how to do it. Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.
codethief 5y ago
> - Deciding on Vue 2 or Vue 3 including transition path Am I the only one here who absolutely hates Vue 2? No TypeScript support and no type safety at all (neither for props, nor for events, nor for provide/inject); many identifiers and references are hard-coded strings, making it very hard to discover dependencies between different parts of the code; `this` gets implicitly populated with props, data, computed, methods all at the same time and in some order that still escapes me; refactoring support even in IntelliJ/WebStorm is full of bugs (hardly a surprise given the missing type safety); horrible documentation ("Here's an example" != documentation); no proper two-way binding (i.e. one that doesn't produce change detection cycles). I could go on and on and on…

353 points by Volker-E 5y ago

Most of the discussion behind this decision, including feedback directly from Evan You (author of Vue), is here: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180 It's pretty interesting to read through.

skybrian 5y ago
This discussion is from early 2020 and the decision seems to have been mostly made by then, but they’re announcing it now. I guess everyone’s been busy, what with a pandemic and all. :)
- katabasis 5y ago
  Various teams have been using Vue on a more experimental basis over the last year. The new Media Search tool on Commons is Vue.js-based, for example: https://commons.wikimedia.org/wiki/Special:MediaSearch https://commons.wikimedia.org/wiki/Special:MediaSearch But this announcement makes things more official.

threatofrain 5y ago

Previous big discussion: https://news.ycombinator.com/item?id=22625556 https://news.ycombinator.com/item?id=22625556 (March 2020)

the__alchemist 5y ago
For anyone alarmed about moving towards a SPA, and potential performance impacts etc, read the comments towards the top of this link from the Vue Team Lead and proposal co-author. They address the most obvious concerns.
seumars 5y ago
Thanks for the link. A lot of people went out of their way to criticise Vue which makes me wonder how the general opinion of Vue has changed in the last year.
- wolverine876 5y ago
  > A lot of people went out of their way to criticise Vue ... For almost every topic on HN, a lot of people will go out of their way to criticize it.

ferdowsi 5y ago

Congratulations to the Vue team, this is definitely a big win for them. Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM. And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices have shifted so drastically in the last few years.

vmception 5y ago
I agree with that. Its been like a twilight zone interviewing for anything frontend in Silicon Valley the last couple years as they "me too" for React, while I use Vue on my own projects. Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.
ggregoire 5y ago
Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years). Oh boy I was wrong. Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core. At the end of the day it makes me more productive, so I guess that big shift was also a big win.
- flowerlad 5y ago
  > you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug... What kind of application are you developing? Do you have complex UI? Or just lots and lots of pages where you reuse components a lot?

deleted 5y ago

[deleted]

ggregoire 5y ago

Can I see the code for the TypeaheadSearch component somewhere? (I followed some links but didn't find it)

katabasis 5y ago
That currently lives here: https://github.com/wikimedia/wvui/tree/master/src/components/typeahead-search https://github.com/wikimedia/wvui/tree/master/src/components.... This is WVUI, the component library created to serve the needs of the Desktop Improvements case study mentioned in the post here. Some of this code may change or get moved around based on the outcome of these tasks: https://phabricator.wikimedia.org/T286946 https://phabricator.wikimedia.org/T286946
- ggregoire 5y ago
  I had no idea that a Vue component is basically a big JS object. Reminds me of Backbone.js' views: https://backbonejs.org/#View https://backbonejs.org/#View

gherkinnn 5y ago

A solid choice and well reasoned. It was a joy to read all of the discussions. Been following Vue and Evan’s work since 2015, before it even reached 1.0. I think it strikes a good balance between the freedom of React and the rigidity if Angular. (Interpret the terms “freedom” and “rigidity” as you please.) My only problem with Vue 2.x was the bad TS support, but I trust 3.x solves that.

seph-reed 5y ago
"The freedom of React" is a hard statement for me to digest. I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.
- Spartan-S63 5y ago
  In my experience, React is very particular at how you present your view logic. For state management, though, it has very few opinions and that freedom can be paralyzing. Do you use Redux? Do you just use built-in component state and props? Do you use the Hooks API? React solves one slice of problems in front-end development, but has few opinions outside of the view layer.
  - seph-reed 5y ago
    I stopped using it a while ago (2-3 years). I had central state management, and a few other bells and whistles. I was the "go to" guy for when React didn't want to do something. Most of my wrestling came in the form of: - recycling html-elements - "tweening" state. a friggin nightmare to have inbetween states - performant animation stuff - stateless node-to-node communication for stuff that would have not fit well in state - keyboard navigation (think game ui) Ugh. The more I learned about how it actually works, the more I came to hate it. And it kills me to see so many people who love it... like I'm an alien amongst the people (developers) who I once felt understood me.
    - Aeolun 5y ago

huuggjkkkk 5y ago

Good luck getting any libraries working. Good luck using graphql. Good luck getting the tooling stable. Good luck getting a PR on the main code base done. Vue in production is a minefield of nightmares. Rather have Facebook as a single point of failure than some random dude who has other things that consume his interest.

codefreakxff 5y ago
Are you trolling? I’ve used Vue in a couple of projects and honestly have no idea what you are talking about. Feel free to expand on your statements. Otherwise this message doesn’t fit in hn
- avaldes 5y ago
  The shift to Vue3 and a new paradigm (composition API) left the community in a state of confusion of where/how/when to migrate. The old paradigm is still supported but more like a legacy layer than the way to go. It reminds me of the python 2-3 schism.
  - mariocesar 5y ago
    I'm part of the community, several big production projects, several migrations from v2 to v3. I was never confused. The backward compatibility has a clean plan. For the bits that were complex changes, it was possible to do partial upgrades. From the beginning, the partial upgrade was in consideration. There was always early documentation, and you have access to v3 in alpha and beta all the time with complete documentation and complete guides. You also have standalone packages to start testing migrating bits of v3 to v2, like the composition API, class components, etc. It was one of the most seamless transitions I experience.
Rapzid 5y ago
I'm not sure a lot of people realize just how much a lot of the ecosystem relies on and is constrained by Evan

animanoir 5y ago

Beautiful. Vue is the future, any other framework, specially React, isn't

arcturus17 5y ago
> Beautiful. Vue is the future, any other framework, specially React, isn't Without making any judgement as to which is better, I'm afraid that's all in your head, bro.

dzonga 5y ago

react is api stable, but not api stable if you know what I mean. with react, the ground is always shifting underneath you, which something like wikimedia probably don't have the resources to keep up with. even, as someone who has done react professionally, I can advise any small nimble teams, out there react ain't for ya. it don't love ya. however, for the big enterprisey apps, yeah react is good.

ng12 5y ago
I cannot relate to this experience at all. Can you specify examples of what you're talking about?
- mdoms 5y ago
  I'm not the guy you asked but I'm guessing he's referring to the "blessed way" of doing React, which seems to change every couple of years. Class components one year, pure components the next, functional components the next. A couple of years after that you're mad if you use React without Redux, the next year you'd be crazy to do Redux. State management a year later should be done with hooks, as should everything else. So what's going to be the next piece of guidance that will make our apps perfect?
  - barbarbar 5y ago
    This comment summarizes the fashion trends in a very elegant way.
- mickael-kerjean 5y ago
  not OP but 4 examples I've faced recently: - facebook used to maintain CSSTransition for animation but dropped support for it and gave it to a dude who broke not only the public API but also some features I was relying on. I'm left having to recreate all the animation in a different lib, meh - lifecycles related deprecation: componentWillMount, componentWillReceiveProps, componentWillUpdate. My app used to have a lot of these but that's the easy part to migrate, the problem comes when third party libraries use those and nobody support those anymore - method deprecation which brake third party libraries: findDOMNode. The 2 one I've used that relied on it: dnd and csstransition. There's no clear path forward that would take less than a few days to migrate my code, meh - upgrading webpack to whatever your config should look like in 2021 and what new plugin for x is named Nothing very specific to react in particular but for simple use case jquery or plain javascript tends to create less problems to maintain things over longer period of time As far as the community is concerned, hooks has been a positive change when used correctly but it's not because you can do something using hooks that you should, some of those abstraction are over-engineeringly absurd (eg: https://react-native-aria.geekyants.com/docs/useCheckbox#example https://react-native-aria.geekyants.com/docs/useCheckbox#exa..., https://react-table.tanstack.com/docs/api/useExpanded https://react-table.tanstack.com/docs/api/useExpanded, ...)

qmmmur 5y ago

Not even a consideration of svelte?

goodoldneon 5y ago
Picking Svelte is risky, given its low adoption. I'm not saying Svelte won't ever be widely adopted, but there's a risk that it fades away and you're stuck using a dead framework.
paulddraper 5y ago
Svelte is very new (a year and half of meaningful adoption). React, Angular, Vue.js are the most popular, in that order. I hate to say might=right, but for a project like Wikimedia, choosing a mature, popular framework is important.
- avaldes 5y ago
  What happened to emberjs? It was poised to become the next big thing after react and angular and suddenly nobody talks about it anymore.
  - finiteseries 5y ago
    It’s still around a bit. It was a hulking, omakase, MVC? based framework at a time when the oppo was Angular 2.0 & Backbone.js and people still used Bower, then React threw everything on its head in favor of component libraries while NPM came into the mix. They eventually refactored in components and I think repackaged everything for the new js fe ecosystem, but the battle was already lost.
    - kyawzazaw 5y ago
      LinkedIn uses it
  - paulddraper 5y ago
    It was the 3rd most popular in 2016, and 4th most popular in 2017-2018. It didn't go anywhere. Vue.js just became more popular for whatever reason.

russellbeattie 5y ago

Huh. They're still deciding on whether to use Vue 2 or Vue 3... To me that's a definitive sign that Vue chasing after React's insane hooks system was a bad idea. I hope they figure out how to heal the rift before it's too late before we get another Python 2/3 situation.

sativallday 5y ago

Love Vue. Polymer 2.0 with its HTML imports still offered a better DX in my opinion. Svelte offers a better DX than both of those frameworks. I don't even bother with FE anymore, more focused on BE/infra - but Svelte is always a pleasure to work in.

sebasslash 5y ago
Agreed, Svelte is by far the most productive FE I’ve used. Coming from a jQuery/templating background, at first felt Vue was the most intuitive to use (React felt alien, Angular overly verbose)… Until I met Svelte…Vue, minus the BS. A clean template system, less boilerplate, no Virtual DOM, nice Typescript support, intuitive state mgmt. 10/10 my goto for any frontend project.
hardwaresofton 5y ago
Btw if you liked Polymer 2.0/3.0 you may also like Lit (formerly lit-element)[0]. It has a less "proven" ecosystem around state/async action management and some other concerns (i.e. there's no redux/vuex), but the controller paradigm[1] looks pretty fresh and interesting. I'm of the belief that most of the time doing an async request or two and some caching and good architecture is enough for most app (not everyone needs the flux pattern). Lit is by the best implementation and standards-compliant component-centric library IMO. Tried a bunch of them back when I was trying to figure out if there's a better way to handle state in a component-centric world[3]. [0]: https://lit.dev/ https://lit.dev/ [1]: https://lit.dev/docs/composition/controllers/#building-controllers-from-other-controllers https://lit.dev/docs/composition/controllers/#building-contr... [3]: https://mrman.gitlab.io/services-as-dom-elements https://mrman.gitlab.io/services-as-dom-elements
- sativallday 5y ago
  Lit doesn't have HTML imports. This is why lit-element is nothing compared to Polymer with HTML imports: https://lit-element.polymer-project.org/guide/templates https://lit-element.polymer-project.org/guide/templates DOM in JS is an anti-pattern from a DX perspective.

h_anna_h 5y ago

I guess soon enough I will not be able to have open more than a few pages of wikipedia at the same time.

Scarbutt 5y ago

Sprinkle all the Vuejs you need, but please don't make Wikipedia a SPA.

katabasis 5y ago
That's the idea. Various tools and power-user features benefit from the things that modern JS frameworks give you. But the basic experience of reading articles should support the lowest-common denominator. Most JS frameworks consider the SPA use-case to be the "happy path". There are a few outliers like the Stimulus family or Alpine (which I don't think existed at the time of the RFC) that expect to be sprinkled in to server-rendered HTML, but scaling these tools to full-blown apps may prove difficult. I think Vue can operate in between these two use-cases better than some of the alternatives. Being able to compile templates at runtime is also a useful feature in a legacy environment, where you can't just transpile all the things ahead of time. You have to ship some extra code for this, but it's nothing compared to the cost of shipping (and running) all of Babel, which you'd need to compile JSX.
- su8898 5y ago
  Glad to see Alpine mentioned here! Hope it gets more adoption.

zkldi 5y ago

I feel like I'm in an alien world when it comes to Vue - it has this weird pattern of making strings do loads of heavy lifting. The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me. Things like v-for="record in commits" to loop over something is insane to me - this isn't code, this is a string inside a html attribute! How can you get any sort of good type analysis/variable checking/syntax highlighting inside this? Similarly, accessing properties like :href="record.html_url" has the exact same issues - what if there's a typo here? My IDE can't highlight that this is wrong because it's *not code* and is just a string. Maybe I'm just the odd one out here, but vue (and angular) love to use strings as a makeshift programming language, which to me is a major smell. ^[1]: https://v3.vuejs.org/examples/commits.html https://v3.vuejs.org/examples/commits.html

AbuAssar 5y ago
This is not a regular string, it is a template. And the tooling handles it just fine. You get type checking, linting, syntax highlighting etc.
- zkldi 5y ago
  If it's a template then it's a very complex one, and under closer inspection it reads almost like storing code in a string and evalling it. Let's say we want to iterate over commits in reverse. A google shows that we can do something like this: v-for="item in items | orderBy 'field' -1" So, there's pipes now, and Vue has essentially re-invented a programming language inside HTML attributes. But then comes this example below it: v-for="item in _.reverse(items)" And this line is terrifying! If this string is able to use lodash, then that means it's able to access the JS global scope, and therefore is very powerful - yet the resulting template is nonsense js, but still at some point involves JS evaluation? Maybe I'm missing something though - I don't use Vue and if something is this big with this approach, I'm definitely missing something. EDIT: A search for *new Function(` calls in the vue github repository shows quite a lot of code that essentially evals strings.
  - 5y ago

Exuma 5y ago

An excellent choice

adevx 5y ago

I really enjoyed working with Vue 2 until I started using TypeScript. Vuex, the goto state manager just wasn't built for it (I ended up using vuex-module-decorators). Type safe templates were only partially possible with Vetur (vs code extension) but it was slow and resource hungry. I'm sure in Vue 3 this is much better now, but while evaluating to migrate to v3 this wasn't the case. I became interested in React, because I was looking for a way to generate type safe email templates. Started using .tsx files with a library called typed-html and loved it so much that I end up migrating to React (now rendering email templates with ReactDOMServer.renderToString(element). Still miss Vue's simplicity at times but having rock solid TypeScript support is something I value more.

rk06 5y ago
Vue 3 has composition api which is more typeo friendly. And Pinia is a vuex alternative which has good typescript support. Vuex 5 will have similar api as pinia
- Rapzid 5y ago
  I'm curious how Pinia works. I actually use MobX with VueJS and the way it has to hack itself into VueJS is a bit of a shame. I wish there would have been a more official integration point for third party reactive libraries.

vagrantJin 5y ago

I'd clap harder if Vue weren't so desperate to become React and focus on their own strengths. React certainly appealed to a lot of devs who at best disliked working with HTML & CSS, but Vue welcomed everyone with an excellent gentle slope to gently move devs away from direct Dom manipulation and embrace reactive paradigms. Folks with small shops could now refactor their codebases with relative ease. If only the Vue team could understand, we don't want React features. We'll use React when we want them. We want Vuejs.

manigandham 5y ago
All JS frameworks will share some features. What specifically about Vue do you think is unnecessary or shows that the Vue team doesn't understand?
- nsonha 5y ago
  I'm guessing hooks, even react devs are not sure about the fake functional programming nonsense.
  - leetrout 5y ago
    Hooks today are like CSS utility classes a few years ago. "It's not semantic" They will stay or they will go but I think they are useful more than they are not but I don't think its the final form we'll all adopt.
  - scotty79 5y ago
    Hooks are way easier to use than everything that came before them.
  - rk06 5y ago
    Vue3's composition api is literally a better version of hooks. Which actually answers vue2's pain points. And is strictly better than mixins. In fact, many Vue projects are using composition Api in Vue2 via a plugin because it is so good.

rank0 5y ago

Am I the only one who still has a preference for vanilla js? Maybe it’s just my use cases, but every time I try to use a high level framework like vue or react I am immediately bogged down by unnecessary abstraction and complexity. Again, I’m no UI dev so please correct me if I’m wrong! I have pretty simple needs for web app UI usually…I’m not trying to build Facebook. Why do I need react/vue/whatever?

jansan 5y ago
You don't if your User Interfaces are basic. But for web applications theses frameworks with the ability to quickly define your own web components are incredibly useful. It can still be frustrating sometimes, but when the app gets more complex, doing this without a web framework is probably insanity. BTW, Vue 3.0 uses Typescript, but you can still programm with plain Javascript. That it what I am doing (I may be part of a minority).
- rank0 5y ago
  Yeah I never really make crazy interfaces so maybe I’m not the target audience for these frameworks
tarsinge 5y ago
Have you tried Vue? It’s very different than React because you can just augment your HTML with what you need, it’s not all or nothing. What’s complex and usually overkill for small projects is the "modern" build tool chain, but you can ignore that and just add the <script src> and be done with it (same with React BTW). You can get familiar with AlpineJS which is kind of a minimalist Vue.
- rank0 5y ago
  That’s for the tips! I’ll take a look at alpineJS. I tried vue a long time ago but would definitely give it another look. My complaints really come from using react and I assumed vue had similar issues
danielbarla 5y ago

cyberpsybin 5y ago

Wish Vue would just adopt JSX. Any web framework that invents another templating language force users to learn a whole new thing with it's own gotchas. So much unnecessary mental overload.

zekica 5y ago
Vue.js works fine with render functions and JSX although it is not recommended.

geenat 5y ago

No obvious advantage or win for wikimedia? * More complex, slower build process. * Increased barrier for development. * ECMAScript has been evolving so quickly lately that it will probably supersede Vue in the near future anyway. The true "futureproof" choice is to continue evolving with the latest ECMAScript spec. * https://htmx.org/ https://htmx.org/

ZeikJT 5y ago
"htmx is small (~10k min.gz'd)" Maybe I'm crazy, but that sounds huge based on the list of features in the docs. Would be interesting to see a breakdown of the features and how much of that size they take up.

Daedren 5y ago

From reading the RFC, I do feel like the choice for Vue.js was already made from the get-go. A few of the concerns laid out were brushed aside without much pondering (At least pondering within the thread, I don't know about the IRC channel) Vue's deprecation process is still a big problem in my view. Migration from Vue 2 to 3 is a painful one, while React doesn't have this problem. You can argue that component writing practices have changed over the past years in React, but the old ones all still work, while Vue 2 components just don't work in 3. EvanYou's comments about a future "compatibility build" for 3 that works with 2 is honestly still a bit worrying. I'm glad it exists but it just so easily convinced them. Is there going to be a performance penalty? Will it all work out of the box?

nojvek 5y ago

Over more than a decade I have gone through Adobe Flex, jquery, vanilla js, angular 1 & 2, vue 1 & 2, React, a bit of svelte, web components, my own custom state mgmt libraries. The fundamental idea behind most modern FE frameworks remain the same. View is a function of state. The hardest problems in FE are state management and CSS/dom layout. So as long as someone knows what they are doing any of the modern frameworks do a decent job. I have seen bad code in every framework. So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them. Use the framework your team knows best. It’s really about the players more than the instrument. I personally like React. It solves many of the pain points I’ve experienced over 10+ years. I’ve invested a lot of time learning it in depth. If someone told me to write react from scratch with hooks api, I know how to do it. Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.

codethief 5y ago

> - Deciding on Vue 2 or Vue 3 including transition path Am I the only one here who absolutely hates Vue 2? No TypeScript support and no type safety at all (neither for props, nor for events, nor for provide/inject); many identifiers and references are hard-coded strings, making it very hard to discover dependencies between different parts of the code; `this` gets implicitly populated with props, data, computed, methods all at the same time and in some order that still escapes me; refactoring support even in IntelliJ/WebStorm is full of bugs (hardly a surprise given the missing type safety); horrible documentation ("Here's an example" != documentation); no proper two-way binding (i.e. one that doesn't produce change detection cycles). I could go on and on and on…