Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js vs. React

vuejs.org

Post reply on HN
Print view View original

451–460 of 486 posts

Re: Vue.js vs. React

#451

Post by jacquesc »

fny wrote: post #37
sudders wrote: post #8

Go for Ember: - Proven tech - No licensing issues - Solid community - Community driven, no company calling the shots

I was a huge Ember evangelist until I started trying to onboard other devs into my project. It took months for people to figure out which way was up. In comparison, other devs picked up Vue in a week or so.

Same here. Going back to some large ember projects I built just 2-3yrs ago, it's almost impossible to comprehend. Also, it's impossible to upgrade to the latest version of Ember due to the amount of churn they went through from 1.x to 2.x

Re: Vue.js vs. React

#452

Post by tomc1985 »

scottmf wrote: post #318
tomc1985 wrote: post #139

Earlier quoted context omitted.

I really don't want Vue to become another React. React used to be a single dependency in the browser and now it is difficult to find examples and discussions that don't require downloading npm and all these other components.

What do you have against npm install create-react-app?

Because I'm programming Rails and I don't want another ecosystem polluting the devspace for these projects. (See the unholy mess that is react-on-rails, what with bringing in v8 when Rails already uses another JS engine). I also strongly disagree with node's module culture, and prefer mature environments. The browser loads scripts, why can't that be enough?

I see React and Vue as tools for scratching very specific itches: fast DOM manipulations and databinding that actually works. React was this, then it grew and grew and grew. Vue is threatening to move away from this.

