Vue.js vs. React

https://vuejs.org/v2/guide/comparison.html#React

by fanf2 • 9 years ago

732 471 9 years ago

vuejs.org

pasta• 9 years ago

My #1: download vue(.min).js and you are ready to go. No packagemanager, bundler and what not needed.

nightski2• 9 years ago

You can do the same with react. Unfortunately with either library you are going to want it for any serious project.

esistgut2• 9 years ago

Exactly. I would rather see the community focusing on a standard workflow like ember-cli and angular-cli.

k__5• 9 years ago

This whole "React is complicated" is a strawman.

How is JSX more complicated than any template language?

How are Vue components any simpler than React components?

mmcnl3• 9 years ago

That usually only works well for really small components. Once you're serious about your web app, you'll end up using the whole developmnet Webpack environment in short time anyway.

andrew_wc_brown• 9 years ago

MithrilJS

porsager• 9 years ago

Oh if only mentioning mithrils name would be enough to explain it's benefit I think a lot more people would be using it, but we need to do a bit better than that. Mithril is one of the few libraries that really embraces JavaScript and the beauty of a clean abstraction and lean API. There's no heavy learning curve, just learn a couple of method signatures, and you're ready to go. Once you need to do something advanced or use a third party library mithril won't be in your way! I still haven't seen anyone happily go back to react or vue for that matter after experiencing mithril.

https://mithril.js.org

tropshop• 9 years ago

I left mithril for domvm. It has a smaller focus and less magic.

https://github.com/leeoniya/domvm

mycat• 9 years ago

Vue.js is like perl. Too many ways to do a single thing

erichdongubler2• 9 years ago

Out of curiousity, examples?

k__5• 9 years ago

They bait newbies with their easy data-binding and switch them to components later.

ktRolster• 9 years ago

That's a good thing.

adriancooney• 9 years ago

This is exactly my concern with Vue, the API is huge! One of React's strongest points is the tiny API.

holydude• 9 years ago

I would go with react just because it is more popular. Unless you are someone with free hand picking a technology that is more widespread (hence more in demand) is in this era the wise choice to make.

hobofan• 9 years ago

The demand for both React and Vue.js is growing tremendously. There isn't really a wrong choice to make here.

(I would also say the same goes for picking programming languages, as long as it's one of the top ~15, and you stay somewhat flexible.)

azr792• 9 years ago

There is way more demand for Angular and react than there is for Vue

sudders• 9 years ago

Go for Ember: - Proven tech - No licensing issues - Solid community - Community driven, no company calling the shots

fny2• 9 years ago

I was a huge Ember evangelist until I started trying to onboard other devs into my project. It took months for people to figure out which way was up. In comparison, other devs picked up Vue in a week or so.

lossolo• 9 years ago

Exact same problem here. I've written ~20k LOC non trivial web app in Ember and getting someone into the project that didn't had prior experience in Ember was really tough. Then we were thinking about Vue too and like in your example, that person picked up Vue in around a week also.

soneca• 9 years ago

Interesting, because my company chosen Ember precisely because it would start a hiring wave of new developers, often junior ones. Mostly because of Ember's "convention over configuration".

I dont see much of this problem, including myself as one of these just hired jr devs.

jacquesc2• 9 years ago

Same here. Going back to some large ember projects I built just 2-3yrs ago, it's almost impossible to comprehend. Also, it's impossible to upgrade to the latest version of Ember due to the amount of churn they went through from 1.x to 2.x

coolvd1312• 9 years ago

This discussion might just get a lot of light just cause of Facebook rejecting the licensing issue.

Chirael• 9 years ago

Absolutely. I just checked and vue.js uses the MIT license which would seem to be much more startup (and investor) friendly than the React license.

kiwee• 9 years ago

Vue is good for simple things. But it do not shines for complex apps and sometime makes it even harder than it should be. React can appears complicated when beginning, but it pays off on complex apps.

tomduncalf9• 9 years ago

This is the impression I get, but I've not got any Vue experience to back it up so it's literally just based on first impressions.

I completely agree that React can feel like overkill for simple stuff, but really shines as the apps get more complex - complexity feels a lot more manageable.

For example, I built this in-browser Illustrator-inspired site/app using React and couldn't have imagined doing it without (in terms of making managing state and reasoning about things easy as the app grows more complex): http://f37foundry.com (the type tester on the desktop homepage, apologies for limited browser support!). Curious if you could do that sort of complex app with Vue.

amirouche• 9 years ago

what seems overkill in reactjs?

inthewoods• 9 years ago

What is complex about the site?

kuschku4• 9 years ago

I’m curious, how did you manage to build a website that claims to work in Chrome, but not in Chromium? In Safari, but not in Firefox?

And worst of all, it actually obviously works in Chromium and Firefox, but you just check the UA.

Works:

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Doesn’t work:

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.90 Chrome/60.0.3112.90 Safari/537.36

I mean, sure, if you want to build a site that relies on ridiculous UA testing, and breaks everywhere, sure.

But not even in the "works best in Netscape" era did people actually intentionally break their pages in browsers where it actually worked. This is a new low. This is completely ridiculous.

Proof: http://i.imgur.com/YlPE77b.jpg Oh, and as you can see, if I spoof the UA in FF; it actually works fine. This is completely bullshit, and I’m sure I’ll never do business with you. This is completely ridiculous, leaving out major browsers (and, for example, over 40% of the desktop browsing market in Germany) intentionally and unnecessarily.

majewsky• 9 years ago

please visit this site using some recent version of [browser that sends all your data to Google]

slowclap

If using a JS framework means you don't have time to test your website in more than one browser, I'll happily continue writing plain JS (or better yet, no JS).

yunyu8• 9 years ago

People keep on saying this, but I've written complex apps with both Vue and React (using state stores) and there don't to be any apparent scaling differences. They even use the same component model (virtual DOM, props down, events up).

There are some claims that Vue uses two-way-binding which is unmaintainable, but v-model isn't true two way binding and is just syntax sugar for builtin tags: https://v1.vuejs.org/guide/forms.html With React, you would have to explicitly write the event handler/setter out, and some may prefer explicitness (but again, there's nothing stopping you from doing the same with Vue).

Vue just has some nice features (computed properties, better style scoping, etc) and different methods for inheritance/templating (but you can use ES6 classes and JSX if you want to), and like somebody else mentioned, is plug and play (yes, you can technically write React render functions without a transpiler, but do you want to?) while Vue (with the template compiler bundled) lets you write templates with HTML attributes using just a script embed.

There are a bunch of other arguments that are more nuanced (ecosystem, bus factor, etc..) but from what I've experienced, Vue is no worse at scaling than React simply because they share the same conceptual model.

tomduncalf9• 9 years ago

Sounds like I'll have to try it out! Definitely don't want to put all my eggs in the React basket with all the patent stuff right now so would like some experience of the alternatives.

devdoomari2• 9 years ago

lets you write templates with HTML attributes

that's somewhat bothersome... does it typecheck on compile time? hope vue works on typescript-language-specs compliant plugin...

As for react, there's TSX (typescript-jsx) that works great (typechecks on props, state, etc.), but I haven't tried it with vue.

deforciant• 9 years ago

This is totally not true. It depends on how you structure your project. Vue is good for simple things but it scales way better for large complex apps than React. Why? Less boilerplate. And less boilerplate = less code to maintain. Vue HTML template functions are really well designed with just enough functionality to make your life easier but also encouraging you to build custom components when you need something custom :)

My only suggestion for people starting with Vue is to not be afraid of directives (Vue directives are nice and have nothing to do with Angular directives), group your .vue components into directories and don't jump into Vuex right away (same goes for React beginners, don't force yourself to learn Redux for your 1 page app).

devdoomari2• 9 years ago

you should try mobx + react for 'local' state management. mobx provides something similar to vue (MVVM), and the amount boilerplate becomes somewhat like vue's

azr792• 9 years ago

but it pays off on complex apps.

so does Angular

k__5• 9 years ago

This.

How much simpler than functions as components, that get their props as parameters could it get?

Every example of Vue components I have seen was more complicated...

pier2510• 9 years ago

How you scale your apps is related to how you architecture your project, not what library you use.

siddhant• 9 years ago

Sorry but that's not true. We have a pretty heavy VueJS application in production with like 500 components and it's a pleasure to work with, and is still quite performant.

jaequery14• 9 years ago

i'd say it's quite the opposite. vue makes complex apps easy to write, where react makes it look complex all the time.

alienspaces• 9 years ago

Agreed, the learning curve to build more complex, larger applications in vuejs was considerably less than with react.

hammerandtongs3• 9 years ago

How are people getting along with Vuex vs Redux?

It looks pretty clean and grokable in the examples and deals with async out of the gate -

https://github.com/vuejs/vuex/tree/dev/examples/counter

meagher2• 9 years ago

Using Vuex has a lot less overhead than Redux and async is super! It's fairly easy to keep modular.

Here's a medium size store for a project I worked on: https://github.com/tmm/notational/tree/master/src/store

hammerandtongs3• 9 years ago

Thanks, that looks pretty reasonable.

mariusandra3• 9 years ago

