10 ms·
Love letter to Vue
- shadykiller 8y agoI've never worked with Vue on a full scale project but I loved the simplicity and the great documentation. would love to use it soon.
- krat0sprakhar 8y agoOne 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? [0] - https://material.angular.io/ https://material.angular.io/ [1] - https://material.angular.io/components/categories https://material.angular.io/components/categories
- ceejayoz 8y agoThere are a number of Material libraries for Vue (https://vuematerial.io/ https://vuematerial.io/, https://vuetifyjs.com/en/ https://vuetifyjs.com/en/, etc.). Not sure they'll ever quite match Angular's, given the relationship to Google.
- irrational 8y agohttps://vuematerial.io/ https://vuematerial.io/ https://vuetifyjs.com/en/ https://vuetifyjs.com/en/ (I prefer vuetify)
- gnclmorais 8y agoThis one is pretty cool as well: http://element.eleme.io http://element.eleme.io
- gremlinsinc 8y agoseconded. This is a breeze to work with.
- joshschreuder 8y agoI 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
- irrational 8y agoDo you mean like this? https://vuetifyjs.com/en/guides/a-la-carte https://vuetifyjs.com/en/guides/a-la-carte
- joshschreuder 8y agoExactly like that :) 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!
- noir_lord 8y agoVuetify possibly thought unlike material.angular.io it's not supported directly by the framework creators. Not sure if that's a negative or not.
- Tade0 8y agoI 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.
- noir_lord 8y agoInteresting, I mostly just use Bootstrap 4 (internal enterprise application so the massive adoption and long release cycles help there).
- lowry 8y agoAnything 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.
- Tade0 8y ago> Minimal CSS frameworks like Picnic CSS are the only way to go. 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.
- jpmoyn 8y agoAll of the major front end frameworks have the same thing
- gremlinsinc 8y agoI like Element a LOT. See: http://element.eleme.io/#/en-US/component/installation http://element.eleme.io/#/en-US/component/installation
- deweller 8y agoI 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.
- MentallyRetired 8y agoI'm in the same boat. Professional React dev, but at home I use Vue. Soon as the job market picks up, I'm there. No ragrets.
- geist 8y agoI'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.
- k__ 8y agoTo me it was the other way around. Vue felt like a subset of Ember. React did something completly new.
- jgalentine007 8y agoSame.Vue-class-component makes for some really clean looking code.
- duhi88 8y agoVue 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.
- mieseratte 8y agoHaving 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.
- pjmlp 8y agoI rather just do plain WebComponents, but we are still a bit far from having them supported everywhere.
- crooked-v 8y agoFor 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.
- diminish 8y agoI love 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.
- Fifer82 8y agoI actually don't use projects that aren't authored in TypeScript these days, I am looking forward to their rewrite. Any particular reason that you prefer Vue over Angular seeing as you have had experience of both?
- MattyRad 8y agoWe'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.
- entropie 8y agoI 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/ http://wecoso.org/~mit/stuff/myClaw/
- mvolkmann 8y agoIf 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.
- abalashov 8y agoThat is definitely true.
- crooked-v 8y agoI 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.
- balfirevic 8y agoI use watchers as a last resort in Vue. It's possible and common to program in Vue using very functional style.
- scardine 8y agoI like business logic in JavaScript and presentation logic in templates - for me Vue fits the bill.
- RpFLCL 8y agoI couldn't be more thrilled with vue. 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.
- crooked-v 8y ago> 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.
- woah 8y agoI’ve found parcel to be very buggy
- oreganoz 8y ago> What if I don't want to use webpack and npm and babel? 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.
- constantlm 8y agoAfter 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.
- k__ 8y agoYes, Vue is basically the components of Ember, without the MVC stuff.
- mockingbirdy 8y agoI'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).
- lowry 8y agoThis 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.
- flabbergast 8y agoThis 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.
- papito 8y agoKnockout JS FOR LIFE!
- tflanitzer 8y agoI 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.
- rhengles 8y agoEvan, 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-385367128 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%.)
- ricardobeat 8y agoThis 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. [1] https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components https://vuejs.org/v2/guide/components-dynamic-async.html#Asy...
- rhengles 8y agoThank 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.
- gravity_123 8y agoHuge 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. 1:https://github.com/vuejs/vuex/pull/1121 https://github.com/vuejs/vuex/pull/1121
- dylanhassinger 8y agoI love Vue! :) best framework ever
- vinceguidry 8y agoAfter 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.
- inspector14 8y agoi 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.
- vinceguidry 8y agoRecently 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.
- meowface 8y agoThat'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.
- vinceguidry 8y agoIt 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.
- NathanCH 8y agoI wonder if there has ever been an article on Vue where both the article and comments aren't a direct comparison to React. 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.
- balfirevic 8y ago> I wonder if there has ever been an article on Vue where both the article and comments aren't a direct comparison to React. This one? The article barely makes a comparison with React, and when it does it emphasizes their similarities.
- zmmmmm 8y agoIt 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.
- balfirevic 8y agoIsn'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.
- wruza 8y agoLong-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.
- vikingcaffiene 8y ago> 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.
- paulddraper 8y agoI'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.
- vikingcaffiene 8y agoI 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.
- paulddraper 8y agoIt'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). [1] https://github.com/angular/tsickle https://github.com/angular/tsickle
- luord 8y agoPretty similar to my experience. Agree on everything. Now to read the many mentions of react in the comments even though the article has nothing to do with it.