Also, still pissed that my year-and-a-half old react code is now hopelessly out of date, and requires updating (guess what, I'll be porting it to vue instead). That is bullshit.

Re: Vue.js vs. React

#453

Post by Bahamut »

chrisco255 wrote: post #309
zero_shift wrote: post #219

Earlier quoted context omitted.

I've been in this gig for years upon years and I still don't see what's terrible about two way binding. Can someone actually justify it without handwaving statements like "you'll notice at scale", or red herrings like "Angular is slow"?

Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic. If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you…

I recommend taking a look at how Angular 2+ does it - the Angular team originally intentionally omitted it, but they found a way to make it work in a technically sound fashion (output changes being evented).

The side-effects problem was certainly true with Angular.js - it is not true with Angular.

Re: Vue.js vs. React

#454

Post by simplify »

ksec wrote: post #222
pier25 wrote: post #132

We moved away from React to Vue about 8 months ago and everyone on the team is a lot happier. First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates. It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc. Another problem with React is that it only really solves o…

What makes Marko better then all others in your opinion? Apart from speed which is the only thing I could gather on the Google. And why are there no interest? Because it is from Ebay? I mean look at the reply and no one even want to touch on it.

We run marko in production. My favorite part about Marko is the automatic dependency management. If you already defined a `Modal` component, you can just use it in other components / pages by writing ``. The JS files AND the CSS files will all get auto-bundled into your page.

Marko is also the only framework that supports server-side rendering streaming. This means that your user will start to see HTML even before the page has finished rendering. Afterwards, the page is bootstrapped and components run on the client side. It's very fast.

Re: Vue.js vs. React

#455

Post by nartubio »

tigershark wrote: post #442
nartubio wrote: post #432

Earlier quoted context omitted.

Say you're about to cook pizza or pasta, you use flour and tomato for both. Comparison not 100% off IMO.

No. 1000 times no. For the pizza base you use flour, water, salt and yeast. For fresh pasta most of the time you use flour and eggs. The process moreover is completely different. You NEVER use tomato for making the fresh pasta or the pizza base. You may use tomato as a condiment for pasta and pizza. This comparison is even more wrong than comparing apples and oranges. But I expect that unlike me you never cooked pizz…

In fact I'm a seasoned pizza cook but pasta is still a pending subject of mine.

Re: Vue.js vs. React

#456

Post by Mz »

nartubio wrote: post #455
tigershark wrote: post #442

Earlier quoted context omitted.

No. 1000 times no. For the pizza base you use flour, water, salt and yeast. For fresh pasta most of the time you use flour and eggs. The process moreover is completely different. You NEVER use tomato for making the fresh pasta or the pizza base. You may use tomato as a condiment for pasta and pizza. This comparison is even more wrong than comparing apples and oranges. But I expect that unlike me you never cooked pizz…

In fact I'm a seasoned pizza cook but pasta is still a pending subject of mine.

In fact I'm a seasoned pizza

I completely misunderstood your comment. I might need to go get food soon.

Re: Vue.js vs. React

#457

Post by breeny592 »

hunterxg wrote: post #439
timmy-turner wrote: post #396

Earlier quoted context omitted.

Right, being able to compose, test, structure and develop my HTML in the same way I'm doing it with my application code is for me the main Reason for never wanting to go back to anything that's based on classic string-like templating. The latter always felt as clunky as programming without a proper function abstraction.

For me it's quite the opposite. I find that so confusing when you look at html in JavaScript and don't know right away what the result will be. It's like were back in 2002 doing PHP.

Different strokes for different folks - my thought to that is pretty much that I don't really care what the result will be on the grand scheme, but more specifically isolated nodes and how they will interact with my model/data etc.

Having the ability to see exactly what's in scope right next to the markup to me is invaluable - one of my biggest dislikes in templating languages is swapping between files that define the data in the scope and the template to use said data.

Re: Vue.js vs. React

#458

Post by chrisco255 »

Bahamut wrote: post #453
chrisco255 wrote: post #309

Earlier quoted context omitted.

Side effects and testability. Two way binding is great for simple forms, if you have like a dozen or so variables on a page? Two way binding is awesome and allows you to write very terse code and logic. If you start adding dynamic forms, multiple developers, unit tests, and advanced interactive application logic, then you are left with a spaghetti code mess (with 2-way binding). The problems really creep up when you…

I recommend taking a look at how Angular 2+ does it - the Angular team originally intentionally omitted it, but they found a way to make it work in a technically sound fashion (output changes being evented). The side-effects problem was certainly true with Angular.js - it is not true with Angular.

Angular2+ is an improvement, no doubt, and the eventing based system is not unlike React's in that sense. Although it does require you to instantiate an EventEmitter which is somewhat arbitrary. Still, it's a better data flow model overall for sure.

Re: Vue.js vs. React

#459

Post by scottmf »

tomc1985 wrote: post #452
scottmf wrote: post #318

Earlier quoted context omitted.

What do you have against npm install create-react-app?

Because I'm programming Rails and I don't want another ecosystem polluting the devspace for these projects. (See the unholy mess that is react-on-rails, what with bringing in v8 when Rails already uses another JS engine). I also strongly disagree with node's module culture, and prefer mature environments. The browser loads scripts, why can't that be enough? I see React and Vue as tools for scratching very specific it…

Your year and a half old React app shouldn't be "hopelessly out of date" unless you did something very wrong.

If you want to use React with Rails, use Rails in API mode and keep the front-end separate. I'm not sure how rewriting in Vue is going to solve any of your problems at all.

"The browser loads scripts, why can't that be enough?"

Not sure what you mean by this. Whatever you use, the browser will be loading scripts.

Re: Vue.js vs. React

#460

Post by breeny592 »

tigershark wrote: post #389
chrisco255 wrote: post #293

Earlier quoted context omitted.

In my experience, the folks that feel the strongest against JSX lean anti-JavaScript in general. JSX is Turing-complete. There are no gotchas, you can't paint yourself into a corner, you can set breakpoints in your map statements, it's more testable...Lots of benefits and a big step up over string-based templating languages stuffed into HTML.

And how in the world is that a good thing? I'm really starting to wonder if people that exalt JSX with his mix of logic and presentation have ever worked on complex systems where the lack of separation between the two layers brings you quickly to an unmaintainable mess.

Separation of concerns != splitting logic from presentation.

SoC comes from MV* architectural patterns. In real world front end applications, people who separate based on the file extension often end up creating JS files that breach SoC - they are both handling view rendering as well as application logic inside a JS file.

If there is something that should be conditionally rendered, using JSX is no different to a template language - only thing is the variable you're using to do that isn't actually in that file either (so, over-separation of concerns?). Both of these are logic - one handles it inline and the other handles it across multiple files.

No one is advocating that JSX should break SoC (a component should never talk to an API, or implement business logic - it should be responsible for given a set of inputs, it will render the same output time and time again).

Post reply on HN