If you use something like Kea (https://kea.js.org), the amount of boilerplate for Redux goes down dramatically. The syntax is actually pretty simiar to Vuex, perhaps with even less boilerplate.

Tade02• 9 years ago

Do you happen to know whether there's an equivalent for NgRx?

hammerandtongs3• 9 years ago

You've done a nice job with kea. The examples are pretty clear. Somehow the selection of verbs and structure is more readable for me in the vuex example but I'm not sure you could do much about that.

I won't be using this as it definitely sets off my library-depth spidey sense.

The multiple libraries it abstracts would all change versions over time and lead my applications to be even more brittle.

Vuex being mainline with Vuejs is a major plus as I look at its long term stability, though whether it insists on vuejs I need to look into.

tanguy_k3• 9 years ago

Did not known about Kea, seems nice! However, there are no unit tests??

keyle• 9 years ago

I've used both. What makes me pick Vue in the end is the fact that there is no compiler needed, no jsx and all the non-sense that goes with that.

If you want a full blown huge application to last years, then go Angular... Although who knows if Angular will be there in 5 or so years.

There is no perfect library/framework but I love Vue because Vue does exactly what it says on the tin.

noir_lord4• 9 years ago

If you want a full blown huge application to last years, then go Angular.

After what they did with Angular 1 -> 2 not a chance.

At least with Vue you can swap it out a lot more easily if it does go away in 3 years.

ergo1414• 9 years ago

Right now a great option with "forward-compatible" applications would be to go Polymer.

k__5• 9 years ago

React has multiple alternatives to JSX too.

paulgrimes1• 9 years ago

No application lasts "years" nowadays, so I'd suggest not go "go Angular" simply because it's Angular. The modularity and speed-to-productivity of Vue is the reason I choose it. Plus, the community is quite supportive; always nice.

recursive• 9 years ago

I work near, but not directly on, an application that's lasted about 20 years so far. It's still actively maintained, and still making money. It's mostly written in vb6 and classic asp. Yes. Some applications far outside the hype cycle can last decades.

barrkel2• 9 years ago

I've been working on a large web app (SaaS, so you won't have heard of it and can't try it out) for the past 5 years, and it's one continuous history codebase using Backbone for UI. It's not going to get rewritten any time soon. I'd expect it to still be using Backbone or something very similar (perhaps switching out some rendering subtrees for Vue or React) in another 5 years.

sotojuan2• 9 years ago

I've never seen a SPA last "years" without some eventual rewrite or major change. The only sites I see last year are serveres rendered ones or very simple ones.

barrkel2• 9 years ago

You probably don't see them because complex web UIs aren't always consumer-facing. The ones you're familiar with are probably maintained by large corporations rather than specialist companies, and can more easily afford rewrites.

dmitriid7• 9 years ago

What makes me pick Vue in the end is the fact that there is no compiler needed

Why are then Vue components written in .vue files and compiled to Javascript then? ;)

yev3• 9 years ago

You don't have to use .vue files to actually write Vue[1].

.vue files are there for simple single file components[2].

[1] https://jsfiddle.net/yyx990803/y91wy85p/?utm_source=website&...

[2] https://vuejs.org/v2/guide/single-file-components.html

erichdongubler2• 9 years ago

I would also add that language additions like TypeScript are not REQUIRED, but one can use them without any additional tech stack concerns in their build pipeline. In other words, things that React and Angular suggest (almost seem to require, given that documentation is written for them) as tech stack recommendations are entirely left to your initiative.

kennysmoothx2• 9 years ago

I used React for a few years and it was great and powerful, there were many things however that I disliked.. Particularly I was not a fan of JSX. I liked React but I did not feel comfortable using it.

When I first saw VueJS I had a hard time understanding how it would be any better than React, that is until I saw single file components.

https://vuejs.org/images/vue-component.png

I fell in love with the eloquence of being able to separate my HTML, JS, Styles for a single component.. it seemed /right/ to me..

In any case, I've been using VueJS ever since for my new projects moving forward and I'm very happy with it. It has everything I would ever need from React but in what I feel is a more polished and thought-out way.

Just my two cents :)

meagher2• 9 years ago

Completely agree! Single-file components are more natural to how I think about the web.

It's worth noting that Vue also supports render functions with JSX (https://vuejs.org/v2/guide/render-function.html).

wolco• 9 years ago

One of the reasons I moved to vue was the template section allowed normal html. Saved me so much time styling.

I do like jsx for simple things but always felt it bogged down the design piece having to convert even if its just the class to className

masklinn• 9 years ago

I used React for a few years and it was great and powerful, there were many things however that I disliked.. Particularly I was not a fan of JSX.

JSX is no more than sugar for vdom function calls. You can use React without JSX, and you can use Vue with JSX.

When I first saw VueJS I had a hard time understanding how it would be any better than React, that is until I saw single file components.
I fell in love with the eloquence of being able to separate my HTML, JS, Styles for a single component.. it seemed /right/ to me..

You… can do that just fine in React? The logic and "template" are in the same file in the first place, and there are solutions like styled-components, csjs or react-styl if you also want the JS.

kennysmoothx2• 9 years ago

Everytime the discussion of React vs. VueJS comes out, there are always people that make the argument that you can make React do everything VueJS can.

Of course you can, these are open sourced projects and you can modify and add packages to do just about anything you want it to do.

However, when presented with an option that is designed from the ground up to work exactly the way you like it, why not use it?

I can install a dozen different packages along with React so that I can get it set up exactly how I want, or I can just use VueJS whose creator's philosophy are more inline with my own and is designed exactly how I like my front-end.

JoshMnem• 9 years ago

Elm is also promising: http://www.oreilly.com/web-platform/free/files/why-elm.pdf

Rotareti• 9 years ago

I'm using react and like its functional approaches. I started implementing libraries such as immutablejs, recompose and ramda. I also make use of pure functional components exclusively. Then I had a look at Elm and I realized that, with all the libraries I have put together, I created my own crippled frankenstein'ish version of Elm. I think I really should give Elm a try!

grav• 9 years ago

Agree that Elm is a good all-in-one solution for SPAs.

You should also give ClojureScript with the simple React-wrapper Reagent a spin. All the functional stuff is built into the language, like Elm, albeit without the types, which both has its pros and cons.

baybal23• 9 years ago

It surprises me how this "vue vs react" gets to the first line for the 10th time in one or another form

hn_throwaway_99• 9 years ago

It's because of the recent decision by Apache Software Foundation to prohibit using Facebook's "BSD+patent" license in their projects. Many people are now on the hunt for alternatives because of the licensing issue.

seattle_spring• 9 years ago

Let me guess-- you're going to argue that "shills" are behind the quick rise?

baybal23• 9 years ago

Tell why should I?

baybal23• 9 years ago

Angular - has appeal for "corporate apps," well, because of Angular 1.*

React - has influence wherever Facebook has influence

Vue - took off in China as FB did not bother to proselytize developers there

a13n2• 9 years ago

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. Interestingly, this share has grown in August compared to both last month (July) and beginning of year (January).

While this thread and the license thread might indicate that React is dying, it's not. It's growing.

If Vue is going to be what React is today, it has quite a long way to go.

throwaway13337• 9 years ago

From the charts, it shows that Vue from 2016 to now well over doubled it's downloads (over 100% growth) while react's only grew by 50%.

It can be deceptive when you look at charts that list totals when what you're concerned with is growth rate.

a13n2• 9 years ago

So from 2016 to 2017, React's market share grew from 74.6% to 74.9% while Vue's market share grew from 5.4% to 9.3%.

A more accurate narrative would be that Vue is eating the dying Angular.

yunyu8• 9 years ago

Something worth noting is that both Angular and Vue are far more script-embed-directly-into-page friendly (mostly due to templating) compared to React. Almost all React users get it from NPM, while I would expect that the proportion of Angular or Vue users who get them from NPM is lower. I've seen a lot of projects for those two run without any build system (and anecdotally, I'm pretty sure I'm not the only one who's learned Vue with just a script embed).

bastawhiz2• 9 years ago

A very large number of people use React in the same way, linking to a cdn.

sb8244• 9 years ago

I think this would be very likely. For instance, we are still using a bower install of angular due to rails asset pipeline that is committed into repo. Our tens builds per day that would be fetching fresh are not fetching angular for that reason.

madmax108• 9 years ago

Perfectly said. I've used Vue for a couple of months now (a couple personal projects, experiments and some dashboards) and used Angular for ~2 years before (admittedly, mostly Angular 1), and have literally never had to start off from 'npm install', unlike react (which I used for a year or so before), where everything needed a lot of boilerplate setup.

Most devs I know start a react application by cloning some standard git repo which has a working webpack/tidyCSS/redux/some test suite etc. and then write your first line of useful code. The boilerplate is enormous!

chrisco25513• 9 years ago

Angular 1 is, but Angular 2+ is not at all. Angular's CLI is Webpack based, and leverages NPM for package management.

As for build systems vs. script includes... I think Vue is probably being used in a lot more hobby projects than npm downloads would seem to indicate...but using a build system is a stronger indicator of a professional web app and pretty much necessary for any non-trivial project.

sotojuan2• 9 years ago

Here in NYC I have yet to see a job posting asking about Vue. It's all either React or maintaining an older Angular app.

jaequery14• 9 years ago

usually it takes a few years for a new framework to take hold, since the react devs are probably still working on their projects and wont be switching in the middle of it. but in two years, who knows, you might be glad you picked up vue when you see almost everyone starting their project in vue come time being.

ergo1414• 9 years ago

I don't think one should base the decision what to choose solely on "who gets more downloads".

Otherwise we would all be still using PHP instead of Python or Ruby.

akirofi• 9 years ago

The "angular" npm-package is for angular1 only though, angular from 2+ forward is located in the @angular namespace on npm. So a more correct package to compare to would be something like @angular/core, or if you want to track all versions combine angular and @angular/core.

edit: looks like angular had 1 million downloads last month and @angular/core 1.7M.

tomc19853• 9 years ago

I really don't want Vue to become another React. React used to be a single </script> dependency in the browser and now it is difficult to find examples and discussions that don't require downloading npm and all these other components.

