Why Choose Vue.js(hire.jonasgalvez.com.br)
hire.jonasgalvez.com.br
Why Choose Vue.js
http://hire.jonasgalvez.com.br/2017/Jun/23/Why-Choose-Vue
166 comments
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.
That is what I like the most in Vuejs : you have the choice.
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).
For example:
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") :
[]
)
> 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.
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.
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:
https://github.com/toldsoftware/boilerplate-react-typescript...
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...
Eh, Vue support the same thing too with render function. Under the hood, the template is compiled to a single render function too.
> Where do you put a breakpoint in such a template?
Just use chrome. It will show compiled template that look much like jsx.
Just use chrome. It will show compiled template that look much like jsx.
[deleted]
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.
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.
Even worse, I once worked in an environment where our web server was an Oracle database, serving snippets of pages from stored procedures on port 80.
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.
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.
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.
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.
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.
Have you seen Vue's single file components?
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).
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).
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.
I'm not seeing the issue here.
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.
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.
That's my whole contention -- Vue is just a better iteration of the same old painful experience. React actually solves the problems I have.
the templates rendered. There is a singular state, because data flow is one directional. mutating properties is an anti-pattern in vue.
My guess is that they started looking at Vue before v2.
I don't know where you formed your impression of what Vue is like, but what you're describing is really not anything like it.
This is my impression of templates as a tool. I dislike Vue for the same reasons I dislike Angular and Marionette.
Ok... I mean, JSX is templates too; it's just a different syntax. Vue supports JSX if you prefer that syntax.
I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.
I think you have a mistaken impression of Vue, it's much more similar to React than it is to Angular.
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?
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.
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.
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.
This includes child components, which trigger events that you bind in the parent component.
> @click="toggleVar = !toggleVar"
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.
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.
Somewhat magical.
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
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.Not entirely true -- I know there's at least special processing for filters: https://vuejs.org/v2/guide/syntax.html#Filters
"sources of truth" usually refers to data.
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.
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.
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.
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.
One word: re-usability.
the components should be reusable, not the styles on them.
Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.
Besides global font settings CSS nowadays is mostly used for positioning and isn't reusable.
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.
[deleted]
reusing css is a great idea for websites, react and Vue are most commonly used for web app where the atomic unit of reusability is the component.
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.
You still get reuse but use it like a default export if styles are used in more than one place.
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.
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.
My 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.
Love the article! But wow this site hurts my eyes. Yellow and red font on a black background aligned very far right?
Firefox reading mode (⌥⌘R) to the rescue!
I find myself increasingly using it even on decently designed websites when I need to read a lot of text.
I find myself increasingly using it even on decently designed websites when I need to read a lot of text.
And the panels are overlapping. A quarter of the text is unreadable.
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.
Thank you! It looks great here but I'll keep that in mind.
It looks like content is cut off no matter how I view the page: http://imgur.com/a/hqsli
Yellow font on a black background = I won't waste my energy reading it.
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. :)
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. :)
[deleted]
So you can see it: http://i.imgur.com/vphYLVa.png
The columns aren't lining up properly and the bold yellow is pulling my eyes away pretty harshly.
The columns aren't lining up properly and the bold yellow is pulling my eyes away pretty harshly.
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!
Just 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
Also seeing issues with the right column overlapping the left
Jeez, CSS is hard :) Thanks guys, I'll get on fixing this.
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.
Might want to fix your meta descriptions on the article -- they're set to your previous article.
[deleted]
Would you say the webpage is hard to vue?
OP not react as badly if it was.
and i had to tore my backbone apart so i could get closer to the screen
I mustache him what he was thinking!
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.
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.
Vue.js is heavily backed by Alibaba, the 7th biggest tech company in the world by market cap.
I like to see some evidence of this claim. Certainly Alibaba.com is not built with Vue.
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.
Doesn't say anything about being sponsored by Alibaba, but Evan does indicate adoption there.
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.
I thought Evan was funded solely through patreon.
Isn't Weex that's backed?
I also have a lot of hope for http://markojs.com ... it lately feels quite a bit like vue, and definitely better than react + jsx.
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.
We 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.
That said, it was a bit difficult to read this article on a fullscreen monitor since it's aligned to the far right.
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.
"specialising in UI/UX work with both React and Vue".. "rare occasions I needed to write javascript in the past 5 years"..
Hmmm
Hmmm
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).
This color scheme gives me extreme anxiety... good article though.
Previously 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.
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.
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?
"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 {
class SomeClass extends React {
someMethod = () => {
// already bound
}
}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.
That 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 .
For reference on proposal status and details, see https://github.com/tc39/proposals .
I 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.
> 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...
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...
You can still use vuex for the flux experience.
[deleted]
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.
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.
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.
Questioning the utility of that stuff is quite reasonable however.
Best thing about React is that I know absolutely nothing about its implementation.
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.
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.
"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.
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.
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.
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.
[deleted]
I'm new to these kind of frameworks. I have been hacking away some small apps. Do you mind explaining why two-way data-binding is a "bad" thing?
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".
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".
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.
"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.
Thanks for the reply.
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.
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.
No problem!
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").
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").
I couldn't agree more with the above. I firmly believe that "Explicit is Better than Implicit".
In general, it's harder to reason about as to which way the data is flowing.
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.
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.
You don't need to use two-way binding. You get one-way by just making things props.
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.
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.
In my view, the best solution is to (as far as possible) eliminate questionable features from the framework and enforce good practices.
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.
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.
I 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.
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.
For the same reason you don't buy a truck if you don't intend to haul things. You use a library that suits your workflow best.
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.
The current version of Vue does not favor two-way binding (although it is still technically supported using `v-model`, it's entirely optional).
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.
This guy really ought to read [Practical Typography](http://practicaltypography.com/).
Why is this site's content off-center...? 1920x1080 desktop on Chrome. Is that slightly ironic?
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).
[deleted]
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.
https://github.com/marko-js/marko/blob/master/test/autotests...
https://github.com/marko-js/marko/blob/master/test/autotests...
This site doesn't render properly for me on latest Chrome (dev) on Linux.
http://imgur.com/a/umXXB
http://imgur.com/a/umXXB
Ouch! I'll look into that. What's your screen resolution?
Using vue without webpack or any build process becomes a maintenance issue when you got dozens of x-template in a single html file.
I thought it was implied that using Webpack eliminates the need for said inline templates. Should have made it clearer.
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!
- 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!
"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.
NOPE. I like .vue because you can easily avoid large files.
Alright guys, updated stylesheet and color scheme due to popular demand :)
[deleted]
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.
> if that's the angle you want to take
I don't think its some "angle" out of left field. Its a valid point.
I don't think its some "angle" out of left field. Its a valid point.
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.
Having said that, I'll definitely work out a update that's readable to wider audience.
It'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.
I've since updated the color scheme.
Sorry, but that's really ugly.
May 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.
Not that I think it is an important issue or anything. I read everything via Pocket.
web development is such a retarded mess
its really amazing how much effort is spent on building the same CRUD apps over and over again
its really amazing how much effort is spent on building the same CRUD apps over and over again
Then 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.
If I were you, I'd delete this comment before anybody steals the idea.
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.
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)
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").
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").
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.
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.
The 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.
What is "proper software development"?
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.
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.
[deleted]
Web development is so mature now that you can make the same application with the same effort than you could in FoxPro 25 years ago.
Just 5 years ago web development was insanely complicated.
Just 5 years ago web development was insanely complicated.
Web Assembly will hopefully straighten out some of this mess.
Not sure why you are being down voted. You speak the truth.
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.
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.
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.