Vue.js is Wikimedia Foundation's future JavaScript framework • Hacker News Board

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#71

Post by hardwaresofton » Tue, Aug 03, 2021, 4:33 AM UTC

sativallday wrote: post #36

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.

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/

[1]: https://lit.dev/docs/composition/controllers/#building-contr...

[3]: https://mrman.gitlab.io/services-as-dom-elements

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#72

Post by zkldi » Tue, Aug 03, 2021, 4:39 AM UTC

Drew_ wrote: post #69

zkldi wrote: post #63

Earlier quoted context omitted.

My issue isn't the existance of programmatic expressions (yeah, it's the point of templating languages), but more that the way vue (and angular) do it is a mess of syntaxes that creates a really, really strange template. The lodash example is the main critique because that is not JS, but it involves evaluating JS - it's created its own programming language with its own rules -- when one was right there from the begin…

Like any templating engine there's always just enough power given to have the ability to write something stupid or complex in the template. Again not really a problem in practice. The scary underscore expression you're referring to can easily just be written as a reversedList variable in "normal" JS and get referenced plainly in the template. So the template expression syntax never has to be as messy as you might thi…

The "scary underscore" expression isn't scary because it's an underscore, it's because it implies the evaluation of JS, such that you could (and obviously wouldn't) do things like

    v-for="x in console.log('hello world!') && fetch('/') && [1,2]"

(my syntax might be off since I don't use Vue, but the merit should still apply)

My point is that when your templating language starts doing things like this (and inevitably, all of them do) - you've created a new programming language that is generally less thought out as one than deliberately made programming languages. Although the above for loop is evaluating JS, the syntax is decidedly not JS.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#73

Post by zkldi » Tue, Aug 03, 2021, 4:41 AM UTC

sangnoir wrote: post #70

zkldi wrote: post #53

Earlier quoted context omitted.

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 exampl…

would you have preferred {{ for item in items | orderBy 'field' -1 }} ? I feel like you're getting hung-up on the fact that the template directive is also a valid attribute and not something similar to jinja - but that's just syntax

I don't really see much of a difference - that is still storing it as a text attribute inside a DOM node.

To be clear, I vastly prefer Reacts approach of putting HTML into JS, rather than Vue/Angulars approach of putting JS into HTML.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#74

Post by worker767424 » Tue, Aug 03, 2021, 4:43 AM UTC

wayneftw wrote: post #23

ferdowsi wrote: post #4

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 h…

Facebook is a steward not a dependency. React has been free and open source and largely driven by the needs of the community. Right down to that time when the community cried out about Facebook's odd license clause regarding patents. And they changed it. But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long…

Compare this to HHVM which evolved into a PHP fork no one other than Slack uses.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#75

Post by seph-reed » Tue, Aug 03, 2021, 4:52 AM UTC

gentleman11 wrote: post #68

seph-reed wrote: post #18

Earlier quoted context omitted.

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…

By tweening and animation, you mean shifting an element from one part of the screen to another? What part of react fights against this? I’ve been using react for 3 weeks and I’m just curious what I might run into later on

If you're animating using just css classes (or transitions), you'll be fine.

Some animations need to be run in javascript though, and doing that through state is a bad idea. You can use ref, and sometimes that's fine, but if the data is changing (hitting a moving target), then you need communication. Think coach-marks and scrolling at the same time.

And "tweening" views means showing the last view fade out while the next one fades in (or scrolls in, etc). This means displaying an old state, and a new state at the same time. The trick is to recycle your html elements, but it'll fight you for it.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#76

Post by katabasis » Tue, Aug 03, 2021, 4:53 AM UTC

Scarbutt wrote: post #50

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

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.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#77

Post by seph-reed » Tue, Aug 03, 2021, 4:53 AM UTC

throwaway99997 wrote: post #43

seph-reed wrote: post #29

Earlier quoted context omitted.

Keyboard navigations as in up/left/right/down jumps around somewhat haphazardly placed items. Not tab/shift-tab accessibility. And you are right that React is not a good fit for these things. That's why I say it's very limiting. Also, for what it's worth, you might be mistaking "the jquery way" with "the vanilla way." As in: - working with HTMLElements - vs working with a superset (tsx) of a superset (ts) of javascri…

Yeah, React is a pain for when you need to interact with the DOM elements themselves. If you want to add some logic based on where the element happens to be placed, instead of where you have told React to place your element, you're in for a headache. Now the DOM is one source of state (positioning) and your store (Redux or otherwise) is no longer the single source of truth.

IMO, there's no way it lasts purely because of this.

We already have the DOM, and there's literally nothing that React can do that requires its complexity EXCEPT server side rendering. Which most people never use.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#78

Post by Exuma » Tue, Aug 03, 2021, 4:54 AM UTC

zkldi wrote: post #58

Exuma wrote: post #56

Earlier quoted context omitted.

Vue is brilliant when you actually use it. Nothing you've mentioned is remotely ever a problem in my experience. Also :href="xxx" isn't a string, that is javascript in there. You won't ever have more than 10 characters at most in an attribute, and if you do you make a method for it and call the method. The other alternative is JSX type stuff in react where you are injecting full JS into the templates which is like co…

> :href="xxx" isn't a string, that is javascript in there. This is the part I don't really follow, though. Technically: href here isn't a string, it's python, but it's stored as a string, representing python. In the :href example for JS, that's not JS - an engine isn't seeing that - that's a string that is evaluated as JS at some point in the vue lifecycle.

Without refreshing my knowledge on it, I don't think it's actually a string. A block is actually a "single file component" which is a special vue plugin/loader/whatever for webpack. It compiles template/script/style tags into a single compiled version.

I'm like 60% sure that your "string' example is never run in production. So I believe that it gets compiled before vue even sees it (at build time, or dev-server compile time) into the standard method that vue is used to... a vue component:

    Vue.component('button-counter', {
      data: function () {
        return {
          count: 0
        }
      },
      template: 'You clicked me {{ count }} times.'
    })

https://v3.vuejs.org/guide/single-file-component.html

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#79

Post by pbalau » Tue, Aug 03, 2021, 4:58 AM UTC

zkldi wrote: post #51

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 analys…

A long, long time ago, in a galaxy far, far away, there was a thing called Coldfusion. And js peeps seem to want to reinvent it.

Re: Vue.js is Wikimedia Foundation's future JavaScript framework

#80

Post by porker » Tue, Aug 03, 2021, 5:03 AM UTC

wayneftw wrote: post #23

ferdowsi wrote: post #4

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 h…

Facebook is a steward not a dependency. React has been free and open source and largely driven by the needs of the community. Right down to that time when the community cried out about Facebook's odd license clause regarding patents. And they changed it. But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long…

> We'll see how Vue fairs in the long run if they never make any big shifts, I suppose.

Vue 2 to Vue 3 has felt like a big shift. Big enough to leave most libraries incompatible with Vue3 and a lot of community forks spread around while library authors work out how (and if) to support both versions.

Vue 3 is an improvement to work with IMO but it's a rewrite your code kind of upgrade.