scottmf7• 9 years ago

What do you have against npm install create-react-app?

KerryJones• 9 years ago

What's also important is that Vue 3x'd growth while React 2x'd growth.

I grabbed a point around the middle and one near the end. React: 642K > 1,184K. Vue: 53K > 155K

danjoc• 9 years ago

Another chart worth viewing:

https://www.hntrends.com/2017/july.html?compare1=React&compa...

Hiring is a lagging indicator, but I see React hitting a plateau the way angular did. I see Vue is on the cusp of takeoff. Time will tell if it fails to launch, but I'm seeing more interest in Vue at meetups than React.

I think a lot of this has more to do with React's state management than licensing. One of the react developers said it best. Paraphrasing;

Everyone stopped saying React is fun after Redux.

tarsinge• 9 years ago

Everyone stopped saying React is fun after Redux.

From my understanding managing state is a fundamentally hard problem, and Redux just make it very explicit and avoid the confusion of a state living in multiple places.

Did not try Vue but is the state management simpler?

myth_drannon3• 9 years ago

Angular didn't hit plateau, but collapsed after ng2 was announced. React will replace angular and hit plateau just because the number of f/e jobs is limited.

chrisco25513• 9 years ago

Redux is completely optional, 3rd party library. So I really don't understand why anyone would say that. You don't like Redux? Don't use it.

davedx• 9 years ago

Indeed. There is a lot of hype around vue.js, and maybe some is even warranted, but companies and devs are almost entirely split between Angular2 and React in my experience (been hiring, so reading lots of CVs and talking to devs).

Vue.js might be better than React in some ways, but is it enough of a paradigm shift to throw away a bunch of hard earned knowledge?

chrisco25513• 9 years ago

This is a great point. I see Vue and I like what I see. However, the difference with React was that it was a big step up from everything that came before it. Vue is more of an evolution and not a revolution in front end dev. If it's better than React, it's marginally better...and that marginal benefit is offset by the massive ecosystem and developer mindshare that React has accrued over the years.

mshenfield2• 9 years ago

I think it's going to get there. The sheer number of JavaScript developers means there's always someone out there who wants to try something new, and haven't invested in learning React yet. Doesn't hurt that contributing a meaningful library for a framework comes w/ a healthy dose of internet points.

React was in the same spot a few years ago. It went from a dark horse to the default over the past two years.

darrinmn2• 9 years ago

npm stats are slightly deceptive because Vue is huge in China. In China npm is very slow so most devs use mirrors to download their packages. so the * here is npm doesnt really include China, which is arguably Vue's biggest market.

pkozlowski_os• 9 years ago

A more interesting graph would be one that includes Angular 2+: https://npm-stat.com/charts.html?package=react&package=vue&p...

peniqliotuv• 9 years ago

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

jaequery14• 9 years ago

i think we all learned that a huge company backing has no bearing to the success of the project.

just ask any ex-angular devs.

myth_drannon3• 9 years ago

JQuery was authored by one guy. One a technology reaches certain threshold no one cares about its origins as long as it's open source.

christilut• 9 years ago

NPM stats are not representative at all because for every big project there are tons of NPM downloads. For every branch, every deploy, every pull request. This grows exponentially.

Just like Github stars arent representative because only (active) Github users would add a star and when a project has critical mass, the amount of actual users will no longer correlate to the amount of stars.

Anyway, I don't think there is a good way to measure usage or popularity of these frameworks. Maybe Google Trends or stackoverflow tags? I don't know really.

thecrazyone3• 9 years ago

Google trends are particularly difficult for this case because angular (the library) is not a "topic" there. React however is, though.

Stackoverflow tags comparison here: http://imgur.com/a/O3mSB

The tool used is here: http://data.stackexchange.com/stackoverflow/query/201360/que...

I felt happy looking at this. Angular has everything (the complete package of router, speed, and all the components you need), and was surprised why react was more popular

robwormald• 9 years ago

Note this chart is actually showing AngularJS (1.x) only. NPM only started exposing stats for @scoped packages recently, so @angular/core (Angular 2+) only has a few months of history.

See https://npm-stat.com/charts.html?package=react&package=vue&p...

daliwali• 9 years ago

npm downloads seem to exaggerate how many actual people are downloading packages rather than bots.

A funny pattern that emerges in the above chart is that downloads drop sharply on weekends. I have seen packages that exhibit the opposite pattern (downloads spike on weekends). And this pattern is correlated with popularity, the most popular packages are downloaded largely by 9-5 industry coders, and mostly via continuous integration bots.

joshribakoff• 9 years ago

Who's to say 99% of the downloads on npm aren't just from CI servers? Some of my side projects made it to 1000s of downloads when I was the only one using them, on various package managers.

Google trends is more useful.

mmgutz• 9 years ago

I work in a coworking space in Seattle. Most of the startups here use React and a few Angular. Not one, that I know, uses Vue. This is a fairly large coworking space and while I don't know every company's stack, the reach of React is impressive considering it wasn't that long ago that Angular dominated.

harunurhan• 9 years ago

I would also check this

https://insights.stackoverflow.com/trends?tags=angular%2Crea...

msoad• 9 years ago

Is there a compiler for Vue components to web components?

I'm worried about forward compability of all this React components I'm building

steinuil2• 9 years ago

What's with the hate for JSX? I think handling HTML as data makes much more sense and is much more convenient than dealing with dumb templates or weird DSLs like Vue's or Angular's.

mediumdeviation2• 9 years ago

JSX is closer to JS than HTML, which means it annoying to write in some cases. Quick, what does this render as?

  <a href="...">Link 1</a> |
  <a href="...">Link 2</a> | 
  <a href="...">Link 3</a>

It's not

  Link 1 | Link 2 | Link 3

as you'd expect - instead, the whitespace after the pipe character is eaten by JSX. This is because HTML is whitespace sensitive, but JS is not, and so to allow indentation, JSX trims whitespace.

