Why we chose Vue.js • Hacker News Board

Re: Why we chose Vue.js

#251

Post by postcarnival » Fri, Oct 21, 2016, 6:35 PM UTC

subbu wrote: post #229

babyrainbow wrote: post #100

Earlier quoted context omitted.

> it's a seriously underrated benefit. It is not without a cost, the cost being an lack of standard ways to accomplish things. For long running projects where devs may come and go, having a standard way to do things is an incredible advantage, and will result in a much more consistent code base. For real world front end project, this is a much more important concern, imho, than ease of picking up. For your particular…

Long running projects in JavaScript may not be that long really. If you leave any codebase for a couple years, things would have changed so drastically, new devs may not even recognize the code. An year old JS project may be using React, a 2-year-old project could be using Angular, a 4-year old project might be using Backbone, a 6-year-old could have $("#el").bind() all over while 8 year-old project could have been i…

thats an interesting reflection thank you

Re: Why we chose Vue.js

#252

Post by debaserab2 » Fri, Oct 21, 2016, 6:50 PM UTC

catshirt wrote: post #217

jakecodes wrote: post #190

Earlier quoted context omitted.

Hi @49531. Sorry you felt that our conversation was weird. Regardless of my opinion of React, Vue or any Frontend Framework, I never want anyone to have a weird interview. My main feeling with Vue vs. React (maybe this should be a different post, as this post was meant to explain why Vue, and focus on the positives): 1. Vue is minimal to add in with existing code. React, is also not bad, but Vue is much simpler to mi…

1. i can't agree. it's possible to integrate React into your application one component at a time. how is Vue "much simpler to mix in"? 2. i think this depends on your background. if you've had the pleasures and displeasures of working through all the trials and errors of jQuery, then Backbone, then Ember, then Angular... React is painfully obvious to work with. because the problems it solves, the ways it solves them,…

> 4. no... React is in fact just React. you can build a working UI without any supplemental React libraries. how is it "many other things" any more than Vue is?

I don't know if this is what @jakecode's argument is, but the tooling surrounding react builds is pretty bonkers. I can't keep up with the flavor of the week tools, and every single time I say this to someone, they tell me that the holy grail of React build tools is finally out and I just need to check it out. Except that holy grail is different every time the conversation comes up.

I'm not willing to put the build process of my entire app on a tool that's likely going to lose support and maintenance in the near future. It's just too risky and it's a big upfront investment to learn something that's going to be outdated quickly. I don't have the time to integrate something new constantly.

Re: Why we chose Vue.js

#253

Post by catshirt » Fri, Oct 21, 2016, 7:20 PM UTC

debaserab2 wrote: post #252

catshirt wrote: post #217

Earlier quoted context omitted.

1. i can't agree. it's possible to integrate React into your application one component at a time. how is Vue "much simpler to mix in"? 2. i think this depends on your background. if you've had the pleasures and displeasures of working through all the trials and errors of jQuery, then Backbone, then Ember, then Angular... React is painfully obvious to work with. because the problems it solves, the ways it solves them,…

> 4. no... React is in fact just React. you can build a working UI without any supplemental React libraries. how is it "many other things" any more than Vue is? I don't know if this is what @jakecode's argument is, but the tooling surrounding react builds is pretty bonkers. I can't keep up with the flavor of the week tools, and every single time I say this to someone, they tell me that the holy grail of React build t…

i've been using webpack for like 3 years now. hasn't changed- besides my boilerplate getting smaller over time. it's a 5 line .rc file now. ignore the noise.

if we are making an apples to apples comparison, React does not need any external tooling to stand up to Vue.

Re: Why we chose Vue.js

#254

Post by riskable » Fri, Oct 21, 2016, 8:06 PM UTC

PDX_bro wrote: post #239

lossolo wrote: post #31

Earlier quoted context omitted.

I have almost the same experience as you. I am maintaining big Ember app and have exactly the same problems as you described with it.I am interested in Vue lately also because it's so lightweight, easy, well structured, documentation is excellent, ecosystem around it is excellent and i have so much more freedom than in Ember. Author really cares about it, issues on github shows that, only 50 open and 3000 closed.

Interestingly enough, maintaining and developing Vue.js is now the author's full time job! Check out his patreon here: https://www.patreon.com/evanyou

Holy cow this is impressive. How do you think he came to this achievement? Was he marketing himself really well? I honestly would love to know what it takes!

Context: I'm currently developing a new web-based remote desktop tool in Rust and I'm still on the fence as to whether or not to release it open source.

It's a port of some work I did on Gate One that ultimately couldn't be released due to the limitations of X11 permissions in multi-user environments (too insecure).

What's funny is that I'm looking at using Vue for the client!

Re: Why we chose Vue.js

#255

Post by seangrogg » Fri, Oct 21, 2016, 8:06 PM UTC

Yaggo wrote: post #39

kentor wrote: post #32

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.

So what is JSX if not DSL? (Yeah, you can use React without JSX, but still.)

It's a sugar over React.createElement which is just a souped up document.createElement.

JSX:

No JSX:

  React.createElement('div', { 
    className: 'classy',
    onClick: this.handleClick,
  });

