[searchhn]

> There are a few more frameworks I would have loved to try, including Polymer and Vue.js. There just wasn't enough time to do a deep dive with all of them.

I hope he gives Vuejs a try. As a javascript beginner, who tried Angular, Angular2, A bit of React and VueJS, I just loved the flexibility and approach of VueJS. I was instantly productive thanks to the amazing documentation and vue-cli that just worked out of the box setting up my project.

PS: Never really spent much time on React as I tried it after VueJS and did not feel like proceeding much further with my tests.

[mr_luc]

Agreed.

I've used Angular 2, React+Redux, and now Vuejs on different projects (and on personal projects, stuff like om, elm, etc).

Vuejs feels like they cheated somehow.

For people in Redux-land: they took the reactivity of MobX and gave it Redux' level of debuggability. One important way, I think, is that Vuex formalizes the 'actions-dispatching-actions' use case of Redux middlewares (which redux says 'is not a part of the architecture, but is important enough to be in core'); in Vuex, all action creators can dispatch other actions, and it throws an error in dev mode if you try to mutate state in a non-safe way.

I've used redux for a couple of years, and felt the pain of juggling different libraries (especially the struggles to manage router state) -- Vue is a delightful experience. Its chrome plugin is ridiculously useful; its documentation always seems clear and helpful; things work together.

I can't wait to see what Alibaba does with Weex -- essentially React Native for Vuejs. I did a test spike with it a month ago, and am trying to keeping tabs on it ...

[mamp]

For our team React + Redux + Redux Saga + TypeScript has been a great way to develop our complex SPAs. We do use MobX selectively (dynamic forms), but the big benefits of the combination is the ability for our team to work productively without stomping on each other. Big factors are the explicit layout for domain models in the store, clear points for mutation, testable orchestrations via sagas, JSON schema validation and type generation.

The downside is the ceremony around it all but everything is so predictable and reliable it's a huge relief. Velocity is now good. We didn't choose this combination first off (via GraphQL, MobX, thunks), but the team decided that this combination was the best way for us to solve the issues we had encounter in the past.

[mr_luc]

I'm actually using a similar stack to you today -- redux + sagas, flow, json-schema.

However, in my experience, Vuex also has explicit stores and clear points for mutation -- Vuex stores are really clear and composable. It's also about 10 lines to get redux-sagas to working with Vuex.

If it weren't for react-native, I'd be pushing to use Vue + Vuex whenever possible. So I'm watching Weex with bated breath :) -- it's very cool that it's recently become an Apache Foundation project!

[enraged_camel]

I really like Vue as well. However, one big problem I found with it is that the community is tiny compared to React. Whereas with React people would respond to my questions on SO within minutes, with Vue it can take days, and that is if I get a response. I'd consider myself intermediate-level so I can usually work my way around whatever problem I'm having, but I would hesitate to recommend Vue to a beginner.

[hanley]

As a Vue beginner, I had the best luck asking questions on https://gitter.im/vuejs/vue and often got responses in minutes.

[jondubois]

I wish the author had tried Polymer because it's the most underrated one. I just love the way Polymer components declare/consume dependencies (as tags in the component file) and connect all sub-components in the template markup via attributes - It makes data binding relationships between components and their children very clear.

Polymer is basically an inverted version of React (and it achieves a similar outcome). In React, template markup is nested inside the code. In Polymer, code is nested inside the template markup.

I really like React but I wouldn't use it for a personal project knowing that Polymer exists. I hope Polymer will gain more traction because I would love to be able to use it professionally.

[H1Supreme]

I've used both Polymer and Vue for a few projects, and Vue's single file component method, coupled with WebPack, is almost identical to writing an app with Polymer.

Except that Vue doesn't ship with all the Polyfill baggage that Polymer does. Polymer has came a long way, but it still feels slow on anything but Chrome.

Once the Web Component spec is finalized, and built into browsers, I think Polymer will be a great choice. Today though, I gotta give the nod to Vue.

[ergo14]

Polymer traction is looking good, over 7k people on slack channel, 750 elements on webcomponents.org. And they got first day on google IO this year, youtube main site is being rewritten in it, ING, IBM, GE are using it, so it gets quite a bit of love from enterprise too.

[jondubois]

I feel more comfortable using technologies that have had moderate, steady growth in popularity over many years like Polymer than technologies which experienced sudden, explosive growth like Angular 1 (we know how that turned out).

Early explosive growth means that the technology is hype-driven; adopters haven't given themselves the time to critically and objectively evaluate the solution - It's not so different from economic bubbles. People get excited and buy into it without thinking and then at some point in the future when they realise that it won't live up to their expectations they all start selling at the same time.

[Pigo]

I remember looking at Polymer before I discovered Angular Material, and I really wanted to give it a go. I guess I played it safe by sticking with the thing I already knew, and I liked the Material docs. But I'd still like to try Polymer.