Here's another -

  <dl>
    { Object.entries(definitions).map(([term, definition]) => (
       <dt>{ term }</dt>
       <dd>{ definition }</dd>
    )}
  </dl>

This does not work - instead, you need to return an array, but the result is ugly - the commas are part of JS, not HTML, and don't appear in the output, but reading this quickly it's hard to see that (the difference is the braces surrounding the block).

  <dl>
    { Object.entries(definitions).map(([term, definition]) => ([
       <dt>{ term }</dt>,
       <dd>{ definition }</dd>,
    ])}
  </dl>

Vue's 'weird DSL' is HTML (the same is not quite true for Angular's). What you see is exactly what you get. Having a DSL also means you can define your own syntax. Things that are verbose (due to historical reasons in JS), such as iterating over an object, can be made simple -

  <dl>
    <template v-for="(definition, term) in definitions">
      <dt>{{ term }}</dt>
      <dd>{{ definition }}</dd>
    </template>
  </dl>

steinuil2• 9 years ago

Good point about the whitespace, but I'd still rather have the templates inside my code than separate the two, mentally parsing two separate languages with different syntax and stitching them together is a lot more mental overhead IMO.

arvinsim• 9 years ago

If you want whitespace, the proper thing to do is to use   HTML entity.

scarlac• 9 years ago

I disagree on your first example: I've historically found the extra whitespace a huge PITA for years. It causes extra "unpredictable" spacing in your design which is usually unwanted. It's only an issue for multi-line prose. React is opinionated here but I've found it's the most useful option.

On the 2nd point, you are partially correct. In general it's a code smell - strongly consider making it a component (in part for optimization). But definition lists are specifically strange: Unlike other repeating elements in HTML they don't have a container element like tr, li, fieldset, etc.

dmitriid7• 9 years ago

It's funny you bash JSX, which is a very thin XML-like DSL on top of JS, and then turn around and claim that Vue's DSL is HTML

   <button v-bind:disabled="isButtonDisabled">Button</button>
   <div v-bind:id="'list-' + id"></div>
   <form v-on:submit.prevent="onSubmit"></form>
   <a @click="doSomething"></a>

Something tells me JSX is the better DSL.

AlfeG• 9 years ago

Especially that Vue support JSX and can be used without templates.

seanwilson2• 9 years ago

Surely the huge win for JSX is that you can type check it?

I have a Typescript + Angular 1 project. The app logic feels robust as Typescript makes sure I'm using the right identifiers, variables aren't null/undefined etc. The Angular templates are a constant source of annoyance: they aren't type checked and aren't part of automatic variable renaming refactorings.

tanguy_k3• 9 years ago

Wow that is a good point! I have the same experience with Angular.js 1 and TypeScript.

Can someone confirm that you cannot type check Vue.js templates (without using Vue.js JSX support of course)?

y2bd• 9 years ago

This is ultimately what makes React the right choice for me. A big part of the whole code=data thing is that code can be typed, which means now your data (markup) can be typed as well.

Of course this only really matters if you use Typescript/Flow.

jrs953• 9 years ago

For what it's worth, I tried Vue first and ended up moving to React and it just seems to click better with me. More/better libraries too. Nothing on the Vue side of things is as good as Material UI.

highace• 9 years ago

http://www.muse-ui.org/

jrs953• 9 years ago

I don't know how I missed this one, but it actually looks great. A lot of others I've looked at either has performance issues or doesn't really conform to MD very well. At least from the demo site, that doesn't appear to be an issue here.

ziggzagg• 9 years ago

Vue is heavily dominated by Chinese, there is a ton of MD implementations, but hard to judge. One solid MD implementation in vue is https://vuetifyjs.com/ which is not Chinese.

jrs953• 9 years ago

I've used this one a bit actually. Seems alright, but the performance isn't great. It's a bit laggy even relative to Angular material 1

okramcivokram• 9 years ago

There's also http://vuematerial.io

equasar• 9 years ago

Vuetify is better IMO: http://vuetifyjs.com

iwebdevfromhome• 9 years ago

If the licensing is an issue with React, then what about Preact?

jvvw• 9 years ago

For anybody looking into vue.js for the first time, I highly recommend starting with Laracasts series of screencasts which I found much more helpful than the information on the vue.js site itself when I was getting to grips to with it:

https://laracasts.com/series/learn-vue-2-step-by-step

hellofunk• 9 years ago

So Vue is based on the same Virtual DOM as Elm, or its own implementation? Do non-react tools in this arena still have react-like lifecycle hooks, or different ways of handling "on mount" behavior, for example?

hanley• 9 years ago

I'm not very familiar with React, but Vue does have lifecycle hooks that work well: https://vuejs.org/v2/guide/instance.html#Instance-Lifecycle-...

jaequery14• 9 years ago

i sense there may be a flood of react devs switching to vuejs. once their react projects are finished.

honestly react devs are missing out on how great the vue experience is. it didnt take me too long to see how much better vue is.

growtofill• 9 years ago

I would say that experience-defining tools are webpack-dev-server with hot reload, ability to use modern ES features and type definitions via TypeScript or Babel+Flow.

These are available for both Vue and React. Is there something on top of that available for Vue?

jaequery14• 9 years ago

https://nuxtjs.org/. here you get all of that out of the box

jameslk3• 9 years ago

These are the things I find to be killer features of React and it's ecosystem:

- React Native (I know there's Weex but it's not production ready, nor as feature rich)

- Streaming server side rendering

- React Relay (GraphQL integration)

- JSX by default. VueJS pushes an Angular-esque template language where I have to learn new syntax, binding concepts, directives and conditional statements.

- Corporate backing

I've used React in very large projects, where these features have been fairly critical. React's licensing is odd but not odd enough for me to ditch it. I'd really hate to see the community churn once again on frontend libraries, but that's JavaScript for you I guess.

jaequery14• 9 years ago

i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.

of all the frameworks, vuejs has the simplest syntax to learn. its no where as complex as angular and way more elegant. also beats jsx in terms of making your code more cleaner and prettier. im never going back to jsx.

mateuszf• 9 years ago

i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.

Not sure about the original poster, but I prefer react/jsx not because it's simpler, but it's more powerful - it's a simple extension to a full programming language. You can do whatever you want with it.

dmitriid7• 9 years ago

Which part of this is clean or pretty?

   <button v-bind:disabled="isButtonDisabled">Button</button>
   <div v-bind:id="'list-' + id"></div>
   <form v-on:submit.prevent="onSubmit"></form>
   <a @click="doSomething"></a>

There are some redeeming qualities compared to say, Polymer. But it's neither clean nor pretty

wishinghand• 9 years ago

On the corporate backing note- Vue has Monterail, Laravel, JSFiddle, STDLib, UpYun, Deepstream Hub, and others to fund a small team.

azangru• 9 years ago

- Streaming server side rendering

This feature appeared in React v16 (which is still in beta). Vue had it long before.

jameslk3• 9 years ago

I wasn't aware VueJS had streaming server rendering (and I still can't find anything about it), but React has had it long before v16 via a library (https://github.com/aickin/react-dom-stream)

PolCPP• 9 years ago

There's also some early/limited support of vue using nativescript, which is more mature than weex.

https://www.nativescript.org/blog/a-new-vue-for-nativescript

spion5• 9 years ago

To me the whole idea of client-side HTML templates seems bad. They start out easy enough, but then they either limit you in power or introduce new and weird concepts to replace things that are easy, familiar and often better designed in the host language.

Here is an example on which I'd love to be proven wrong:

https://jsfiddle.net/j2sxgat2/2/

Its a generic spinner component that waits on a promise then passes off the fetched data to any other custom jsx. It can also take onFulfill and onReject handlers to run code when the promise resolves.

The concrete example shown in the fiddle renders a select list with the options received after waiting for a response from the "server". An onFulfill handler pre-selects the first option once data arrives. The observable selected item is also used from outside the spinner component.

With React+mobx and JSX its all simple functions/closures (some of them returning jsx), lexical scope and components. With Vue I'm not sure where to start - I assume I would need to register a custom component for the inner content and use slots?

al2o3cr• 9 years ago

    or introduce new and weird concepts to replace things that
    are easy, familiar and often better designed in the host
    language.

Oddly, that's exactly how I feel about the "{condition_expression && template_evaluation}" idiom in JSX.

spion5• 9 years ago

Personally I prefer the ternary operator in those cases, however I think do expressions will fix most of the if/else awkward stuff: https://babeljs.io/docs/plugins/transform-do-expressions/

elyobo4• 9 years ago

Hmmm, I really like the terseness and obviousness of that approach, I use it all the time :)

I have sometimes been caught out by doing `{somearray.length && thing}` though, which leaves `0` hanging out there in the false case...

alevans45• 9 years ago

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.

spion5• 9 years ago

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 modules have already solved this elegantly, and I believe its a must for larger scale applications that may consist of multiple complex modules

3. I see many wheels being reinvented, and as a non-vue user I have no idea what they mean. For example, does `<template scope="data">` name the first argument passed to the function? Is `default` the name of the first unnamed template? And this page is utterly baffling: https://vuejs.org/v2/guide/components.html#Scoped-Slots as I cannot figure out which thing is the template that is being passed arguments and which is doing the passing (and how).

edit: re (3) I finally got it, a `template`'s `scope` gives the props passed to a `slot` a name.

It seems to me that templates look like less learning initially, but they end up being more...

DonnyV• 9 years ago

A lot of people don't know about RactiveJS https://ractive.js.org/. Which I think is better and easier to use then most.

codehaks• 9 years ago

I used both react and Vue, and I would always choose Vue.js over react. beside all the features Vue has, its the documentation that I really like. it makes you want to read more and more.

ergo1414• 9 years ago

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 components.

Performance is nice, there is more and more adoption from giant enterprises like Netflix, IBM, GE, Gannett, Electronics Arts, CocaCola, ING, BBVA.

Webcomponents.org has over 1k components to choose from and is growing.

Now with `lit-html` arriving soon we might see alternative to JSX if someone wants that, polymer-redux or polymer-uniflow is available as an option too.

https://hnpwa.com/ - one of fastest Hacker News implementations is based on Polymer - and that is even without SSR.

