I write Vue every day, in a large application. Only small bits use VueX.
Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid.
I HIGHLY recommend it, and this is from someone doing web since 1997.
I'm too inexperienced to have a definitive opinion, but I'm not nearly so positive and wanted to toss out a contrasting opinion to the current comments.
After a few years of using React and some past experience with various other templating/view systems (webdev of one sort or another since '99) I started picking up a little Vue. So far it's been easy enough, but it is highly confusing compared to most other systems I know.
The syntax is like JS handled through custom HTML attributes. In one place a string is a string, in another it's a reference to a component property. If I want to iterate over a list, I spit out the `<ul>` and then an `<li>` that has special attributes that says to repeat it N times, filling in these different bound values. Compare that to, say, React, where my code is code, and my HTML looks like HTML (but is actually code) and the relationships become more clear, less magic. If I want to loop over an array and output some <li> tags....that is exactly what I do.
Vue reminds me of JSP...that's not a point in it's favor in my book.
Now - I've only been using it for a week, and there is so much more to learn. But in terms of first impressions, Vue has not impressed me...and I actually expected to be impressed.
I've been using it for 6 months now, and I still can't wait to go back to React, for the exact same reason you mentioned. I'm 'fluent' in Vue now, and it hasn't grown on me in the slightest.
I have the opposite feeling to you. The template feels like HTML to me and the syntax is clear and concise. React for me gets confusing with it all muddled together. But each to their own.
I feel that this baybe the case when you know js very well and it's just easier for you to write 'custom-js' that will be transpiled to regular one.
I'm working on backend most of the time and relatively recently I needed to do switch to frontend part of our service. For me Vue seems much easier and less confusing. You just have your plain html template and a few 'hooks' to make it work with your js script.
>magnitude more complex and is very inconsistent:
Just as the other guy said - it is very intuitive. You don't even have to learn much of js to make it work perfectly.
I think this is accurate. My background is also in the backend realm and so I'm not a frontend person and my Javascript knowledge is marginal. I recently had to take on a more frontend project and I went with Nuxt/Vue over React.
That being said, I do share some of the other comments about how it can be confusing with bound elements and iterating over objects, or areas you aren't allowed to use string concatenation. A lot of this magic happens behind the scenes so it's a bit of trial and error, and feels foreign if you're used to being able to do those sorts of things in the past.
I also think that React (with JSX) is a bit more "out in the open" about how things work and what is expected, without reading tons of documentation, and less under-the-hood magic. So it's easier to get up to speed, and your JS knowledge will improve over time (especially if you already know other languages).
That's a very strong statement. To me the templating part of Vue is the least of my problems. While in theory you could make it sound complex by listing an exhaustive list of custom attributes, in reality this is almost never a problem. I have 2+ years experience in Vue, and I've never had any issues with the templating. Problems that are orders of magnitude more complex than templating are problems related to component lifecycles, functional composition, higher-order components, application architecture, server-side rendering + hydration, etc. None of this is solved by using JSX or some other templating language and these kind of problems exist regardless choosing Vue/React.
I feel like these kind of arguments are usually made by people who don't have any extensive experience using Vue, because in practice, it's not really a problem. Sure, you may not like it and prefer JSX (I understand all the pros and cons, all very valid), but that's a whole different statement than saying "Vue's syntax is orders of magnitude more complex and very inconsistent". That's just plain wrong.
> a whole different statement than saying "Vue's syntax is orders of magnitude more complex and very inconsistent". That's just plain wrong.
There is an easy test to see if my statement was true or false:
<tag attr="x">
where "attr" is a Vue attribute. What is x and what can x be? An expression? A string? A function reference? An object? How will it be processed and presented in the end? As a string? As a function call?
At any given point in time the value in an attribute is entirely dependent on context (which particular Vue attribute it's in) and on a very arbitrarily defined rules for those attributes. For example, v-on accepts three absolutely different and incompatible things:
v-on:click="x + 1"
A Javascript expression
v-on:click="function_ref"
A function reference bound to JS-code
v-on:click="function_call(param1, param2)"
Looks like a function call but isn't. It's a way to
declare a function ref that will be called with bound params
<tag attr="x"> // x is a string
<tag attr={{ x }}> // x is a valid Javascript expression
These are the same and they are consistent for every single attribute. The only limitations come from the meaning and the usage of the attributes themselves.
<tag onClick={{ function_ref }}>
<tag onClick={{ () => regular_JS_arrow_function() }}>
onClick expects a function reference because that's
what it will eventually call
And the rest around JSX? Plain old Javascript. Where this:
{
data: function () {
return {
open: false
}
}
}
doesn't magically turn into this in a completely different part of the object:
You can use JSX in Vue if you so choose (https://vuejs.org/v2/guide/render-function.html). I personally prefer the templates, and I enjoy the usage of HTML attributes for loops / conditionals, but the option is there, and there's no one correct answer here that everybody can agree on (which is fine).
I doubt we'll agree, but something as simple as: make an unordered list of hrefs with a url (based on name) and the name. Also, have a class on the currently selected <li> (currently selected meaning some variable matches the item name in the list) ends up with several special attributes, and a scope question (will a bound class see the iteration variable?) - all of which is not a question in something like React because there's not special scope being created, the same rules I'm used to always apply.
Different strokes for different folks, but I was quite surprised at my experience. Everyone keeps using the word "intuitive", and anything that I have to learn all these rules and special cases for is the opposite.
If you want to use pure javascript, you can create the render function directly and forget about templates. Most of vuetify components are pure javascript.
>I HIGHLY recommend it, and this is from someone doing web since 1997.
I started in 97 as well, and cannot recommend Vue enough. I've done React, Angular 1 & 2, and I keep coming back to Vue.
I always feel like with React/Angular I'm conforming to work how they want me to work. (Esp. Angular - React is more forgiving). Whereas Vue is just a complement to the way I already work. I can use as much or as little of it as I wish.
So for personal projects or for small apps I think that’s great. But when I think about projects that need to live on well after I’m around, then they shouldn’t work the way I work, they should be in standard way that anyone can come into and know what’s going on. That jumping applications between teams feels simple.
This is why I like angular quite a bit, it’s not whatever the dev decided to do. It doesn’t include a whole bunch of small libraries of questionable support.
I think you might be reading into what the poster wrote the wrong way. the implications of a framework being able to be used the way the poster descibes is that it closely follows existing standards and best practices. So as opposed to forcing you to do things entirely differently, it helps you work the way you might already work. Quite different from an anything goes wild wild west. And as with any language or framework, whether or not it's hard to debug is up to the developer.
It's been a few years since I checked in with Angular because the projects I worked on were distinctively unpleasant, so what I'm about to say may not be current. But at the time, the wide variation in project structure (and available opinionated approaches) and libraries/tooling of questionable support were definitely part of the problem (though certainly not the full extent).
Yeah, if it’s been a few years things are pretty different. The RC era was a little rough, but things are pretty standardized now. I wouldn’t say go start building with it unless it fits your use cases, but certainly don’t stay away from it if you come across it.
I think OP does not mean that Vue is unstructured / non-disciplined. Vue does have a rigid structure and standard though, but it's pleasantly designed and doesn't get in your way. Maintenance has been a breeze for me.
The usual <div :something='stuff + "here"'/> way of writing it errs on the side of HTML over JS, using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets. It makes it harder to visually parse, and it's sometimes annoying to not be able to use one type of quote marks unescaped within the statement.
Overall, this is one of many ways in which Vue (like Angular) seems like HTML with functionality tacked on, as opposed to React, which is closer to idiomatic JS. I've used both extensively and I don't think I can recommend Vue over React anymore -- unless you're, say, prototyping and looking to build an app entirely on the client, with no build step, where Vue really shines. Or unless you're doing something HTML-centric, like converting a static site.
I have to agree with this. Ultimately whether or not you like Vue or React better boils down to if you agree with the semantics of the web, and including them in your app building process (i.e you like html, and css, and just want to "pepper" in some logic and interactivity with JavaScript), or if you would rather just embrace JavaScript whole-heartedly.
Vue relies too much on overloading the string type for my taste (fundamentally, all JS libs do this to some extent). Too much magic happens with these string-based v-bindings.
Irrespective of that, these days I am hard pressed to not use typed JS in some form or fashion anyways.
As far as component libraries that start from HTML, I think Marko has the best syntax. Attributes are always parsed as JS expressions, for example. There's still some quirks, but overall it's pretty nice. https://markojs.com/docs/syntax/
There are some benefits from just embracing JavaScript though, especially, as you mention, integration with things like TypeScript.
That attribute syntax is awesome! I've found VueJS's handling of attributes to be somewhat confusing, sometimes getting a different type passed through than I was expecting. Marko takes the approach that would least confuse.
Despite whatever framework I use, I believe adding types improves it and reduces bugs, Vue included. (These days I'm favoring ReasonML and that skews me to React, but I believe Vue.js is also available on Bucklescript)
My least favorite part of Vue. Proper intelisense/checking for the templates never materialized either. A start-and-stop effort or two languishing in the Github issues..
I have a feeling after Vue 3 hits and in a couple years JSX will be the defacto way to work with Vue.
Non string values in props and attributes is basically my only complaint about Vue, but saying that it's HTML with functionality tacked on is so completely uninformed. It's got all of the functionality of React, and can do cool stuff with slots (both scoped and unscoped), renderless and/or functional components.
The "I wouldn't use Vue except for a small project" meme really needs to die too. Vue's build process is mature, has server-side rendering, and is used by some of the biggest companies in the world. If it's good enough for them at scale, it's good enough for the rest of us.
Detouring from the most popular path tends to come at the price of tooling idiosyncrasies that are rarely worth it, but it seems to at least work with eslint-react and has syntax highlighting in some editors.
Basically, what irks you is that Vue separates presentation (visual) from the logic via <template> and <script>, reusing components via HTML elements is poorly thought out and binding values to attributes is bad because hey, you can actually use JS to compute the value.
Naturally, even though you can disregard the templating and resort to idiomatic JS, like one in React, you managed to develop an opinion after not using the features you like.
This just makes no sense honestly. I'm all for people having opinion to the point where you can blatantly say "I hate Vue because I like React more", there's literally no need for justification.
But spewing nonsense just to justify your preference is just bad. Are you a junior dev by any chance?
I've used both extensively and I can recommend Vue over React because React is a pile of mental manure. I never understood React hype, but then again - IT is a fashion business, and when "leaders" invent crap - flies tend to follow.
>Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid.
That's exactly what it's like. Working with Vue doesn't even feel like you're using a JavaScript framework. You just write your HTML, your CSS, your scripts/data and you're done. Vue is brilliant.
I worked more with backend (Java, Python, PHP), but in my current project we needed a good UI, and decided to use Vue. No regrets. Using it almost everyday. I knew Backbone and a bit of Angular, but after using Vue, its cli, i18n, vuex, and also vue mastery, I'm not looking at any other tool for now.
The community around it is also extremely helpful.
Have you tried React in a similar setting?
Personally I couldn't bear it and it's massive adoption on frontend pushed me away from following that route much. Vue on the other hand certainly looks more "logical" to my eyes.
Weird, I came away with just the opposite impression. Vue forces you to organize everything in a certain way: data goes in data, computed properties go in computed, methods in method... it all felt very Rails to me.
React sort of used to have this problem, too, when you had to rely on classes for state, but the hooks era is a breath of fresh air. Everything is just a function. It feels freeing.
With Typescript classes that becomes better imo. Data are instance variables, computed properties are getters (and setters) and methods are instance methods.
To be honest, your post is like this submission. It's not helping people who want to decide. You just say Vue is great but people would like to understand why or why it might be better than React. This submission is also not helpful because it's from 2017 and I wonder why it is heavily upvoted and not a newer post. Things changed in two years and again, readers would like to understand how Vue compares against React but in 2019.
Curious how do you deal with state management in large application if you are only using small bits of vuex. I am writing this vue application where one component has become so huge that I would like to break it into smaller components but then passing data around in props is a nightmare. So I then need to look into something like vuex. So how do you get away from that in a large app ?
It depends a lot on what you're hoping to do. There's a happy medium for a large app between "every component manages their own state/props and those of their children" and "every component is a stateless vessel for VueX data".
I think if you're at the point where "passing data around in props is a nightmare" that's the pain point that VueX is meant to resolve, and it should feed into the solution. But following the principle of "components should manage their state without VueX if it's easy/convenient for them to do so" is a good way to avoid the global state becoming too unwieldy.
That's a problem you'll have with any of those frameworks. Personally I have endpoints that ask for the data at a component level and if they're small, they're being passed the data from the view that contains them.
I've been working with Vue for a few months now, after several years with React, angular, JSP, rails and django (and of course jquery).
I know a lot of people, especially in HN, are impressed by it but I found it very lacking. It makes things easy to write at first and with very little learning curve but trades that ease of use for stability, simplicity and maintainability.
The main problems, to me, are:
* too much global state - the Vue object is the new window,a global registry, you add custom elements,filters,directives,plugins and even just utility methods. You can of course opt not to use it, but since all the libraries use it and it's the canonical way, you'd be hard pressed to.
* lack of controlled components - unlike react there are no controlled components. For example if you are trying to make an input that doesn't accept certain characters, in vue you'll need to handle keypress events to make sure the value doesn't change, while in react you can simply not update the rendered value. This can be worked around of course, but the fact that vue doesn't have a clear definition of it permeates throughout the ecosystem.
* component definition syntax - the syntax for definition a component with it's data,props,methods,computed,hooks is a very inconvenient way of writing classes (which vue 3 is going to support natively finally)
* template syntax - after doing JSX, going back to template syntax is not the greatest experience. It doesn't work as well with IDEs, you have to spin circles to do things that can be a one liner in javascript and it prevents doing any form of reuse and structure unless it's by splitting it to more components (I.E. no way to use just functions or internal methods).
Of course vue prides itself for the fact that you can choose to do things a different way - use JSX instead of template Syntax, don't use the global vue registry, etc...
But that's really in theory, it's like React can be used without JSX, it's technically true, but it's extremely hard not to and the ecosystem won't work well.
As to VueX, for me it takes the verbosity, single global object and dependence on strings for differentiation from redux and leaves out the immutability and reducer syntax. It takes the publish/subscribe technique from ReactiveX or mobX but leaves out the ability to combine, manipulate, stream and the general reusability that those frameworks provide.
It is almost a comical selection of the worst features of both without any of the benefits.
I've also been using Vue for a couple of months now. Initial experience is fairly positive, but there are absolutely things I miss. I don't miss JSX that much, but I really miss the way Angular let me inject services wherever I need, and views get updated automatically. If I try anything like that in Vue, it doesn't work, I need to put everything in the Vuex store, which makes the store a single global variable that contains all my data and services.
Fortunately you can cut up the store into multiple modules, but I still prefer the decentralised approach from Angular over the central store.
I also regret the lack of classes and the lack of a more webcomponent-like approach. Component definitions work fine and are fairly flexible, but they look messy.
Tell me, what's the difference of simply importing a JavaScript file with your service code compared to injecting the service with DI in Angular? At the end of the day, Vue is just a UI library. From here you can build your application architecture the way you like. So the difference to Angular is, that Angular is a complete framework which tells you how to define services the Angular way. In React and Vue, you just do that how you would do it in vanilla JavaScript.
I wrote this article back in 2017. A lot has changed since then. If anyone has any questions I'd be happy to answer them. We now use Vue in our data science startup meltano.com.
Have you done any work with Vue and Typescript? We're just starting out with Vue. But my understanding was that TypeScript is a first class citizen in the new version of Vue.
TS isn't a first-class citizen in 2.x, and you'll need to go through a couple of awkward maneuvers to prevent Vue from negating many of the benefits of TS, but it can absolutely be done. This sample project sums it up nicely: https://github.com/Armour/vue-typescript-admin-template
Looks like 3.x plans to be built on typescript but I'm not sure if this article is still relevant, I very recently started paying serious attention to Vue.js so I'm playing a game of drink from a fire-hose.
https://hub.packtpub.com/vue-js-3-0-is-ditching-javascript-f...
I can't think of any bad parts of Vue off the top of my head. I really do enjoy the whole library. Although I think slots is a harder concept for most to grasp then it needs to be.
Why would one choose Vue over React except for the goal of making the project "easier to jump into" for "more junior developers" and sort of accessible to "designer-developers" too?
The way I see it Vue complicates the logic of the app (due to two-way-binding, observable state etc.), it does decrease some the boilerplate needed at the beginning, but makes getting started or doing simple UI tweaks accessible for juniors devs / designer-developers / "web-developers". (React is well known for the fact that once an app grows beyond a certain size only actual "javascript engineers" can touch it, it's no longer intelligible to "designer-developers", and it can have a codebase specific learning curve for every junior dev joining the team.)
EDIT+: To clarify, the way I see it, React's advantage is its simplicity, the core conceptual logic of things is very simple/mentally-compact, you can "run around with the whole thing loaded up in your head" easily. Yes, it does require more in terms of "IQ/cleverness" and also some "sense of architecture" from developers in exchange for being able to wield this simplicity without "cutting yourself", but I'd say it's worth it. I'd say React is the "catana sword" of web frameworks in a way :)
> Why would one choose Vue over React except for the goal of making the project "easier to jump into" for "more junior developers" and sort of accessible to "designer-developers" too?
In my (admittedly inexperienced w.r.t. Vue) view, that is exactly the reason for Vue's popularity, and a perfectly fine one at that.
What I've seen from GitLab's workflow is that their front-end developers are not of the "SPA type", for lack of a better term, but more of the "design a page using HTML+CSS and add some Javascript for interactivity" type (same lack of a proper term). And that's perfectly fine; I'd presume they work more closely with designers or take up some design work themselves, and would at least expect them to be proficient in areas like accessibility much like many in the industry are not.
I think what's the better choice mostly depends on how one's organisation is structured. Though honestly, either would probably have worked just fine, and it's mostly a matter of nuance.
I love Vue and use it wherever I can. I used to feel iffy about the angular-y syntax and how CSS JS and HTML all often live in the same file, but I've come to love the way that coupling embraces the component architecture: "This file has one (1) self-contained component that does this one thing". That plus the built-in routing, global state management, and scoped CSS/SCSS made me never want to go back to React.
The one thing that keeps React in my toolkit: React-Native development with Expo is truly an excellent experience. Getting everything going without having to fire up visual studio or Xcode is a dream. I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done"
> I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done"
I had a similar experience. I will say, though, that the nativescript-vue plugin is now officially supported by Telerik rather than just a community plugin, so it should theoretically be getting easier to use.
quasar lets you build a responsive web app, and iOS and Android apps, where ionic focuses on mobile, not bad just different. Also, Ionic’s support for vue is really new and not as well documented.
> Surely you could query the DOM for this. A better solution, in this case, is to let the backend developers mark the last user comment in the JSON they return. Backend developers have direct access to the database, which means they may be able to optimize the code. Then no client-side work has to be done at all, in this case.
Look, I know what I am, I'm no fancy-pants silicon valley guru here. But what is described in this example is primarily a client-side function. So I think the wording for this is "a different solution" at minimum. Better? Meh. Will that new backend query ever serve any purpose other than facilitating this frontend feature?
Perhaps instead of adhering to a "let's not query the DOM" at all costs, ask yourself what exactly you are complicating and for what gain.
To be fair, they pointed out additional motivations to move to Vue like making the client-side UX more maintainable and improve client-side performance.
Also, for all we know their server-side Rails+Haml stack took <50ms to query the database + render the comments, but they still wanted to factor that out of the initial page load to improve TTI.
I (and an extended team) have built multiple large-scale Vue.js apps, including a full rewrite of a solar power plant modeling tool (First Solar) from ES5/Angular to ES6/Vue. I am continually reassured of our bet on Vue.js over React. I'm happy to answer questions from my experience!
Q2: Did you compare Vue vs React or Vue+Vuex vs React+Redux? What do you think of "React without Redux"?
Q3: What advantages would Vue bring over react in your context? The way I see it, Vue could lower TCO for web apps by allowing more junior developers or web-developers/designer-developers to make smaller UI changes instead of needing more senior/expensive frontend-engineers or full-stack-engineers-withs-strong-js-skills that React seems to require? (I mean your project doesn't seem like the one that would benefit from making the codebase easier for junior devs to work in, but at the expense of it getting more complicated for senior devs as the overall logic is more complicated in Vue...)
There were many times in the beginning of working with React when I checked out Vue because I was stuck. I was reading threads like this one where people were worshipping Vue and why it might be the better choice than React. People brought up many good points but forget one important decision factor most of the time:
While Vue has a big ecosystem, it's still a fraction of React's. And this is probably the most important thing about React: The ecosystem is so huge, that you have choice, strong competition between lib authors and at the end of the day often or usually superior products. You hate redux? Me too, but there are literally dozens of competitors or wrappers out there + React's own Context and Hooks which bring you quite far. You want a UI lib? There was guy on Reddit testing 40 UI kits for React. Animation? A dozen good ones plus one major one. E.g. I was looking for a page-transition lib for Vue for cross-fading page transitions (real cross-fading where pages blend into each other), I found nothing, just one which can do page-transitions but not real cross-fading (fade-out and then fade-in of the new page). Not that just that vast amount of libs makes life easier, there are so many people you can ask, React got the lingua franca of frontend.
Another thing I like is the actual (small) API of React. It's low-level and if you are stuck, you know quickly what the problem is. React shines also re maintainability , if I enter my biggest and quite complex React app after months I still know where to go and how things work.
Finally, the React team and how they manage issues is amazing. Their thoughts, their chosen architecture, their communication is far beyond many other maintainers on Github. You ask stupid questions in an issue, often Dan answers himself, always super friendly and helping out.
Once you passed the first weeks, I realized what smart architecture React has, that it never stands in my way. Just the fact that I am always and 100% in JS makes things so much easier.
Of the big 3 frameworks (vue angular react) vue feels to me the most like what HTML custom components should be
I could see vue-like syntax and features supported natively in the browser in a utopian future; have never felt that way about react or the ancient version of angular I had to touch.
i would too really welcome DOM2 modelled after Vue. current way of reimplementing the DOM stack with JS feels like putting a new engine into cars trunk and hacking the transmission around instead of replacing the old engine that's occupying the front.
The main argument why I am using Vue (especially) on a lot of side projects is that I am able to deliver faster and better software products to my customers. For small businesses, they rarely care with which framework you utilized to deliver the software. What they care for is that they know they are getting value out of their financial investment and that it could really help with their operations.
And the ease with which I am able to extend / scale / enhance the application within a very short notice is also one of the highest selling points of my choice. Majority of businesses equate time resources with $ and the faster they are able to utilize the software, the better their business becomes.
I have used both React and Vue in large, long lived apps. I personally found both to be excellent - React has better TS support as of now. When Vue 3 hits with its internal TS api and you can use TSX as a first class citizen, I’d say you could go with either and have a comparable experience. At the moment the lack of static type checking due to Vue’s .vue file is the main disadvantage, IMO.
I'm doing my first proper project with VueJS, enhancing a traditional web app with components. I picked Vue because a year ago when I first started experimenting it seemed much easier than React to enhance parts of existing pages with. That story has changed since, and the React docs are beter about how to use components within pages.
I echo the issues with the attribute syntax. I found marshalling data from the server into components to be painful. I ended up with the following:
If you mix server-side rendered apps with Vue, this is the most common way. Second method is to push the data to a window.__data.staffMemberOptions = "{{ foo }}" and use it in Vue.
The revolving door of front-end frameworks is somewhat irritating; spending a nontrivial amount of time in Angular (1), then React, and now Vue. I wonder what the next one will be
angular.js is not a viable choice anymore (no clear statements of how long it's going to be supported), causing huge migration costs for everyone involved.
A portion of Vue projects are not single page app: it can be used on top of a server-rendered frameworks like Laravel, Rails. Even the document mentions using Vue by a script tag inside the HTML.
This may contribute to Vue being downloaded through npm in lower volume than React
React looks a lot more popular than that comparing title:react vs title:vue on indeed.com or stackoverflow.com/jobs. Though I don't see the point -- they're exploring almost the exact same concepts.
As for what's next, I have a hard time envisioning anything usurping React any time soon. Its breed is basically the state of the art in UI paradigm and an active field of research. I'd put things like Elm in that cohort as well.
I think the better question is: what's next for React and its cohort?
When are we going to see these ideas appear first-class in Cocoa/UIKit/etc? When will we finally see "OOP is good for UIs" (OOP's final foothold in our dogma) lose out to "FP is good for UIs"? What's the next big thing inside the React ecosystem? How far can something mainstream like React move towards the strictness of something like Elm?
React can be used from a CDN as well, including using it with JSX. Although using JSX from CDN scripts is a bad idea in production because it's slower.
I used riot.js for a few years and was quite happy with it. Sadly it had a few misconceptions (e.g. the parent.parent.parent... problem) which could have been changed easily. But as the lead dev wasn't very cooperative I switched to the closest alternative: Vue. I don't have enough experience with Vue yet to judge it, but given how similar Vue and riot.js are I hope that it gives me the same productivity without those broken bits and hopefully a better community interaction.
I also came to vue from riot, and now find myself much more productive with vue. stick with it. and check out nuxt for out of the box server-side rendering, another thing that was a bit tricky with riot.
You can use JSX with Vue but you miss out on some of the template features. Two way binding is one I think but there's add-ons that write the boiler plate for that for you. Either way, it feels uncomfortable working with Vue in a less standard way in the event you run into problems.
JSX + Vue + TypeScript is pretty nice.
HTML templates + Vue + TypeScript is not so nice because you get lots of bugs coming from the untyped templates.
Two-way binding isn't so much a 'feature' so much as it is the bug that caused the front-end framework churn to finally steady as frameworks migrated to a more predictable model of one-way binding.
Vue is much more limited in the way it uses two way bindings compared to Angular v1 which you're probably referring to i.e. between form input elements and data, not between components.
I started out in SPA development a little over 3 years ago. Before that I was very inexperienced with front-end development, and we used ASP.NET MVC with JQuery sprinkled around.
I realized that this was going to be a spaghetti nightmare, so decided that I had to choose a real front-end framework.
At that time, Angular 2 was in a alpha,pre-alpha state, React (JSX) seemed to weird, I didn't know anything about Vue, so I chose Aurelia.
At that time Aurelia was going to be the next big thing, but I believe there was a series of technical missteps with Aurelia and I saw that it wasn't going to go anywhere, so changed direction to React.
By the time I started with React, I had months of front-end development under my belt, so I felt more comfortable with it. It had/has a large community with plenty of resources, but I started running into problems with the whole a-la-carte nature of the React ecosystem.
At first, I used a little Mobx for state management, but at that time I had what would be considered several mini-SPA as I was migrating away from server side MVC. After a while I decided to migrate to Redux since that seemed to be the canonical state management solution for React.
Redux turned out to be a productivity nightmare. Redux has its own ecosystem of libraries - Redux Promise, Redux Saga, Redux Forms, etc..The whole complexity was turning me off. Not only that, but other 3rd party libraries like React Router was a big bummer. There is 15 viable styling solutions in the React ecosystem, and the ones I played around with me just didn't stick, but I could deal with the styling issue.
But Redux was just killing me in terms of productivity. There were small abstraction libraries over Redux, but I didn't feel comfortable enough with their small communities to make the leap. Eventually, I moved to Mobx State Tree. I thought that would be the holy grail. I ran into known huge performance issues with Mobx State Tree. That along with some of the leadership issues I had with the project was the final straw for me. I made the tough decision to rewrite everything in Vue.
And I can't be happier with that decision. Vue just seems to have been developed with the number one goal of being productive in mind. Vuex is mostly a joy to work with. I love the built-in SCSS, scoped, etc styling mechanism. The community is great. I'm happy with my decision.
Recent React has made some good strides with Hooks and Context. I'll have to take a look at using React in another project down the road. And I do have an affinity towards JSX, even though right now I don't use it in Vue (which supports it).
And I think things like supporting JSX and more than one way to do thing in the Vue world is its greatest strength. If you don't like the "stringy" of template directives, then you can use JSX, you can write classes or you can write object style components.
I look forward to Vue 3.0 and being able to drop legacy browser support so we don't have to use vue.set and friends because of reactivity issues.
As a React developer I have yet to hear a compelling reason to use Vue. Most of the time it seems like the Vue defender was just looking for the next hot thing and would have used literally anything else, didn’t understand that React is just a library and conflated it with the React ecosystem, or couldn’t wrap their head around FRP. From a business standpoint I can’t understand why you’d put anything on Vue unless their was a long list of extremely compelling reasons to not use the larger, battle tested React ecosystem.
1) 2-way bindings. i used to hate the concept of it as it was a form of black magic and had hard to debug performance issues ala Angular. but in Vue, it is actually fast and straightforward, it's essentially a light boilerplate around getter/setter methods. it took me a while to convert to this way of thinking but once i did, i never looked back.
2) @click, @submit, @emit, :some_property. at first glance, those unconventional symbols/etc irked me and was turned off by it. but after 5 min reading their doc, it became really intuitive and extremely handy. its unlike Angular who have way too many things going on, with Vue its minimal.
Yeah, I've heard this before. It really makes no sense why you'd want to use getters and setters when FPR is so exceedingly powerful and easy to reason about, which circles back to my point about people not understanding FPR and the benefits thereof.
The community. Hands down the community. Vue has such a better community than react or angular by a Long shot. If you ever end up needing help and jump into the discord channel. No matter how annoying you are the entire community is always patient polite and helpful. I can’t say my experience has been close to the same in react or angular.
Have you been on the React discord channel? Acemarke is like 20 people masquerading as a single person. I've never had a bad experience with the React community.
Case in point, any whiff of dissatisfaction and Dan Abramov will comment on your post. Literally can't get any better service than that.
Thanks. I had no idea react had discord, I believe I used gitter? at the time. I may have just had a bad apple but it just left a bad taste in my mouth, something I haven't experienced with Vue.
Yeah, the Reactiflux community has been on Discord since late 2015 (we were on Slack before that). Don't think this group was ever on Gitter - perhaps there was some other group besides Reactiflux?
There's an invite link at https://www.reactiflux.com . Please come by and say hi! We've always got a bunch of folks hanging around happy to help answer questions.
Sorry to hear you've had troubles in React community! Do you have any examples of places where people haven't been polite or helpful? Your feedback is appreciated.
This is quite a while ago now. I have no examples because it was a 1 off thing when I was learning and it just left a sour taste in my mouth, I believe it was in gitter.
I didn't know react has discord now though. So I'll have to join that as we've got a new react project at work (even tho I wish we were using Vue).
The angular gitter is worse. On their gitter I asked about some performance issues and was told I was "stupid" and "don't do it like that" even tho that's how the documentation showed how to do it, and "you shouldn't be using Angular because you don't know what you're doing". (I was eventually helped in a private chat by someone and resolved the performance issues just changing a few things, but this was driving force to ditch Angular and move to React)
Edit: Also for you to reply with concern does give me more faith that the community may be better than I thought. I appreciate your time to read my comment and reply.
If there’s negative behavior from those communities or if they’re not moderated well we’d love to be alerted so that we stop sending people there. What you went through with that gitter chat sounds horrible!
The #1 reason for me was how easy it was to pick up vue and start building something quickly. Which probably just has to do with my own background experience working with knockout and html/css/js. It's an easier stepping stone, a more natural progression for me.
I think it'd be a lot easier to pick up react now that I'm proficient with Vue.
I suspect most of the issues u face exist in other frameworks too. The comparison with scala isnt too right. They are probably 2 ends of the spectrurm for moment i saw scala, i knew its crap. Vue however has a certain beauty in its design, which really isnt too different from react/angular2, but much better syntax. most probably u guys have too many inexperienced developers.
That's the problem with large-scale Vue apps. Vue is awesome until you need to use VueX, after which it just becomes an inferior version of React + Redux.
I've always found Redux to be an overcomplicated mess, whereas Vuex is quite simple and has a nice, logical flow. For those who think it's still too complex, I've heard that Pathify https://davestewart.github.io/vuex-pathify is a great solution.
I regret every line of Redux boilerplate I ever wrote before discovering MobX. MobX is now even more fantastic with the new proxy based implementation.
Reading up on VueX.. Not really looking forward to having to use it over MobX.
VueX is terrible. I'm using vue with MobX, and though it's not as seamless as with react, you still get most of the benefits. There's just nothing that comes close to it.
Redux is a couple hundred lines of code. A good way to learn the pattern it to reimplement it yourself - which you could probably do in ~100LOC if you ignore the helper functions
I believe the OP meant in the sense of say, implementing a client for a network service in python using recursion with multiple re-entry points instead of a for loop..
I like the idea that the 200 line event dispatching state atom is more over-engineered than a framework that works off wrapped "observable" objects and uses ES6 proxy magic (MobX). Do proxies work in IE11? Didn't think you could just polyfill them.
Let's be honest Vue is a temporary blimp in web frameworks like all the others. I've been doing mobile dev the last 2 years and React was the hot thing. Then a year before that it was Angular. These things change and Vue is temporary like the others
Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid.
I HIGHLY recommend it, and this is from someone doing web since 1997.