Native (note this naive implementation lacks proper scoping):

  var el = document.createElement('div');
  el.className = 'classy';
  el.onclick = handleClick;

This has been available on all major browsers for quite some time, React just provides some convenience around it and a sugar for those that prefer code that looks like HTML because people tend to (fairly, imo) associate their HTML with the state of the DOM.

Re: Why we chose Vue.js

#256

Post by BinaryIdiot » Fri, Oct 21, 2016, 8:46 PM UTC

really_operator wrote: post #74

BinaryIdiot wrote: post #49

Earlier quoted context omitted.

I guess but it feels like such an anti pattern. I have to tag every thing that uses the template system with ng-cloak and that assumes the angular css loads before the HTML which can still not be guaranteed it's just more likely. The worst part is many default values could be displayed but now we're hiding sometimes large junks when for the best UX you should show as much of the page as possible. Ultimately just not…

To reduce the need for ng-cloak, use ng-bind instead of {{value}} It is preferable to use ngBind instead of {{ expression }} if a template is momentarily displayed by the browser in its raw state before Angular compiles it. Since ngBind is an element attribute, it makes the bindings invisible to the user while the page is loading.

Interesting, I forgot about ng-bind (honestly it's a pattern I never see on the web). That is, for sure, the superior pattern.

Re: Why we chose Vue.js

#257

Post by edwinnathaniel » Fri, Oct 21, 2016, 9:01 PM UTC

subbu wrote: post #229

babyrainbow wrote: post #100

Earlier quoted context omitted.

> it's a seriously underrated benefit. It is not without a cost, the cost being an lack of standard ways to accomplish things. For long running projects where devs may come and go, having a standard way to do things is an incredible advantage, and will result in a much more consistent code base. For real world front end project, this is a much more important concern, imho, than ease of picking up. For your particular…

Long running projects in JavaScript may not be that long really. If you leave any codebase for a couple years, things would have changed so drastically, new devs may not even recognize the code. An year old JS project may be using React, a 2-year-old project could be using Angular, a 4-year old project might be using Backbone, a 6-year-old could have $("#el").bind() all over while 8 year-old project could have been i…

Since I've gone through the same experience like this, I'd like to know if this is a norm :D.

I've seen people do write-up of how they re-write the front-end from jQuery to Angular|Ember|React so it's not like there are many long-running JS projects that require solid structure. 3 years old (small-medium size) projects tend to get re-written.

Here's another one that I've seen and experienced before: 10 years old product where some section of the products are written in pure JS, some section in jQuery, some section in BackboneJS + Marionnete, some section using EmberJS.

Re: Why we chose Vue.js

#258

Post by hajile » Fri, Oct 21, 2016, 9:23 PM UTC

debaserab2 wrote: post #252

catshirt wrote: post #217

Earlier quoted context omitted.

1. i can't agree. it's possible to integrate React into your application one component at a time. how is Vue "much simpler to mix in"? 2. i think this depends on your background. if you've had the pleasures and displeasures of working through all the trials and errors of jQuery, then Backbone, then Ember, then Angular... React is painfully obvious to work with. because the problems it solves, the ways it solves them,…

> 4. no... React is in fact just React. you can build a working UI without any supplemental React libraries. how is it "many other things" any more than Vue is? I don't know if this is what @jakecode's argument is, but the tooling surrounding react builds is pretty bonkers. I can't keep up with the flavor of the week tools, and every single time I say this to someone, they tell me that the holy grail of React build t…

React, babel, webpack, redux, react-redux

Vue, babel, webpack, vuex (or redux and vue-redux).

There's hardly a significant difference in requirements.

Re: Why we chose Vue.js

#259

Post by hajile » Fri, Oct 21, 2016, 9:41 PM UTC

Cthulhu_ wrote: post #137

y0ghur7_xxx wrote: post #112

I 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…

I'd like to see more standardization efforts, easier way to separate your business logic from the UI layer. It should be possible already, but there's often still too much interference from the framework of the week. One thing I've been working on lately is writing unit tests (and test runner) that have nothing to do with the underlying framework - no Angular references, no Angular DI, nothing of the sort. Much clean…

We need the W3C to make a `node.replaceWithJsNode(obj)` or similar that takes a uniform vdom object style and updates the DOM accordingly. It would bring together all the different vdom implementations, reduce library size (given time), and would be much faster because of native implementation.

Re: Why we chose Vue.js

#260

Post by hajile » Fri, Oct 21, 2016, 9:59 PM UTC

thaiphanvevo wrote: post #5

nodesocket wrote: post #4

I as well gravitate toward Vue.js for its simplicity, but I wonder if React's mind share and community size "trump" simplicity. For example, if you're hiring for a front-end position, you'll probably get more candidates familiar and experts in React over Vue.js.

The thing is that most React developers don't actually think React is that complex at all.

I spent weeks learning Angular, Ember, and other last-gen frameworks. The todo equivalent was simple, but once you got into their render cycles on a moderately complex project, the wall was very steep.

I started off with simple React apps and it was easy, but I expected to hit a wall. That wall simply never comes like it did last generation. I find it interesting that someone would consider it too complex only a couple years later.