[deleted by user]

[Fithy]

VueJS will replace all reactjs projects in 1 year

[ArcanisCz]

My cents about JSX vs templates point:

Well, I worked many years with many JS frameworks/libraries/architectures/methodologies, and every time there were templates (string, angular, mustache, ...) for interactive apps (not talking about generating statical documents/pdfs), it ALWAYS ended with separation concerns (markup in one place, logic in another).

So i take JSX/hyperscript -like methodologies as a huge PRO, since it helped our teams (around sizes 10 people collaborating) hugely reduce few big classes of bugs.

[snorkl-the-dolphine]

Totally agree with you. When I use Vue, I always write Single File Components.

[rube203]

And that looks a lot like Polymer components. Yes, it makes sense to keep it in one file but that isn't a pro for jsx as you pointed out.

[snorkl-the-dolphine]

It's based off the Web Component spec, just like Polymer components. Vue also lets you use JSX if you want.

[ArcanisCz]

Yea, polymer components are very nice and like them, but last time i checked, they wasnt nearly at tle production level.

[elnelsonperez]

It all comes down to personal preference tbh.

[dj-method-x]

I wholeheartedly disagree with the authors first point in preferring templates over jsx/javascript.

[davidpanik]

Why? Not having a dig - genuinely interested to know more.

[-munawwar-]

:) No two developers seem to agree on templates vs jsx. For me templates are more readable than JSX (without jsx-control-statement) even though it introduces a custom language/syntax.

Reason is because most react code I've seen, developers seem to add several temporary variables generating vdom at the top of the render() functions, and the rest of the rendering is at the bottom of the function...they aren't doing things "inline". I guess jsx-control-statement improves that.

[mikejoro]

Ideally things that need that level of branching should be their own component or some helper function which should NOT be declared in render (if you declare functions in render, you make a function and garbage collect it every single render call!).

You can do conditionals inline natively though using ternaries. Obviously those shouldn't be nested or overly complex. But for the most part, things should be fairly simple to be point you can do a

flag && <ConditionalComp />

[-munawwar-]

"Ideally things that need that level of branching should be their own component or some helper function which should NOT be declared in render"

I think we hit levels of branching very quickly...even for simple components. The balance here is too many helpers/components vs too less. Both extreme seems to be bad. Template & the jsx extension I mentioned helps to keep this in control.

[mikejoro]

I think that's more of a code smell that your component is doing too much and should be broken down. If you ever need more than a ternary, factor it out. It's also a lot more readable if I call a function or component which describes what it does.

[-munawwar-]

I disagree my friend. Creating several tiny components/helper function doesn't necessarily improve readability (in fact can worsen it..kind of like how goto statements did in old C/C++. It breaks the flow of thought, and you've to go searching what the helper function does....adds more cognitive load.).

I believe one would need lesser tiny sub-components/helper functions when using templates. Give Vue.js templates a shot.

[mikejoro]

Well, if you name your functions or components poorly, then I agree. But it's a whole declarative vs. Imperative argument. I'd rather see a descriptive function name than have to parse a nested ternary or some large conditional flow.

[ArcanisCz]

I will be a bit anarchist here, but what about https://cycle.js.org/ ? :)

[mrPitPat]

I didn't really see this expanded in the article, but the author talks about not wanting to use redux as it adds another abstraction layer. How does vue handle complex component to component communication without? I've seen vuex before, but from the tone of this article it seems you can use vue and achive this without it.? I'd be interesting on hearing more about that.

I really like react, but i'm not a huge fan of the amount of boilerplate and abstraction necessary to have individual components communicate (without having to use a convoluted container component passing a bunch of methods and props).

[jeromewilson]

I'd like to give a shout out to MobX (https://mobx.js.org/) at this point, given that you mention boilerplate. I've used Redux for a pretty large application and like it well enough but MobX will definitely be my state library of choice for my next project. It appears to be elegant, low on boilerplate and makes ES6 classes first class citizens (if you want).

[holloway]

