How we do Vue: one year later (2017)
about.gitlab.com
about.gitlab.com
Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid.
I HIGHLY recommend it, and this is from someone doing web since 1997.
I started in 97 as well, and cannot recommend Vue enough. I've done React, Angular 1 & 2, and I keep coming back to Vue.
I always feel like with React/Angular I'm conforming to work how they want me to work. (Esp. Angular - React is more forgiving). Whereas Vue is just a complement to the way I already work. I can use as much or as little of it as I wish.
A hearty endorsement indeed.
This is why I like angular quite a bit, it’s not whatever the dev decided to do. It doesn’t include a whole bunch of small libraries of questionable support.
React sort of used to have this problem, too, when you had to rely on classes for state, but the hooks era is a breath of fresh air. Everything is just a function. It feels freeing.
I think if you're at the point where "passing data around in props is a nightmare" that's the pain point that VueX is meant to resolve, and it should feed into the solution. But following the principle of "components should manage their state without VueX if it's easy/convenient for them to do so" is a good way to avoid the global state becoming too unwieldy.
The usual <div :something='stuff + "here"'/> way of writing it errs on the side of HTML over JS, using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets. It makes it harder to visually parse, and it's sometimes annoying to not be able to use one type of quote marks unescaped within the statement.
Overall, this is one of many ways in which Vue (like Angular) seems like HTML with functionality tacked on, as opposed to React, which is closer to idiomatic JS. I've used both extensively and I don't think I can recommend Vue over React anymore -- unless you're, say, prototyping and looking to build an app entirely on the client, with no build step, where Vue really shines. Or unless you're doing something HTML-centric, like converting a static site.
Vue relies too much on overloading the string type for my taste (fundamentally, all JS libs do this to some extent). Too much magic happens with these string-based v-bindings.
Irrespective of that, these days I am hard pressed to not use typed JS in some form or fashion anyways.
What do you mean by "anyways"? I use TypeScript with Vue and it's great.
Mutiny.
There are some benefits from just embracing JavaScript though, especially, as you mention, integration with things like TypeScript.
I'm still waiting for the 2019 equivalent of http://haml.info/
Here's a Pug -> JSX transformation: https://github.com/pugjs/babel-plugin-transform-react-pug
Detouring from the most popular path tends to come at the price of tooling idiosyncrasies that are rarely worth it, but it seems to at least work with eslint-react and has syntax highlighting in some editors.
Some examples here: https://reagent-project.github.io/
It's not haml, but I'd argue it's awesome.
I have a feeling after Vue 3 hits and in a couple years JSX will be the defacto way to work with Vue.
Sounds like you should be making more use of computed properties and component methods.
The "I wouldn't use Vue except for a small project" meme really needs to die too. Vue's build process is mature, has server-side rendering, and is used by some of the biggest companies in the world. If it's good enough for them at scale, it's good enough for the rest of us.
Naturally, even though you can disregard the templating and resort to idiomatic JS, like one in React, you managed to develop an opinion after not using the features you like.
This just makes no sense honestly. I'm all for people having opinion to the point where you can blatantly say "I hate Vue because I like React more", there's literally no need for justification.
But spewing nonsense just to justify your preference is just bad. Are you a junior dev by any chance?
I've used both extensively and I can recommend Vue over React because React is a pile of mental manure. I never understood React hype, but then again - IT is a fashion business, and when "leaders" invent crap - flies tend to follow.
The community around it is also extremely helpful.
That's exactly what it's like. Working with Vue doesn't even feel like you're using a JavaScript framework. You just write your HTML, your CSS, your scripts/data and you're done. Vue is brilliant.
After a few years of using React and some past experience with various other templating/view systems (webdev of one sort or another since '99) I started picking up a little Vue. So far it's been easy enough, but it is highly confusing compared to most other systems I know.
The syntax is like JS handled through custom HTML attributes. In one place a string is a string, in another it's a reference to a component property. If I want to iterate over a list, I spit out the `<ul>` and then an `<li>` that has special attributes that says to repeat it N times, filling in these different bound values. Compare that to, say, React, where my code is code, and my HTML looks like HTML (but is actually code) and the relationships become more clear, less magic. If I want to loop over an array and output some <li> tags....that is exactly what I do.
Vue reminds me of JSP...that's not a point in it's favor in my book.
Now - I've only been using it for a week, and there is so much more to learn. But in terms of first impressions, Vue has not impressed me...and I actually expected to be impressed.
I'm working on backend most of the time and relatively recently I needed to do switch to frontend part of our service. For me Vue seems much easier and less confusing. You just have your plain html template and a few 'hooks' to make it work with your js script.
>magnitude more complex and is very inconsistent:
Just as the other guy said - it is very intuitive. You don't even have to learn much of js to make it work perfectly.
That being said, I do share some of the other comments about how it can be confusing with bound elements and iterating over objects, or areas you aren't allowed to use string concatenation. A lot of this magic happens behind the scenes so it's a bit of trial and error, and feels foreign if you're used to being able to do those sorts of things in the past.
I also think that React (with JSX) is a bit more "out in the open" about how things work and what is expected, without reading tons of documentation, and less under-the-hood magic. So it's easier to get up to speed, and your JS knowledge will improve over time (especially if you already know other languages).
I feel like these kind of arguments are usually made by people who don't have any extensive experience using Vue, because in practice, it's not really a problem. Sure, you may not like it and prefer JSX (I understand all the pros and cons, all very valid), but that's a whole different statement than saying "Vue's syntax is orders of magnitude more complex and very inconsistent". That's just plain wrong.
There is an easy test to see if my statement was true or false:
<tag attr="x">
At any given point in time the value in an attribute is entirely dependent on context (which particular Vue attribute it's in) and on a very arbitrarily defined rules for those attributes. For example, v-on accepts three absolutely different and incompatible things:
v-on:click="x + 1"
A Javascript expression
v-on:click="function_ref"
A function reference bound to JS-code
v-on:click="function_call(param1, param2)"
Looks like a function call but isn't. It's a way to
declare a function ref that will be called with bound params
Compare to React's JSX:
<tag attr="x"> // x is a string
<tag attr={{ x }}> // x is a valid Javascript expression
<tag onClick={{ function_ref }}>
<tag onClick={{ () => regular_JS_arrow_function() }}>
onClick expects a function reference because that's
what it will eventually call
{
data: function () {
return {
open: false
}
}
}
{
methods: {
toggle: function () {
this.open = !this.open
}
}Different strokes for different folks, but I was quite surprised at my experience. Everyone keeps using the word "intuitive", and anything that I have to learn all these rules and special cases for is the opposite.
It's not wrong, but this way it sounds way more scary than:
"Properties which start with "v-" are treated specially by Vue and don't end up in the rendered output."
Vue’s v-* attributes are a stringy mess [1], and it doesn’t really matter that they don’t end up in the output.
If you want to use pure javascript, you can create the render function directly and forget about templates. Most of vuetify components are pure javascript.
Also vue has support for JSX if you prefer that.
I know a lot of people, especially in HN, are impressed by it but I found it very lacking. It makes things easy to write at first and with very little learning curve but trades that ease of use for stability, simplicity and maintainability.
The main problems, to me, are:
* too much global state - the Vue object is the new window,a global registry, you add custom elements,filters,directives,plugins and even just utility methods. You can of course opt not to use it, but since all the libraries use it and it's the canonical way, you'd be hard pressed to.
* lack of controlled components - unlike react there are no controlled components. For example if you are trying to make an input that doesn't accept certain characters, in vue you'll need to handle keypress events to make sure the value doesn't change, while in react you can simply not update the rendered value. This can be worked around of course, but the fact that vue doesn't have a clear definition of it permeates throughout the ecosystem.
* component definition syntax - the syntax for definition a component with it's data,props,methods,computed,hooks is a very inconvenient way of writing classes (which vue 3 is going to support natively finally)
* template syntax - after doing JSX, going back to template syntax is not the greatest experience. It doesn't work as well with IDEs, you have to spin circles to do things that can be a one liner in javascript and it prevents doing any form of reuse and structure unless it's by splitting it to more components (I.E. no way to use just functions or internal methods).
Of course vue prides itself for the fact that you can choose to do things a different way - use JSX instead of template Syntax, don't use the global vue registry, etc...
But that's really in theory, it's like React can be used without JSX, it's technically true, but it's extremely hard not to and the ecosystem won't work well.
As to VueX, for me it takes the verbosity, single global object and dependence on strings for differentiation from redux and leaves out the immutability and reducer syntax. It takes the publish/subscribe technique from ReactiveX or mobX but leaves out the ability to combine, manipulate, stream and the general reusability that those frameworks provide. It is almost a comical selection of the worst features of both without any of the benefits.
Fortunately you can cut up the store into multiple modules, but I still prefer the decentralised approach from Angular over the central store.
I also regret the lack of classes and the lack of a more webcomponent-like approach. Component definitions work fine and are fairly flexible, but they look messy.
Looks like 3.x plans to be built on typescript but I'm not sure if this article is still relevant, I very recently started paying serious attention to Vue.js so I'm playing a game of drink from a fire-hose. https://hub.packtpub.com/vue-js-3-0-is-ditching-javascript-f...
The way I see it Vue complicates the logic of the app (due to two-way-binding, observable state etc.), it does decrease some the boilerplate needed at the beginning, but makes getting started or doing simple UI tweaks accessible for juniors devs / designer-developers / "web-developers". (React is well known for the fact that once an app grows beyond a certain size only actual "javascript engineers" can touch it, it's no longer intelligible to "designer-developers", and it can have a codebase specific learning curve for every junior dev joining the team.)
EDIT+: To clarify, the way I see it, React's advantage is its simplicity, the core conceptual logic of things is very simple/mentally-compact, you can "run around with the whole thing loaded up in your head" easily. Yes, it does require more in terms of "IQ/cleverness" and also some "sense of architecture" from developers in exchange for being able to wield this simplicity without "cutting yourself", but I'd say it's worth it. I'd say React is the "catana sword" of web frameworks in a way :)
In my (admittedly inexperienced w.r.t. Vue) view, that is exactly the reason for Vue's popularity, and a perfectly fine one at that.
What I've seen from GitLab's workflow is that their front-end developers are not of the "SPA type", for lack of a better term, but more of the "design a page using HTML+CSS and add some Javascript for interactivity" type (same lack of a proper term). And that's perfectly fine; I'd presume they work more closely with designers or take up some design work themselves, and would at least expect them to be proficient in areas like accessibility much like many in the industry are not.
I think what's the better choice mostly depends on how one's organisation is structured. Though honestly, either would probably have worked just fine, and it's mostly a matter of nuance.
The one thing that keeps React in my toolkit: React-Native development with Expo is truly an excellent experience. Getting everything going without having to fire up visual studio or Xcode is a dream. I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done"
I had a similar experience. I will say, though, that the nativescript-vue plugin is now officially supported by Telerik rather than just a community plugin, so it should theoretically be getting easier to use.
Also, for all we know their server-side Rails+Haml stack took <50ms to query the database + render the comments, but they still wanted to factor that out of the initial page load to improve TTI.
> Surely you could query the DOM for this. A better solution, in this case, is to let the backend developers mark the last user comment in the JSON they return. Backend developers have direct access to the database, which means they may be able to optimize the code. Then no client-side work has to be done at all, in this case.
Look, I know what I am, I'm no fancy-pants silicon valley guru here. But what is described in this example is primarily a client-side function. So I think the wording for this is "a different solution" at minimum. Better? Meh. Will that new backend query ever serve any purpose other than facilitating this frontend feature?
Perhaps instead of adhering to a "let's not query the DOM" at all costs, ask yourself what exactly you are complicating and for what gain.
Q2: Did you compare Vue vs React or Vue+Vuex vs React+Redux? What do you think of "React without Redux"?
Q3: What advantages would Vue bring over react in your context? The way I see it, Vue could lower TCO for web apps by allowing more junior developers or web-developers/designer-developers to make smaller UI changes instead of needing more senior/expensive frontend-engineers or full-stack-engineers-withs-strong-js-skills that React seems to require? (I mean your project doesn't seem like the one that would benefit from making the codebase easier for junior devs to work in, but at the expense of it getting more complicated for senior devs as the overall logic is more complicated in Vue...)
While Vue has a big ecosystem, it's still a fraction of React's. And this is probably the most important thing about React: The ecosystem is so huge, that you have choice, strong competition between lib authors and at the end of the day often or usually superior products. You hate redux? Me too, but there are literally dozens of competitors or wrappers out there + React's own Context and Hooks which bring you quite far. You want a UI lib? There was guy on Reddit testing 40 UI kits for React. Animation? A dozen good ones plus one major one. E.g. I was looking for a page-transition lib for Vue for cross-fading page transitions (real cross-fading where pages blend into each other), I found nothing, just one which can do page-transitions but not real cross-fading (fade-out and then fade-in of the new page). Not that just that vast amount of libs makes life easier, there are so many people you can ask, React got the lingua franca of frontend.
Another thing I like is the actual (small) API of React. It's low-level and if you are stuck, you know quickly what the problem is. React shines also re maintainability , if I enter my biggest and quite complex React app after months I still know where to go and how things work.
Finally, the React team and how they manage issues is amazing. Their thoughts, their chosen architecture, their communication is far beyond many other maintainers on Github. You ask stupid questions in an issue, often Dan answers himself, always super friendly and helping out.
Once you passed the first weeks, I realized what smart architecture React has, that it never stands in my way. Just the fact that I am always and 100% in JS makes things so much easier.
I could see vue-like syntax and features supported natively in the browser in a utopian future; have never felt that way about react or the ancient version of angular I had to touch.
And the ease with which I am able to extend / scale / enhance the application within a very short notice is also one of the highest selling points of my choice. Majority of businesses equate time resources with $ and the faster they are able to utilize the software, the better their business becomes.
I echo the issues with the attribute syntax. I found marshalling data from the server into components to be painful. I ended up with the following:
<activity-form action="/admin/applications/edit/1001/ajax-activity"
:staff-member="1"
:staff-member-options="[{"value":"1","text":"First Person"},{"value":"2","text":"Second Personki"},{"value":"3","text":"Third Person"}]"
:activity-type-options="[{"value":"note","text":"Note"},{"value":"reminder","text":"Reminder"}]"
:is-super-administrator="true"
@new-activity-log-entry="addActivityLogEntry"
>
</activity-form>
var vue = new Vue({
el: '#app',
created: function () {
for (var key in __app.dataForVue) {
this[key] = __app.dataForVue[key];
}
},
// ...
}; <!-- inventory.html.twig: -->
<div
id="app"
data-inventory="{{ inventory | json_encode }}"
>
</div>
// main.js
new Vue({
template: '<App :inventory="inventory"/>',
components: {App},
data() {
return {
inventory: null
}
},
beforeMount: function () {
this.inventory = JSON.parse(this.$el.attributes['data-inventory'].value);
}
}).$mount('#app');Pass the values from the parent component.
Vue looks like it's about 1.8x more popular in China.
As for what's next, I have a hard time envisioning anything usurping React any time soon. Its breed is basically the state of the art in UI paradigm and an active field of research. I'd put things like Elm in that cohort as well.
I think the better question is: what's next for React and its cohort?
When are we going to see these ideas appear first-class in Cocoa/UIKit/etc? When will we finally see "OOP is good for UIs" (OOP's final foothold in our dogma) lose out to "FP is good for UIs"? What's the next big thing inside the React ecosystem? How far can something mainstream like React move towards the strictness of something like Elm?
This may contribute to Vue being downloaded through npm in lower volume than React
JSX + Vue + TypeScript is pretty nice.
HTML templates + Vue + TypeScript is not so nice because you get lots of bugs coming from the untyped templates.
I realized that this was going to be a spaghetti nightmare, so decided that I had to choose a real front-end framework.
At that time, Angular 2 was in a alpha,pre-alpha state, React (JSX) seemed to weird, I didn't know anything about Vue, so I chose Aurelia.
At that time Aurelia was going to be the next big thing, but I believe there was a series of technical missteps with Aurelia and I saw that it wasn't going to go anywhere, so changed direction to React.
By the time I started with React, I had months of front-end development under my belt, so I felt more comfortable with it. It had/has a large community with plenty of resources, but I started running into problems with the whole a-la-carte nature of the React ecosystem.
At first, I used a little Mobx for state management, but at that time I had what would be considered several mini-SPA as I was migrating away from server side MVC. After a while I decided to migrate to Redux since that seemed to be the canonical state management solution for React.
Redux turned out to be a productivity nightmare. Redux has its own ecosystem of libraries - Redux Promise, Redux Saga, Redux Forms, etc..The whole complexity was turning me off. Not only that, but other 3rd party libraries like React Router was a big bummer. There is 15 viable styling solutions in the React ecosystem, and the ones I played around with me just didn't stick, but I could deal with the styling issue.
But Redux was just killing me in terms of productivity. There were small abstraction libraries over Redux, but I didn't feel comfortable enough with their small communities to make the leap. Eventually, I moved to Mobx State Tree. I thought that would be the holy grail. I ran into known huge performance issues with Mobx State Tree. That along with some of the leadership issues I had with the project was the final straw for me. I made the tough decision to rewrite everything in Vue.
And I can't be happier with that decision. Vue just seems to have been developed with the number one goal of being productive in mind. Vuex is mostly a joy to work with. I love the built-in SCSS, scoped, etc styling mechanism. The community is great. I'm happy with my decision.
Recent React has made some good strides with Hooks and Context. I'll have to take a look at using React in another project down the road. And I do have an affinity towards JSX, even though right now I don't use it in Vue (which supports it).
And I think things like supporting JSX and more than one way to do thing in the Vue world is its greatest strength. If you don't like the "stringy" of template directives, then you can use JSX, you can write classes or you can write object style components.
I look forward to Vue 3.0 and being able to drop legacy browser support so we don't have to use vue.set and friends because of reactivity issues.
1) 2-way bindings. i used to hate the concept of it as it was a form of black magic and had hard to debug performance issues ala Angular. but in Vue, it is actually fast and straightforward, it's essentially a light boilerplate around getter/setter methods. it took me a while to convert to this way of thinking but once i did, i never looked back.
2) @click, @submit, @emit, :some_property. at first glance, those unconventional symbols/etc irked me and was turned off by it. but after 5 min reading their doc, it became really intuitive and extremely handy. its unlike Angular who have way too many things going on, with Vue its minimal.
The community. Hands down the community. Vue has such a better community than react or angular by a Long shot. If you ever end up needing help and jump into the discord channel. No matter how annoying you are the entire community is always patient polite and helpful. I can’t say my experience has been close to the same in react or angular.
I didn't know react has discord now though. So I'll have to join that as we've got a new react project at work (even tho I wish we were using Vue).
The angular gitter is worse. On their gitter I asked about some performance issues and was told I was "stupid" and "don't do it like that" even tho that's how the documentation showed how to do it, and "you shouldn't be using Angular because you don't know what you're doing". (I was eventually helped in a private chat by someone and resolved the performance issues just changing a few things, but this was driving force to ditch Angular and move to React)
Edit: Also for you to reply with concern does give me more faith that the community may be better than I thought. I appreciate your time to read my comment and reply.
If there’s negative behavior from those communities or if they’re not moderated well we’d love to be alerted so that we stop sending people there. What you went through with that gitter chat sounds horrible!
Case in point, any whiff of dissatisfaction and Dan Abramov will comment on your post. Literally can't get any better service than that.
There's an invite link at https://www.reactiflux.com . Please come by and say hi! We've always got a bunch of folks hanging around happy to help answer questions.
I think it'd be a lot easier to pick up react now that I'm proficient with Vue.
function HelloWorld(props) { return <h1>Hello World from {props.name}</h1>; }
function App() { return ( <div> <HelloWorld name="Sara" /> </div> ); }
ReactDOM.render( <App />, document.getElementById('root') );
That's pretty much the whole thing.
Oof, I haven't heard that word in awhile.
That's the problem with large-scale Vue apps. Vue is awesome until you need to use VueX, after which it just becomes an inferior version of React + Redux.
I found Redux to be highly over-engineered in contrast to Vuex which is a lot like MobX - easy to use, yet powerful.
Redux is a couple hundred lines of code. A good way to learn the pattern it to reimplement it yourself - which you could probably do in ~100LOC if you ignore the helper functions
That's not a refutation of the parent's statement.
Reading up on VueX.. Not really looking forward to having to use it over MobX.
What does this mean? I've used MobX in the past but curious what has changed with this.