Live data from Hacker News

Vue.js vs. React

vuejs.org

251–260 of 486 posts

Re: Vue.js vs. React

#251
post #46

You'll see quotes in this thread like "The demand for both React and Vue.js is growing tremendously" thrown around. It's good to check out npm install stats to get an unopinionated comparison. https://npm-stat.com/charts.html?package=react&package=vue&p... In reality, React is downloaded roughly 4-5x more than angular and 7-8x more than Vue. In August so far, React has 75% market share among these three libs. Interes…

Having worked for a big company, one of the things that people look for in a framework is a tech giant like Facebook supporting it. One of the reasons why people are shying away from moving to Vue is because that it's completely community driven. Think about Angular's huge initial success - it had the backing of Google

Re: Vue.js vs. React

#252
post #242

Earlier quoted context omitted.

Here is an example of that code implemented in Vue. https://codepen.io/Kradek/pen/JyLPaL?editors=1010 I really haven't run into anything I could do in React that I couldn't do in Vue. What I mainly miss in Vue is react-native.

Great, here are my thoughts on it 1. Render methods make vue basically the same as React plus MobX, right? (and afaik you can use JSX too) 2. The spinner component was registered in the global scope. Will normal build tools know about the file and properly include it, or an import will need to be placed somewhere for that to work? What happens if another module registers a "spinner" component? ES6 and CommonJS module…

1. The MobX-like functionality is moreso simply a native feature of Vue. All data values are converted into observed values. A render is triggered by changes to data. I believe Evan himself basically said React + MobX = Vue. Using a render function was just a choice. It could just as easily have been written with a template.

2. Again, this was basically just a choice for the example. The spinner could be defined in a module and imported/registered locally. Codepen/JSFiddle just isn't the greatest place for that kind of example.

3. Scoped slots are a way for a component to expose internal data to elements contained in a slot (content thats contained within the component but defined by it's parent). I agree, its initially one of the more confusing concepts in Vue.

Re: Vue.js vs. React

#253

Earlier quoted context omitted.

I love single file components. I used Polymer before React and that is the thing I miss the most. I've also been using CSS-in-JS for the same reason. I landed on JSS for now, but I'm hoping we'll see a solid scoped CSS solution soon.

I'm still to be totally convinced by single page components, the idea of mixing languages within a file just doesn't feel right. I think I'd prefer to have a component directory with HTML, JS/TS and CSS/SCSS files in.

Doesn't that depend on pipeline? I've been doing for polymer components with html css and js split into separate files. They get concatenated into single file in build process.

Re: Vue.js vs. React

#254
post #232
post #203

Earlier quoted context omitted.

I'm not sure I follow. To use the basic example from the link, as opposed to this: const listItems = numbers.map((number) => {number} ); return ( {listItems} ); What's wrong with looping this way?: return ( {numbers.map((num, i) => {num} )} )

> What's wrong with looping this way? The problem IMO is that it's harder to read and write than: {{num}} That's Vue's syntax, but any other templating language is more readable to me than JSX.

How is that more readable? Furthermore, does that break at runtime if listItem is undefined or you typo'd the second num? JSX would catch it as a syntax error.

Re: Vue.js vs. React

#256
post #104

Another option that is interesting right now is Polymer 2.x if you haven't tried it recently, give it a shot. https://vuejs.org/v2/guide/comparison.html#Polymer There are some similarities shared between polymer and react/vue (personally only used react and angular 1.x before). I've built applications with it using polyfills and things worked just fine with legacy applications on IE10 + jquery interacting with web co…

Having 1k components sort of seems like a bug rather than a feature. How does that avoid becoming left-pad hell again and how would you expect any sort of quality control out of that?

Not really (I'm not even sure of a feature of "what" would it be?)- it is not like you have to use any of that - you could make same criticism for NPM, pypi etc. Webcomponents.org is just a repository, nothing more. If you want quality then you just use components backed by reputable authors - I guess that is the universal rule for development in general.

Re: Vue.js vs. React

#257
post #188
post #127

One of the biggest things React has going for it, other than being maintained by Facebook and having a much larger community, is React Native. You can learn one web framework and now also make compelling, real native apps. To me those are both deal makers. Surprised I haven't seen this mentioned more in the thread.

Or you can just compile any HTML5 mobile app using Cordova and in 99% of the cases your users won't notice any performance difference between native-app and HTML5 app.

Maybe for extremely simple webapps that might be true, but for any non-trivial Cordova+React based app you can't come anywhere close to the UX you can get with React Native without some extreme engineering effort. I'd much rather eat the cost to port the HTML5 app to React Native instead. Yes, the users DO notice.

Inability to have the same level of control over soft keyboard behavior is one of the top problems with Cordova, IMO.

Source: wrote & maintained a Cordova+React app on iOS/Android for 3 yrs.

Re: Vue.js vs. React

#258

Earlier quoted context omitted.

> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript. From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so…

To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.

Actually those idiosyncracies are React, not JSX. Using JSX with Mithril I've had no trouble using reserved words as attribute names. Dynamically inserted html in Mithril/JSX is just {m.trust(str)}

Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.

Re: Vue.js vs. React

#259
post #193

Earlier quoted context omitted.

I saw a talk on Polymer about 2 years ago where it was the next big thing, here we are two years later and it doesn't seem to have progressed at all - I do get that it is the future I just don't think it's one that's quite ready yet.

The update from Polymer 1 (Web Components v0) to Polymer 2 (Web Components v1) was huge for both code simplicity and performance. I know that my huge hangup with Polymer was performance, but it was solved (mostly) by Polymer 2 (released last May.) I'd give it a second look, especially now that most of the major pieces of Web Components v1 are shipping natively in browsers. On the other hand, a lighter Web Components…

Does it make that much of a difference? My applications are still on 1.x, I did migrate my components to hybrid though. One other interesting libraries to look at are svelte or skatejs - haven't used them personally yet.

Re: Vue.js vs. React

#260
post #232

Earlier quoted context omitted.

> What's wrong with looping this way? The problem IMO is that it's harder to read and write than: {{num}} That's Vue's syntax, but any other templating language is more readable to me than JSX.

I find the JSX loop infinitely easier to understand what's going on. It's a javascript map. With your Vue example, what is listItem? An array? Can it be an object? Does listItem need a special decorator for v-for to be able to loop through it? So many initial questions that just aren't there if you just use Javascript.

it's just plain for(x in list){ .. }

v-for="item in list"

if you need idx:

v-for="(item, i) in list"

pretty standard stuffs

Post reply on HN