Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js is Wikimedia Foundation's future JavaScript framework

lists.wikimedia.org

Post reply on HN
Print view View original

191–200 of 204 posts

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

#191

Post by ducharmdev »

GormanFletcher wrote: post #181
ducharmdev wrote: post #167

Earlier quoted context omitted.

Just curious, but in your opinion, how does the composition API improve on React hooks? I used Vue 2 for some projects a year or two ago, and recently have been comparing React hooks & Vue's composition API. Composition is definitely better than mixins, but as a new React user, hooks are feeling more intuitive right off the bat. With Vue 3, I feel like I have to decide for every component whether to stick with the op…

> Just curious, but in your opinion, how does the composition API improve on React hooks? I'm a fan of how Vue's composition API executes exactly once during a component lifetime (during `setup()`), whereas React hooks get set up again on every render. I find it I find Vue's approach easier to mentally model, and thus easier to write correct code (especially when doing something complicated where state changes / effe…

I think this puts it in perspective more; if I understand what you're saying correctly, then setup essentially gives you more fine-grained control over Vue's reactivity system, as opposed to just doing it all for you when a component is created. Which allows you to more easily pull out & consolidate reusable logic as needed.

It is kinda nice making reactive state really explicit like that; I like Svelte's approach for similar reasons.

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

#192

Post by zkldi »

likeclockwork wrote: post #183
zkldi wrote: post #180

Earlier quoted context omitted.

Because that loop doesn't do what you think it does? for...in iterates over the keys of an object, but for in in vue iterates over the elements of an array.

Actually, for ... in does both. It is you who doesn't think that loop does what it actually does. Please read the spec and verify with your favorite JS runtime before continuing this argument.

    for (x in [6,1,6,2,6,3]) {
      console.log(x);
    }
Please run this in your browser console and tell me if it iterates over the elements of the array.

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

#193

Post by zkldi »

manigandham wrote: post #184
zkldi wrote: post #180

Earlier quoted context omitted.

Because that loop doesn't do what you think it does? for...in iterates over the keys of an object, but for in in vue iterates over the elements of an array.

It does exactly what I think it does, which is either iterate over the properties if it's an object or the elements if it's an array. This is true for Vue and Javascript. I suggest you read the documentation I linked earlier. Also Vue's directives are not JS. It's a separate DSL. I've repeated this enough so I'll end this discussion here.

> This is true for Vue and Javascript.

This is not true for javascript at all.

    for (x in [6,1,6,2,6,3]) {
        console.log(x);
    }
Please run this in any javascript runtime.

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

#194

Post by zkldi »

lenkite wrote: post #186
zkldi wrote: post #159

Earlier quoted context omitted.

Then that sounds pretty good that it's not ran in production and compiled out! I guess my remaining alien issue is that the DSL for Vue is a mish-mash of JS, custom syntax, dom attribute context and possibly more?

Vue template HTML can be parsed by an HTML parser - lots of them available. Can you do that with JSX ? Personally, I find JSX is more of an "alien" than Vue template HTML.

Well, no, because JSX is meant to be parsed by a JS parser and not a HTML parser.

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

#195

Post by [deleted] »

ratww wrote: post #171
flowerlad wrote: post #161

Earlier quoted context omitted.

> It is merely "gluing" those things together. That's pretty bad if you need "glue". > Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at. React is a UI technology, and only your view layer should know about the React stack. The model layer should be UI-technology agnostic (includes avoiding Redux etc.) and so should most of the controller layer.…

Once again, I suggest that you search what each of those HOCs is doing. These functions are not part of what would be a controller or model layer in MVC. This code is not dealing with routing, fetching, managing state or rendering. They are merely gluing complex data coming from these other parts of the system into what is the view layer here. The logical separation still exists! Sure OP could reimplement all of them…

[deleted]

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

#196

Post by midrus »

rk06 wrote: post #182
ducharmdev wrote: post #167

Earlier quoted context omitted.

Just curious, but in your opinion, how does the composition API improve on React hooks? I used Vue 2 for some projects a year or two ago, and recently have been comparing React hooks & Vue's composition API. Composition is definitely better than mixins, but as a new React user, hooks are feeling more intuitive right off the bat. With Vue 3, I feel like I have to decide for every component whether to stick with the op…