SvelteJS also seems nice, although it seems one-man project for now :( On Polymer end I hope that on the summit next week they will announce proper NPM support finally and I miss that.

kevmo3142• 9 years ago

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?

ergo1414• 9 years ago

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.

briantakita• 9 years ago

I can vouch for SvelteJS. It's simple & has near vanillaJS performance.

I use SvelteJS on both the client & server side. SvelteJS also has a rehydrate feature, which allows you to render html on the server & then bind the Component on the client.

ergo1414• 9 years ago

There will be talks about SSR with web components on https://summit.polymer-project.org/speakers. There is talk by author of SkateJS.

jacquesc2• 9 years ago

I used Polymer 2 to build a couple of highly used internal web components recently. And I'm currently in the process of ripping it all out. Why? It's not technically Polymer's fault, but the performance and stability on iOS and Safari are complete crap. Often crashes the browser on both desktop and mobile.

Also, the Shadow DOM is one concept that I liked in theory and hated in practice. Made it very difficult to do very simple styling tasks that were accomplished easily with plain css and proper naming (e.g. having parent components provide default styles for child components).

The polymer bundler in 2.0 is a buggy mess (it's still in beta) and I couldn't find any decent way to use Webpack with Polymer.

Many other complaints about Polymer that I won't go into. It's way too green in my opinion and I'd recommend avoiding it for at least the near future.

ergo1414• 9 years ago

I got into same problem you had - the trick is to have view/parent components not use Shadow DOM - then you can use normal css styling, or alternatively prepare a `shared-styles` file that will contain styles shared across elements.

IMO having everything inside Shadow DOM is an anti-pattern.

I use my own pipeline based on gulp so I don't know much about polymer bundler, webpack support was recently added though, I haven't used it yet.

Kiro4• 9 years ago

I've built semi-large applications in both Vue.js and React. I like both but prefer React.

For me Vue.js is like a light-weight Angular 1, in a good way. It's very intuitive and you can start working immediately. It does however easily end up in confusion about where the state lives with the two-way binding. I've run into a lot of implicit state changes wrecking havoc. The declarative nature of React definitely wins here, especially working with stateless functional components. If you're serious about Vue you should adhere to unidirectional bindings, components and use Vuex.

The best thing about Vue.js for me is the single file components. It's such a nice feeling to know that everything affecting a certain component is right before your eyes. That's also the reason I started adapting CSS-in-JS in my React components.

The biggest problem for me with Vue.js is the template DSL. You often think "how do I do this complicated tree render in Vue's template syntax? In JSX I would just use JavaScript". For me, that was the best upgrade going from Angular to React and it feels like a step backwards when using Vue.js.

LrnByTeach• 9 years ago

Very Nice summary

I've built semi-large applications in both Vue.js and React. I like both but prefer React.
If you're serious about Vue you should adhere to unidirectional bindings, components and use Vuex.
The best thing about Vue.js for me is the single file components. It's such a nice feeling to know that everything affecting a certain component is right before your eyes.
The biggest problem for me with Vue.js is the template DSL. You end up with the "how do I do this complicated tree render in Vue's template syntax?

yunyu8• 9 years ago

Vue removed real two-way-binding in 2.0. The v-model you commonly see is just syntax sugar.

Also, here's the obligatory "Vue supports JSX" link: https://medium.com/js-dojo/using-jsx-with-vue-js-846f4fbbf07...

I personally feel that JSX feels a bit "unnatural" compared to Vue's DSL, but that's a matter of opinion. It's always good to have the option :)

Kiro4• 9 years ago

Thanks! That's cool and yes, it supports JSX but it's still not a first-class citizen like in React. I don't know the practical implications though since I haven't used so maybe my fear is unfounded.

mariushn• 9 years ago

Thanks for the Vue bestpractices!

For newcomers like me, I've found these videos very useful: https://laracasts.com/series/learn-vue-2-step-by-step

Extra tips:

* use axios to transfer data, no need for jQuery

* when you find yourself reaching for jQuery to change DOM, eg add/remove a class, think again. v-if depending on component state data variables worked well for me.

* after trying several authentication libraries, found it simpler to build my own layer, storing user state in Vuex

Anybody has more tips to share? Something you wish you knew earlier?

eibrahim• 9 years ago

I have been building web apps for 19+ years. I like many of the frameworks out there but for some reason I HATE React. I think JSX is a huge turnoff for me. I just can't get past html in javascript. It feels wrong.

With that said, there are so many VERY smart people embracing React, so I am always questioning my "hate". Maybe one day I will change my mind.

I haven't use Vue but watched/read about it and seems very cool and simple to use.

For now, my favorite framework by far is Ember JS and it really blows my mind why it is not the most popular framework out there. The amount of stuff you get out of the box and the incredible productivity and happiness it brings to the developer experience is IMPRESSIVE. It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app*

* I could be wrong.

Bahamut3• 9 years ago

Interestingly, I had recently joined a team that was using Ember, and we found that Ember hampered our productivity. We switched to React and was able to rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how many developers were working on the Ember app originally, but it was mainly 2 of us who built the React app), including requisite tests.

I’m of the opinion that Angular is much better than Ember (note: I have 4.5 years of experience in the Angular ecosystem, including in open source), and I think I am overall perhaps more productive with React than Angular, although I feel like there are less issues with state management in Angular, which has been a pita in React. All the libraries/frameworks have various tradeoffs ultimately, so I don’t believe there is a cure all for everyone’s preferences.

A note about JSX - I am not a big fan of it, but I see it more as having tradeoffs like more traditional templating languages, but different ones. I have been a bit resigned that this is the direction the ecosystem has turned towards, so I have personally decided to hold that dislike more loosely and focus on more important architecture issues. It does little good to let dislike over style paper over higher level issues if you can help it IMO. I don’t think we’ll ever see a perfect template language.

pitaj• 9 years ago

For a long time, people have been saying "separation of concerns" to support the idea of keeping HTML, JavaScript, and CSS in separate files.

The problem with that is that the document, application state, and styling is all highly coupled when dealing with web apps. Web pages which are content based are fine with these being separate, changes to one don't necessarily affect another.

For web pages, the separation of languages is a separation of concerns. However, for web apps, the separation of languages becomes a barrier, since everything about a certain behavior in your program could be in three different languages or more.

React changes this notion with the idea of a component. A component is ideally pure, meaning that it affects itself and it's children, and nothing else in the application. Components are composable, so you can combine multiple components, allowing for very DRY view code.

Idiomatically, React components have elements, styles, and the relevant code in a single file. This keeps things encapsulated and easily maintainable.

alpinecode• 9 years ago

I worked with Ember for a few months and I like it a lot - it definitely deserves more recognition. One thing that frustrated me a lot in Ember was the run loop. The docs suggest that you don't have to worry about the run loop at all and its merely an implementation detail, yet we had to constantly us Ember.run, Ember.run.schedule, etc. all over the app. But of course in order to know which Ember.run methods to use, you end up diving deeply into the implementation details of the framework itself.

guscost• 9 years ago

It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app

You're probably right about this. But it's not always the whole story - maintain and grow your app for a year, and you may find your experience shifts dramatically.

Disclaimer: I haven't used Ember for anything but the tutorial, and I hear it's pretty good these days.

jaequery14• 9 years ago

working anything with loops and conditionals, Vue is way nicer than JSX all the way around, especially the more complex it gets with *-level nested json data trying to mix in with conditional portions of the view, and even saving reactive data back the scope of the loop, etc. i'm not sure why you'd think otherwise. JSX code with many loops and conditionals can start look incredibly ugly pretty fast. if you can provide an example, we can compare between the two to see which is nicer.

brlewis3• 9 years ago

I have a JSX example. It isn't React, but it's Mithril which is similar: https://github.com/brlewis/brlewis.github.io/blob/master/201...

Blog post accompanying said example: https://medium.com/front-end-hacking/how-it-feels-to-learn-j...

I'd be interested to see the equivalent vue.

Kiro4• 9 years ago

Maybe it's just me but I've struggled a lot with especially Angular's template syntax.

Would love to see a side-by-side comparison of complex nested data structures in Vue and React.

octalmage3• 9 years ago

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.

petepete2• 9 years ago

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.

dave7• 9 years ago

I've been very impressed with styled-components - it's outstanding. Inline, scoped, fully native CSS.

If you're using vscode add plugin "Template literal editor" and you get full intellisense on the CSS too!

jbreckmckye4• 9 years ago

I've been in this gig for years upon years and I still don't see what's terrible about two way binding.

Can someone actually justify it without handwaving statements like "you'll notice at scale", or red herrings like "Angular is slow"?

Kiro4• 9 years ago

I honestly don't remember since I don't use two-way binding anymore but the last problem I had was something with copying one person in a list of people with inputs from one place on the page to another and things got really messy. Sorry, don't remember the details. :/

chrisco25513• 9 years ago

Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic.

If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you start adding observables or watchers, which watch a particular variable for changes. If you two way bind a UI element with a controller variable, and then have watchers or observables on that variable...it is now no longer clear what side effects you're triggering as your interacting with that UI element. Wonky things can and will happen to you as your app's complexity grows.

r00nb00m• 9 years ago

It's pretty much an issue of getting to a "stable" state, which means that model stabilizes to a certain value after all the actions by user and code. That can be a problem with 2way binding and sometimes it causes very subtle bugs, but it boils down to the infamous event storm. So that's why they gave up on 2way binding and made it more optional and deliberate

luord• 9 years ago

The problem with two-way binding is that people use more than one source of truth and blame that questionable (to not use stronger words) decision on the framework.

At least that's what I've seen it come down to.

vladimir-y7• 9 years ago

Vue.js is going to win because simplicity and easier bootstrapping matter. In the same time Vue.js is powerful enough for building the complex and scalable apps.

scottmf7• 9 years ago

CRA or Next.js make bootstrapping incredibly simple, and they're production ready.

vladimir-y7• 9 years ago

Bootstrapping matters more for the сurious and not very experienced individuals, think like Vue is a new jQuery.

danielharrison• 9 years ago

Onboarding green devs into anything more than a simple Vue app is a lot more complex than a React app of similar complexity, from my experience.

The simplicity of the nested, inception style architecture of React makes it super easy to onboard and up-ramp.

zmmmmm• 9 years ago

Couldn't disagree more. Or perhaps, more accurately, I think the scenario you are referring to isn't the one that matters.

It's not about taking a massively existing complex application written using one of VueJS or React and onboarding someone completely green into it. Adoption is about "how easily can I incrementally adopt this technology into my legacy app". And the problem is that React is nearly unusable without switching entirely over to a Webpack / transpiler system and learning JSX, which makes it almost a non-starter for someone who isn't planning a major rewrite of their legacy app front end. By contrast VueJS "just works" after dropping a simple JS bundle into a page and the first templates you write are barely distinguishable from regular HTML. You can start by just enhancing the odd page element here and there, and slowly build up to a fully based VueJS app.

zpr• 9 years ago

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.

krirken• 9 years ago

I agree, there are many competitors to React for targeting the DOM, but there is much less competition for targeting Native. I hope to see more JSX-to-Native engines pop up soon to solve that problem.

XCSme2• 9 years ago

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.

jdiaz5513• 9 years ago

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.

rjvir• 9 years ago

Yup, the marginal convenience advantages to web apps are so minimal compared to the ability to write legitimate native mobile apps.

Vue.js and Angular are complete non-starters for me since they don't have native counterparts.

phatbyte3• 9 years ago

Exactly this. In fact (as someone who only knows Swift for mobile dev) learning React was my first step to get into React-Native, so I can make iOS and Android apps.

pier2510• 9 years ago

We moved away from React to Vue about 8 months ago and everyone on the team is a lot happier.

First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates. It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Another problem with React is that it only really solves one problem. There is no official React router and we hated using the unofficial react-router for a number of reasons. A lot of people end up using MobX too.

With Vue there is no need to resort to third parties for your essential blocks. It provides an official router and store called Vuex, which IMO blows Redux out of the water when combined with Vue's reactive data.

Vue docs are probably one of the best I've used. They provide technical docs, plus excellent narrative docs (guides) for all their projects (Vue, Router, Vuex, templates, etc).

I won't say that Vue is perfect, but we would never go back to React.

If you don't like Vue but want to get out of React, check out Marko, the UI library by Ebay. It's better in every way than Vue or React except that the community and ecosystem are almost non existent.

http://markojs.com/

meesterdude• 9 years ago

First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates.

here here! This has been my experience as well

dom0• 9 years ago

*hear hear! ;)

chrisco25513• 9 years ago

