Live data from Hacker News

Vue.js is Wikimedia Foundation's future JavaScript framework

lists.wikimedia.org

181–190 of 204 posts

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

#181
post #135

Earlier quoted context omitted.

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.

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 / effect executions trigger each other). Since `setup()` is only run once, I can also do things like store non-reactive state in closure variables without wrapping those variables in hooks.

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

#182
post #135

Earlier quoted context omitted.

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.

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.

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

#183
post #180

Earlier quoted context omitted.

How is it invalid? Here's the syntax about a for..in loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for (variable in object) { statement } The only difference in Vue is not having to explicitly declare the variable. But so what? You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string i…

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.

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

#184
post #180

Earlier quoted context omitted.

How is it invalid? Here's the syntax about a for..in loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for (variable in object) { statement } The only difference in Vue is not having to explicitly declare the variable. But so what? You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string i…

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.

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

#185
post #178
post #170

Earlier quoted context omitted.

Where do they teach this "people do things because they're dumb, I'm special I see the truth" thing? Let me sign up.

Honestly if you just pay attention to the constantly shifting fads and “best practices” you’d have noticed by now. Example: object oriented programming was THE WAY the write code a few years ago. Now functional programming is all the rage even though it has existed for decades. In fact, idiomatic react code just recently made the same switch. I think it’s important to think critically and frankly having a discussion…

I agree with that, but what you advocade isn't efficacy, "just write good vanilla js" is as useful of a statement as "just write clean code".

In practice I've never seen anyone capable of writing clean vanilla js except for myself.

Of course that's just me jerking off to my own standard. "Vanilla" is an useless approach when it comes to finding a common ground to work in a professional context. It's in-efficacy in that sense.

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

#186
post #159
post #78

Earlier quoted context omitted.

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

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.

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

#187
post #171

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…

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

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

#188
post #172

Earlier quoted context omitted.

> It's basically any valid `for..in/of` expression This isn't true at all though, because `for x in y` is invalid JS.

How is it invalid? Here's the syntax about a for..in loop: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... for (variable in object) { statement } The only difference in Vue is not having to explicitly declare the variable. But so what? You said "strings are magic and not code" to which I said "all code is text so there are no magic strings". Now you and the other poster keep saying "well this string i…

> How is it invalid? Here's the syntax about a for..in loop

   for (variable in object) {
     statement
   }
And here's the syntax for Vue's for..in loop. Only one of it is somewhat Javascript:

   item in items
   (item, index) in items
   (val, key) in object
   (val, name, index) in object
And, of course, there's an extension to that

   v-for="item in items" :key="item.id"

Edit: additionally, from that very link: "for...in should not be used to iterate over an Array where the index order is important." But this doesn't concern Vue, it maintains the order in its for..in.

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

#189

Earlier quoted context omitted.

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

I've been through two large-scale projects now where we went 100% into hooks, and after a couple years the excitement has faded and I often wonder if it was worth it. It seems to end up making code even more complex than before, even though components look simpler on the surface. Not enough to go back to classes, but doesn't feel as good as those first steps. I absolutely hate the manual dependency tracking and havin…

In my opinion, the issue here is going 100%. There are use cases where having a class component is easier to manage, f.ex: if you make use of external classes.

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

#190

Earlier quoted context omitted.

> The point is that all code starts as simple text, and is parsed and compiled into some lower layer Yup > What actually does the compilation is irrelevant. Nope. It is relevant. For the stuff you put between script tags there's at the very least https://github.com/tc39/ecma262 that you can look at and tell exactly what's going on with your code. With Vue (and, yes, React and Svelte and Angular): who knows? It might…

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 always solve your mystery of "who knows" by just looking at the source code

Ah yes. The good old "code is the source of truth" fallacy. Can you point to me where exactly in code it specifies this: `Expects: Array | Object | number | string | Iterable (since 2.6)`?

Post reply on HN