I learned React before I learned Vue. After I wrote an application in React, I decided to try Vue for the next one. It was like a breath of fresh air. The templating language is more intuitive to me and the lack of boilerplate makes it great for the small projects I've used it for.
To each their own. But there is nothing I miss about React after switching to Vue.
I'm in the exact same boat. React never really felt comfortable for me, but Vue clicked immediately. Admittedly, I'm coming from an AngularJS background.
Vue has all the stuff that made AngularJS so great, and none of the baggage. I've made a few small to medium-sized projects with it, and I see no reason to use Angular[JS] or React anymore. I love how well it plays with regular JS modules, allowing you to share your HTTP code and service libraries across multiple apps (Vue or React, or vanilla JS).
Vue hits a nice balance between opinionated code and flexibility. Throw in their ESLint plugin and I think you will end up with very maintainable code.
One thing I really like about Angular is Angular Material[0]. For me, it solved the same problem Bootstrap first solved - get a decent looking & usable app ready even if you suck at design. With the library of components[1], it's super easy to prototype and build stuff with Angular. Is there an equivalent of this in the Vue land?
I had a look not too long ago and Vuetify didn't do component imports so you could use just the bits you wanted (you had to import the whole lot, and it's a big lib)
Vue-material lets you do this so I went with that but I also get the feeling it's a smaller / less updated package so YMMV
I spent a year working with Angular Material, currently I'm in a project that uses Vue + Vuetify and to me Vuetify has much more to offer than Angular Material.
Anything Material is utter crap, Vuetify is not the exception. Minimal CSS frameworks like Picnic CSS are the only way to go. You do not need components and CSS classes to have a decent design. Quite to the contrary.
Did you consider using individual components instead of adopting an entire component framework? Interestingly, I just picked a random Vuetify component from your list, Autocomplete, and the demo is broken in Chrome (cannot type or click trigger - only keyboard down arrow works):
> Did you consider using individual components instead of adopting an entire component framework?
Yes and it's a headache. Mostly because they have separate docs and CSS. The other day I had to change the appearance of all the labels - with a single framework I could just add a simple, single selector(because Vuetify as opposed to Angular Material uses BEM) and be done with it.
> Control question: did you click the icon on the left or on the right?
This is the first time I've ever been stumped by a simple read-only field. I think my confusion was due to the floating label animation on focus which I would expect only if the field was editable. You typically don't encounter read-only fields in mobile apps but they're common place in enterprise desktop apps.
Regardless, there is a bug since clicking the down arrow on the keyboard still allows me to select a state even though the field is read-only.
Having used vanilla JS, jQuery, Backbone, AngularJS, React (with and without Redux), and Vue (with and without Vuex) I really don't see eye to eye with the folks who love Vue so much.
To me, it looks like Backbone, AngularJS, and React had an orgy and out came Vue. The "opinionated" claim strikes me as marketing BS, templating vs. JSX, attributes vs. components (assuming you're using their templating language), etc. There really isn't a performance benefit over React. You're wading into a new ecosystem without all the build-up React benefits from. The templating language itself is yet another thing to learn, and frankly I just don't think embedding control flow into the templates themselves is a sane approach.
The documentation folks love to talk about is alright, I've definitely seen worse, but it is too much "Go do X" and not a lot of "Why we do X." The latter is a particular strength of React, in my opinion, as they describe very well the underlying logic behind why something is the way it is.
About the best argument for it is the batteries-included nature of the projects, but even then I've not truly had that much trouble upgrading something like React Router such that it would make me question using it in the future.
For me, the fundamental problem with web components is that attributes are limited to strings, so for anything even mildly complicated you have to stick something weird on top of them that serializes/deserializes things all the time.
And component logic is very imperative and error prone... e.g attributeChangedCallback and batched renders. The webcomponent spec feels so outdated already compared to what modern libs do.
I think the only concrete criticism here is that the Vue ecosystem is new, which is (admittedly) perilous.
But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all. I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach, which Vue does not significantly suffer from (sort of, we don't need a bunch of apps, just a good phone).
Is there a particular situation you are thinking of when you say we are in need of said ecosystem?
> But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all.
I think quite similarly. I've only paid attention to third-party components maybe once or twice.
That said, ecosystem size, health and critical mass do factor into project longevity, as well as perceived adoptability, all of which feed back into each other.
However, in the context of React, the discussion about ecosystem elides the high necessity of using it, since core React stands a virtually zero chance of being sufficient.
> However, in the context of React, the discussion about ecosystem elides the high necessity of using it, since core React stands a virtually zero chance of being sufficient.
I think an SPA version of a CRUD app wouldn't need anything past core React. Most people don't talk about things that unamibitous, though.
For me? Something on par with React Native. I've used Vue/Vuex extensively and I'm playing with React Native. RN isn't perfect, but at least people have shipped with it. I haven't heard of anything vaguely production-ready for mobile app development in the Vue ecosystem.
Disclaimer: I don't use React or Vue. I have no idea how their mobile versions compare. I get my virtual DOM kicks from Ractive, developed by The Guardian newspaper. I'm told it's like Vue. I really like it. I'll probably move to Svelte for my next major project.
In addition to Nativescript (from Telerik, although the Vue bindings are community-sourced), there's also weex[1], which is backed by Alibaba. Downside is that a lot of the docs are in chinese.
While NS is fairly mature at this point, the vue bindings only reached a 1.0 release this year. There's been a lot of development done on it recently, though. I am unsure if anyone major company has shipped using NS-Vue.
> But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all.
> Is there a particular situation you are thinking of when you say we are in need of said ecosystem?
Here's a concrete, real-world example. I spent several months researching Vue and React for a large SPA migration from AngularJS at work.
In order to migrate a single page, I had to write three compatibility libraries that already existed for React. This was for a simple page that pulled in data via an API and displayed it in a handful of tables.
Another engineer did an audit of our third-party library use and needs, e.g. complicated "excel" like spreadsheet tables, and we simply couldn't find an existing Vue solution. That meant I would need to write my own compatibility libraries for at least another half-dozen complex libraries. There was an argument in favor of using Vue because we could get a lot of open-source exposure so I'll give it that. Plenty of low-hanging fruit for the open-source Vue developer.
Perhaps Vue folks are only working on extremely small, basic, CRUD applications. The software I work on is not.
> I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach
React simply provides you components with a lifecycle. You are free to architect and compose those primitives however you see fit.
Contrast with Vue, can you please reasonably explain the difference between a custom attribute vs. a component and when it would be appropriate to use one over the other? How is this simpler? How is this "keeping it simple?" This is only a single deviation between the two.
Vue tells me it is "opinionated" but when I have to research, compare, and contrast it's own core features I have to ask how is this "opinionated." If I have to do all of this legwork how is it "Keeping it Simple, Stupid?"
With full respect for your choices, I don't have your code in front of me so I can't review or comment on architectural decisions made, but given that disclaimer - when people say they "need" a plugin to do something, I often wonder if their viewpoint is accurate to the real problem being addressed, or if they are programming by habit, rather than by best practice. Again, I mean no disrespect because I have no information to criticize other than base assumptions.
To Excel, I wonder how much reimplementing was needed again, did you need computations in-cells like Excel has? It seems like if you are going that deep you will need to implement much of the logic on your own. I guess if you are truly just reimplementing Excel in a web interface, then your point has merit, but it seems like for something that specific, the preboxed solution would more get in the way?
To directives versus components, certain behaviors make more sense to me as an HTML element (an infinite scroller, for example) than as a "controller-level" component. Additionally I've found a great transparency of debugging by starting with the HTML and looking at what functions are being invoked when, than by hoping I know where the "controller" is binding into the HTML, and perhaps never finding all of it.
And fair - I still don't know what "opinionated" means... lol
I think it's okay that you don't see eye to eye with people who love Vue.
And I think it's also important to note that most of the things you point out are matters of preference. I've seen Vue fans and React fans argue about these things until they're blue in the face, when all it really boils down to is that some people like the way Vue does things, and some people like the way React does things.
Healthy debate is good. But the downside is that I've noticed these debates devolving into what I call identity politics for programmers - instead of seeing the other group as front-end developers who just like doing things differently, I see people breaking the world down into two groups: people who agree with them, and idiots. And I don't think this approach is very good for us as a community.
So I don't mean to single you out here, but the author didn't really criticize React in any way, so I don't think coming to the defense of React vs Vue here really added to the conversation.
Why not just say, "hey, I prefer React, but it's good Vue exists for folks who prefer a different approach.". Vue's existence isn't a threat to React. It's okay to have multiple approaches to the same problem.
I prefer React too, but I don't think a front end framework monoculture is a good thing so I hope that Vue, React, Aurelia, Ember, and others continue to grow.
It's just annoying that when I look for a new front-end job I see more and more Vue.. I really don't want to write all that markup, for me it feels like a step back from React, so I skip those jobs. Maybe I'm just afraid for non interesting technologies becoming a standard I have to concede to eventually.
And on the flip-side; I can't stand React so I'm glad to see that Vue is growing. I hate the JSX "everything is JavaScript" mentality where you shove all of your HTML into a render function.
Vue's component separation of HTML/JavaScript/CSS just clicks better for me.
> I hate the JSX "everything is JavaScript" mentality
Would you object to things like unobtrusive javascript?
Things like unobtrusive javascript came to be because people recognized early on that HTML was not enoug for writing applications -- that you needed something more. Since basically the entire world has come to embrace unobtrusive javascript, it isn't a logical leap to embrace JSX.
Some people don't appreciate being required to run arbitrary code just to view an HTML page and the eye candy of JS is just not worth it.
Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.
> Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.
That's an entirely different discussion than what the parent was discussing though. This is about those cases where you're not building a static website.
Saying that "your website" should be able to "display" its "content" without JS seems to assume (as so many do) that the web is fundamentally a collection of articles (read them, look at the pictures, link to other articles) with a few exceptions, and keeping it that way is every developer's responsibility.
That's not what it is anymore. It has evolved into a general, distributed computing and communications platform. More and more uses of this platform require doing things that involve customized behaviors, not just the built-in features for displaying articles, so more and more people leave JS enabled. Kids who couldn't have afforded a family PC and MS Office now have a Chromebook at school (and maybe at home) and free Google Docs. And how many people whose only internet access device is a phone turn JS off in their phone?
I think it makes more sense now to treat the JS-disabled, article-browsing case as the exception. If I were trying to distribute public health articles as widely as possible, I would try to limit them to simple text, small photos, no JS, nothing that wouldn't have worked 20 years ago. And even for less-critical articles, if they were just simple articles, I'm still inclined to leave out the JavaScript in most cases for the sake of simplicity, reliability, reach, and archival robustness.
But for general purpose today, most developers in the developed world can assume JS is going to be enabled by the market they want to target.
That particular argument doesn't make a case of React or Vue's approach being particularly better than the other.
In the author's conclusion he states, "JSX isn’t revolutionary. It’s evolutionary. Like most forms of evolution, it’s a clear improvement."
I will concede the author's point that React & JSX are better than the jQuery spaghetti that came before and is therefore an improvement. As the comparison here is to that of evolution which is superior the shark or the tiger? With evolution many things will evolve out of those things that came before and the strong will survive. Vue and React are both evolutions of what came before; time will tell which, if either, survives.
I don't think you are really going to have to concede to the latest hotness for a very long time. There's still plenty of jobs for building and maintaining PHP + jQuery applications. Shoot, I spent a lot of time at my last job maintaining Classic ASP serving up HTML. React isn't going anywhere.
That's fair. I've been scratching my head about vue for a while now. Every so often I try it again expecting some sort of, "ohhhh that's why everyone likes it!" But it never comes.
Oh well. I'm glad it's providing value to people. I might just never understand.
> Why not just say, "hey, I prefer React, but it's good Vue exists for folks who prefer a different approach.". Vue's existence isn't a threat to React. It's okay to have multiple approaches to the same problem.
Because I keep seeing folks extolling the virtues of Vue, but when I went and used it I simply found little to nothing of merit compared to existing solutions.
I'm not running around telling folks what to use here, but rather stating my experiences. Perhaps someone might come along and provide a reasonable explanation of how I misunderstood something or a problem it solves better than existing frameworks but all I get is "I look it and you don't so meh."
In short, I'm trying to spur a technical discussion here but all I get in return is fanboyism and folks trying to shut down the conversation.
> but the author didn't really criticize React in any way
Actually, the author criticized React both in direct and indirect ways. He also made incorrect and or misleading claims. Of course the author also goes on the mention that he or she is inexperienced with React but somehow still feels qualified to make those claims.
Sorry for trying to add to the discussion and not just posting "Oh gee, I sure do love Vue too!"
> but I don't think a front end framework monoculture is a good thing
My only trouble with the React stack is that, for me, someone who mostly works on apps, pretty much everything I work on is going to need a view library / a router / a means of managing state; I have a lot of inertia when it comes to working on new things because I know it's going to take a day or two just to get my project structure set up and running, before I even consider working on even the most general, common features of web apps (login, for instance.) Beyond that, Redux works well with user input, api calls, and sockets to manage state, because it is so explicit. IDK. Vue may be cool, but React/Redux has always done what I need of it.
I'm a React fan, too, as it enables nice FP-based front-end experimentation, such as pretty much all of the front-end Clojure solutions. It's really hard to do something like those using Angular or Vue.
I'd like to hear more about this. The reason ClojureScript's front-ends are React-based is that React provides a native JS view-layer (no templating required). I'm assuming Vue must do this, too, but I had a hard time tracking docs down when I looked a few years back.
The other thing that React does is encourages top-down propagation of immutable data, which nicely fits ClojureScript and other FP languages. Is this approach equally efficient in Vue?
Lastly, when I looked at view, it had a lot of sort of OO stuff happening in the docs, which doesn't map very nicely to ClojureScript and friends.
Do you have any docs / blog posts on programming in Vue with pure JS (no templates or magic) and in a functional way? If so, I'd love to read them. I may spend a weekend trying to put a ClojureScript layer on top of Vue.
After Angular 1/2, React, Riot I ended up there. It conforms to my principle of least surprise, and principle of least new ontologies. In the world of transient JS world, it's the best thing that happened.
Hope every other front end framework disappears and the whole world settles on Vue.
We've been using Vue in production since Vue 0.12. It was a joy to use way back when, and it's only gotten better and better.
That's not to say that I haven't shot myself in the foot dozens of times in the process though. We've had to solve a lot of pain points from our original 0.12 code (two-way binding, too many props in components, some jquery dotted in, lots and lots of pre es6 code). But even sitting on code I wrote that looking back makes me cringe, Vue is always enjoyable.
It has truly improved my daily quality of life and I owe Evan You a lot of gratitude.
I started looking into Vue just because I looked cool and its good to learn new stuff.
A few month later I got myself a smartwatch besides most of the work was getting around the tizen framework I made my own watchface in Vue - and this was/is a pure joy. http://wecoso.org/~mit/stuff/myClaw/
If you like templates and framework-specific syntax for conditional logic and iteration sprinkled into your HTML then you will love Vue. If you prefer the JSX approach and relying on JavaScript for conditional logic and iteration then you will love React. Vue does support JSX, but it is not the idiomatic way to use Vue.
I would say the other big deciding influence is that Vue leans towards the idea of a persistent state object with watchers that you update in place, while React leans towards disposable state objects that you update by calling a method that re-renders with a new disposable state object.
Dude... Ridiculously complex logic in the view is like the quintessential problem of templates; this problem is further amplified by the burden of groking the idiosyncrasies of every other self-styled templating API.
The other huge difference is how much React beneficiates from static typing (typescript for instance) whereas just like angular, vue templates and all the glue code cannot possibly benefit from it. A vue or angular app is almost as typed checked as a JS app.
I feel most vue lovers don't care about static typing.
Vue templates do not, but non-template component code very much benefits from Typescript. And of course, there is a lot of non-component code in SPAs. Vue app might be two thirds as checked as React app.
Having learned with react, I think the component structure and updating are wonderful. But the baggage of the React ecosystem made it tedious to add to projects. What if I don't want to use webpack and npm and babel?
As this author notes, Vue just drops in and works.
I can use it in existing projects. I can use it in experiments. I can use it with my PHP projects. I can use it without a server to compile anything.
It's been a pleasant experience and the tools I've built with it have been refreshingly stable.
> What if I don't want to use webpack and npm and babel?
You may want to look at Parcel, which gets you most of the Babel/Webpack benefits (minification, ES6 syntax, using image files as imports in JS, etc) in a way that "just works".
npm i --save-dev parcel-bundler
npx parcel src/index.html # where index.html has <script src="whatever.js"></script>
...and that's it, if you're not doing anything really weird.
After a few years in the Ember ecosystem, I started using Vue a few months ago and damn it's amazing. Of course you can't compare the two at all. I've found Vue and the structures it imposes on your application a bit easier to reason about than what I've found with Ember. It could also very well be that having learnt Ember, I picked up Vue very easily. Either way, I love Vue, and outside of Ember I can't say I've loved any other front-end framework.
I'm using Vue for 2 years professionally. Before that, I've used Backbone and Ember (back in the days those were the popular ones) and Angular and React.
React lacked crucial functionality and it felt like I had to rebuild basic functions everytime e.g. a simple input field which communicates its value through setState. In Vue, you just use v-model, but in React you have to add an onchange handler which just feels very low-level - I just don't want to operate on this low level, the framework is allowed to make assumptions e.g. for checkboxes to make my life easier (i.e. grouping all checked inputs with the same v-model name into an array). Another thing I don't like is that JSX is not very good-looking e.g. if I want to add an "if", I need to use the ternary operator in complex components. This is just a hacky way and not very descriptive IMO.
And Angular was awful with its $scope and felt so dirty (it used dirty checking, that's probably why). The new version is ok, but Vue has all the same concepts but wrapped up in a nicer interface. I don't even understand what the ng team tried to achieve with their difficult to read templating language. Looks awful and feels complicated compared to Vue's simple constructs (mainly v-model, v-for, v-if and v-show and v-on, v-bind and ref) - you can learn to write Vue templates in 20 minutes.
The core concepts are reduced to their essentials and it really shines. React is too basic IMO and Angular tried too much with all that controller, service, ... stuff. It was too complicated.
Vue is basically what Web components (using .vue files) should be: Small modules with HTML, style and JS code.
And a very nice API and a great developer behind it (so it has all the nice things: vdom, custom rendering e.g. for JSX support, a webpack loader, ...).
Overall, it's the greatest thing I've seen since Ember (and it's much better and more flexible than that).
This is exactly my experience. I used AngularJS, then studied many options including the latest AngularJS, Angular 2 and 4, ReactJS... in order to finally settle on Vue. Doing Vue front ends for over a year already.
This makes me think of the Apple marketing campaign in 2004. With Apple everything is better, hmmm not really. Apple has the fastest pc's in the world, hmmm not really.. With an Apple pc you'll get your work faster done, sure? Especially the non-technical designers, writers, musicians etc.. believed that shit. In a way Vue gives me that same feeling.
I find such euphoric praises of tech ridiculous. Especially when at the same time its alternatives are declared unusable (or in this particular case "obsolete" or a "trainwreck"). I have not used Vue yet and heard some good things about it. But despite this lack of experience I'm confident to say it is not the solution for everything and everyone.
Evan, if you are reading, I would like to say that I also fell in love with Vue, but I am frustrated that my feature request ( https://github.com/vuejs/vue/issues/8106#issuecomment-385367... ) was a little too quickly shot down, without much discussion or understanding. I understand that not every proposal can be accepted, but I think that the merit of the change wasn't even considered. I specifically designed the change to change as little as possible, and have as much power as possible.
I think that specifically in the case of Vue, this hurts more because of the philosophy highlighted in the article- to not stand in the way of experienced developers who know what they're doing.
(Edit: oh no, please don't come with the downvote train. This is a real issue, when you have something that solves 99% of your problems but you can't get it to 100%.)
This piqued my curiosity, so I read through the issue and here is my take: you are proposing a change that implements a _second_ way of loading async components, in addition to what's already supported [1]. This is unlikely to go through.
What you want is achievable with the existing async feature, except you either need to 1) keep a list of component names up to date, or 2) use a special component like `<dynamic-loader>` instead of the component tag directly. Neither is a deal breaker, nor enough to warrant introducing a duplicate API; it's rare that you'd be using advanced features like async components while lacking a build process.
Evan's first answer wasn't the most friendly but you also come out as very combative in those messages - as reinforced by your suggestion here that the 'merit of the change wasn't even considered'. Maybe there is some middle ground to be found, an alternate proposal, but I find it extremely unlikely anything will come out of this discussion using this tone. Humility is a must even for experienced developers.
Thank you for the reply. I hope I am not combative in this reply, I just want you to understand from my point of view.
It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components.
But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue.
I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.
Huge fan of the framework and been using it for an year now. My biggest complaint though is the speed at which things move. See for example this PR[1] : it has been reviewed and approved since early January of this year. That's 7 months without it being merged.
After reading the comments, I must be the only person in the world who misses good, old-fashioned Rails templates / views. With someone who knew the internals well, they were a productivity gold mine.
i love using flask, jinja, and jquery, but as i start to create more dynamic interfaces with this pattern both the pitfalls of it and the appeal of things like react and vue are making themselves apparent. think it may be time to sit down and have a go at vue.
Recently there's a push to eliminate jQuery usage from our codebase, and it's highlighting just how much React doesn't do for you. jQuery, for all it's faults, has been maturing for 10 years or so. It makes a pretty good footgun, but it's not like I've never seen anyone shoot themselves in the foot with React either.
That's still a valid way of doing development, but it doesn't really work for a SPA. You may not want a SPA, but if you do, you pretty much need something like Angular/React/Vue.
It would still be a valid way of doing development, if teams weren't cargo culting frameworks for tasks that really don't need them. I can't begin to tell you just how annoying React is for making a CMS.
It is interesting how personal the Vue / React divide seems to be. Nobody on either side seems to have very good objective reasons to use their preferred framework, at least for greenfield development. In the end people mostly just "like" one approach or the other - and this is for two frameworks that at a high level share basically an identical design philosophy. I feel like this must go to something very deep about how people think about software development - what it is, what is important about how it is done, etc.
Isn't that kind of expected, since both frameworks are so similar? Only thing that remains is what you like, or rather how you prefer your ideas to be expressed in code. And it's great that there are two (or more) solid options.
What is weird to me is that lot of people seem to insist that there are major (sometimes deal-breaking) differences between them, when even core developers of both frameworks agree that they are more similar than different.
Long-time desktop developer’s who didn’t touch react and even web fe/be until last year opinion here.
While Vue is obviously a kick-starter to frontend programming that makes templating easy and unix-y light, I still have few complaints. First, it is not obvious or easy to start with components. Separate files, build ecosystem, props handling, all this. What I want is to reference ‘that last place’ in html and have a copy of that template right here that would capture props like un-hygienic macros of C would do. Iow, my style of small apps doesn’t map well to heavy isolated-component based style of thinking. I don’t want to wash my hands every five minutes when I’m at home.
Second, vue forces you to be fully contained in .data and .methods. I would like to bind to any data and function roots, including window itself, but it’s obviously a bad idea to pass window to vue vm for now. But still, it would be nice to forget that vue exists at all at the source level and have just a bunch of vars, functions and [3rd-party] modules at global level and that’s it. Now I have to export methods to vue by hand and to have all the state pre-defined, as if it wasn’t clear how my state is structured from {{these expressions}} alone. I often find that something doesn’t show because I forgot to init data.key = { k2: “” }.
Third, you cannot ‘chroot’ without making a component. Would be nice to write something like <template v-with=‘client.contacts’> and then reference ‘phone’, ‘address’, etc without a prefix. With copy-style described above it would replace the need for components for me for ages, even if I meet that need.
Still my jquery experiments can’t beat vue in simplicity, though I hope some day I’ll get rid of vue too (due to points I listed, not because it’s bad). But de wae still has to be found yet.
> Angular 2/4 is a completely over-engineered trainwreck.
I can appreciate that the author loves Vue.js but I don't think its very constructive have such a binary view of something they clearly haven't spent much time with. Angular is not "over-engineered". Its complete. Its got everything you need and an established, well documented pattern to do it. Its far from perfect but then what is? I've used it, React, Angular 1.x etc and all of them have their strengths and weaknesses. It depends on your team and what you are trying to do.
Its important to remember all these frameworks are built by people just like us who try very hard to make them the best they can be. It would be nice if we spent more time celebrating all the wonderful FREE tools they build for us rather than tearing down the ones that we didn't pick.
I'm not in love with the way the MVC framework takes over and wraps the TS compiler (and a very specific version of the TS compiler) to compile templates. Seems an obvious layering violation.
I'll take composition over inheritance in my tooling.
I suppose I'd need to know what specifically you've run up against to justify your distaste for the approach. I too prefer composition but I'm not against another way if it works.
It's a really bad architecture. Couple of examples
(1) The angular compiler doesn't have the same JS or CLI interface as the TypeScript compiler. I have to know very specifically which I am using when; my build tooling must always know whether it's compiling TS the Angular way, or the vanilla way, and there isn't much commonality.
(2) What if I want to use an alternative TS compiler? Or someone writes a faster one in Go? Or I want to use tsickle [1], which is Closure Compiler-compatible?
Now it turns out there isn't a TS compiler in Go, and the Angular team are the authors of tsickle, and so ngc happens to work with it. But it's an architectural smell to couple that closely for my MVC framework (and IMO with little necessity).
116 comments
[ 3.5 ms ] story [ 189 ms ] threadTo each their own. But there is nothing I miss about React after switching to Vue.
Vue felt like a subset of Ember. React did something completly new.
Vue hits a nice balance between opinionated code and flexibility. Throw in their ESLint plugin and I think you will end up with very maintainable code.
[0] - https://material.angular.io/
[1] - https://material.angular.io/components/categories
https://vuetifyjs.com/en/
(I prefer vuetify)
Vue-material lets you do this so I went with that but I also get the feeling it's a smaller / less updated package so YMMV
https://vuetifyjs.com/en/guides/a-la-carte
I did find reference to a-la-carte when I looked but the page was 404ing so I assumed it was unsupported or in beta. Thanks!
Not sure if that's a negative or not.
They are not if you need the components do something aside from looking a specific way.
For the project I'm in I need a:
-Range slider
-Date picker
-Autocomplete select
-Data table with pagination
Obviously none of the "minimal CSS frameworks" have any of those because it's impossible.
https://vuetifyjs.com/en/components/autocompletes
Yes and it's a headache. Mostly because they have separate docs and CSS. The other day I had to change the appearance of all the labels - with a single framework I could just add a simple, single selector(because Vuetify as opposed to Angular Material uses BEM) and be done with it.
I may have to use an individual component for uploading since it hasn't landed in Vuetify yet: https://github.com/vuetifyjs/vuetify/issues/238
> (cannot type or click trigger - only keyboard down arrow works):
Control question: did you click the icon on the left or on the right?
This is the first time I've ever been stumped by a simple read-only field. I think my confusion was due to the floating label animation on focus which I would expect only if the field was editable. You typically don't encounter read-only fields in mobile apps but they're common place in enterprise desktop apps.
Regardless, there is a bug since clicking the down arrow on the keyboard still allows me to select a state even though the field is read-only.
Out of the box support for Material and iOS themes.
https://quasar-framework.org/quasar-play/android/index.html#...
I have one app deployed for web / iOS / Android, and 3 more in progress for clients.
To me, it looks like Backbone, AngularJS, and React had an orgy and out came Vue. The "opinionated" claim strikes me as marketing BS, templating vs. JSX, attributes vs. components (assuming you're using their templating language), etc. There really isn't a performance benefit over React. You're wading into a new ecosystem without all the build-up React benefits from. The templating language itself is yet another thing to learn, and frankly I just don't think embedding control flow into the templates themselves is a sane approach.
The documentation folks love to talk about is alright, I've definitely seen worse, but it is too much "Go do X" and not a lot of "Why we do X." The latter is a particular strength of React, in my opinion, as they describe very well the underlying logic behind why something is the way it is.
About the best argument for it is the batteries-included nature of the projects, but even then I've not truly had that much trouble upgrading something like React Router such that it would make me question using it in the future.
But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all. I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach, which Vue does not significantly suffer from (sort of, we don't need a bunch of apps, just a good phone).
Is there a particular situation you are thinking of when you say we are in need of said ecosystem?
I think quite similarly. I've only paid attention to third-party components maybe once or twice.
That said, ecosystem size, health and critical mass do factor into project longevity, as well as perceived adoptability, all of which feed back into each other.
However, in the context of React, the discussion about ecosystem elides the high necessity of using it, since core React stands a virtually zero chance of being sufficient.
I think an SPA version of a CRUD app wouldn't need anything past core React. Most people don't talk about things that unamibitous, though.
Disclaimer: I don't use React or Vue. I have no idea how their mobile versions compare. I get my virtual DOM kicks from Ractive, developed by The Guardian newspaper. I'm told it's like Vue. I really like it. I'll probably move to Svelte for my next major project.
While NS is fairly mature at this point, the vue bindings only reached a 1.0 release this year. There's been a lot of development done on it recently, though. I am unsure if anyone major company has shipped using NS-Vue.
[1]: https://weex.incubator.apache.org/
> Is there a particular situation you are thinking of when you say we are in need of said ecosystem?
Here's a concrete, real-world example. I spent several months researching Vue and React for a large SPA migration from AngularJS at work.
In order to migrate a single page, I had to write three compatibility libraries that already existed for React. This was for a simple page that pulled in data via an API and displayed it in a handful of tables.
Another engineer did an audit of our third-party library use and needs, e.g. complicated "excel" like spreadsheet tables, and we simply couldn't find an existing Vue solution. That meant I would need to write my own compatibility libraries for at least another half-dozen complex libraries. There was an argument in favor of using Vue because we could get a lot of open-source exposure so I'll give it that. Plenty of low-hanging fruit for the open-source Vue developer.
Perhaps Vue folks are only working on extremely small, basic, CRUD applications. The software I work on is not.
> I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach
React simply provides you components with a lifecycle. You are free to architect and compose those primitives however you see fit.
Contrast with Vue, can you please reasonably explain the difference between a custom attribute vs. a component and when it would be appropriate to use one over the other? How is this simpler? How is this "keeping it simple?" This is only a single deviation between the two.
Vue tells me it is "opinionated" but when I have to research, compare, and contrast it's own core features I have to ask how is this "opinionated." If I have to do all of this legwork how is it "Keeping it Simple, Stupid?"
To Excel, I wonder how much reimplementing was needed again, did you need computations in-cells like Excel has? It seems like if you are going that deep you will need to implement much of the logic on your own. I guess if you are truly just reimplementing Excel in a web interface, then your point has merit, but it seems like for something that specific, the preboxed solution would more get in the way?
To directives versus components, certain behaviors make more sense to me as an HTML element (an infinite scroller, for example) than as a "controller-level" component. Additionally I've found a great transparency of debugging by starting with the HTML and looking at what functions are being invoked when, than by hoping I know where the "controller" is binding into the HTML, and perhaps never finding all of it.
And fair - I still don't know what "opinionated" means... lol
And I think it's also important to note that most of the things you point out are matters of preference. I've seen Vue fans and React fans argue about these things until they're blue in the face, when all it really boils down to is that some people like the way Vue does things, and some people like the way React does things.
Healthy debate is good. But the downside is that I've noticed these debates devolving into what I call identity politics for programmers - instead of seeing the other group as front-end developers who just like doing things differently, I see people breaking the world down into two groups: people who agree with them, and idiots. And I don't think this approach is very good for us as a community.
So I don't mean to single you out here, but the author didn't really criticize React in any way, so I don't think coming to the defense of React vs Vue here really added to the conversation.
Why not just say, "hey, I prefer React, but it's good Vue exists for folks who prefer a different approach.". Vue's existence isn't a threat to React. It's okay to have multiple approaches to the same problem.
I prefer React too, but I don't think a front end framework monoculture is a good thing so I hope that Vue, React, Aurelia, Ember, and others continue to grow.
Vue's component separation of HTML/JavaScript/CSS just clicks better for me.
Would you object to things like unobtrusive javascript?
Things like unobtrusive javascript came to be because people recognized early on that HTML was not enoug for writing applications -- that you needed something more. Since basically the entire world has come to embrace unobtrusive javascript, it isn't a logical leap to embrace JSX.
https://medium.freecodecamp.org/react-s-jsx-the-other-side-o...
Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.
That's an entirely different discussion than what the parent was discussing though. This is about those cases where you're not building a static website.
"HTML was not enoug for writing applications"
That's not what it is anymore. It has evolved into a general, distributed computing and communications platform. More and more uses of this platform require doing things that involve customized behaviors, not just the built-in features for displaying articles, so more and more people leave JS enabled. Kids who couldn't have afforded a family PC and MS Office now have a Chromebook at school (and maybe at home) and free Google Docs. And how many people whose only internet access device is a phone turn JS off in their phone?
I think it makes more sense now to treat the JS-disabled, article-browsing case as the exception. If I were trying to distribute public health articles as widely as possible, I would try to limit them to simple text, small photos, no JS, nothing that wouldn't have worked 20 years ago. And even for less-critical articles, if they were just simple articles, I'm still inclined to leave out the JavaScript in most cases for the sake of simplicity, reliability, reach, and archival robustness.
But for general purpose today, most developers in the developed world can assume JS is going to be enabled by the market they want to target.
In the author's conclusion he states, "JSX isn’t revolutionary. It’s evolutionary. Like most forms of evolution, it’s a clear improvement."
I will concede the author's point that React & JSX are better than the jQuery spaghetti that came before and is therefore an improvement. As the comparison here is to that of evolution which is superior the shark or the tiger? With evolution many things will evolve out of those things that came before and the strong will survive. Vue and React are both evolutions of what came before; time will tell which, if either, survives.
> PHP + jQuery applications.
As much as people like to detract, Wordpress and friends power a significant portion of the web. The PHP market is pretty big.
Yeah, as a C++ dev, I skip all of the front-end, back-end and "full-stack" jobs... :(
Oh well. I'm glad it's providing value to people. I might just never understand.
Because I keep seeing folks extolling the virtues of Vue, but when I went and used it I simply found little to nothing of merit compared to existing solutions.
I'm not running around telling folks what to use here, but rather stating my experiences. Perhaps someone might come along and provide a reasonable explanation of how I misunderstood something or a problem it solves better than existing frameworks but all I get is "I look it and you don't so meh."
In short, I'm trying to spur a technical discussion here but all I get in return is fanboyism and folks trying to shut down the conversation.
> but the author didn't really criticize React in any way
Actually, the author criticized React both in direct and indirect ways. He also made incorrect and or misleading claims. Of course the author also goes on the mention that he or she is inexperienced with React but somehow still feels qualified to make those claims.
Sorry for trying to add to the discussion and not just posting "Oh gee, I sure do love Vue too!"
> but I don't think a front end framework monoculture is a good thing
Neither do I.
The other thing that React does is encourages top-down propagation of immutable data, which nicely fits ClojureScript and other FP languages. Is this approach equally efficient in Vue?
Lastly, when I looked at view, it had a lot of sort of OO stuff happening in the docs, which doesn't map very nicely to ClojureScript and friends.
Do you have any docs / blog posts on programming in Vue with pure JS (no templates or magic) and in a functional way? If so, I'd love to read them. I may spend a weekend trying to put a ClojureScript layer on top of Vue.
After Angular 1/2, React, Riot I ended up there. It conforms to my principle of least surprise, and principle of least new ontologies. In the world of transient JS world, it's the best thing that happened.
Hope every other front end framework disappears and the whole world settles on Vue.
Any particular reason that you prefer Vue over Angular seeing as you have had experience of both?
That's not to say that I haven't shot myself in the foot dozens of times in the process though. We've had to solve a lot of pain points from our original 0.12 code (two-way binding, too many props in components, some jquery dotted in, lots and lots of pre es6 code). But even sitting on code I wrote that looking back makes me cringe, Vue is always enjoyable.
It has truly improved my daily quality of life and I owe Evan You a lot of gratitude.
A few month later I got myself a smartwatch besides most of the work was getting around the tizen framework I made my own watchface in Vue - and this was/is a pure joy. http://wecoso.org/~mit/stuff/myClaw/
I feel most vue lovers don't care about static typing.
https://github.com/vuejs/roadmap/blob/master/README.md
Having learned with react, I think the component structure and updating are wonderful. But the baggage of the React ecosystem made it tedious to add to projects. What if I don't want to use webpack and npm and babel?
As this author notes, Vue just drops in and works.
I can use it in existing projects. I can use it in experiments. I can use it with my PHP projects. I can use it without a server to compile anything.
It's been a pleasant experience and the tools I've built with it have been refreshingly stable.
You may want to look at Parcel, which gets you most of the Babel/Webpack benefits (minification, ES6 syntax, using image files as imports in JS, etc) in a way that "just works".
...and that's it, if you're not doing anything really weird.You don't have to use those if you use React. It can be as simple as including a script tag in your HTML and be done with it.
React lacked crucial functionality and it felt like I had to rebuild basic functions everytime e.g. a simple input field which communicates its value through setState. In Vue, you just use v-model, but in React you have to add an onchange handler which just feels very low-level - I just don't want to operate on this low level, the framework is allowed to make assumptions e.g. for checkboxes to make my life easier (i.e. grouping all checked inputs with the same v-model name into an array). Another thing I don't like is that JSX is not very good-looking e.g. if I want to add an "if", I need to use the ternary operator in complex components. This is just a hacky way and not very descriptive IMO.
And Angular was awful with its $scope and felt so dirty (it used dirty checking, that's probably why). The new version is ok, but Vue has all the same concepts but wrapped up in a nicer interface. I don't even understand what the ng team tried to achieve with their difficult to read templating language. Looks awful and feels complicated compared to Vue's simple constructs (mainly v-model, v-for, v-if and v-show and v-on, v-bind and ref) - you can learn to write Vue templates in 20 minutes.
The core concepts are reduced to their essentials and it really shines. React is too basic IMO and Angular tried too much with all that controller, service, ... stuff. It was too complicated.
Vue is basically what Web components (using .vue files) should be: Small modules with HTML, style and JS code. And a very nice API and a great developer behind it (so it has all the nice things: vdom, custom rendering e.g. for JSX support, a webpack loader, ...).
Overall, it's the greatest thing I've seen since Ember (and it's much better and more flexible than that).
I think that specifically in the case of Vue, this hurts more because of the philosophy highlighted in the article- to not stand in the way of experienced developers who know what they're doing.
(Edit: oh no, please don't come with the downvote train. This is a real issue, when you have something that solves 99% of your problems but you can't get it to 100%.)
What you want is achievable with the existing async feature, except you either need to 1) keep a list of component names up to date, or 2) use a special component like `<dynamic-loader>` instead of the component tag directly. Neither is a deal breaker, nor enough to warrant introducing a duplicate API; it's rare that you'd be using advanced features like async components while lacking a build process.
Evan's first answer wasn't the most friendly but you also come out as very combative in those messages - as reinforced by your suggestion here that the 'merit of the change wasn't even considered'. Maybe there is some middle ground to be found, an alternate proposal, but I find it extremely unlikely anything will come out of this discussion using this tone. Humility is a must even for experienced developers.
[1] https://vuejs.org/v2/guide/components-dynamic-async.html#Asy...
It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components.
But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue.
I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.
1:https://github.com/vuejs/vuex/pull/1121
Look no further than these comments. As always it's a mix of, "I tried React and hated it, then I tried Vue and loved it!" or visa versa.
Metrics such as "I understood it immediately" or "it didn't feel right to me" are shallow and meaningless.
Fact is, React and Vue are increasingly similar. So why these types of articles make the front-page once a week is beyond me.
This one? The article barely makes a comparison with React, and when it does it emphasizes their similarities.
What is weird to me is that lot of people seem to insist that there are major (sometimes deal-breaking) differences between them, when even core developers of both frameworks agree that they are more similar than different.
While Vue is obviously a kick-starter to frontend programming that makes templating easy and unix-y light, I still have few complaints. First, it is not obvious or easy to start with components. Separate files, build ecosystem, props handling, all this. What I want is to reference ‘that last place’ in html and have a copy of that template right here that would capture props like un-hygienic macros of C would do. Iow, my style of small apps doesn’t map well to heavy isolated-component based style of thinking. I don’t want to wash my hands every five minutes when I’m at home.
Second, vue forces you to be fully contained in .data and .methods. I would like to bind to any data and function roots, including window itself, but it’s obviously a bad idea to pass window to vue vm for now. But still, it would be nice to forget that vue exists at all at the source level and have just a bunch of vars, functions and [3rd-party] modules at global level and that’s it. Now I have to export methods to vue by hand and to have all the state pre-defined, as if it wasn’t clear how my state is structured from {{these expressions}} alone. I often find that something doesn’t show because I forgot to init data.key = { k2: “” }.
Third, you cannot ‘chroot’ without making a component. Would be nice to write something like <template v-with=‘client.contacts’> and then reference ‘phone’, ‘address’, etc without a prefix. With copy-style described above it would replace the need for components for me for ages, even if I meet that need.
Still my jquery experiments can’t beat vue in simplicity, though I hope some day I’ll get rid of vue too (due to points I listed, not because it’s bad). But de wae still has to be found yet.
I can appreciate that the author loves Vue.js but I don't think its very constructive have such a binary view of something they clearly haven't spent much time with. Angular is not "over-engineered". Its complete. Its got everything you need and an established, well documented pattern to do it. Its far from perfect but then what is? I've used it, React, Angular 1.x etc and all of them have their strengths and weaknesses. It depends on your team and what you are trying to do.
Its important to remember all these frameworks are built by people just like us who try very hard to make them the best they can be. It would be nice if we spent more time celebrating all the wonderful FREE tools they build for us rather than tearing down the ones that we didn't pick.
I'll take composition over inheritance in my tooling.
(1) The angular compiler doesn't have the same JS or CLI interface as the TypeScript compiler. I have to know very specifically which I am using when; my build tooling must always know whether it's compiling TS the Angular way, or the vanilla way, and there isn't much commonality.
(2) What if I want to use an alternative TS compiler? Or someone writes a faster one in Go? Or I want to use tsickle [1], which is Closure Compiler-compatible?
Now it turns out there isn't a TS compiler in Go, and the Angular team are the authors of tsickle, and so ngc happens to work with it. But it's an architectural smell to couple that closely for my MVC framework (and IMO with little necessity).
[1] https://github.com/angular/tsickle
Now to read the many mentions of react in the comments even though the article has nothing to do with it.