Live data from Hacker News

Vue.js is Wikimedia Foundation's future JavaScript framework

lists.wikimedia.org

91–100 of 204 posts

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

#91
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…

> My IDE can't highlight that this is wrong because it's not code and is just a string

Code is just a string too, treating the 'code' inside the string literals after the v-for is just an extra level of syntax handling - The IDE I use (Intellij) can handle it just fine.

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

#92
post #26

Not even a consideration of svelte?

Svelte and Vue are actually very similar in some ways. Personally, I hope Vue creates an option to compile its components into static components like svelte; having the option to have a runtime component or a static compile time component would be super powerful!

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

#93
post #82
post #79

Earlier quoted context omitted.

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.

Many users - who weren't programmers by training - loved CF for the ease of understanding. They had a DX paradigm that worked and I understand why people try to emulate it. It's a question of audience, and not for the HN crowd.

Except that SPA frameworks are designed to complicate things, not to make them easier to understand. And SPA framework developers are crazy expensive, mor expensive than seasoned C++ systems programmers. (The two facts are probably linked.)

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

#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, 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.

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

#95
post #85
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…

Yeah, this isn't really an issue; it's just a templating language. You can get an extension for your IDE to make it syntax highlight correctly. That's like saying a .js file is just a string. Um, yes I guess sure? All code is just a string. HTML is also just a string. Vue's HTML templating syntax is also just a string, but it's also code. It's code that's mainly HTML, with certain spots that allow full JavaScript. An…

What about type checks?

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

#96
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…

For my in mind-blowing that people still code with plain strings.

Why in the world would you ever write text over proper JavaScript language.

You lose so many features.

For example you lose type check, which it's core to any project.

For me it's a no brainer to use an existing language to render stuff. Tsx I know it's not just js, but I can consider as just plan js/ts code.

Edit: seems like they do type checking, but I'm pretty sure can't do type checking at the whole file level.

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

#97

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

Glad to see Alpine mentioned here! Hope it gets more adoption.

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

#98
post #25

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…

React does not seem like a good fit for doing any of these things. Aside from keyboard navigation, which works just fine as far as I’ve seen. I dunno, every time I see someone hating React they’ve been kind of stuck in doing things the jQuery way, and their components become this horrible frankenstein of modifying HTML both through React and directly.

> their components become this horrible frankenstein of modifying HTML both through React and directly.

I need to know what the problem is with modifying HTML inside a browser that knows and expects the HTML to be modified, even providing DOM APIs for this exact reason. What is the benefit of modifying a not the DOM besides the dubious claim of performace++?

I use react everyday now BTW. I needed to do something trivial like use something similar to setproperty to update CSS variable with JS returned values. This was part of a component that gets 3 colors and returns an array of RGB values which I need to change the background into a gradient. The one piece of advice I got from the internet is...

styled components.

FfS.

React is breaking every best practice from ~20 years ago of keeping concerns seperate. Sure Jqeury wasnt perfect but I could get a junior dev fresh out of school up an running in two weeks flat. There was no need to bend the time-space continuum with the black whole density of node_modules for every_single_thing.

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

#99
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.

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

#100
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…

> Right down to that time when the community cried out about Facebook's odd license clause regarding patents. And they changed it.

Looks like you are remembering things differently. Facebook doubled down on public outcry and even react maintainers gave up on it.

Then wordpress chose to stop its adoption of react in its new editor. And that caused Facebook to change the licence.

The fact a big org was needed for this change, is a major factor for Facebook's distrust.

Post reply on HN