Love letter to Vue
evaristesys.com
evaristesys.com
To me, it looks like Backbone, AngularJS, and React had an orgy and out came Vue. The "opinionated" claim strikes me as marketing BS, templating vs. JSX, attributes vs. components (assuming you're using their templating language), etc. There really isn't a performance benefit over React. You're wading into a new ecosystem without all the build-up React benefits from. The templating language itself is yet another thing to learn, and frankly I just don't think embedding control flow into the templates themselves is a sane approach.
The documentation folks love to talk about is alright, I've definitely seen worse, but it is too much "Go do X" and not a lot of "Why we do X." The latter is a particular strength of React, in my opinion, as they describe very well the underlying logic behind why something is the way it is.
About the best argument for it is the batteries-included nature of the projects, but even then I've not truly had that much trouble upgrading something like React Router such that it would make me question using it in the future.
But with the KISS approach Vue takes, I've only very rarely cared about the ecosystem at all. I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach, which Vue does not significantly suffer from (sort of, we don't need a bunch of apps, just a good phone).
Is there a particular situation you are thinking of when you say we are in need of said ecosystem?
I think quite similarly. I've only paid attention to third-party components maybe once or twice.
That said, ecosystem size, health and critical mass do factor into project longevity, as well as perceived adoptability, all of which feed back into each other.
However, in the context of React, the discussion about ecosystem elides the high necessity of using it, since core React stands a virtually zero chance of being sufficient.
I think an SPA version of a CRUD app wouldn't need anything past core React. Most people don't talk about things that unamibitous, though.
Disclaimer: I don't use React or Vue. I have no idea how their mobile versions compare. I get my virtual DOM kicks from Ractive, developed by The Guardian newspaper. I'm told it's like Vue. I really like it. I'll probably move to Svelte for my next major project.
While NS is fairly mature at this point, the vue bindings only reached a 1.0 release this year. There's been a lot of development done on it recently, though. I am unsure if anyone major company has shipped using NS-Vue.
> Is there a particular situation you are thinking of when you say we are in need of said ecosystem?
Here's a concrete, real-world example. I spent several months researching Vue and React for a large SPA migration from AngularJS at work.
In order to migrate a single page, I had to write three compatibility libraries that already existed for React. This was for a simple page that pulled in data via an API and displayed it in a handful of tables.
Another engineer did an audit of our third-party library use and needs, e.g. complicated "excel" like spreadsheet tables, and we simply couldn't find an existing Vue solution. That meant I would need to write my own compatibility libraries for at least another half-dozen complex libraries. There was an argument in favor of using Vue because we could get a lot of open-source exposure so I'll give it that. Plenty of low-hanging fruit for the open-source Vue developer.
Perhaps Vue folks are only working on extremely small, basic, CRUD applications. The software I work on is not.
> I think that the weakness you are seeing here is a straw man from the nature of React's over-architected approach
React simply provides you components with a lifecycle. You are free to architect and compose those primitives however you see fit.
Contrast with Vue, can you please reasonably explain the difference between a custom attribute vs. a component and when it would be appropriate to use one over the other? How is this simpler? How is this "keeping it simple?" This is only a single deviation between the two.
Vue tells me it is "opinionated" but when I have to research, compare, and contrast it's own core features I have to ask how is this "opinionated." If I have to do all of this legwork how is it "Keeping it Simple, Stupid?"
To Excel, I wonder how much reimplementing was needed again, did you need computations in-cells like Excel has? It seems like if you are going that deep you will need to implement much of the logic on your own. I guess if you are truly just reimplementing Excel in a web interface, then your point has merit, but it seems like for something that specific, the preboxed solution would more get in the way?
To directives versus components, certain behaviors make more sense to me as an HTML element (an infinite scroller, for example) than as a "controller-level" component. Additionally I've found a great transparency of debugging by starting with the HTML and looking at what functions are being invoked when, than by hoping I know where the "controller" is binding into the HTML, and perhaps never finding all of it.
And fair - I still don't know what "opinionated" means... lol
And I think it's also important to note that most of the things you point out are matters of preference. I've seen Vue fans and React fans argue about these things until they're blue in the face, when all it really boils down to is that some people like the way Vue does things, and some people like the way React does things.
Healthy debate is good. But the downside is that I've noticed these debates devolving into what I call identity politics for programmers - instead of seeing the other group as front-end developers who just like doing things differently, I see people breaking the world down into two groups: people who agree with them, and idiots. And I don't think this approach is very good for us as a community.
So I don't mean to single you out here, but the author didn't really criticize React in any way, so I don't think coming to the defense of React vs Vue here really added to the conversation.
Why not just say, "hey, I prefer React, but it's good Vue exists for folks who prefer a different approach.". Vue's existence isn't a threat to React. It's okay to have multiple approaches to the same problem.
I prefer React too, but I don't think a front end framework monoculture is a good thing so I hope that Vue, React, Aurelia, Ember, and others continue to grow.
Vue's component separation of HTML/JavaScript/CSS just clicks better for me.
Would you object to things like unobtrusive javascript?
Things like unobtrusive javascript came to be because people recognized early on that HTML was not enoug for writing applications -- that you needed something more. Since basically the entire world has come to embrace unobtrusive javascript, it isn't a logical leap to embrace JSX.
https://medium.freecodecamp.org/react-s-jsx-the-other-side-o...
Sure there are cases where JS is incredibly useful and beneficial, but your website should be able to display the majority of content with JS disabled.
That's an entirely different discussion than what the parent was discussing though. This is about those cases where you're not building a static website.
"HTML was not enoug for writing applications"
That's not what it is anymore. It has evolved into a general, distributed computing and communications platform. More and more uses of this platform require doing things that involve customized behaviors, not just the built-in features for displaying articles, so more and more people leave JS enabled. Kids who couldn't have afforded a family PC and MS Office now have a Chromebook at school (and maybe at home) and free Google Docs. And how many people whose only internet access device is a phone turn JS off in their phone?
I think it makes more sense now to treat the JS-disabled, article-browsing case as the exception. If I were trying to distribute public health articles as widely as possible, I would try to limit them to simple text, small photos, no JS, nothing that wouldn't have worked 20 years ago. And even for less-critical articles, if they were just simple articles, I'm still inclined to leave out the JavaScript in most cases for the sake of simplicity, reliability, reach, and archival robustness.
But for general purpose today, most developers in the developed world can assume JS is going to be enabled by the market they want to target.
In the author's conclusion he states, "JSX isn’t revolutionary. It’s evolutionary. Like most forms of evolution, it’s a clear improvement."
I will concede the author's point that React & JSX are better than the jQuery spaghetti that came before and is therefore an improvement. As the comparison here is to that of evolution which is superior the shark or the tiger? With evolution many things will evolve out of those things that came before and the strong will survive. Vue and React are both evolutions of what came before; time will tell which, if either, survives.
> PHP + jQuery applications.
As much as people like to detract, Wordpress and friends power a significant portion of the web. The PHP market is pretty big.
Yeah, as a C++ dev, I skip all of the front-end, back-end and "full-stack" jobs... :(
Oh well. I'm glad it's providing value to people. I might just never understand.
Because I keep seeing folks extolling the virtues of Vue, but when I went and used it I simply found little to nothing of merit compared to existing solutions.
I'm not running around telling folks what to use here, but rather stating my experiences. Perhaps someone might come along and provide a reasonable explanation of how I misunderstood something or a problem it solves better than existing frameworks but all I get is "I look it and you don't so meh."
In short, I'm trying to spur a technical discussion here but all I get in return is fanboyism and folks trying to shut down the conversation.
> but the author didn't really criticize React in any way
Actually, the author criticized React both in direct and indirect ways. He also made incorrect and or misleading claims. Of course the author also goes on the mention that he or she is inexperienced with React but somehow still feels qualified to make those claims.
Sorry for trying to add to the discussion and not just posting "Oh gee, I sure do love Vue too!"
> but I don't think a front end framework monoculture is a good thing
Neither do I.
The other thing that React does is encourages top-down propagation of immutable data, which nicely fits ClojureScript and other FP languages. Is this approach equally efficient in Vue?
Lastly, when I looked at view, it had a lot of sort of OO stuff happening in the docs, which doesn't map very nicely to ClojureScript and friends.
Do you have any docs / blog posts on programming in Vue with pure JS (no templates or magic) and in a functional way? If so, I'd love to read them. I may spend a weekend trying to put a ClojureScript layer on top of Vue.
To each their own. But there is nothing I miss about React after switching to Vue.
Vue felt like a subset of Ember. React did something completly new.
Vue hits a nice balance between opinionated code and flexibility. Throw in their ESLint plugin and I think you will end up with very maintainable code.
After Angular 1/2, React, Riot I ended up there. It conforms to my principle of least surprise, and principle of least new ontologies. In the world of transient JS world, it's the best thing that happened.
Hope every other front end framework disappears and the whole world settles on Vue.
Any particular reason that you prefer Vue over Angular seeing as you have had experience of both?
That's not to say that I haven't shot myself in the foot dozens of times in the process though. We've had to solve a lot of pain points from our original 0.12 code (two-way binding, too many props in components, some jquery dotted in, lots and lots of pre es6 code). But even sitting on code I wrote that looking back makes me cringe, Vue is always enjoyable.
It has truly improved my daily quality of life and I owe Evan You a lot of gratitude.
A few month later I got myself a smartwatch besides most of the work was getting around the tizen framework I made my own watchface in Vue - and this was/is a pure joy. http://wecoso.org/~mit/stuff/myClaw/
React lacked crucial functionality and it felt like I had to rebuild basic functions everytime e.g. a simple input field which communicates its value through setState. In Vue, you just use v-model, but in React you have to add an onchange handler which just feels very low-level - I just don't want to operate on this low level, the framework is allowed to make assumptions e.g. for checkboxes to make my life easier (i.e. grouping all checked inputs with the same v-model name into an array). Another thing I don't like is that JSX is not very good-looking e.g. if I want to add an "if", I need to use the ternary operator in complex components. This is just a hacky way and not very descriptive IMO.
And Angular was awful with its $scope and felt so dirty (it used dirty checking, that's probably why). The new version is ok, but Vue has all the same concepts but wrapped up in a nicer interface. I don't even understand what the ng team tried to achieve with their difficult to read templating language. Looks awful and feels complicated compared to Vue's simple constructs (mainly v-model, v-for, v-if and v-show and v-on, v-bind and ref) - you can learn to write Vue templates in 20 minutes.
The core concepts are reduced to their essentials and it really shines. React is too basic IMO and Angular tried too much with all that controller, service, ... stuff. It was too complicated.
Vue is basically what Web components (using .vue files) should be: Small modules with HTML, style and JS code. And a very nice API and a great developer behind it (so it has all the nice things: vdom, custom rendering e.g. for JSX support, a webpack loader, ...).
Overall, it's the greatest thing I've seen since Ember (and it's much better and more flexible than that).
Having learned with react, I think the component structure and updating are wonderful. But the baggage of the React ecosystem made it tedious to add to projects. What if I don't want to use webpack and npm and babel?
As this author notes, Vue just drops in and works.
I can use it in existing projects. I can use it in experiments. I can use it with my PHP projects. I can use it without a server to compile anything.
It's been a pleasant experience and the tools I've built with it have been refreshingly stable.
You may want to look at Parcel, which gets you most of the Babel/Webpack benefits (minification, ES6 syntax, using image files as imports in JS, etc) in a way that "just works".
npm i --save-dev parcel-bundler
npx parcel src/index.html # where index.html has <script src="whatever.js"></script>
You don't have to use those if you use React. It can be as simple as including a script tag in your HTML and be done with it.
I feel most vue lovers don't care about static typing.
I can appreciate that the author loves Vue.js but I don't think its very constructive have such a binary view of something they clearly haven't spent much time with. Angular is not "over-engineered". Its complete. Its got everything you need and an established, well documented pattern to do it. Its far from perfect but then what is? I've used it, React, Angular 1.x etc and all of them have their strengths and weaknesses. It depends on your team and what you are trying to do.
Its important to remember all these frameworks are built by people just like us who try very hard to make them the best they can be. It would be nice if we spent more time celebrating all the wonderful FREE tools they build for us rather than tearing down the ones that we didn't pick.
I'll take composition over inheritance in my tooling.
(1) The angular compiler doesn't have the same JS or CLI interface as the TypeScript compiler. I have to know very specifically which I am using when; my build tooling must always know whether it's compiling TS the Angular way, or the vanilla way, and there isn't much commonality.
(2) What if I want to use an alternative TS compiler? Or someone writes a faster one in Go? Or I want to use tsickle [1], which is Closure Compiler-compatible?
Now it turns out there isn't a TS compiler in Go, and the Angular team are the authors of tsickle, and so ngc happens to work with it. But it's an architectural smell to couple that closely for my MVC framework (and IMO with little necessity).
While Vue is obviously a kick-starter to frontend programming that makes templating easy and unix-y light, I still have few complaints. First, it is not obvious or easy to start with components. Separate files, build ecosystem, props handling, all this. What I want is to reference ‘that last place’ in html and have a copy of that template right here that would capture props like un-hygienic macros of C would do. Iow, my style of small apps doesn’t map well to heavy isolated-component based style of thinking. I don’t want to wash my hands every five minutes when I’m at home.
Second, vue forces you to be fully contained in .data and .methods. I would like to bind to any data and function roots, including window itself, but it’s obviously a bad idea to pass window to vue vm for now. But still, it would be nice to forget that vue exists at all at the source level and have just a bunch of vars, functions and [3rd-party] modules at global level and that’s it. Now I have to export methods to vue by hand and to have all the state pre-defined, as if it wasn’t clear how my state is structured from {{these expressions}} alone. I often find that something doesn’t show because I forgot to init data.key = { k2: “” }.
Third, you cannot ‘chroot’ without making a component. Would be nice to write something like <template v-with=‘client.contacts’> and then reference ‘phone’, ‘address’, etc without a prefix. With copy-style described above it would replace the need for components for me for ages, even if I meet that need.
Still my jquery experiments can’t beat vue in simplicity, though I hope some day I’ll get rid of vue too (due to points I listed, not because it’s bad). But de wae still has to be found yet.
Vue-material lets you do this so I went with that but I also get the feeling it's a smaller / less updated package so YMMV
I did find reference to a-la-carte when I looked but the page was 404ing so I assumed it was unsupported or in beta. Thanks!
Not sure if that's a negative or not.
They are not if you need the components do something aside from looking a specific way.
For the project I'm in I need a:
-Range slider
-Date picker
-Autocomplete select
-Data table with pagination
Obviously none of the "minimal CSS frameworks" have any of those because it's impossible.
Yes and it's a headache. Mostly because they have separate docs and CSS. The other day I had to change the appearance of all the labels - with a single framework I could just add a simple, single selector(because Vuetify as opposed to Angular Material uses BEM) and be done with it.
I may have to use an individual component for uploading since it hasn't landed in Vuetify yet: https://github.com/vuetifyjs/vuetify/issues/238
> (cannot type or click trigger - only keyboard down arrow works):
Control question: did you click the icon on the left or on the right?
This is the first time I've ever been stumped by a simple read-only field. I think my confusion was due to the floating label animation on focus which I would expect only if the field was editable. You typically don't encounter read-only fields in mobile apps but they're common place in enterprise desktop apps.
Regardless, there is a bug since clicking the down arrow on the keyboard still allows me to select a state even though the field is read-only.
Out of the box support for Material and iOS themes.
https://quasar-framework.org/quasar-play/android/index.html#...
I have one app deployed for web / iOS / Android, and 3 more in progress for clients.
What is weird to me is that lot of people seem to insist that there are major (sometimes deal-breaking) differences between them, when even core developers of both frameworks agree that they are more similar than different.
Look no further than these comments. As always it's a mix of, "I tried React and hated it, then I tried Vue and loved it!" or visa versa.
Metrics such as "I understood it immediately" or "it didn't feel right to me" are shallow and meaningless.
Fact is, React and Vue are increasingly similar. So why these types of articles make the front-page once a week is beyond me.
This one? The article barely makes a comparison with React, and when it does it emphasizes their similarities.
Now to read the many mentions of react in the comments even though the article has nothing to do with it.
I think that specifically in the case of Vue, this hurts more because of the philosophy highlighted in the article- to not stand in the way of experienced developers who know what they're doing.
(Edit: oh no, please don't come with the downvote train. This is a real issue, when you have something that solves 99% of your problems but you can't get it to 100%.)
What you want is achievable with the existing async feature, except you either need to 1) keep a list of component names up to date, or 2) use a special component like `<dynamic-loader>` instead of the component tag directly. Neither is a deal breaker, nor enough to warrant introducing a duplicate API; it's rare that you'd be using advanced features like async components while lacking a build process.
Evan's first answer wasn't the most friendly but you also come out as very combative in those messages - as reinforced by your suggestion here that the 'merit of the change wasn't even considered'. Maybe there is some middle ground to be found, an alternate proposal, but I find it extremely unlikely anything will come out of this discussion using this tone. Humility is a must even for experienced developers.
[1] https://vuejs.org/v2/guide/components-dynamic-async.html#Asy...
It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components.
But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue.
I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.