After using React, I am firmly in the #nevertemplates camp. I don't ever want to learn a template DSL again when I could be using the full power of javascript.
Same here. In my opinion JSX is one of the best thing happened in the front-end world. Let's not forget how horrible Angular templating was: {{::item.name}}
Why we chose Vue.js
271–280 of 282 posts
Re: Why we chose Vue.js
#272Earlier quoted context omitted.
Isn't Vue.js hype too? I mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)
Personally it's Angular 2.0 for me. I'm a big fan of Angular 1.0 but can't stand how complex it has become. I want to be able to start using a framework in a matter of hours, not weeks. Most of Angular 2 complexity is unecessary and I write large SPAs ,not toys, but I don't like the noise. I use Go and Python on the server, I don't want to have to manage a Java style application on the client, because that's what it…
Re: Why we chose Vue.js
#273Earlier quoted context omitted.
You only need to look at a DevTools timeline to see that it's the front-end which is slow: https://www.webpagetest.org/result/161021_08_XZF/ 600KB of CSS, 800KB of JS... That's fine on your MBP over WiFi but on most pages it locks up the main thread on my phone for a good 5-10 seconds.
Hi wldlyinaccurate, thanks for your comment. There are a lot of frontend performance things we are focusing on for the next release. https://gitlab.com/gitlab-org/gitlab-ce/issues/23213 .
Is there a strategy to tackle the CSS and JS bloat?
Is performance something the front-end endboss folk consider important enough to delay feature releases?
Are you monitoring performance with a tool like SpeedCurve?
Re: Why we chose Vue.js
#274The company I work for has an app built with Angular 1.x (the backend is .NET). We started sensing that Angular was not best choice, especially when working with 3rd party components. There are other factors to, but they have been already mentioned in other comments. Long story short, we had enough of wrapping everything in $timeout and started looking at alternatives. After some consideration, we were left with choo…
Re: Why we chose Vue.js
#275The company I work for has an app built with Angular 1.x (the backend is .NET). We started sensing that Angular was not best choice, especially when working with 3rd party components. There are other factors to, but they have been already mentioned in other comments. Long story short, we had enough of wrapping everything in $timeout and started looking at alternatives. After some consideration, we were left with choo…
Re: Why we chose Vue.js
#276Earlier quoted context omitted.
I've heard this argument before and I find it fascinating. Why can't we have something that is both standardized and easy to pick up? Is there something inherent to one that blocks the other? Any ideas? Disclaimer? I don't use Vue, but I've seen this argument made for Ember (against Angular 1.x) and Angular 2 (against React).
>Why can't we have something that is both standardized and easy to pick up? Simply because one has to learn the standards in the former case. In the latter, it is mostly left to the users imagination and their own sensibilities, which differ from person to person.
Re: Why we chose Vue.js
#277There's something that irks me about incorporating logic into templates. UI development is hard enough without having to bounce between js and templates to figure out how a component is actually going to behave. I haven't used Vue or React, so this is all just my gut speaking, but at least with React all the logic is there in front of you. In my mind, if there's a loop or a conditional or whatever piece of logic that…
Then you get into the gray zone with filters and v-if but somewhere you have to do switching and for many things, having the code where it is actually used makes most sense.
The data should decide what will show up and the template should decide how. Eg: if data.ok img.url=ok.png else img.url=error.png
The if there is totally okay to have in your template because it's deciding how the data should be presented. The data model should not need to know which images are being used, or even care that you are using images at all.
Re: Why we chose Vue.js
#278Re: Why we chose Vue.js
#279Earlier quoted context omitted.
>Why can't we have something that is both standardized and easy to pick up? Simply because one has to learn the standards in the former case. In the latter, it is mostly left to the users imagination and their own sensibilities, which differ from person to person.
But does being "easy to pick up" intrinsically mean things are left to the user's imagination? Can't we make something that is standardized AND easy to learn?
Re: Why we chose Vue.js
#280I am more and more of the opinion that you should NOT use a js framework for long term projects (that span more than a few years), but just use vanilla js with some libraries that you can easily switch when something better comes out. Vue.js is here today, and it is nice, but tomorrow gintzx.js comes out, and the community will be flabbergasted and everyone will use it and vue.js will slowly die. Making big complex w…
There are many ways to make good views with dynamic updates, but there are even more ways to make them spaghetti.
A framework is simply a pattern that takes a certain approach to solve a problem. The lifetime of it is mostly irrelevant. Vanilla JS changes too.