Live data from Hacker News

Why we chose Vue.js over React

pixeljets.com

211–220 of 267 posts

Re: Why we chose Vue.js over React

#211
post #103

If you prefer html templates you're going to choose a framework like Vue, Angular or Svelte. If you prefer Javascript driving the show you'll be more comfortable with something like React. The two approaches are duals of each other. Personally I prefer an all JS solution because it's better suited to handle conditions and loops as compared to using custom SGML markup with framework-specific tags and attributes. In my…

Except Vue supports JSX.

Re: Why we chose Vue.js over React

#212

Earlier quoted context omitted.

> [event.target.name]: event.target.value Dumb question but I've never seen this syntax before. What does it do or what is it called? (The brackets)

Computed property names. Any expression whose value can convert to a string or symbol will work. ES6 added them: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Excellent, thanks!

Re: Why we chose Vue.js over React

#213
Clickbait title for the HN crowd, I sense that articles like these are analogous to the old which color to paint the bikeshed debate.

Front-end libraries and frameworks should be trivial because front-end web development is largely trivial, it's the ecosystem around it that has bloated in complexity, including Vue.js and React.

Take a standard API that is already simple enough to understand and use (DOM), and re-package it for people who wish to call themselves "software engineers" to justify the time they spend on making simple things work in a complicated fashion. If you disagree that front-end complexity is getting way out of hand, just read the source code of any modern single-page app including its dependencies.

I think that code written by amateurs cobbling together vanilla JS is generally faster in development and performance, more easily understood, and easier to maintain than code written by a professional web developer using whatever framework. The early web itself was largely cobbled together by hobbyists, and so should it continue to be.

The industry disagrees with me, that's fine. I'm aware there are many reasons why my views are the exception not the norm. I just hope that something far better supercedes this era of web development, which would require social and cultural shifts to occur.

Re: Why we chose Vue.js over React

#214

Earlier quoted context omitted.

> And finally, what stops you from creating a custom component that works like this? I wondered what the issue was myself, so I actually implemented that pattern in a codepen, then looked at the compiled form of the JSX to Javascript. The essential issue is that the value of a prop is always evaluated at runtime, regardless of if the prop is actually used. In the case of props.children this means that and are both ev…

You can get around it with a Babel transform: https://www.npmjs.com/package/jsx-control-statements Disclosure: self-promotion. It's really frustrating that I see this React-is-crap-because-no-conditionals come up again and again but if you want them all it takes is an npm install and a line of babel config :(.

The article doesn't bash react, but it does say that Vue's ability to use conditionals is superior.

Re: Why we chose Vue.js over React

#215
post #122

Earlier quoted context omitted.

> I've done a few simple prototypes in Clojure/Script > I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front. If you are good enough to be able to pick clojure/script which requires a JVM and a specific approach to programming, then you are a programmer.

Fair enough, thank you for the kind words. I feel that a certain amount of humility is due when commenting on a field of study that's not my own. I know that there are many—particularly here, most likely—who have thought far longer and harder about these problems than I have. Edit: by the way, the reason I picked up Clojure is because I (for some reason) watched Rich Hickey's talk Simple Made Easy and thought to myse…

That's a super interesting perspective.

After programming for many years I found Clojure pretty mind-bending, so definitely props for being able to pick it up.

Clojure 100% made me a better programmer. I got pretty in to it for a while but ended up punting and going back to React, and then later Vue, because I really started to feel like the "code is data" thing makes the code really hard to understand at a glance.

Example: in Reagent (this applies to all of the react-wrappers I think), displaying a table is as simple as returning a vector in a certain format; thus my code is a simple function mapping what I have (probably a vector of maps) to what Reagent wants.

Simple. Mathematical. But here's the thing - my brain doesn't work in functions that transform data. Instead, I'm trying to think in HTML, because that's the target result anyway. So I have to kind of parse the code mentally and mentally compile it to what it will "really" look like. Maybe I didn't work with it long enough to get used to it or something, though.

JSX, Vue, Angular really help with that mental compilation step and allow you to see something a lot closer to what's going to be actually output, and therefore make it a lot easier to reason about what the browser's gonna do.

Anyway, I was curious, have you continued working with Clojure very much?

Re: Why we chose Vue.js over React

#216
post #65

The arguments against JSX and React requiring many small components are very surface level and sound like "we couldn't figure out how to make it work for us so it must be impossible". 1. This was mentioned already, but, yes, you can use ternaries and boolean logic for simple conditionals (loggedIn && Logout || Login ) 2. When you need more markup, put them in an if-else statement in the same render function. render()…

When I first started using React, I was very concerned about the lack of template support for conditionals.

In practice, I've find that I now segregate heavy logic into it's own function, which ends up making my components very readable. The lack of first class support for conditionals as a part of JSX has forced me to encapsulate code better.

I would say the only trade-off I've noticed is I end up losing a little bit of DRY-ness here and there with some components having near identical functions. I think it's an acceptable trade off as long as functions are small.

Re: Why we chose Vue.js over React

#219

> Fun fact: Yii was created by a Chinese speaking guy - Qiang Xue. So, you might call Yii+Vue stack not just very difficult to pronounce, but also a Chinese stack :) Fun fact: Qiang Xue got his PhD at Duke University and developed Yii2 while living in the D.C. Area by leading a multi-national team of core contributors, the top 3 being from Germany, Russia, and Ukraine. He also moved on from the project mid-2015 and t…

I don't understand the joke, and the joke seems to hint at a disadvantage since it's being explicitly spotlighted in such a way.

Re: Why we chose Vue.js over React

#220

Earlier quoted context omitted.

I think that, similar to how everyone realized that jQuery wasn't the right tool for certain problems, people are coming to the conclusion that Angular and React+[Flux/Redux/MobX/etc.] isn't always the right tool for certain problems as well. And I think that Vue.js fills the needs for those problems very well. The truth is, the majority of the work I've done in React for my job on the web would have been much better…

You are On. The. Money. When I first started dabbling in web programming a few years ago, I quickly learned about jQuery from SO while looking up common patterns to create the behaviors I wanted in the browser. But even accounting for my unfamiliarity with the browser paradigm, jQuery always rubbed me the wrong way because of how loosely structured it allowed you to be and the amount of leaky scope it encouraged. I f…

> I've never used Vue's component system

Once components click, everything becomes a component.

That's not a two-bit attempt at Javascript zen, what I mean is that components are basically reusable building blocks of functionality. Mastering them provides an excellent way to reason about your app's structure.

Post reply on HN