10 ms·
Why Choose Vue.js
- pyedpiper 9y agotaking frontend framework advice from a website that is arguably uglier and more poorly laid out than the bulk of geocities pages is a tough pill to swallow.
- jgalvez 9y agoAside from the Jakob Nielsen-y vibe to the color scheme (intentional), it's not that much different than any other developer blog out there -- but if that's the angle you want to take to discredit what I am saying, fine.
- devmunchies 9y ago> if that's the angle you want to take I don't think its some "angle" out of left field. Its a valid point.
- jgalvez 9y agoWell, to be frank, I honestly don't know what to think. I've had people telling me it looks great, people telling me it looks awful -- it does look amazing to me: http://imgur.com/a/yMTz8 http://imgur.com/a/yMTz8 Having said that, I'll definitely work out a update that's readable to wider audience.
- avarun 9y agoSorry, but that's really ugly.
- nickthemagicman 9y agoIt's not that ugly. The layout is ok, the typography is fine. It's just that yellow color that's not the best. As far as the rest it's fine.
- jgalvez 9y agoI've since updated the color scheme.
- Shorel 9y agoMay be developers should standarize in Jekyll for our blogs. Not that I think it is an important issue or anything. I read everything via Pocket.
- Exuma 9y agoThis color scheme gives me extreme anxiety... good article though.
- vyrotek 9y agoWe love Vue at our company. I'm personally a fan of how Vue separates and handles templates. That said, it was a bit difficult to read this article on a fullscreen monitor since it's aligned to the far right.
- wintorez 9y agoI was very interested in Vue.js initially, but I had to pass once I realized it uses two-way data-binding. I prefer React.js since it has less behind the scene magic than Vue.js or Angular. Although I like certain aspects of Vue.js which I think React could learn from.
- badthingfactory 9y agoI'm not sure I understand rejecting a library because it allows two-way binding. If two-way binding doesn't work for some control, nothing is stopping you from falling back to one-way binding.
- Klathmon 9y agoThere's something to be said about staying as close to the "intended" way of doing things as possible with libraries. Yeah, you might be able to stick with one way binding, but anything that interacts with vue will most likely expect 2 way binding, as well as most learning resources. Updates and improvements will be made with 2 way binding in mind, and you won't have nearly as many "coded with vue in mind" tools or libraries to use. It's possible, and it might actually work out just fine. But in my experience going "against the grain" with libraries only leads to pain.
- outsidetheparty 9y agoI really haven't found this to be the case. One-way data binding is the default for just about everything in Vue; the only exception is v-model which is generally used only for form fields or similar elements where two-way binding makes sense -- two-way binding is definitely not pervasive throughout the framework as in Angular. Apps of any complexity tend to use vuex (which is a sort-of-flux-like data store) for state management.
- Klathmon 9y agoWell then it seems I'm horribly wrong here! I haven't really used Vue (only angular) and I made a bad assumption, but my point still stands in a more general form.
- graysonk 9y agoLove the article! But wow this site hurts my eyes. Yellow and red font on a black background aligned very far right?
- jgalvez 9y agoThank you! It looks great here but I'll keep that in mind.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- mikewhy 9y agoIt looks like content is cut off no matter how I view the page: http://imgur.com/a/hqsli http://imgur.com/a/hqsli
- Posibyte 9y agoSo you can see it: http://i.imgur.com/vphYLVa.png http://i.imgur.com/vphYLVa.png The columns aren't lining up properly and the bold yellow is pulling my eyes away pretty harshly.
- apocalyptic0n3 9y agoJust to add my voice to this, I read about 3 sentences before closing the tab. That is extremely difficult to read. Also seeing issues with the right column overlapping the left
- jgalvez 9y agoJeez, CSS is hard :) Thanks guys, I'll get on fixing this.
- Marinlemaignan 9y ago
- murukesh_s 9y agoRemarkable that Vue.js (Single dev) is holding up well against React. I was recommending Vue.js to others while react was the craze. It somehow felt more cleaner to me and the performance, if I am not wrong was on par or better than React.
- desdiv 9y agoVue.js is heavily backed by Alibaba, the 7th biggest tech company in the world by market cap.
- murukesh_s 9y agoI thought Evan was funded solely through patreon.
- jgalvez 9y agoIsn't Weex that's backed?
- lightblade 9y agoI like to see some evidence of this claim. Certainly Alibaba.com is not built with Vue.
- bdcravens 9y agohttps://medium.com/the-vue-point/the-state-of-vue-1655e10a340a https://medium.com/the-vue-point/the-state-of-vue-1655e10a34... Doesn't say anything about being sponsored by Alibaba, but Evan does indicate adoption there.
- lightblade 9y agoThat's the thing. All claims of Alibaba's adoption of Vue comes from the author himself. I think it's reasonable to have doubt. I'm sure they use it. But to claim that they heavily invest in it may be exaggerated.
- linkmotif 9y agoI really don't get how separating templates is a good thing. Been there, done that. Not going back. Not going back to separate CSS either. Because having everything together is great. Not to mention using JS for render logic. That's great too. It's what I always wanted. People kept pushing "best practices" on me—like not using the style attribute, separating templates—and I am so grateful for the people at Facebook for ending that. Like most articles about Vue.js—and I keep looking because I keep wanting to understand the appeal—there's never a clear explanation regarding why separating templates and not using JS for render logic is good. Maybe it's a matter of taste. For me, having everything about a component in one place is very convenient and simplifies abstraction and composability. Maybe I just need to try Vue.js to understand the draw. That was true for me with React. But React was a totally new paradigm for me. Vue.js seems like a combination of several familiar paradigms in a way that doesn't really make sense having gone React.
- cjalmeida 9y agoMy experience is that the HTML CSS experts can more easily understand Vue components. So going back and forth between dev and UX is simpler with Vue.
- jgalvez 9y agohttps://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html
- outsidetheparty 9y agoVue components have the html template, the javascript code, and the component's scoped CSS all in one file. You can define the template in a string, or even in JSX if for some reason you wanted to do that, or you can just use regular old HTML which is stored alongside the javascript that controls it and the css that styles it.
- deleted 9y ago[deleted]
- nkg 9y ago
- sjroot 9y agoI embraced Vue after making multiple attempts to digest the React platform with little success. I have found that Vue's templating system and APIs have brought so much clarity to the complex projects that I set out to build, and would highly recommend it to anyone. It is my hope that React may learn from some of Vue's triumphs.
- nkg 9y agoI initiated the adoption of Vue.js in our agency about a year ago and we never had to regret it. One positive aspect that I didn't expect is that the architecture of Vuejs apps kind of forces you to write cleaner code: methods, states, mutations, every piece has its own place.
- luketheobscure 9y agoAlmost all of his arguments are also true for Ember.js, with the notable exception of compatibility with "web components" (but there's Glimmer for that).
- sebringj 9y ago"no need to bind methods", that's true but just letting you know its not a thing if you use es6 arrow functions. class SomeClass extends React { someMethod = () => { // already bound } }
- acemarke 9y agoTo be clear, that's not just an ES6 arrow function. That example relies on the Stage 2 Class Properties syntax, which currently requires a Babel plugin. Now, the React team does recommend using that syntax as a viable option, but it's not yet implemented in browsers, and _might_ still change down the road.
- sebringj 9y agointeresting point. that reminds me of the "..." syntax on object properties that isn't supported on es6 for objects but still is a pretty sweet feature.
- acemarke 9y agoThat one's a lot closer to being finalized. Object Rest/Spread is currently at Stage 3, and is already implemented in Chrome/V8. For reference on proposal status and details, see https://github.com/tc39/proposals https://github.com/tc39/proposals .
- StreamBright 9y agoIs this a CSS joke that backend people won't get? Or why does this site look like a 90s parody of web standards? I am not sure if I can take him seriously over which JS framework to use just by judging on his site.
- Brockenstein 9y agoSince when does expertise in javascript have anything to do with design? The site is simple, why does it need to be more complex or flashy for you to take it seriously?
- invalid_ 9y ago"specialising in UI/UX work with both React and Vue".. "rare occasions I needed to write javascript in the past 5 years".. Hmmm
- jgalvez 9y agoWell, that's not entirely accurate if you're going to be nitpicky about it. I did work on a multitude of frontend projects in the same period (http://linkedin.com/in/jonasgalvez http://linkedin.com/in/jonasgalvez), just took me a while to consider updating my toolset (which was my point).
- deleted 9y ago[deleted]
- QuotesDante 9y agoThis guy really ought to read [Practical Typography](http://practicaltypography.com/ http://practicaltypography.com/).
- lytedev 9y agoWhy is this site's content off-center...? 1920x1080 desktop on Chrome. Is that slightly ironic?
- lapsock 9y agoweb development is such a retarded mess its really amazing how much effort is spent on building the same CRUD apps over and over again
- eduren 9y agoThen why don't you build that one CRUD app and sell it to everybody? That's gotta be worth all the money being paid to develop duplicate apps. If I were you, I'd delete this comment before anybody steals the idea.
- LeoNatan25 9y agoTheir constant jump from one framework to another is simply hilarious. PHP! Yuck; jQuery! Eww, Ruby on Rails! Yawza; Angular! Err, React! Nope; Vue. And all that (and much more), in, what, 10 years? Meanwhile, proper software development has had frameworks that last for decades.
- acemarke 9y agoTell that to the developer communities for Microsoft, Apple, and Linux. Quick, should I develop a new Windows GUI app using Win32, MFC, ATL, WTL, WinForms, WPF, or UWP? Which of the five million flavors of .NET am I supposed to be using right now? Should I be developing Mac/iOS apps using Cocoa or Carbon, and writing them in Objective-C or Swift? What about Qt (or KDE's variations) vs Gtk, and use of Mono or Vala? Yes, I'm somewhat deliberately conflating languages and libs there, but my point is that while the web dev world has certainly been churning quickly, there's also been tons of churn on the desktop and backend development fronts as well.
- LeoNatan25 9y agoThe churn you are conflating is over a period of decades for almost each mentioned, whereas here, the turnaround of frameworks is a year to two.
- cat199 9y agoHad a similar opinion until dusting off my browser for some front end work recently.. Browsers being roughly standards compliant, and those standards congealing is a relatively new thing (last 10 years), having this happens facillitates alot of browser-side dev (e.g. JS) which simply wasn't possible before, throw in the growth of mobile/tablet UI's, and server side javascript, and the shift from 'CGI extensions' into web-native applications where the browser is the GUI and the 'web server' is really the 'application server', and the appropriate paradigms to deal with this change rapidly.. the frameworks have changed because the underlying platform and its use is rapidly evolving. I think if you look at GUI toolkits early on as the desktop evolved and you'll find a similarly chaotic and changing picture (e.g. Cocoa is not MacOS v1; WinNT is not Windows 1.0, and neither are dosshell, etc)
- deleted 9y ago[deleted]
- terenceng2010 9y agoUsing vue without webpack or any build process becomes a maintenance issue when you got dozens of x-template in a single html file.
- jgalvez 9y agoI thought it was implied that using Webpack eliminates the need for said inline templates. Should have made it clearer.
- deleted 9y ago[deleted]
- attrezzarturo 9y agoJSX being transformed into JS allows you to test your logic (minus brower/acceptance testing) in node, even if you load css and do weird stuff with webpack. I am not looking at anything else until that is true for <put your backbone/angular evolution here>.
- ramses0 9y agoTake a look at this example of relatively complicated component-tests w/ markojs. It is an example of testing a transcluded component's variation (arguably very valuable and complicated to test) and all the code, setup, tests, etc. are very straightforward to understand. https://github.com/marko-js/marko/blob/master/test/autotests/components-browser/transclusion-body-slot-tag/test.js https://github.com/marko-js/marko/blob/master/test/autotests...
- yavi 9y agoI've used Vue.js in projects for the better part of a year now and have enjoyed it, for the most part. It's easier to grasp, is very usable right out of the box without any build tools, and the documentation is solid. I've mostly used vanilla Vue without Vuex or other dedicated state management (so I can't speak well to how that would improve the experience), but my gripes with it so far have mostly been: - Less explicit behavior leads to more magic. There are few if any 'gotchas' with the React component lifecycle. If state changes in the component or in its ancestry, React will re-render unless you explicitly tell it not to, every time. There's a performance trade-off to this, but for most applications it's not a problem, and you can handle it explicitly. By contrast, Vue decides when to update components, and its algorithm works perfectly 95% of the time. The other 5% of the time I find myself writing workarounds with watchers, and it's a frustrating experience. Additionally, while Vue 2 got rid of many magic variables, there are still a few that can lead to confusing behavior. For example, the magic variable '$event' for emitted event data is needed only when the event handler uses other variables too - otherwise it's included for you automatically. It's convenient, sure, but I've seen more than a few developers get tripped up by the ergonomics of Vue's magic. There are also a number of gotchas around handling reactivity in arrays. - Size of community. While the community is certainly existent and growing, you're still far more likely to find what you're looking for in the React community. Additionally, much of what exists for Vue is written for the Chinese community, which sometimes means less-than-ideal English documentation. This should change over time but it's something to consider in the present. - Everything in Vue is reactive, which has added some real performance overhead for us in some pathological cases. - This is purely personal preference, but I've never been quite sold on extensions to HTML for templating. It might be a bias from working with React but I prefer HTML-in-JS to JS-in-HTML. As for the points the article brought up: - Explicitly bound methods: Sure, but this isn't a React thing, that's how ES6 classes work. If the extra line or two per method is that troubling React.createClass() inserts all that magical binding for you. - State management: I don't really find setState all that difficult to use. By contrast, Vue requires that all class properties for the component be setup initially. If you decide to add one later, Vue will simply ignore it unless you use Vue.$set() to register the property as a reactive one. - Mixins: This is certainly a controversial topic, but I tend to agree with the React team, at least when it comes to larger codebases: https://facebook.github.io/react/blog/2016/07/13/mixins-considered-harmful.html https://facebook.github.io/react/blog/2016/07/13/mixins-cons... . Mixin-like functionality is possible with either library, regardless. - Templating: I don't find the overhead of either JSX or Vue templates to be problematic after spending a day or two with either. My experience has been that developers with a background in Angular gravitate towards Vue templates as they have a similar DSL. The biggest differences to me seem to be that Vue templates are slightly easier to read while React templates offer the full flexibility of JS. Don't let any of this detract you from Vue - I've enjoyed using it and would recommend giving it a shot. Despite the caveats I've encountered with it there's certainly good reason for its recent popularity!
- isaac739 9y ago"if the main application code is under 1000 lines, keep it in a single file" NOPE. I like .vue because you can easily avoid large files.
- scyclow 9y agoThe two tabs on your website overlap on my 15" screen. I think you might need to do .left { left: 100px } instead of .left { right: 740px }
- jgalvez 9y agoFixed that with right: 55%, thanks.
- ausjke 9y agoSo, I was told to separate html, css and js into different files and such, now web components, vuejs are saying no let us mix three into one component instead. IMHO, too much abstraction kills productivity, I am choosing vuejs and polymer for future projects, yes I like to mix html/css/js together and make them components for reuse.
- dmix 9y agoThis site doesn't render properly for me on latest Chrome (dev) on Linux. http://imgur.com/a/umXXB http://imgur.com/a/umXXB
- jgalvez 9y agoAlright guys, updated stylesheet and color scheme due to popular demand :)
- mpalmer 9y ago> In React, you need to use the setState() to trigger rendering updates as you modify the state. In Vue, you simply assign things to this and, if necessary, the component's automatically rerendered. You do need to provide an initial state (data) for safety. Hoo boy. "Simply" assign directly to `this`! This may come down to preference for/against functional tools, but on this point Vue loses big for me. Seems way less testable...
- Can_Not 9y agoYou can still use vuex for the flux experience.
- ajoy 9y agoPreviously used Vue and switched back to React. I have a few gripes about Vue for larger projects. Most have to do with a lack of 'namespacing' or ability to isolate functions. 1. Plugins - Eg. Recently VueResource plugin was deprecated, but i had a hard time finding out where all the plugin was being used. The dependencies were hard to figure out. 2. Functions introduced in Plugins added to a parent component are inherited in all the child components' 'namespace'. It was hard for me to determine if a function that I am writing has a naming conflict with a plugin function, until runtime. 3. Since this dependency is not obvious, a new dev looking at a piece of code that is using some functionality inserted by a plugin, needs to be aware of all plugins that have been interjected at any of it’s parent level components and the functions they introduce. 4. Mixins help with re-use code, but can lead to potential function naming conflicts. Maybe I was doing things wrongly w/ Vue. If so, any recommendations are welcome.
- nickthemagicman 9y agoI think Front End development is so insane because Front End dev is chained to the browser and javascript/css implementation by the browser makers. With web assembly, hopefully browser developers can separate from making languages and instead make language targets. Then the separately developed language can stay stable while its underlying implementation can adapt to the dumb browser madness. Then we can have some sanity in web development. It's what we are trying to do now with all the maddening layers of transpilation.