Live data from Hacker News

Vue.js is Wikimedia Foundation's future JavaScript framework

lists.wikimedia.org

161–170 of 204 posts

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

#161
post #46

Earlier quoted context omitted.

Your example would be considerably simpler if you had separation of concerns [1]. You have routing, data fetching, redux, visual components, all in that small snippet. Sadly React devs seem to do this all the time... its like they have never heard of MVC. [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

I suggest searching what each of those HOCs is doing. This code is not dealing with routing, fetching, managing state or rendering. It is merely "gluing" those things together. Doing that can be considered a "single concern". Over-splitting things only makes them worse to read and understand, even though each sub-component is prettier to look at. Also notice there's a disclaimer on your linked article here the author…

> 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. If something better than React comes along (and it will) only the view layer should need to be rewritten.

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

#162
post #126
post #102

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?

> vanilla js? you either: 1. write spagetti 2. make your own abstractions, utilities, structures etc No comment on 1. On 2. I know you think your code is so elegant and blows people' mind away or whatever, but trust me, give it to someone else to have a read. They'd probably disagree with you more than they would ever disagree with a framework. At least the frameworks have tests and documents for their functions

The only UIs I create are pretty simple. For simple interfaces I would much rather deal with spaghetti and homegrown solutions rather than massive overhead and complicated abstractions.

A lot of people just blindly build everything they write with their framework of choice. I argue that react is overkill for 9/10 web apps.

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

#163
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?

I think it won't really make sense until you try the alternatives. I've used react since it's inception, vue, ember, angular (going back all the way to angular 1), knockout, etc etc etc.

All these frameworks try to solve what you're mentioning in different ways.

Obviously people have different opinions, but after seeing the way things are done from all these different frameworks, Vue is extremely "clean" and minimal feeling, while remaining extremely flexible. I have built multiple very complicated apps and there's nothing that I'm not absolutely DELIGHTED how it's solved, especially with the new composition API. It feels extremely elegant compared to the other ones I've mentioned.

Perhaps consider the alternatives, and you most certainly will have a much worse development experience if you're not willing to play ball with 2-way data binding (ie use html attributes to bind things, etc). As I said, other frameworks have tried other methods to minimize attribute use and they're excruciating to use. Ember is literally one of the most painful frameworks I've ever used to do even the most simple of things.

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

#164

Earlier quoted context omitted.

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?

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…

Vetur languished for years without the resources it needed. From lack-luster type recognition to bugs that would just crush its performance. I believe it has just recently(within the past year or so) been taken up a level.

TSX support, and frankly JSX is the future of VueJS IMHO, also only really started working well with the addition of attribute namespaces to TypeScript.

So while these things have improved recently I would say language tooling has been really lackluster compared to the React ecosystem even 4+ years ago..

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

#165
post #101
post #94

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, bec…

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

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.

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

#166
post #130

Earlier quoted context omitted.

Angularjs didn’t really stick around after google moved on to angular 2, despite being open source. People who still wanted a similar workflow switched to vue. I think that’s the concern

There's plenty of angularjs still around, for projects that can't or don't want to move to angular 2. The official end-of-life keeps getting pushed back, and I won't be surprised if someone r eventually forks it.

Wow, had no idea AngularJS hadn't hit it's EOL yet

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

#167
post #135
post #124

Earlier quoted context omitted.

I'm guessing hooks, even react devs are not sure about the fake functional programming nonsense.

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 options API or use the setup method, or end up with some awkward in-between.

I was always a big fan of Vue though; I'd appreciate any insight you can give on the Vue 3 additions.

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

#168

Earlier quoted context omitted.

> Text inside script tags is parsed as JavaScript by default. It can be other languages too It can be, but usually isn't. > Again, it’s all just text in different syntax. Again, it's not. And the reason is simple: the browser literally knows nothing about other syntaxes but Javascript [1] So, no, "text in Vue" is literally not the same as "text in script tags". It is a mish-mash of: - Vue's own DSL (see v-for) - JS e…

The point is that all code starts as simple text, and is parsed and compiled into some lower layer until it finally gets to machine code. What actually does the compilation is irrelevant. All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it, but compilation is the same fundamental process regardless of langu…

> 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 very well evalueate strings at runtime for all we know.

> All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it,

Yup. It's an additional, different step before it can even get to the browser. The problem with this step is that for most of this code there's not even a coherent specification of what it is, and how it's compiled.

> and Vue's documentation already describes exactly what you can run

It really doesn't. For example, here's the "documentation" on v-for:

    Expects: Array | Object | number | string | Iterable
Expects where? Is this correct:

    
Answer: no. Because the actual description of what is expected is written in examples. Same goes for every single other directive. I mean, v-bind expects "any (with argument)" (what does this even mean?) and v-if expects "any", and both of these are false statements.

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

#169

Earlier quoted context omitted.

The point is that all code starts as simple text, and is parsed and compiled into some lower layer until it finally gets to machine code. What actually does the compilation is irrelevant. All of these JS frameworks (React+JSX, Vue+HTML, Angular, Svelte, etc) require template compilation into an actual JS render function before a browser ever runs it, but compilation is the same fundamental process regardless of langu…

> 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 you can do anything?

It's basically any valid `for..in/of` expression but you can always solve your mystery of "who knows" by just looking at the source code: https://github.com/vuejs/vue-next/blob/master/packages/compi...

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

#170
post #162
post #126

Earlier quoted context omitted.

> vanilla js? you either: 1. write spagetti 2. make your own abstractions, utilities, structures etc No comment on 1. On 2. I know you think your code is so elegant and blows people' mind away or whatever, but trust me, give it to someone else to have a read. They'd probably disagree with you more than they would ever disagree with a framework. At least the frameworks have tests and documents for their functions

The only UIs I create are pretty simple. For simple interfaces I would much rather deal with spaghetti and homegrown solutions rather than massive overhead and complicated abstractions. A lot of people just blindly build everything they write with their framework of choice. I argue that react is overkill for 9/10 web apps.

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