In my experience, the folks that feel the strongest against JSX lean anti-JavaScript in general. JSX is Turing-complete. There are no gotchas, you can't paint yourself into a corner, you can set breakpoints in your map statements, it's more testable...Lots of benefits and a big step up over string-based templating languages stuffed into HTML.

ng125• 9 years ago

It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading

What does this mean? I have a sneaking suspicion this is a symptom of poor separation of concerns.

pier2510• 9 years ago

It means that you can't loop where you actually need that loop and that makes reading and writing markup harder than it needs to be.

https://facebook.github.io/react/docs/lists-and-keys.html

Since JSX mixes logic and markup indistinguishably I'd say that's where the poor separation of concerns really is.

gramstrong2• 9 years ago

First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates.

You could theoretically write some template components and "avoid" javascript altogether. I wonder if anyone has actually done that?

JSX isn't perfect, but I find the dirty things about it can be mitigated by keeping your components small, and if that isn't possible then keeping the render function small by breaking it out into several functions that return pieces of your markup. Writing small functions is sound general programming advice, but it seems especially true with JSX/React.

pier2510• 9 years ago

Yes, there is a project called react-templates by Wix that does that.

We used it, but once you start using libraries like that one or MobX, why even use React at all?

jbreckmckye4• 9 years ago

I don't think I buy your defence. Sure, you can make JSX look readable - if you decompose your markup into a thousand scattered functions. But this just swaps one problem for another: indirect code, verbosity, not being able to see the component markup at a glance.

I just feel JSX is too awkward and verbose to be pleasant working.

thomasDE• 9 years ago

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 happy that I did not have to learn another template syntax as it all was just JavaScript.

Another template engine syntax? No, thank you. I stick to React.

Bahamut3• 9 years ago

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.

Rusky• 9 years ago

You can use JSX with Vue, and still get its other benefits. :)

unclebucknasty5• 9 years ago

I can at least remember six template engines' syntax I've learned...

TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language.

Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options.

I think the intense UI-demands of progressiveness/SPAs expose the unsuitability of HTML for the task. But, simply because HTML is what we're stuck with browser-wise, there's no reason we have to think or work in HTML. Use tooling to abstract it away altogether and let a translator generate it.

jcoffland2• 9 years ago

Another template engine syntax? No, thank you.

JSX is another templating language. One built on top of JavaScript rather than HTML.

hesarenu2• 9 years ago

Jsx is one of the best parts of react. No way I can go back string templates and it's own languages.

cderwin• 9 years ago

Vue optionally supports jsx, too

moo3605• 9 years ago

Absolutely agree. Most front-end meetups/conferences I've been to have had the majority of people there expressing a dislike for JSX. I still don't understand that to this day, to me JSX is one of the best things about React.

pacomerh• 9 years ago

Hm? You can actually write loops and conditionals inside of the markup. And... why would you strictly want to do that?, you can write cleaner code by separating your logic/UI. This look more like a rant overall.

pier2510• 9 years ago

Ultimately you can, but your JSX code becomes more difficult to read and write.

you can write cleaner code by separating your logic/UI

That's precisely the point of using a templating language: separation of concerns.

JSX mixes producing markup with your component logic.

This look more like a rant overall.

There is a difference between an opinion and a rant. I really won't debate whether Vue is superior to React, I'm just stating why I prefer it.

jbreckmckye4• 9 years ago

I feel like JSX is the biggest failed promise of React. It's supposed to make the behavior of views transparent by building markup in plain JS. But what actually happens is you have to write noisy JavaScript that obfuscates your markup.

Just look at any component that dynamically generates CSS classes. Template strings with ternaries? Another dependency for generating nice CSS class strings? Give me a break.

JSX falters because JS is not terse enough. You end up with templates that have neither readable logic nor readable markup. And naturally, programmers being as lazy as they are, these templates become a holding bag for -every- concern.

TheCoelacanth• 9 years ago

It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading.

I don't get this complaint at all. Between map and ternary expressions, you can get both loops and conditionals in your markup, e.g.

    <div>
      {listOfThings.map(thing => thing.isX ?
        <X thing={thing} />
        <Y thing={thing} />
      )}
    </div>

pier2510• 9 years ago

And you think that's easier to read and write compared to any templating language of the last 15 years?

Btw you missed :

iammiles• 9 years ago

I'm with you on this. JSX is quite a bit easier for me to reason about than the Angular-like expressions of Vue. But I am glad that there are viable alternatives available for those who don't feel the same way.

breeny5923• 9 years ago

Not to mention that if a section of markup gets too big, you can break that down to it's own method that returns tiny snippets so you can have really simple methods that end up creating the more complex end result i.e.

_renderXOrY = (thing) => { return thing.isX ? <X thing={thing} /> : <Y thing={thing} /> }

//inside the render method <div> {listOfThings.map(thing => this._renderXOrY(thing))} </div>

I personally prefer this because when creating the top level of a component, I largely don't care about the individual elements of a list, but rather am structuring how that list will be contained etc.

And let's not discount then the value that JSX brings of being able to easily unit test that your conditional logic renders the correct output easily (Jest + Enzyme = easiest tests I've ever had to write, bar simple functional checks).

ksec• 9 years ago

What makes Marko better then all others in your opinion? Apart from speed which is the only thing I could gather on the Google.

And why are there no interest? Because it is from Ebay? I mean look at the reply and no one even want to touch on it.

pier2510• 9 years ago

Marko is faster and lighter. Also the syntax of single file components is more minimalistic than Vue, which is a good thing.

I'd say there is no interest because the single file components are quite new, and before that the project was focused on being a really fast templating engine.

https://github.com/marko-js/templating-benchmarks

Check this presentation about Marko, I found it illuminating.

https://www.youtube.com/watch?v=i6eZA8Y_GgA

ramses02• 9 years ago

I've been using marko for ~1yr now and don't work for eBay.

1) It's a templating language, not JS, not ternary operators, etc. Where this really makes sense is the following (probably valid marko). I _dare_ you to rewrite this simple search-results component in your FE framework or programming language of choice. Note how "state" is transferred in to a component

.../components/my-component/index.marko ``` <await( results from component.resultsPromise(state.search) )> <ul if( state.search && results.length > 0 )> <li for( r in results )>  <a href="${component.getLink(r)}" on-click('emitEvent_ResultClicked', r ) >${ r }</a> </li> </ul> <ul else> <li><i>no results</i></li> </ul> <await-placeholder>Loading...</await-placeholder> <await-timeout>Timed Out!</await-timeout> <await-error>Errored Out!</await-error> </await> ```

.../component/other-component/index.marko ``` <div> <my-component search="whatever user searches for" on-result-clicked('handleUserSelectedResult')/> </div> ```

2) It's like PHP (mostly the good parts) ... there's only one negative I currently have with marko and that's the deprecation of "<var />" or "<scope />", as with "really large templates" (already an anti-pattern), the lack of scope can cause variable shadowing.

3) you can break out into "just javascript" at any point ... `$ var xyz = 1 + 2 * component.functionAbc( 123 )` and then use ${ xyz } right after. I personally prefer having `scope...` in my arsenal so I don't accidentally re-use `var xyz` but it's really rare if you make small components and keep an eye on your refactoring.

4) It is _designed_ for both "virtual dom" + "HTML streaming" ... virtual dom is what helps diff trees efficiently (client side), but HTML streaming is the real genius. Given a relatively declarative template (which is what marko deals with), marko will actually take your "foo.marko" and literally compiles it into: "make_a_tree(...)" or "make_a_string(...)" which runs on client or server respectively.

Seriously.

``` $ mkdir foo && cd foo $ marko create xyz $ cd xyz $ npm start $ open http://127.0.0.1:8080/ ```

Follow along with the docs / tutorial and then humor me and run the following:

``` $ npm start $ curl -s http://127.0.0.1:8080 | wc -c 5388

$ NODE_ENV=production npm start $ curl -s http://127.0.0.1:8080 | wc -c 1678 ```

I've used angular 1.x, ember 1.x, a touch of react, and I'm most hopeful for marko, as I really see a way for an SPA to start up using the smallest-possible-html-bootstrap, marko to download after first paint, attach handlers, etc. and be "as active" but "as quickly as possible" ... harkening back to the "good old days" of PHP and JSP where the content rendered quickly ... mixed in with the "good days of today" where subsequent page renders don't just blank out the browser, but instead, efficiently load up only the changed portions (ie: the SPA / single page app / progressive experience).

It's easy to do a "progressive" experience requires a 1MB download of JS before first paint. It's actually really cool to be able to render a 100kb page in only 100kb of network traffic, but also to have all your handlers / regular JS working from the remaining 900kb ready to work automatically _enhancing_ your page, but not to have to make any tradeoffs or think about it in order to do it.

simplify• 9 years ago

We run marko in production. My favorite part about Marko is the automatic dependency management. If you already defined a `Modal` component, you can just use it in other components / pages by writing `<Modal />`. The JS files AND the CSS files will all get auto-bundled into your page.

Marko is also the only framework that supports server-side rendering streaming. This means that your user will start to see HTML even before the page has finished rendering. Afterwards, the page is bootstrapped and components run on the client side. It's very fast.

nikkwong• 9 years ago

The quality of ebay's website gives me a lot of hope for marko /s. Seriously though, if they're going to build this why not fix the UI on ebay itself? Is it just too large an application or are is an update just around the corner?

Also the scroll jank on markojs' homepage doesn't make me feel extremely bullish about the framework.

andrewstuart• 9 years ago

I like JSX.

stephenhuey• 9 years ago

Aurelia has a great router and many other things going for it as well.

moo3605• 9 years ago

First reason is we hate JSX.

