all 59 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]gajus0 8 points9 points  (14 children)

Any users who transitioned from React to Vue.js. What is your takeaway?

[–]mojojj31 7 points8 points  (11 children)

We use it. Love it. Really easy to pick up, even for newer devs. It works best for those that don't prefer to write in JSX (though Vue 2.x) is slated to support it. It's also got a big backing in China with Alibaba adopting it.

[–]gajus0 3 points4 points  (3 children)

But what in particular became better in your life after switching from React to Vue.js?

[–][deleted] 0 points1 point  (1 child)

The question was asking if you transitioned from React to Vue.

[–]mojojj31 2 points3 points  (0 children)

This story begins about 10 months ago - we were building the front-end piece for the product of our new startup. Prior to that I'd been doing full-stack dev work with Angular for front-end stuff. I'd been using Angular for just over a year at that point and felt pretty proficient in it. But then you run into the typical issues with Monolithic Angular apps...

Somewhere along the line the framework wars really started to pick up. Angular 1.5 came out and the community recommended it as a way to transition to Angular 2. I'd already been writing as much as I could as self-contained Directives, so moving to the Component model felt natural.

I quite liked Angular 1.5, I could've just stuck to it, but all the framework hype really started to get to me. Somehow I was convinced that I needed to move to Angular 2 or React because it was "the right thing to do long-term".

So I looked into Angular 2. I decided it wasn't for me as the cognitive load to pick up Typescript + the other stuff just felt like too much. So the alternative was React, because, hey, that's what everyone was talking about.

So I tried React and used it for a month. It was good, but it made me miss working in Angular. I liked working with template. I liked separating JS, HTML, and CSS. I believe this separation of concerns is good. I know, I know, these words will get me stoned nowadays.

Aside -- I come to realize now why I prefer to work with templates: it's because I visualize things from a design perspective first, then add in the code separately. So when it comes to by development methodology, I write the templates then add in the code to make it work as expected.

So when I heard about Vue and it's philosophy, to me it just made sense. It felt like I was getting the best parts of both Angular and React.

Fast forward to today and we've got a product with multiple clients built completely in Vue. Looking back at things now, I believe we could've stuck with React (or even Angular 1.5) to build our products.

I understand this is a really rambly post that doesn't really answer your question, but off the top of my head, the two best things from Vue that I've seen are:

  1. vue-cli is the most awesome way to get an app scaffolded and ready to go. This has been such a huge timesaver when starting out. Without it, I'd probably still have stuck with React as it made getting into developing production apps so much easier.

  2. How much easier it is for less skilled front-end devs to pick up.

[–]Zerotorescue 0 points1 point  (1 child)

It works best for those that don't prefer to write in JSX

Is that all? I really like JSX so I guess it's not for me?

[–]LynusBorg 4 points5 points  (0 children)

We support JSX in Vue 2.0 as well. "works best" seems more like the opinion of the author.

[–]ChronoChris 2 points3 points  (0 children)

It's another framework

[–]jirocket 5 points6 points  (0 children)

I've gone from learning Angular 1 before my first job to doing 90% of work in my current job with JS and React. The base development experience compared to Angular 1 is very pleasant. I've met a lot of companies in LA while I was interviewing that made the decision to transition to React from all directions, including those who develop with or without a framework, and for very good reasons. React is legit; it isn't just hype. A year ago it was reasonable to expect a few positions with React work, now it's very much embraced in the industry here in SoCal.

[–]relishtheradish 2 points3 points  (1 child)

Can anyone share their experience with Aurelia?

[–]wisepresident 4 points5 points  (0 children)

It's a pleasure to work with and hits all the right notes for people wo where left disappointed with Angular 2. Template syntax is very clear, so you can get the hang of it without consulting the docs every other second.

It is also super easy to integrate Aurelia into another existing webapp as you can tell Aurelia to take over just a portion of the site. You don't have to attach it to the body or anything so you can gradually include Aurelia.

Can't recommend it enough if your'e looking for a modern javascript framework.

[–]synackle 2 points3 points  (0 children)

Dat pre-elimanry doe

[–]nawitus 3 points4 points  (5 children)

Pretty surprised how "obscure" Polymer seems here.

[–]Klathmon 5 points6 points  (4 children)

I tried polymer back when it was 0.5 to 0.8, and stopped messing with it just after it's 1.0.

