With Vue you can write a scalable understandable application using the documentation. The same criticisms do certainly apply, but many of the advanced features are worked into the application.

For example Vuex is bundled into Vue and has verbose and opinionated documentation on how it lives in your vue application.

The React and Redux developers are incredibly good at what they do - they've also spent a lot of time putting out material, books, video courses, blog posts, talks help everybody else understand the new paradigm they've created

They can't be that stupid when a lot of modern javascript framework components are either direct clones of, or influenced by, their work

I'm a big vi and sublime text user but always open for better tooling.

btw - I actually agree with you on the learning thing but React just sucks. I'm able to get shit done with Vue and at the end of the week I haven't wasted three afternoons learning jsx/webpack/deployment/relearning-a-new-way-of-doing-css blah blah. I say this with some hesitation but CSS is a solved problem in my opinion with Sass.

You might still need to place actions/selectors in their own directory since they're not necessarily specific to any reducer. I believe this is how sagas are organized, though.

Can you list off any tools that you like where there aren't any people using them to make crap? Does the fact that some people produce junk undermine your success using a tool? Or is it actually inevitable that people will use a tool to produce garbage?

So I'm not understanding your point.

Except you're coupling your application state with the document model. If you ever do anything to change the DOM later on, (like installing React into your codebase) it'll come back to bite you in the ass hard, as now you need to find a means to communicate state that you just threw into the DOM like it were a slightly more acceptable global variable.

But, the learning materials and marketing are the ones that bug me...especially the ones that neglect to mention that the materials cover React+product, and only mention React in the title. You might not even know it's marketing until you've read half the darned thing and the crux of the thing turns out to be "now create an account here and use this service to outsource the specific thing you googled to learn how to implement yourself". GraphQL has a lot of the same thing going on. It's like "how to draw an owl", only instead of "now draw the rest of the fucking owl", it's "now send us money every month for the rest of your app's life and we'll draw an owl for you".

So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS. I don't think it's unreasonable for a designer to object to that - how would you feel if you were presented with a build system that required you to write all your JavaScript inside one big string statement?

Maybe it's just me, but I don't find it intuitive at all. `styled` has properties for, I assume, every HTML tag? But it can also be called as a function for inheritance purposes? And that inherited call appears to use the same tag as its parent... but what if I want to reuse styles across different tags? How could I define some shared CSS properties I'd use across different elements?

Don't get me wrong, it is cool stuff. But it also feels far too much like hand-wavey magic stuff. I've literally never used Vue before, but looking at this page:

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

I have zero confusion about how to write styles for it. And I really don't understand why styled-components would be worth the extra effort by comparison. What does it bring to the table? It's different without a compelling reason for being different.

BTW - You don't need webpack for React either. It is entirely possible to write React without it.

One of the boons of react is that you can create a set of reusable base components that can be built upon throughout your app.

If you can code-split the app, lazy-loading components as needed, and if you can cache all of the static app anyway, why does it matter if the presentation is tied to the logic?

The same can be said for vue.js. :)

The two languages have many merits and they both make their own sacrifices. But they are ultimately two peas of a pod.

Like Thor and Loki. But who is Thor and who is Loki? ;)

Because everyone with a React job or substantial React project uses Redux (or a similar library). It is common for junior devs to rush through learning libraries in hopes of being employable or a "real developer" as soon as possible.

Now I did two projects without and everything is nice and simple.

My first step is to hire someone that knows how to build a FE app. We'll use the tool that someone is familiar with.

If you're a CTO of an incubator startup with 2 people straight out of college who learnt Python and basic JavaScript and you're trying to build a serious web app from there, well, it doesn't really matter what you pick, you'll have to rewrite it in a few months anyway (that's a pretty common scenario).

Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux.

Then, build something small. Learn Vue. Repeat.

Now you understand both options enough to make an educated decision. Feel confident building your big, gotta-get-it-right-off-the-bat startup project in whatever works best for you.

Okay, how big is our web application? A few pages with a form? We'll avoid Redux for now. We might even avoid React.

It's like anything else: should you set up a Spark cluster if you're only processing Gb's of data? Probably not, but you might need it some day -- so make your best guess.

And the reason is: projects starts small, and grow. But not all grow to become large.

The wonderful thing with vue: you start small, and IF you reach the stage you need more, you can do so easily.

That's not part of Redux, it's a separate design pattern you can use with any Flux architecture. React-Redux doesn't even require you to do it that way, and for good reason: you might not need it. There's nothing wrong with just importing a store reference wherever you want it. That's a totally reasonable pattern for some applications.

This illustrates my point I guess. There's so many people thinking about how to architect and implement React applications that there's a lot of cargo-culting.

Vuex & Vue are the easier APIs to learn. Not only that the developer ergonomics are just better for Vue's API. For example in vue you have "mounted()" instead of "componentDidMount()" or "ngOnInit()". Likewise, redux requires learning CS terms (if you don't know them) like thunk, saga, memoized selectors, etc. Vue uses more layman's terms, like "computed" instead of "memoized selector" which just makes it easier to learn.