I feel like this is often the reason people dislike React, and it mostly comes out of a misunderstanding of JSX and es6 syntax and interaction. Why do I say this? Because I've yet to hear an argument that came after a statement like above which was actually true in any way. Most arguments that come after actually expose the fact that the author of the statement simply doesn't understand the syntax usually because they've never really bothered to try to use it and instead are simply turned off by something new in their code.

It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading

This is quite simply false, it doesn't force you to do any of these things. A lot of people seem to think it does which again comes from a misunderstanding of the syntax. You're quite able to either embed your logic into the JSX or not, whichever you prefer. I most often see people lean toward the former unless the logic in question is extremely complex in which case it could be argued it's best being removed from the markup anyway. But JSX itself does not force you either way.

It's like writing shitty PHP code without templates

I simply don't see a viable comparison here at all.

It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Again, this is simply untrue. In fact I'd argue that if you're using lots of .binds you're doing it wrong. .binds inside your render function are actually bad practice due to the fact that they mean you're adding overhead of creating new bound functions as each .bind returns a brand new function every time your render tree executes. The overhead of such is probably negligible, however it's still inefficient and cumbersome and thus is bad practice.

As for Object.keys() - While I share your dislike of the overuse of this particular method, I'd love an example of where you think this is forced on you by JSX because for the life of me I can't think of one.

There is no official React router

This I completely agree with, it is annoying, and I too am not a fan of react-router. However it's so easy to create your own routing setup and/or plug and play other lightweight ones that I don't usually think of it as a particular plus/minus point when comparing to frameworks like Vue.

alexkoeh• 9 years ago

Our team had the same thoughts on react-router. I'd suggest checking out https://github.com/kriasoft/universal-router. It uses the HTML5 History Library (https://github.com/ReactTraining/history) for navigation.

phatbyte3• 9 years ago

It's like writing shitty PHP code without templates.

I don't think you or your team knows how React works or even PHP.

Another problem with React is that it only really solves one problem.

You and your team hate React for the wrong reasons. You just simply don't know what React is in the first place. React is not a framework, is more like a view framework, it was never designed to solve routing, models, problems.

chj2• 9 years ago

I checked React, didn't like JSX, then I find out about vue, and after an hour or two into its guide, I am completely hooked. Especially love the fact that you don't need a compiler, or a node installation. Although single file component looks very nice, I don't want to "bring in a whole jungle just to have a banana".

baxtr• 9 years ago

The single best argument for vue is that we should not support large internet monopolies. vue is so awesome even more so once you realize that it is basically driven by a single person

shams93• 9 years ago

I don't know why inferno isn't more popular, I use a lot of html5 apis so for what I'm working on inferno is more useful to me than react or Vue. I'm doing webaudio so react native doesn't help me. Also inferno doesn't require me to enter into a patent agreement with Facebook and yet I get all the benefits of react from using inferno. Now if I were needing to use native APIs then I might need react native but then you have to balance that need with the potential license issues

colordrops2• 9 years ago

I know this is about Vue vs React, but a lot of the things people are saying they like about Vue can be found in Google's Polymer. It's very simple to comprehend and you can make single file components. And it's based on W3C standard web components so you won't be building yourself into future obsolescence. With Polymer 2 components are now built using classes, so your code is clear and 100% native JS. Lastly, the goal of the Polymer team is to get rid of Polymer by advancing web standards, and with 2.0 you can see they are definitely following this approach as Polymer doesn't add much to web components other than ease of use functionality such as template binding and cross browser shims.

mStreamTeam• 9 years ago

I've used polymer and I wasn't impressed. I found it was much slower than Vue and the docs left a lot to be desired.

colordrops2• 9 years ago

What was slow about it? Depending on how you use template binding, it should be as fast as anything else.

Xeoncross• 9 years ago

I use material design. Angular and React have the best MD libs as of a month ago.

I also make mobile apps. Angular and React have the best native apps as of a month ago.

I use old devices. React and Vue are the most responsive.

Large companies use React on desktop and mobile.

React it is.

_nalply2• 9 years ago

I experimented a little bit with Vue. I was a little bit disappointed about two points:

1. I couldn't CSS style a Vue component. I find components very important and they should behave like HTML elements. It should be possible to write a <video> element in Vue if that element didn't exist.

2. I find the state management Vuex somewhat an afterthought. Some people say you will know when you need state management, but I think if the integration of state management is really seamless there is no need to avoid state management even for the most simple apps. So don't listen to these people and start with Vuex straight away, even if it takes a little bit more effort.

I'm sure that there are more points for an even better solution. However for the moment Vue seems to me the simplest, the most elegant and most intuitive framework. So I will use it for my future projects.

yunyu8• 9 years ago

One of the biggest selling points for single file components is styling (with optional scoping): https://vue-loader.vuejs.org/en/features/scoped-css.html

If you need to override child component styles from a parent (bad idea in 99.999% of cases), /deep/ would work.

_nalply2• 9 years ago

Vue components are second class citizens compared to HTML elements, because you don't style them, you pass them props.

This idea with stylable components is for a different framework, perhaps.

jaequery14• 9 years ago

what? vue does all that. i don't think the op tried vue at all, lol.

davidw• 9 years ago

Not knowing much about either one, I find 'scaling down' very appealing. I recently did some work with Angular 2, and found it very distasteful because of the big learning curve.

saganus• 9 years ago

Maybe a bit off-topic, but not so much IMO.

Everyone talks about react, angular and vue.js. How about Polymer?

What are your experiences with it, if any? I'm no expert in either technology, but Polymer seems much more lean, needs no build process as far as I know, and is quite flexible.

Why wouldn't it be an option to replace react/angular/vue? Any thoughts?

ergo1414• 9 years ago

It is an option to replace other frameworks - I've built an SPA with it, it was very clean and natural feeling to me.

Building Polymer components is very similar to building Angualar 1.5 `component()`s or react components (or actually any component system for that matter).

New elements are true DOM nodes which is quite an advantage in my opinion.

You can add redux/uniflow on top of that or some vdom lib like preact too if you need that - I wonder what will come out of `lit-html` that is supposed to be vdom alternative.

One interesting thing one should understand that applications view components that are not meant to reusable should NOT use Shadow DOM (just regular DOM)- this way you can use bootstrap or whatever else to provide "traditional" styling of your application.

BTW I think right now Polymer also requires a build process - because 2.0 is written in ES6 so that means building to support older browsers like IE10/11.

idibidiart• 9 years ago

I have to many points associated with this handle. I'd like a 100 or so shaved off

React is for CS-savvy programmers. Vue is for those who like to think of themselves as programmers.

kraf• 9 years ago

I prefer React. I do like a lot of the ideas in Vue.js, but when it comes down to it I prefer the lower abstraction level of React.

Where React wins for me:

- Higher order components - Stateless functional components - React 16, especially the scheduler

Also I really like building the virtual DOM directly (JSX) but that doesn't seem to be very popular reading the other comments.

mrtracy• 9 years ago

As someone who has been maintaining a growing React/Redux app for a while now, this one has kept me up at night.

The main arguments in favor of Vue.js revolve around the idea that it is easier for new developers to understand; that people can pick it up and immediately be productive, with React/Redux being much harder to understand. As someone who wants to onboard new developers onto my project, it makes me wonder if I need to look into a switch, if not for my current project then for the next one.