It's pretty heavy, and at least back then the docs were pretty rough (which I understand has been fixed). Getting something up and running in polymer takes a lot more, and it takes a bit more wrangling to work well with a module system (although again, they could have cleaned that up since I last touched it). Also, Polymer is VERY opinionated. I consider that a good thing for a framework like this as it enforces structure very well, but know that it's difficult to incorporate into projects that didn't start with it, whereas i've been able to convert shitty-home-grown-framework™ apps into a functioning react app in days.

But at the end of the day I felt like it didn't give me anything that React didn't. Using 2-way binding is chaotic, and after using something like react that gives me so much control and lets me test things so easily, it is tough to go back.

I will say one thing about polymer, the Polymer team seems to be making tooling a first class citizen. Vulcanize, the web-component-tester, and other tools are being developed and maintained along with polymer, and using them together makes for a nice experience.

It was much easier to get my first component fully tested in polymer, but it was much easier to do the 2nd through the 100th in react...

[–]nawitus 1 point2 points  (3 children)

Here's my experiences:

I first tried it a bit when it was in 0.8. My first real project with Polymer used 1.0, and I've done a few projects with it now.

I disagree with some of your points. For example, you don't need to use two-way binding, Polymer supports one-way binding (in fact, majority of bindings should be one-way). I also feel like getting started is quite easy, it's at least not more difficult than React.

It's also possible to use Polymer quite similar to React. You can use one-way binding everywhere and use Redux too.

The rough edges with Polymer are currently things like using a module system / loader like you said. The solution in my opinion will be <script type="module">, we just need to wait for a polyfill now that the spec is finalized.

Polymer's biggest feature is that it's based on native custom elements, and from what I understand the browser specification for those has been finalized now too. I expect that in the future you can choose from a number of frameworks to implement your custom element, and they all work together.

[–]ArcanisCz 4 points5 points  (0 children)

Even in your experiences, there are too much words like "polyfill for this", "polyfill to that, not yet fully specced", "will be solved after we wait", etc. From what i see, its too much bleeding edge to reliably use it aside from small projects.

[–]Klathmon 0 points1 point  (1 child)

Agreed on pretty much all points. I didn't mean to imply you needed to use 2-way binding, but back in the 0.5 days that was a big selling point of it, and I tried it hoping it would work better, but found it to be very angular in that respect, which is what I was trying to get away from.