My big hangup with Vue is having to declare reactive properties up front. It's author says this is a best practice anyways, but it leads to hard to debug issues when you accidentally declare new properties at runtime & you get race conditions. With react & redux both making immutability possible & encouraging immutability, you get easier to debug apps. But there is a more up front investment.

I also really love Vue's single file components. I know you can do that in Angular & React, but again the API is just so much more ergonomic in Vue.

Starting with vue is just: add a script tag, put your template here, now your data here. Done.

The start up experience is nothing alike.

The reality is that tooling for templates (even Angular or Mustache style) is pretty terrible. Tooling for CSS is just as terrible. Static analysis or doing simple things like interpolation of data is pretty darn bad.

But JavaScript tooling isn't half bad. It's not the best there is, but its still reasonably advanced. Thus you have React, which is basically just JavaScript and objects. Sure JSX, but when used in React, it's just sugar to define those objects (hyperscript would work just fine too if you don't want to use a compiler, and early on in React's life just creating the objects from factories was just fine. Certainly better than weird templates with bad tooling).

Once it's all javascript, everything works: my linter works (and is certainly more advanced than css linters), both major type systems work, my refactoring tools work, and I have all the language at my disposal without learning anything new to do stuff like conditionally showing or hiding things. No need for an ng-if, v-if or whatever.

The same logic keeps going with styled-components. Associate the styles with a plain old JavaScript object, using javascript constructs (in this case, template strings), and all the tooling to manipulate them, interpolate them, or type check them just works (eg: TypeScript isn't bad at typing interpolations in template strings). And if that's not good enough, Glamorous is just objects so it's even easier.

Now I mentioned both styled-components and glamorous...normally this logic would heavily favor the later, but for some reason, tooling for styled-components have gone above and beyond to make up for the shortcomings of template strings, so it ends up working better for me.

Maybe someday some very motivated people will make tooling for the non-JS parts of ecosystems that are not "all JS", and this point will be moot, but right now the React ecosystem is the one that lets you most heavily lean on tools.

It's probably why it doesn't look so great from a newcomer perspective though: if you're not at a point where you're trying to squeeze every last bits of power from the tooling ecosystem, then it's just overhead and a waste of time.

Create React App gives you a zero configuration way to not only write hello world, but also bootstrap a non-trivial production ready application. In the company I work for, we were previously using JSPM/SystemJS/Gulp. We replaced all of that with create-react-app. It allows you to very easily bootstrap existing applications on top of it: http://fredrik.anderzon.se/2016/12/04/adding-create-react-ap...

And if you want full control of your project, you can "eject" and CRA will generate the webpack configuration file being used so that you can tweak to your heart's content.

I use React daily, and the whole experience has been extremely pleasant.

Thank you! Every time I've tried react (and enough attempts were made to finally decide it was just not for me), there was always something in the back of my mind that I didn't like and I just couldn't put it to words. You just described what it was.

And, if one forgoes tooling, then the situation is like the one you described in your previous comment: an afternoon just to get a "Hello world".

I'm aware of Rich Hickey and Clojure. In my experience with Lisps, although they are superficially simple, they make you do more abstraction work than is necessary in more commonly used high-level imperative languages. Lisp seems to strongly encourage building a high number of helper functions, which is fine if you're highly opinionated about how a job should be done, and less so if you just want to import some battle-tested libraries and write something that gets the job done. I suspect this is where the learning curve with Clojure really comes in, in that it's more closely related to being learn how to architect an application in a Lisp-friendly way than it is about getting familiar with the language.

You have to take yourself out of the "experienced React+Redux dev" mindset and put yourself in the shoes of "Experienced dev looking to invest in one of two ecosystems" mindset. Which one is the path of least resistance?

The point is, React+Redux people would love to believe that it's "Vue+VueX." But in reality, it feels like "just vue." A sword is stronger as a single piece, and Vue+VueX feels like a single piece.

It's up to people to learn both and decide for themselves, but my argument is simply this: it's a mistake to underestimate the traction Vue is gaining.

There's a strong temptation to blame the dev: They're not smart enough, they should have been able to pick up Redux easier, Vue+VueX is the same as React+Redux. But all I can do is report my experiences, and an honest survey of the ecosystem would lead us to conclude that Vue+VueX is far easier to learn without sacrificing any flexibility for your company in the long run.