My biggest hangup with trying new platforms is finding a good UI framework to go with it, I like handing off styling to people who know what their doing.

[pluma]

In React there are no templates, just component trees.

[renesd]

Everything in react is done in the template language.

This react below is not JavaScript... it's a reverse template language with a mix of not-quite-html and not-quite-JavaScript. jQuery style code is nicer than that! I hate the enterprise boilerplate in react projects. No wonder they're all failing!

  class Square extends React.Component {
    constructor() {
      super();
      this.state = {
        value: null,
      };
    }
    render() {
      return (
        <button className="square" onClick={() => this.setState({value: 'X'})}>
          {this.state.value}
        </button>
      );
    }
  }

It's like facebook is a php shop or something... Oh wait. Not for me thanks.

[johnfn]

If you don't like the "boilerplate" of a single class definition, use a functional component, which is just a function that returns JSX, that is also a component. It could literally not be more straightforward.

Or could you not hear me over the sound of that axe you're grinding? :)

[mtzaldo]

*stateless components

[bromuro]

JSX is not a template language, it is just syntax sugar: see it as a different way to write javascript: https://facebook.github.io/react/docs/jsx-in-depth.html you can't say the same about templates.

[renesd]

It's not JavaScript, and it mixes in almost-html... but it's not a template language?

Wrong. It's a template language, even if Facebook tells you otherwise.

[zodiac]

It really isn't a template language as the term is commonly used. If you feel so strongly about the weird syntax you can write equivalent code in javascript syntax instead.

  return React.createElement(
    button,
    { className: "square", onClick: () => this.setState({value: 'X'}) },
    this.state.value
  );

If you think your code is written in a template language, then the code I just wrote must also be written in a template language (with different syntax).

[brlewis]

Template languages create strings. JSX creates hyperscript.

JSX by its nature statically checks for tag balance, etc. The non-JavaScript part of its syntax has actual semantics. In a template language the non-Turing-complete part of the syntax is just strings.

JSX is a perfectly good notation for describing how data maps to its presentation in a DOM tree.

[bromuro]

if you want to build your UI with React you have to think about JSX as an easier way to write javascript. you can see it as a template language but it won't help you to code :)

[ergo14]

I like both Vue and Polymer. I've also tried react and while I get it works, I don't really like it.

So far Polymer is my go to solution, but Vue is close second. I like the fact that everything (web components) is native to browser platform.

[renesd]

The vue looks good.

Yeah, Vue.js is for people who make things. React is for enterprises who don't seem to mind being 3 months late shipping basic stuff.

In react everything is done in the template language. It's a sort of reverse template language, that doesn't even really use proper html for things. So weird.

Vue is just all together, and is based on web standards. Not a weird thing by facebook enterprise developers who think that documents are dead and everything should be a slow loading monster single page thingo. Vue does components properly.

React components aren't. They tell you to move state from the child to the parents. That's not a component, and probably one of the biggest reasons many of the react projects are giant messes.

React is sort of like the old enterprise thing that doesn't solve any of the real issues with Angular style frameworks.

React does have a pretty good marketing budget though. Lots of evangelists paid to talk it up. Plus lots of developers who have invested so much time learning useless non-standard framework stuff. Also, there's plenty of freelance gigs cleaning up failed messy react projects.

[bshimmin]

Ah, so jQuery spaghetti has now been replaced by React messes. I can also contribute that I've seen some Angular abominations and - a year or two back - some baleful Backbone projects. It's almost like whatever the framework or the library you give developers to use, regardless of its quality or scope, they're capable of making a mess with it! Hard to imagine, I know.

[boubiyeah]

And likewise, you can/could do some excellent coding with 0 framework :D

[dentemple]

My spaghetti requires no extra seasoning

[renesd]

Except Vue projects seem to be succeeding. This is good for clients, but bad for freelancers getting paid lots to clean up messes.

The good components, and the docs are the biggest reasons. But also it's a very well thought through thing based on web specs, using html technology. People can get useful work done almost right away, and what they made is self contained by default, limiting their damage. It also works for the document case, AND the single page app case. Want to make a landing page that converts well? Vue has your back. Want to use that one jQuery plugin, because it's awesome... Vue can do that easily - it plays nice with others.

React should copy it more, and copy web standards more.

[trylist]

Speaking of evangelists...

[renesd]

I'm happily cleaning up react messes :) As my dads plumber friend used to say... "There's money in shit!".

Fair cop. Not sure why I'm participating in a JavaScript framework internet discussion. I wish people would concentrate on standards, and apps.

[Bahamut]

I personally have to refrain from commenting a lot of times - the arguments that happen tend to be the equivalent of video game console flame wars.

[HighlandSpring]

What component library do you recommend for Vue?

[zodiac]

> React components aren't. They tell you to move state from the child to the parents.

You don't have to do that if you don't want to - I don't in the react I write. Is there anything special about vue components which would allow you to keep state in child components in vue but force you to move the state to parent components in react?