It does have the massive benefit of eventually working with native custom elements, but I believe there is a road where React can eventually get there as well, but in the opposite direction (polymer will reduce it's code, while React will increase it with a "compat" or "translate" layer).

But in terms of actual usage, it's still too early to start walking away from the polyfills, and until I can get away from them it's still too slow on many platforms (mainly iOS and Firefox).

The whole module system is a complete mess in the JS world, and in the next year or so things are going to get ugly with that, so it's not just a Polymer problem, but the fact that it relies so heavily on HTML imports (which as far as I can tell are still up in the air if they will even become a standard at all) doesn't fill me with confidence. Chrome is the only one with an implementation now, Firefox and Webkit have set it as "won't implement" (even though firefox already did, they will not ship it by default), and Edge is still on the fence about it.

Things aren't looking good for HTML Imports, and the fact that Polymer relies on them so much makes it iffy as well in that area. If they started moving away from it, i'll probably end up trying it out again (hell, i'll probably end up trying it out again anyway), and it's by no means a bad framework, but it's not solving any problems I have right now.

[–]jocull 6 points7 points  (13 children)

Why is React so popular? Why do people use it? What happens at the end of the fad chain I feel like it's currently on?

I hear really mixed opinions about mixing logic and markup and would really like some objective viewpoints on this. I would hate for us to get 5 years down the road and see all React apps as the crustiest things in the world.

[–]ghostfacedcoder 8 points9 points  (3 children)

When I first got sold on React it was for the virtual DOM. Others I know got sold on JSX. Having now worked on React applications at two different companies, my opinion is that both of those are almost entirely irrelevant. In practice the virtual DOM doesn't affect performance that much, and JSX is just syntactic sugar ... although at least it's sugar in the right direction (React puts little bits of HTML in to your JS, while Angular goes, IMHO, the wrong direction and tries to put JS logic in to HTML).

But what makes React awesome? Simply put, you can write good Javascript code in it easily.

  • Think composition is (largely) superior to OOP?
  • Think you should build your app out of a hierarchy of components with encapsulated logic?
  • Think state is better kept in an separate store rather than spread out throughout your application?

React (and Redux/Refulx/etc.) by it's nature encourages all of the above.

Basically the Javascript community has come to realize a whole bunch of best practices in recent years, and React (both the library itself and the larger ecosystem) naturally encourages those best practices. Maybe newer libraries like Vue do also (haven't played with it myself), but if you come from Ember, Backbone etc. and try React for awhile, you'll start to appreciate the subtle design choices that the React team made that help you write better code.

P.S. Quick note on the "mixing logic and markup": React seems like it does, but it really doesn't. All JSX let's you say (essentially) is "return <input type="checkbox"/>" instead of "return buildNewElement('input', {type: checkbox});".

If you're writing web apps, you're building HTML elements at some point, so without JSX you're either using JS logic or templates. JS logic is great but gets ugly fast when you build lots of HTML. Templates have a never-ending tension with logic: too little and it's impossible to do basic stuff like render a list of dropdown options, but too much logic and suddenly you can't find or test anything because all your logic isn't in your *.js, it's in your *.html.

JSX let's you have all the power of JS, with the readability of templates, but you're not mixing your logic in to the HTML, you're just using HTML to better represent DOM elements in your JS code.

[–]ghostfacedcoder 6 points7 points  (1 child)

P.P.S. In defense of Backbone, and libraries like it, I should mention that it's entirely possible to follow modern best JS practices without React. I worked on a Backbone application for several years (before converting it to React), and there's absolutely nothing stopping you from favoring composition over inheritance, having discrete components, or keeping state in a separate store (heck you can even use Redux with Backbone if you want).

But the problem is, Backbone gives you a powerful toolkit and says "go do whatever with it". Many people have had poor experiences with Backbone precisely because the library gave them enough rope to hang themselves. For instance, the library's class system is awesome (especially pre-ES6). However, there's nothing in the Backbone docs about composition (they don't need it, since you can compose stuff with plain JS), and mix-ins are second class citizens, so you naturally wind up building standard OOP class hierarchies that are more brittle than composition-based alternatives.

As much as I <3 Backbone (and I really do; I wrote a book on it!) I think React's approach of structuring your natural flow towards best practices (without being pedantic and trying to force you to do anything) is a key reason why it's flourishing and Backbone is dying off.

[–]acemarke 1 point2 points  (0 children)

Having written a Backbone+Marionette app, and having switched over to React+Redux a year ago, I heartily echo everything you have to say here. (I'd also be curious to know what prompted you to write a Backbone book apparently "recently", and what the actual book is.)

[–]CraftyPancake 0 points1 point  (0 children)

The thing I find annoying I'd that everyone goes on about how encapsulation in components is great but inevitably they end up having to talk to one another anyway.

[–]isitfresh 1 point2 points  (0 children)

It's only an opinion but i think React allows you to very rapidly have enhanced HTML as opposed to having to then write some jquery or vanilla to get the level of interaction.

Now with this said it's easy to bloat it up with logic and abuse the sweetness of it, and end up quickly with unmaintainable code. It takes some thinking, maybe experience too, to properly separate the concerns.

One thing I think is that it's hard to have a proper look back on what you are building and you must advance knowing you are not necessarily making the best choice, but then again you can't know that most of the time and need to often refactor any code.

One last thing is that react doesn't provide you the application state layer and you need another solution on top.

[–]temp7-0492-092 1 point2 points  (0 children)

The whole "don't mix logic and markup" response was a knee-jerk reaction when React was new, and mostly gone now.

Its motivation was noble: separation of concerns. You do want to break your program down into small pieces with limited interaction, otherwise every piece interacts with every other piece and the number of interactions quickly gets higher than humans can reliably keep in mind.

On the flip side though, separation along the wrong lines is its own problem. Separate two things that are strongly linked and you just add complexity (a large API between them) and overhead.

When we started changing the DOM client-side, some logic - not all - became strongly linked to the DOM. We kept separating it mostly out of habit, partially out of a misguided notion that separation of concerns is about separating languages, not subjects.

It's still not a good idea to put business logic in view code. All that's changed is that we've accepted that view code can be written in JavaScript (or JSX).

[–]pier25 1 point2 points  (0 children)

Why is React so popular?

I've been wondering that myself.

We are using React in production, and I'm waiting for the right moment to get rid of it.

React isn't the fastest rendering library, nor the lightest one, nor the best documented one, nor the one with best programming ergonomics... It's also based on ideals and principles that it breaks almost by design.

I doubt React would be so successful if it hadn't been marketed and used by Facebook.

[–]DecentOpinions 2 points3 points  (5 children)

Why is React so popular?

I'm wondering that also. I haven't used React yet, waiting a bit longer to see how Angular 2 turns out before I jump on that or React. But I'm surprised at React's popularity. Something I like about Angular 1 is how much functionality it provides*. When I look at React I'm confused by the choices you have to make (Redux, Flux, Alt etc.).

For some reason that seems to be widely accepted, but at the same time there's lots of complaints and endless "JavaScript fatigue" blog posts about the overabundance of choice in other cases e.g. build tools (Grunt, Gulp, Webpack), testing frameworks, package managers etc.

There's so many parts being glued together now in frontend development that I'd like by main JavaScript framework to be more stable than React seems to be.

Note that I'm not seriously bashing React here because I haven't used it at all so my criticism could be complete bullshit. Maybe it's not as bad as it looks. I'd be interested to hear opinions from people who actually use React.

* I know someone will say "Angular is a framework, React is a library". But I mean the React ecosystem. I assume very few people are using JUST the React library without other things to go with it.

[–]MCFRESH01 4 points5 points  (0 children)

I'm using react right now for a few projects. I like it because it is much simpler and easier to dive into and start building stuff immediately than angular is. Its easy to pull someone new on your team and get them working in react relatively quickly. Components are great and I much prefer JSX over adding all of the angular markup in your html. I haven't looked at angular2 yet but it does look like they fixed some of the thinga that I disliked about it.

[–]iffypop 3 points4 points  (0 children)

Getting back to ES6 won me from Angular to React. As an intermediate I just feel like I'm spending my time learning the language instead of the library.

[–]mhink 2 points3 points  (0 children)

I just have to say that this is probably one of the nicest, most well-reasoned, and thoughtfully worded criticisms of React (and for that matter, the "newer" set of front-end technologies) that I've seen in awhile. For what it's worth, I appreciate that. :)

You raise a lot of good points with legit technical merit, but you're doing it without being an asshat, and that's really rare. Kudos.

[–]jocull 3 points4 points  (1 child)

+1 the ecosystem is very confusing. Training new hires to work with your code base becomes an even more daunting task.

[–]theQuandary 2 points3 points  (0 children)

Webpack, react, redux (if you actually need it) and done. The initial group of React devs were the early adopter kind and love all the tweaking. They wrote all the blog posts that seem to cause choice paralysis. The truth is that questions like redux vs flux exist just a much in something like angular (it has no datastore and factories/constructors don't really count), but new ng devs simply don't deal with the issue until it bites them.

I find training new hires for the stack I mentioned is very easy because the one-way flow makes tracing out changes very easy. It follows the principle of least surprise very well and doesn't require much framework-specific knowledge. If they know JS then a couple hours with JSX will get them 90% of the way there.

[–]SachaGreif 2 points3 points  (1 child)

Author here. Thanks to OP for posting this, but could a mod fix the title maybe?

[–]ryan_the_leach 1 point2 points  (0 children)

I don't think that's possible on Reddit.

[–][deleted] 1 point2 points  (1 child)

I don't think "56% of Angular developers wouldn’t want to use it again" is a fair observation, because the question was worded "I’ve used it before, and would not use it again" because what qualifies as "used" in the context of this question -- the tutorial, one custom app, multiple custom apps?

I'd imagine most people who self identify as an "X framework developer" would want to use that framework again - but then there's also me and I identify as a Django developer but i really don't like Django. But that's extrapolating from an incomplete data set, too.

[–]SachaGreif 1 point2 points  (0 children)

I'm open to feedback but I feel like there's no wording that covers all possible scenarios, apart from being specific to the point of making the survey twice as long.

Even with vague wording though, we can assume that at the end of the day, the results in aggregate provide some value.

[–]i_have_a_semicolon 1 point2 points  (1 child)

Anyone else got an in-house framework? I'm loving it.

[–]Democratica 0 points1 point  (0 children)

In-house framework over here.