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

61–70 of 204 posts

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

#61

Post by buchanaf »

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…

I don't know. I'm not as familiar with Vue, but React's ecosystem is in such a good spot right now. Between things like RTKQ (or react-query), Material-UI, and react-hook-form, the abstractions over common web use-cases are just so terrific to work with nowadays.

And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.

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

#62

Post by dragonwriter »

Drew_ wrote: post #60
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…

I don't know if you haven't had much experience with templating engines, but having the ability to write programmatic expressions to make a layout dynamic is a basic necessity that pretty much every known templating engine has. "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does and it works pretty well in practice.

> "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does.

Its not, though. JSX-based solutions (not just React, but Solid and others) don't (actually, neither do many frameworks with more traditional-looking templates, including, AIUI, Vue, actually compile templates to render functions, so it just looks like old school “string with embedded code which is evalled” ttemplates)

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

#63

Post by zkldi »

Drew_ wrote: post #60
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…

I don't know if you haven't had much experience with templating engines, but having the ability to write programmatic expressions to make a layout dynamic is a basic necessity that pretty much every known templating engine has. "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does and it works pretty well in practice.

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 beginning!

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

#64

Post by mdoms »

ng12 wrote: post #30
dzonga wrote: post #22

react is api stable, but not api stable if you know what I mean. with react, the ground is always shifting underneath you, which something like wikimedia probably don't have the resources to keep up with. even, as someone who has done react professionally, I can advise any small nimble teams, out there react ain't for ya. it don't love ya. however, for the big enterprisey apps, yeah react is good.

I cannot relate to this experience at all. Can you specify examples of what you're talking about?

I'm not the guy you asked but I'm guessing he's referring to the "blessed way" of doing React, which seems to change every couple of years. Class components one year, pure components the next, functional components the next. A couple of years after that you're mad if you use React without Redux, the next year you'd be crazy to do Redux. State management a year later should be done with hooks, as should everything else. So what's going to be the next piece of guidance that will make our apps perfect?

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

#65

Post by tomjen3 »

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…

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

Webstorm has zero problems letting me refactor it, because it can parse vue code in .vue files. This is seriously a non-issue.

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

#66

Post by gentleman11 »

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…

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

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

#67

Post by Drew_ »

dragonwriter wrote: post #62
Drew_ wrote: post #60

Earlier quoted context omitted.

I don't know if you haven't had much experience with templating engines, but having the ability to write programmatic expressions to make a layout dynamic is a basic necessity that pretty much every known templating engine has. "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does and it works pretty well in practice.

> "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does. Its not, though. JSX-based solutions (not just React, but Solid and others) don't (actually, neither do many frameworks with more traditional-looking templates, including, AIUI, Vue, actually compile templates to render functions, so it just looks like old school “string with e…

I know it's pedantic but this is still JavaScript we're talking about not binary so the "compiled render function" is still ultimately just "a string that gets evaled".

In any case the implementation details aren't important it's what it appears to be that is apparently the problem.

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

#68

Post by gentleman11 »

seph-reed wrote: post #18
Spartan-S63 wrote: post #16

Earlier quoted context omitted.

In my experience, React is very particular at how you present your view logic. For state management, though, it has very few opinions and that freedom can be paralyzing. Do you use Redux? Do you just use built-in component state and props? Do you use the Hooks API? React solves one slice of problems in front-end development, but has few opinions outside of the view layer.

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

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

#69

Post by Drew_ »

zkldi wrote: post #63
Drew_ wrote: post #60

Earlier quoted context omitted.

I don't know if you haven't had much experience with templating engines, but having the ability to write programmatic expressions to make a layout dynamic is a basic necessity that pretty much every known templating engine has. "It reads like storing code in a string and evalling it" sounds very funny in this context because that's exactly what every solution does and it works pretty well in practice.

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 think it is.

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

#70

Post by sangnoir »

zkldi wrote: post #53
AbuAssar wrote: post #52

Earlier quoted context omitted.

This is not a regular string, it is a template. And the tooling handles it just fine. You get type checking, linting, syntax highlighting etc.

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