There are many points. The main point for me is dependency tracking. React hooks require manual dependency tracking and mistakes in this can lead hard to identify bugs Vue has automatic dependency tracking, so that entire class of issues do not occur.

THIS. People focus so much on templates vs jsx and most forget this is the biggest difference, and a very important one. I think people discarding Vue because they don't like templates just don't understand this difference.

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

#197

Post by ratww »

flowerlad wrote: post #187
ratww wrote: post #171

Earlier quoted context omitted.

Once again, I suggest that you search what each of those HOCs is doing. These functions are not part of what would be a controller or model layer in MVC. This code is not dealing with routing, fetching, managing state or rendering. They are merely gluing complex data coming from these other parts of the system into what is the view layer here. The logical separation still exists! Sure OP could reimplement all of them…

Once again: UI should not be aware that routing is happening. It makes the UI less reusable.

You are still wrong. This portion of the UI in this case doesn't care about the routing mechanism itself, but it does care about the history, which page is the current, and it also wants to trigger route navigations. This is a navigational component after all!

If your app needs to show, say, a menu bar, you need those things. Maybe some apps don't, but most of them do.

How would you implement this communication in your ideal system?

Let's see:

This component lives around two or three levels down from the entry point of your React tree (the part which communicates with the router). Which way is simplest way to connect this to the router indirectly? One way is by passing values and callbacks via props, from layer to layer, until it reaches the menubar. This works and is completely isolated, you basically have plain-simple-Javascript-objects "injected" from the top level, or instances of an interface, if you're doing Typescript! This follows the I of SOLID: Interface Segregation Principle. It also provides you with the S, Separation of Concerns.

But the "prop-drilling" is way too cumbersome. Let's maybe use the Context API, which is a way of replacing prop-drilling? It's still properly isolated.

Congratulations, you just re-invented the wheel and re-implemented exactly what withRouter does.

Sure you could have your own homegrown interfaces. Or maybe you could have no menu at all in your app! It's your choice. But it doesn't matter: this is still following the rules you are calling for.

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

#198

Post by manigandham »

dmitriid wrote: post #190
manigandham wrote: post #169

Earlier quoted context omitted.

The topic is that all code is text, and everything can be parsed and understood based on specific language grammars, even if they're embedded within each other. What are you even arguing at this point? This isn't about compilation or strings anymore. You don't like Vue's specific DSL? Or you don't understand it? Or you found a problem with the documentation? Or do you need a full grammar and syntax definition before…

> What are you even arguing at this point? That Vue isn't "the same as text between script tags". Because "text between script tags" is fully specified, and known to the browser. Vue's ad-hoc mish-mash of DSLs has to go through an unspecified series of transformations before it can even become a "text between script tags". And that's the issue not just with Vue, but with any other templating layers. > but you can alw…

Yes, Vue directives aren't JS. It's a separate DSL. The whole point is that it is a syntax that can be parsed, compiled and understood rather than just "strings".

I'm not sure why you're stuck on this. Templates are just a more simplistic programming language. That's how so many IDEs can still provide help with them.

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

#199

Post by ZeikJT »

manigandham wrote: post #153
baybal2 wrote: post #129

Earlier quoted context omitted.

I tried React during its early years, and switched to Vue. It's just a little bit more coherent platform than React. There are core Vue projects, and they go in lockstep with Vue releases. Second, Vue understood how fragile, and the same time important tooling is. There are many very mature Vue packages to scaffold, and manage your Webpack, or other build system setup for you. This saves a lot of hours because if thi…

Vue still has the same progressive-enhancement low-tooling approach as before. It's only broadened in its ability to be used in more complex environments with full toolchains but you can just add a tag and start coding. I do agree that Vue 3 was rather badly released though, as everything from the websites and docs to the plugins and devtools were all at different stages.

Agreed, you can do the same thing with React too. Just add script tags with React and ReactDOM and away you go, no need for anything else.

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

#200

Post by ZeikJT »

geenat wrote: post #118

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/

"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.
Post reply on HN