Why Choose Vue.js
hire.jonasgalvez.com.br
hire.jonasgalvez.com.br
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:
h("div",
h("ul",
h("li", "one"),
h("li", "two"),
h("li", "three"),
someExtraListItems(),
otherItems.map((item) => h("li", item.name))
),
isListEditable ?
h("button", { onclick: editList }, "Edit extra list items") :
[]
)
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.
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...
Just use chrome. It will show compiled template that look much like jsx.
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.
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.
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.
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?
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
this.toggleVar = !this.toggleVar.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.
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.
You still get reuse but use it like a default export if styles are used in more than one place.
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 find myself increasingly using it even on decently designed websites when I need to read a lot of text.
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. :)
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
Doesn't say anything about being sponsored by Alibaba, but Evan does indicate adoption there.
That said, it was a bit difficult to read this article on a fullscreen monitor since it's aligned to the far right.
document.getElementsByClassName("left")[0].style.right = "55%";
document.getElementsByClassName("articles")[0].style.width = "50%";Hmmm
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.
class SomeClass extends React {
someMethod = () => {
// already bound
}
}For reference on proposal status and details, see https://github.com/tc39/proposals .
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...
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.
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.
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.
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".
"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 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").
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 my view, the best solution is to (as far as possible) eliminate questionable features from the framework and enforce good practices.
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.
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.
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.
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.
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").
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.
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.