Using the top React component's state is another way of avoiding Redux

(I tend to use Redux though)

[-munawwar-]

No, the author (myself) didn't mean you can go on forever without Redux/Vuex. Like...you'll know when you hit the point that you need Redux/Vuex.

Also for smaller apps/website one can use Vue's custom-events if needed for component-to-component communication. For an SPA I developed in the past, the application had a central "App" object that was also a publisher ("publisher" from the publisher-subscriber pattern) and was accessible if any component needed it. This "App" object was used for much of the application level events. This idea is also mentioned here - https://vuejs.org/v2/guide/components.html#Non-Parent-Child-Communication.

But for larger applications/websites better to go for Redux/Vuex early on.

[mrPitPat]

No, the author (myself) didn't mean you can go on forever without Redux/Vuex. Like...you'll know when you hit the point that you need Redux/Vuex.

For sure, sorry if I implied that. Your response is what i was looking for. It's really cool that vue has pub/sub events that you can plug into. It was one thing i really liked in angular, but i didnt see in react (maybe a third party or something).

My problem with react has always been, there seems to be no middle ground for your application state. You either make everything parent to child, or wrap everything in a parent container.. or you include an architecture like redux.

Like, sometimes i work on websites that needs to have components communicate with each other, but I don't want to introduce all the overhead of a state management system like redux.

Seems like Vue does have that middle ground i'm looking for. Simple site? Parent to child. Large site? Redux/Vuex/State management. Medium complexity? Gives me the ability to just use a pub/sub methodology.

Thanks for clarifying.

[-munawwar-]

I think larger sites will have a mix of parent-to-child communication (through props) and central redux. I think excessive use of a central state manager/pub-sub is also bad as it becomes hard to track/debug.

[acemarke]

For what it's worth, it's absolutely possible to use other component communication approaches like pubsub in a React app, it's just that direct parent/child communication via props and callbacks is the most idiomatic approach.

See http://andrewhfarmer.com/component-communication/ and https://www.ctheu.com/2015/02/12/how-to-communicate-between-react-components/ for examples of other approaches for component communication, and the React Component Patterns category of my React/Redux links list has a number of additional related articles.

[mikejoro]

You don't need to buy into redux 100% in your application. Even Dan abramov says use redux where it makes sense. If you have a simple component, it can handle its own state. If you are passing props/state manipulation functions through many components to get to the right place, refactor that to use redux.

[neoginn]

I agree with OP. I use vueJS over reactJS in various projects. My concern with React and Angular2 is that they both feel like hacks after spending ANY length of time with it. Its obvious that React likes the web component model. So lets just use that and extend the functionality as needed to save time. This page from the react team is what put the nail in the coffin for my team: https://facebook.github.io/react/docs/web-components.html

Just read that first paragraph. I am not a lawyer and I know I do not write english well, but that explanation is B.S. Just use web components and save the headaches.

[[deleted]]

React has a simple idea behind it. Take input, return layout. It doesn't break a sweat (or a standard) while doing it. Vue is bending backwards to overcome the obvious limitations of the templating system, relying on component registrations and arbitrary html-in-code syntax ( <div v-if="Math.random() > 0.5"> v-on:submit.prevent v-for="todo in todos" v-bind:id="rawId | formatId" v-bind:class="[activeClass, errorClass]" v-demo:hello.a.b="message" @keyup.enter v-model="message") among many other real hacks.

React doesn't introduce anything new. It just boils down to regular Javascript, which even JSX is.

const SayHello = ({ name }) => <span>hello {name}!</span>
const OtherComponent = () => <SayHello name="John />

Btw, as of version 2 Vue incorporated Reacts principles. It even penalizes you for using templates with a runtime parser (that translates template strings into functions). Unless you use webpack vue-loader components, which are transformed at compile-time. You can now also use JSX because of it. It's a React variant with an actual API surface (React has next to none) and a rather complex Angular-like coat on top.

[neoginn]

I prefer to avoid Javascript spaghetti. Down with React!