A lot of the commonly touted differences are either a wash, or are only benefits for very small applications with perhaps a single developer. These would be Templates vs. JSX (This is a wash, they're the same thing, but this maybe even favors JSX for large applications), running Vue.js without a build system (you will want a build system regardless for any production application), "Two-way data binding" (Fools gold, will cause horrors if you ever use watches, you will end up hoisting almost all of your data to Vuex anyway in a production application) and "Single-file components" (Really skeptical that this will make a difference in development vs. any other organizational strategy). I can expand on any of these, but they've already been discussed to death.

+ Where I think Vue.js is actually superior to React:

Vue.js is quite opinionated and clear on where to put both data and computed properties. That's basically it, but it's a huge difference.

React itself is very hand-wavy about where to put data and how to interact with it; it basically leaves the problem for someone else to solve. Even Redux, which is designed specifically to store application data, has a weird interface to connect your data to the React application and has no opinion on where to put computed properties. React-router suffers from this same problem as well; you basically end up looking for blog posts on Medium to figure out how to construct an actual SPA out of these components.

This is a gigantic failing of the React ecosystem, and I think this represents almost 100% of the perception (or perhaps even reality) that developers understand Vue.js better than React.

+ Where I think React/Redux is still better

The React ecosystem takes a lot of inspiration from functional programming; it prefers "immutability" and pure functions whenever possible, and I think this becomes increasingly valuable as your application grows; not just for enormous applications, but even for medium-sized applications.

Even if you're exercising maximum discipline with Vue by hoisting your state to Vuex, you've still got many opportunities to create difficult bugs based on the mutable state. Are you sure you're not referencing mutated state in one your actions? Does one of your components hold onto mutable state in order to do a custom transition or animation? If you're using watchers, you're really risking some dangerous bugs here. Now, I know you probably won't do something silly like this, but as your development team grows and you can't code review everything going in anymore; can you vouch for everyone on your team not to make a subtle mistake with a mutable reference?

React/Redux also enables a few very useful patterns that Vue/Vuex doesn't offer at all. For example, the famous optimistic application is nearly a first-class use case for Redux, but would be quite difficult to implement in Vue. This doesn't matter for small applications; it does matter for large applications. Will it matter for your medium application? The same thing about Isomorphic rendering; Redux was built with this squarely in mind. It won't matter for your small app; are you planning for your app to be small forever?

Finally, because it is all Javascript, I think React/Redux has a much better ecosystem of tooling. That includes both linters and transpilers; for example, writing Vue in typescript isn't especially natural, but it works great with React/Redux. When considering my own purposes, effectiveness with Typescript is one of React/Redux's greatest advantages.

In summary, I would still maintain that React/Redux is better for medium to large applications than Vue, due to its commitment to pure JS and the inspiration it takes from functional programming. However, I definitely see the appeal of Vue.js, and I wish that the React ecosystem would take a note on how to provide clear opinions for developers.

mshenfield2• 9 years ago

The conciliatory tone is refreshing - as a community it doesn't have to be a "Vue vs. React" death match. Both are reasonable approaches that incorporate some pretty dope technology in slightly different ways.

IgorPartola• 9 years ago

I happily used Angular 1 for a few things. When it became clear that Angular 2 was the party line, I looked at it and unfortunately found an overengineered framework chasing what React was.

I looked at React, but without a cohesive framework, that ecosystem is just a bit too much of a mess. A gazillion starter app templates that can't quite agree and always seem a little out of date with the fast moving components. JSX is just ugly. At least to me. I regularly use Django templates, so the clean leap to Handlebars-style templates feels very natural to me. Redux is straight up unapproachable to someone new to the concepts, but at the same time it feels like it simply reinvents events and event handlers.

Vue was a revelation. It is simple, cohesive and I feel productive.

bennyp101• 9 years ago

I'm currently investigating Vue to see how it compares to the current React code I have. So far I'm liking it.

The main things that I like so far;

* Single file components - I actually really like this, I find it much easier on my brain to have everything related to a component in the same file.

* The router and data modules - having the router and Vuex as "official" parts of the ecosystem (as opposed to in React where they are "adopted") means that everything just clicks.

* Styling - when I first started out with React, it was a pain to find a nice way to do CSS - do you use modules? Just have files that you import? Inline? Having it automatically scope the styling to the component if wanted, or using modules if thats your thing - is so much nicer than having to think about it. I just add <style lang="scss" scoped> and I don't have to worry.

The only downside I have at the moment, is having to learn the "v-" bindings (which is what put me off Angular when it first came out) but I think that it is something I can live with. Although you can use JSX and have a render method so I might try that and see how that flows for me.

erdle• 9 years ago

These are the threads that are often to the most frustrating to picking anything...

obilgic• 9 years ago

    In React, everything is just JavaScript. Not only are HTML structures expressed via JSX, the recent trends also tend to put CSS management inside JavaScript as well.

for me this is the deal breaker, just JS should be enough.

tomelders• 9 years ago

Ugh. Vue.js is just Angular 1.

conradfr3• 9 years ago

In a way VueJS is "React for those who liked Angular1".

I've done many Angular apps. I've done a bit of React (with Reflux & Browserify).

I tried moving to React/Redux/Webpack but it's not an easy task to grasp the whole thing. Webpack itself was close to make me throw the towel on side projects.

I tried VueJS because of a job interview and quite liked it and got productive really fast thanks to good documentation and my previous experience in angular & React.

Professionally I wouldn't mind any of those but for side projects it will be VueJS from now on.

As a side note I don't get why all the boilerplates always mix backend and frontend code and dependencies. If you're not interested in a node backend and learning it's overwhelming.

The worst thing is that boilerplates you find are always outdated (router, hot-reloading etc) and worst of all mingling server and client deps so if you're not interested in a node backend you have to

buchanaf• 9 years ago

I feel like a broken record, but definitely take a look at create-react-app if you haven't already. Its extremely well documented and takes care of managing the 20+ dev dependencies that are typically associated with a project.

tommyd2• 9 years ago

And likewise I feel like a broken record, but try MobX instead of Redux. Much quicker to get started.

conradfr3• 9 years ago

It's useful but doesn't take care of state management AFAIK which can be a big part.

phatbyte3• 9 years ago

If I was reading your post 3 months ago, I would completely agree with you. But learning React/Redux and Webpack is not that hard at all, just focus on one and move on to the next. WebPack is dead easy IMO, Redux is just an design concept, but it's easy to implement as well. I think sometimes developers over hype technology and make it sound incredibly hard, when in fact is just isn't.

conradfr3• 9 years ago

React itself is simple but having a whole project with React/Redux and a full fledged Webpack/Babel config managing dev and prod build is really not simple IMHO.

And, once you have all that working, staying up to date without bugs due to version mismatches can be a real pain.

sheeshkebab• 9 years ago

Vue feels like a framework written by AngularJs developers. It's not "better React", it's more like better angularjs.

Html templates are a major turn off for me there, and using JSX is not optimal.

taphangum• 9 years ago

If anyone is interested in more Vue talk and some back and forth, check out the VueJS subreddit here: https://www.reddit.com/r/vuejs. It's probably the most active VueJS community online.

coding123• 9 years ago

Actually my major complaint of React is the state of state. There seems to be no common knowledge about how to do this right. I just joined a team that has two React projects that development started about two months ago (I just joined like a week ago). There is a a large component that I am working on that is completely bound to Redux. There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it. On top of all that, the application is completely unable to handle 2 instances of any component they wrote. I am trying to re-write some of it to encapsulate the state in at the component level. It's pretty awful compared to the Angular (not AngularJS) app I recently rolled off of.

Edit : Also wanted to add, while I think a lot of people really don't like JSX, I actually do like it but I think someone could take that aspect and come up with a better state management system outside of redux and friends. I think something along the lines of Angular (not AngularJS) with JSX would be great.

mmcnl3• 9 years ago

There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it.

This sounds awful and seems like an anti-pattern. I don't think this anything to do with React (other than perhapps that React gives you the freedom to do things wrong). Your devs don't have a proper understanding how React (or Vue) works. Define state model, define view, modify/interact with state, let React modify view. That way you'll never need dirty hacks like fetching state from Redux by using the DOM ID.

blumomo2• 9 years ago

In this thread people are fighting about their _opinions_ why they use Vue.js or React. And why X is really better than Y.

In reality these programmers don't want to have the feeling they might have made the wrong choice when they used X instead of Y. The idea that they might have taken the poorer choice hurts so much that they need to defend their decision so heavily while in reality taking ReactJS or Vue.js is like ordering pizza or pasta. You usually don't want to have both at the same time. So you need to explain why pizza is better than pasta tonight. Only that you usually have to stick longer around with Vue.js or ReactJS once chosen. Enjoy your choice and solve real problems, but stop fighting about it, programmers. Pasta and pizza will always both win.

frogfuzion• 9 years ago

This should be the top comment. This sort of "debate" has happened since the dawn of programming and will continue to happen until AI programs for us.

The reality is it is all shite! Just get your job done.

tigershark10• 9 years ago

You can't compare react and vue with pizza and pasta. Pizza and pasta are two finished products, while react and vue are two different ways of building the same product. Your comparison doesn't make sense at all to me.

nartubio2• 9 years ago

Say you're about to cook pizza or pasta, you use flour and tomato for both. Comparison not 100% off IMO.

blumomo2• 9 years ago

If you imagine pizza and pasta as ways to get satisfied, then you can consider your final satisfaction as the finished products.

Whether you choose pizza or pasta depends on your personal taste. And maybe on your skillset, if you need to prepare the food. Both lead to mostly the same outcome – your satisfaction.

Whether you choose React JS or Vue.JS also depend on your personal taste and skills. Both lead to a finished product.

bluepnume• 9 years ago

For me, the best thing about jsx is the fact that it's so easy to create different implementations of `React.createElement` to solve different problems outside of the scope of React itself. Want a render function that uses jsx but returns a string, a DOM tree, or something entirely different? Totally possible! I didn't like jsx at first, but the fact that it's so decoupled from React itself counts extremely in its favor, in my view.

For example, for one of my libraries I wanted a really simple way to allow people to include custom templates. I started with string-based templates, but quickly realized that this was inflexible for any kind of event binding or later dom mutations. Achieving that was super easy with jsx -- I just implemented a custom jsx function which directly outputs DOM elements.

Step 1: implement a jsxDom function [^1] which takes (name, props, children) (e.g. https://github.com/krakenjs/xcomponent/blob/master/.babelrc#...)

Step 2: point babel to my jsxDom function (e.g. https://github.com/krakenjs/xcomponent/blob/master/src/lib/d...)

This even allowed some cool hacks like including iframes directly in the jsx, to sandbox sections of the page (since the library is geared towards creating components to be embedded on 3rd party sites):

  containerTemplate({ jsxDom }) {
    return (
      <iframe>
        <style>
          p {
            margin-top: 40px;
          }
        </style>

        <p>I can be sure the styles in this iframe won't affect the parent page</p>
      </iframe>
    )
  }

crisopolis• 9 years ago

I'm curious Vue.js has always had this comparison guide. Why re-post it now?

xxxmaster• 9 years ago

This part of the documentation is pretty unchanged for the last 6 months I think, how come it gained so much attention today? We've been using Vue instead of Angular 2 and we are pretty happy with our everyday work. So +1 for the VueJS team.

tycho01• 9 years ago

Dunno if it's just me, but I read these Vue articles and all I see is a bunch of hypocrites with an identity crisis, criticizing React for fragmentation, Angular for having 'one Right Way'. So they're better than React for offering one Right Way, then they're better than Angular for offering fragmentation? I mean, jeez, pick one stance and stick with it.

dcsan• 9 years ago

it seems odd that vuex is part of core but there isn't a default way to do get/post requests. http://jrmeyer.github.io/tutorial/2016/02/01/TensorFlow-Tuto...

Vue.js vs. React

Related Stories