I 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.
I'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.
There'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.
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.
Well 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.
Oh, I totally agree with you -- I'm an Angular refugee myself. I'm genuinely surprised by how many people in this discussion seem to have such wildly incorrect impressions of what Vue is like.
I would say it's more like purchasing a standard transmission instead of a semi-automatic transmission because a standard transmission gives you better control on slippery roads.
Ever bad language feature gets used eventually. This is doubly true for frameworks where not only are bad features used, but also unintended and hidden features. Even if I know when to avoid 2-way binding, there is a high likelihood that someone else does not or does know, but adds a TODO because they "didn't have the time" to do it right.
In my view, the best solution is to (as far as possible) eliminate questionable features from the framework and enforce good practices.
I'm not the guy you asked, but for me it's not that 2 way binding is bad, it's that one way binding is better.
Using one-way binding you get a very clear picture of how data flows through the components. Components pass data to their children via props, and get data back from the children via callbacks. It forces you to be more explicit with how things are working.
With 2 way binding, you don't have any guarantees that the child won't be modifying what you pass in, and in many cases i've found that it's difficult to see which direction data is flowing just by looking at the component.
If your component had a property named "value", is it the component filling that in and passing it to the parent? is it the parent passing the value to the child? With 1-way binding you know value is being passed "down" to the child, and a property named something like "onChange" will be the callback that it uses to pass data back "up".
And again I do want to stress that two-way binding isn't necessarily bad in my opinion, it just doesn't "require" the explicitness that one way binding does. I have seen 2-way binding work wonderfully when used with some strict guidelines or with external tools that can enforce some of that explicitness. And it can have it's benefits! 2-way data binding is often simpler, and can be faster than one way binding (it's really just a fancy term for "pass by reference").
FYI, Two-way binding in VueJS isn't about parent-child communication. It's about binding to input fields and other interactive HTML elements:
"You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases."
So... I think the term "two-way binding" is overloaded here, and paints an improper picture of what VueJS is actually about.
Vue is really interesting, but feels like it's retreading some of the missteps of frameworks past.
I worked with knockout extensively on an inherited codebase a few years ago and my overriding opinion was that 2 way binding sacrifices everything for convenience.
Everything? Here is what the recommended use of two-way binding does in VueJS:
"You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases."
Seems like a very specific, deliberate functionality. Changing a value of a reference from a parent component, however, is advised against and is probably what you're referring to.
IMO, that's the beauty of Vue data binding. It will work as you'd expect for the majority of cases (ie. simple form binding) without the boilerplate and shooting you in the foot.
One thing I'll mention is that even though Vue.js has more "magic" than React, its implementation is substantially smaller in size than React. I guess its centralized nature (one major developer) plays a role in this.
React is backed by the Facebook engineering team, which is both good and bad -- a group is a bug with a brain on each leg. I think for this reason it's burdened with a noticeable measure of over-engineering.
It's mostly because React does more behind the scenes. You can argue if it should do more but it is doing a lot more stuff than Vue, it's not simply bloat.
Questioning the utility of that stuff is quite reasonable however.
Two-way data binding is only syntactic sugar for setting value as a property and assigning it's value on event listener. You can read about it in the docs
Except it has a drastic effect on the architecture and data flow of your application (which some believe to be detrimental). I think this is more what the OP was alluding to.
No, in Vue.js it really doesn't have any drastic effect - or almost any effect on what you would call "architecture".
I have to ask - are you just talking abstractly about two way data binding or specifically as implemented in Vue.js?
I was speaking more generally but yes, even in Vue.js it does. It's impossible to escape for any data-binding system.
The reason is that "effects", "data modifications", or whatever you want to call them are now local and appear everywhere. As your application grows it becomes harder and harder to know where and how your data model is updated.
This becomes especially apparent as you introduce more complicated workflows where you can't update a single value of state at a time but instead would like to treat it as a transaction.
It can also appear when dealing with computed/derived state.
Two-way data binding is fine for a simple form of 5 values. But once you start trying to build a larger application the desire for a top-down data flow and isolated state modifications becomes very apparent.
It's not an attack on Vue.js, as you have options like veux. I'm merely stating that there are very large disadvantages to two-way databinding itself.
I'm having a hard time reconciling what you're describing with the Vue.js development experience. I have lot of experience with Angula so I understand what you're saying.
But in Vue, two way data binding is _very_ local. It doesn't appear everywhere, on the contrary. It's barely worth mentioning when describing how development works. Honestly, this whole debate just seems weird - take away two-way data binding from Vue.js and at most you'd get several sighs from developers as they change few form-handling lines of code.
You mistake 2way data binding with ui decomposition and right view model structure, if you have those problems.
With the right view models everything becomes is easy and simple, but you do not get there right away, it's hard to learn, and no framework will bring you there.
This is due to ppl spending way to much time chasing frameworks in vogue, than learn to architect applications.
I love vue btw.
There always seems to be misunderstanding about this - Vue only does "2 way binding" for local state within the component, and is purely syntactic sugar around you coding a setter/getter yourself. That's all it is.
Any cross-component communication is done with events/mutations/actions, ideally with a central state store.
This offers the perfect mix of readable, understandable, composable, testable state architecture without the constant verbosity of binding everything yourself.
In vuejs, two-way data binding is an optional feature, it's not a default and it's usage is not encouraged for beginners who aren't sure if they should use it.
If i may..?
The equally symetrical layout is hard to read, you should rather use an one third - two thirds layout, or about.
Then i'd try something like #FFF1CA for the left hand column, so it looks like the text (i know they right now are the exact same color but one being surrounded by black making it look lighter).
Also, maybe increasing the padding up of the right col up to a 100px would prevent eyes from being lost between both columns when jumping lines.
Overall contrast is way too high.
Hope that helps.
Hey jgalvez, I wanted to come back a few days later to check this out. I love the article, which I didn't mention, but I also think this format looks a LOT nicer. Thank you for changing it!
I actually like the yellow on black (not so much the red). There is a reason highway signs often combine yellow and black, the contrast makes it very easy to read.
I think it's the screen. It's a little painful to read and the letters around wherever I'm focusing keep sort of "dancing" and distracting me. I'm sure if this were printed with exactly the same colors it wouldn't be as distracting.
Remarkable 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.
That'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.
Yes, he has openly said he is funded through patreon. Now that the framework is super popular, he may have other sources of income, but it's not built by/for/in Alibaba afaik.
Marko components are lovely. I've used a lot of off-brand and mainstream template engines, and few have delivered on the promise of composability as cleanly and nicely.
I 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.
Vue 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.
This might not apply to the case here, where are talking about code style, but I find that in programming it is often good not to have a choice. More options means more decisions, more decisions means more complexity involved in completing a task, and it means more questions the next person reading or maintaining the code will have.
There are clear patterns in Vue that encourage you to put your filters, methods and every other piece in its place, but at the same time, depending on your deadline you can choose not to create a single-file component for every <li> and just use a <template> tag. I like that!
I understand your point, though.
But a template is not "regular old HTML". HTML is a standard for declaring marked up text. What Vue and similar libraries do is make adhoc variants of HTML (all different) with extra looping constructs and if/then constructs and so on. The templates also require embedding snippets of JavaScript code in them -- code which standard JavaScript/TypeScript IDE tools don't know about and so can't refactor, validate, or navigate.
These templates may look declarative because the look HTML-ish but they are not -- because of the embedded code that can call arbitrary functions in your application. The result is hard to debug and reason about. Where do you put a breakpoint in such a template? How do you abstract part of a template into a function? How do you add logging to such templates? How do you know what object is having its data accessed for templating languages like with Angular that do complex contextual lookups behind the scenes? How do you get code coverage reports? How do you get code completion? How do you get precise error reports? And so on. For more on why templates are a bad idea, see: https://blog.dantup.com/2014/08/you-have-ruined-html/
That is why I feel these sorts of template-based approaches will eventually be discarded as obsolete for writing single page applications as web programming continues to progress (in favor of generating UIs directly from code). HTML-ish templates feel familiar to people with experience building progressively enhanced web apps by sprinkling a bit of CSS and JavaScript on top of HTML generated from a server -- but for single-page apps that spend most of their time converting JSON from a server into HTML (or just doing stand-alone activities), a templating HTML-first approach make little sense. You just don't need extra templating machinery that you need to learn and maintain and that just gets in the way of development.
By contrast, consider the HyperScript API for generating HTML from JavaScript/TypeScript (as used in Mithril, Maquette, and optionally in Inferno and some other vdom libraries).
If you use the HyperScript approach (especially with Tachyons.css or similar), you are just writing JavaScript/TypeScript/whatever and can leverage all of the language's features. JavaScript-first for modern SPAs!
You should try tsx (typescript jsx). It is 100% first class code: autocomplete of names and attributes, type safety of attributes, unlimited mixing of tsx and JavaScript, rename refactoring, navigate to definitions, etc.
It is similar to a function based approach, but has many advantages that reduce code and increase productivity.
Here is a page of examples from me React typescript setup repo:
> These templates may look declarative because the look HTML-ish but they are not
Yes! Precisely. How many of these "regular old HTML"s I've seen and even used. Each with their own looping constructs, their own if/then constructs. The benefit, honestly, was lost on me then and is still lost on me.
React is not perfect. JavaScript is horrible. But pretend "HTML" templates are so much worse for all the reasons you describe.
I still suspect there must be something to Vue, though. So many people like it. Many of them have tried React, so I'm sure it's not like they're all ignorant to the glory of JS-based rendering. I wonder what it is.
Separating CSS always seemed stupid to me, I was so happy when it finally became "best practice" to have inline styles within isolated components. HTML is the markup and as far as I'm concerned the styling is part of that markup.
I don't understand how anyone ever thought CSS's style inheritance was a good idea. I don't mind HTML and even JS these days but CSS really needs to be sent straight back to hell where it came from.
For components, bundling the CSS makes sense. For other use cases external CSS resources with inheritance are very beneficial.See for example Scalable and Modular Architecture for CSS or any modern CSS framework for lots of examples.
Single file components are extremely common in Vue. You can also render templates with JavaScript (although from what i've seen, this is much more intuitive in React than Vue)
That doesn't solve the problem though -- you still have two sources of truth. Is this array processed in the template or the JS? Where does this crazy directive get called? How does the model get updated when you click some element? That mental back-and-forth becomes a huge pain in a big project. With JSX you never have to worry about it.
For the life of me I cannot shake the feeling that Vue is just a simpler Backbone/Marionette. React was life changing because it actually solved the problems I had as a professional I-do-this-every-day web developer. I can't feel that way about Vue.
Have you tried Vue? I had that impression too—that it's like Backbone/Marionette—but people have told me it's not. I don't think you mess with the DOM and I don't think you refer to elements except for the root, like in React.
JSX is different though -- it's sugar around a 1:1 mapping to plain old JavaScript. There's no magic behind the scenes binding variables or interpreting stringly-typed code.
I wasn't aware you could use JSX with Vue. If you do, what benefits does Vue offer?
Vue simplifies a lot of the "data propagation" from what I've seen of React. I loved React's vdom and props, but just felt the syntax for props (e.g. `.setProp({name: val})` was excessive boiler plate. Vue simplifies that aspect with reactive props and data, its just more intuitive for me than React. One big improvement is the really nice system for `computed` and `watch` properties which reactively transform data. Your templates (jsx or the default html-directives, which I prefer) can rely on `computed` properties to transform from say an Dict to a list for say a list of `li` components. It gives a nice "raw input data -> reactive data transforms -> reactive html repr` flow.
Having some designated separation of presentation and data is usually understood as a good thing.
I get that having them located in strongly separated locations increases workflow friction, but that isn't how Vue does things, and the rest of the problems you're talking about are present in any system where presentation and data have some kind of separation convention.
I'm also not convinced there where React is used to collapse the difference between the two it's actually solving problems rather than switching to a different set of problems, but then again I suppose every engineer has the right to pick which set of problems they prefer to wrestle with.
In a larger Vue application you would use a data store (ie Vuex). The only thing that can mutate the data are "mutation" methods in the data store. It is your single source of truth.
If you aren't using a data store, your parent component would solely be responsible for mutating data. If the child component needed to alter it, it would raise an event that the parent would listen to and make whatever modifications necessary.
I'm having a lot of trouble truthfully understanding your "mental back-and-forth" issue and I'm wondering if it's an inexperience with Vue issue. Give it a try... I'm willing to bet you'll love it.
Maybe using "source of truth" was bad phrasing, the question is about rendering data not the data itself. I am convinced templates are a fundamentally broken technology. In React there's only one place things happen: in the JSX. This is not true for Vue -- you have at least two discrete objects (the template and the view) communicating back and forth.
I realize this is a completely trivial example, but is this what you're getting at? Everything related to that component is in a single place. The template itself handles any UI specific logic: conditionally showing an element, looping, binding an event.
Any real logic is going to be handled from the component itself.
That said, Vue actually supports using a render function as opposed to using a template. You can even use JSX if you want (though I certainly wouldn't consider JSX a first class citizen in Vue).
But do you see the inter-dependencies between the script and the template? The template is assuming that it's provided a variable named messages and that it's an array of ready-to-display strings. And this information is stringly typed -- will your editor complain if you fail to define messages? Can I use Typescript to ensure that each message is what I expect? Sure, it's easy enough for simple examples but I've seen it fall apart quickly for large projects with multiple developers.
This kind of system is extremely common on the backend---Python's Django and Ruby on Rails, to name a few frameworks follow the practice of templates being given data and simply acting upon it.
Since these are dynamically typed languages, there's no IDE typing support in the template.
There's just testing.
As someone who uses Django regularly, I can say there's a huge swatch of territory between "small examples" and "large projects".
That territory can easily cover teams of 19, and multimillion dollar projects.
Right, it's a common technology and it's always been a pain. With React everything is well-defined and typesafe (either through PropTypes, Typescript, or Flow) and the IDE support is fantastic.
That's my whole contention -- Vue is just a better iteration of the same old painful experience. React actually solves the problems I have.
Vue has one source of truth: the data stored in each component. You bind elements in the template to that data and they get automatically re-rendered when it changes, and you bind events in the template to methods (or just ad-hoc things like @click="toggleVar = !toggleVar" for a boolean) that update that data.
This includes child components, which trigger events that you bind in the parent component.
Oh boy. Another reason why I don't like templates -- you invariably end up with magical incantations like this. Working with JSX has given me an incredible distaste for templating languages.
All bound expressions in Vue are javascript expressions. Names are typically bound on "this", which is the component instance. So the above expression is equivalent to
Yes, I agree on separation being overrated. It was probably pushed to promote teams working on UI/UX and programmers with overlap but code being on its own. In practice, developers usually modify the css from how it is done from designers as in practice, things seem to change.
You still get reuse but use it like a default export if styles are used in more than one place.
I'm in the completely opposite camp. Many small files are easier to maintain with large teams. The one caveat is the files need to be very well organized. I'm personally a fan of having a folder for each component with separate js/html/css/test files living side by side.
In general, mixing html/js/css in a single file feels really dirty to me, but that might just be PTSD from a past life where I did a bunch of work on PHP spaghetti code with no separation of concerns.
I agree. I am building a big angular 1 project right now and for every new component I make a new folder with three files - html template, sass, and javascript controller. It works the best in my opinion. Otherwise the files would just be way too big.
I like Vue because it puts style, markup, and template into the same file (single file components), but separates them in a way that's incredibly intuitive. I also love how simple Vue feels. Like it doesn't feel like it's doing any sort of dark magic under the hood, it just makes sense in a way that you can wrap your head around the entire thing in an afternoon, and that's refreshing.
Also the docs are like really really good. The Vue guide is a better experience than the official Angular tutorials (don't even get me started on the non-typescript angular documentation). They're a huge strong point for this project, especially considering how young it is.
I 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.
I 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.
Almost 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).
To 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.
interesting 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.
Is 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.
Since 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?
Well, 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), just took me a while to consider updating my toolset (which was my point).
Their 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.
Tell 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.
Had 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)
Uhm, huh?
The DOM model has not really changed at all. All those framework just purport to make some improvements on how nodes are configured and accessed.
On the other hand, you are very much wrong on the technologies you mention. Cocoa was developed in Next, and a huge amount has remained as was at the time of creation. NT is a kernel, not API. Assuming you mean Win32, which debuted with Windows NT 3.1, it was very compatible in concepts and source with the Windows API (retrofitted as "Win16").
Front-end dev moves fast because the web moves fast. It's gone from simple documents to complex application delivery in a decade. Backend dev is perfectly complicated with build toolchains and deployment pipelines so why is the frontside somehow not allowed to evolve? None of this is really required and nobody is forcing you to keep up.
taking 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.
Aside 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.
Well, 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
Having said that, I'll definitely work out a update that's readable to wider audience.
JSX 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>.
Take 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.
I'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-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!
So, 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.
166 comments
[ 5.5 ms ] story [ 237 ms ] threadThat said, it was a bit difficult to read this article on a fullscreen monitor since it's aligned to the far right.
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.
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.
In my view, the best solution is to (as far as possible) eliminate questionable features from the framework and enforce good practices.
Using one-way binding you get a very clear picture of how data flows through the components. Components pass data to their children via props, and get data back from the children via callbacks. It forces you to be more explicit with how things are working.
With 2 way binding, you don't have any guarantees that the child won't be modifying what you pass in, and in many cases i've found that it's difficult to see which direction data is flowing just by looking at the component.
If your component had a property named "value", is it the component filling that in and passing it to the parent? is it the parent passing the value to the child? With 1-way binding you know value is being passed "down" to the child, and a property named something like "onChange" will be the callback that it uses to pass data back "up".
I think I can understand why two-way data-binding would be bad on a complex app. Or even with more than one person working on the app.
And again I do want to stress that two-way binding isn't necessarily bad in my opinion, it just doesn't "require" the explicitness that one way binding does. I have seen 2-way binding work wonderfully when used with some strict guidelines or with external tools that can enforce some of that explicitness. And it can have it's benefits! 2-way data binding is often simpler, and can be faster than one way binding (it's really just a fancy term for "pass by reference").
"You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases."
So... I think the term "two-way binding" is overloaded here, and paints an improper picture of what VueJS is actually about.
I worked with knockout extensively on an inherited codebase a few years ago and my overriding opinion was that 2 way binding sacrifices everything for convenience.
"You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases."
Seems like a very specific, deliberate functionality. Changing a value of a reference from a parent component, however, is advised against and is probably what you're referring to.
React is backed by the Facebook engineering team, which is both good and bad -- a group is a bug with a brain on each leg. I think for this reason it's burdened with a noticeable measure of over-engineering.
Questioning the utility of that stuff is quite reasonable however.
The reason is that "effects", "data modifications", or whatever you want to call them are now local and appear everywhere. As your application grows it becomes harder and harder to know where and how your data model is updated.
This becomes especially apparent as you introduce more complicated workflows where you can't update a single value of state at a time but instead would like to treat it as a transaction.
It can also appear when dealing with computed/derived state.
Two-way data binding is fine for a simple form of 5 values. But once you start trying to build a larger application the desire for a top-down data flow and isolated state modifications becomes very apparent.
It's not an attack on Vue.js, as you have options like veux. I'm merely stating that there are very large disadvantages to two-way databinding itself.
But in Vue, two way data binding is _very_ local. It doesn't appear everywhere, on the contrary. It's barely worth mentioning when describing how development works. Honestly, this whole debate just seems weird - take away two-way data binding from Vue.js and at most you'd get several sighs from developers as they change few form-handling lines of code.
Any cross-component communication is done with events/mutations/actions, ideally with a central state store.
This offers the perfect mix of readable, understandable, composable, testable state architecture without the constant verbosity of binding everything yourself.
The columns aren't lining up properly and the bold yellow is pulling my eyes away pretty harshly.
Also seeing issues with the right column overlapping the left
Just follow readability standards and people won't skip your content based on presentation.
Also, your sidebar's content is cut off and hidden... in Chrome. Which I shouldn't have to explain how problematic that is. :)
I find myself increasingly using it even on decently designed websites when I need to read a lot of text.
Doesn't say anything about being sponsored by Alibaba, but Evan does indicate adoption there.
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.
These templates may look declarative because the look HTML-ish but they are not -- because of the embedded code that can call arbitrary functions in your application. The result is hard to debug and reason about. Where do you put a breakpoint in such a template? How do you abstract part of a template into a function? How do you add logging to such templates? How do you know what object is having its data accessed for templating languages like with Angular that do complex contextual lookups behind the scenes? How do you get code coverage reports? How do you get code completion? How do you get precise error reports? And so on. For more on why templates are a bad idea, see: https://blog.dantup.com/2014/08/you-have-ruined-html/
That is why I feel these sorts of template-based approaches will eventually be discarded as obsolete for writing single page applications as web programming continues to progress (in favor of generating UIs directly from code). HTML-ish templates feel familiar to people with experience building progressively enhanced web apps by sprinkling a bit of CSS and JavaScript on top of HTML generated from a server -- but for single-page apps that spend most of their time converting JSON from a server into HTML (or just doing stand-alone activities), a templating HTML-first approach make little sense. You just don't need extra templating machinery that you need to learn and maintain and that just gets in the way of development.
By contrast, consider the HyperScript API for generating HTML from JavaScript/TypeScript (as used in Mithril, Maquette, and optionally in Inferno and some other vdom libraries).
For example:
If you use the HyperScript approach (especially with Tachyons.css or similar), you are just writing JavaScript/TypeScript/whatever and can leverage all of the language's features. JavaScript-first for modern SPAs!It is similar to a function based approach, but has many advantages that reduce code and increase productivity.
Here is a page of examples from me React typescript setup repo:
https://github.com/toldsoftware/boilerplate-react-typescript...
Yes! Precisely. How many of these "regular old HTML"s I've seen and even used. Each with their own looping constructs, their own if/then constructs. The benefit, honestly, was lost on me then and is still lost on me.
React is not perfect. JavaScript is horrible. But pretend "HTML" templates are so much worse for all the reasons you describe.
I still suspect there must be something to Vue, though. So many people like it. Many of them have tried React, so I'm sure it's not like they're all ignorant to the glory of JS-based rendering. I wonder what it is.
Just use chrome. It will show compiled template that look much like jsx.
I don't understand how anyone ever thought CSS's style inheritance was a good idea. I don't mind HTML and even JS these days but CSS really needs to be sent straight back to hell where it came from.
Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.
For the life of me I cannot shake the feeling that Vue is just a simpler Backbone/Marionette. React was life changing because it actually solved the problems I had as a professional I-do-this-every-day web developer. I can't feel that way about Vue.
I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.
I wasn't aware you could use JSX with Vue. If you do, what benefits does Vue offer?
Having some designated separation of presentation and data is usually understood as a good thing.
I get that having them located in strongly separated locations increases workflow friction, but that isn't how Vue does things, and the rest of the problems you're talking about are present in any system where presentation and data have some kind of separation convention.
I'm also not convinced there where React is used to collapse the difference between the two it's actually solving problems rather than switching to a different set of problems, but then again I suppose every engineer has the right to pick which set of problems they prefer to wrestle with.
If you aren't using a data store, your parent component would solely be responsible for mutating data. If the child component needed to alter it, it would raise an event that the parent would listen to and make whatever modifications necessary.
I'm having a lot of trouble truthfully understanding your "mental back-and-forth" issue and I'm wondering if it's an inexperience with Vue issue. Give it a try... I'm willing to bet you'll love it.
It's a (single file), which would look something like (idk how to format code on h/n lol):
<template> <ul> <li v-for="message in messages">{{ message }}</li> </ul> </template>
<script> export default { data () { return { messages: ['hello', 'world'] } } } </script>
I realize this is a completely trivial example, but is this what you're getting at? Everything related to that component is in a single place. The template itself handles any UI specific logic: conditionally showing an element, looping, binding an event.
Any real logic is going to be handled from the component itself.
That said, Vue actually supports using a render function as opposed to using a template. You can even use JSX if you want (though I certainly wouldn't consider JSX a first class citizen in Vue).
This kind of system is extremely common on the backend---Python's Django and Ruby on Rails, to name a few frameworks follow the practice of templates being given data and simply acting upon it.
Since these are dynamically typed languages, there's no IDE typing support in the template.
There's just testing.
As someone who uses Django regularly, I can say there's a huge swatch of territory between "small examples" and "large projects".
That territory can easily cover teams of 19, and multimillion dollar projects.
That's my whole contention -- Vue is just a better iteration of the same old painful experience. React actually solves the problems I have.
This includes child components, which trigger events that you bind in the parent component.
Oh boy. Another reason why I don't like templates -- you invariably end up with magical incantations like this. Working with JSX has given me an incredible distaste for templating languages.
All bound expressions in Vue are javascript expressions. Names are typically bound on "this", which is the component instance. So the above expression is equivalent to
You still get reuse but use it like a default export if styles are used in more than one place.
In general, mixing html/js/css in a single file feels really dirty to me, but that might just be PTSD from a past life where I did a bunch of work on PHP spaghetti code with no separation of concerns.
Also the docs are like really really good. The Vue guide is a better experience than the official Angular tutorials (don't even get me started on the non-typescript angular documentation). They're a huge strong point for this project, especially considering how young it is.
class SomeClass extends React {
For reference on proposal status and details, see https://github.com/tc39/proposals .
Hmmm
its really amazing how much effort is spent on building the same CRUD apps over and over again
If I were you, I'd delete this comment before anybody steals the idea.
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.
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)
On the other hand, you are very much wrong on the technologies you mention. Cocoa was developed in Next, and a huge amount has remained as was at the time of creation. NT is a kernel, not API. Assuming you mean Win32, which debuted with Windows NT 3.1, it was very compatible in concepts and source with the Windows API (retrofitted as "Win16").
Front-end dev moves fast because the web moves fast. It's gone from simple documents to complex application delivery in a decade. Backend dev is perfectly complicated with build toolchains and deployment pipelines so why is the frontside somehow not allowed to evolve? None of this is really required and nobody is forcing you to keep up.
Just 5 years ago web development was insanely complicated.
Just peering into your average bower_components or node_modules folder is like staring into the abyss.
Guess that's the gift and the curse of OSS based web dev. I think there are far too many cooks.
I don't think its some "angle" out of left field. Its a valid point.
Having said that, I'll definitely work out a update that's readable to wider audience.
Not that I think it is an important issue or anything. I read everything via Pocket.
https://github.com/marko-js/marko/blob/master/test/autotests...
- 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-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!
NOPE. I like .vue because you can easily avoid large files.
http://imgur.com/a/umXXB
http://imgur.com/a/mbLoI