Live data from Hacker News

Why we chose Vue.js over React

pixeljets.com

131–140 of 267 posts

Re: Why we chose Vue.js over React

#133
post #102

Earlier quoted context omitted.

What does "want you to do things their way" even mean? Aren't you doing things a certain way by virtue of using a framework? Maybe angular/react is just making you do things in a way that you prefer not to, while vue.js is making you do things in a way that you find reasonable. For other people, it's the reverse.

If you have to do things in a specific way, then you are forced to learn that at the same time as you are learning the technology. Learning just vue on the other hand, is much easier when you can retrofit your existing knowledge into it. Then worry about the 'proper way' later when you have made your first few apps. I already have boatloads of knowledge, and whilst it may not be '2016', it's been good enough for the…

Try looking for react + mobx tutorials.

Re: Why we chose Vue.js over React

#134

I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front. That being said, JSX vs. wrapping HTML in if-statements seems like the same kind of trouble to me. I've done a few simple prototypes in Clojure/Script, so my reasoning is heavily influenced by the fact that I know very little about other languages, and only have moderate amount of knowledge about Clojure. The solution I…

Can you tell me what clojure libraries/frameworks work the way you describe? I'm learning clojure and would like to build some toy web apps because I've never done webdev before.

Start with Figwheel[1] to enable hot-loading code and live reloading:

  lein new figwheel 
I have used Reagent[2] since I'm only doing prototypes and don't have to worry about production quality. Om/Om Next[3] seems like it would be worth checking out since it does a bunch of clever things that Reagent doesn't. Reagent is very straightforward and therefore might be the better starting point, seeing as you're just starting out.

Like the sibling comment pointed out, Reagent uses Hiccup-style data structures to represent HTML. Om can be configured to do the same, but doesn't out of the box last time I checked. Either way, the Hiccup syntax looks like this:

  [:div [:h1 "Hello world"]]
It's just regular arrays with symbols, strings and what-have-you, meaning you can construct them using standard Clojure functions in any way you see fit.

Add either Reagent or Om to your project.clj, and off you go.

[1]: https://github.com/bhauman/lein-figwheel

[2]: https://github.com/reagent-project/reagent

[3]: https://github.com/omcljs/om

Re: Why we chose Vue.js over React

#135
post #43

I hope I don't get downvoted for asking this but is React going out of fashion already? A lot of the talk about it was "React is here to stay" or "React is as permanent as JS itself" but now this is the second or third time people seem to be going for Vue instead. What happened?

I can't see React going away soon. It really does work well, and a lot of the author's problems aren't not unsolvable problems. Some are so easy to solve that many people probably never thought of them as problems (Micro components and forms have never been an issue for me.) The only real issue that I agree about is the excessive typing, but that seems like an adequate trade-off. His complaints about pure functions and immutability seem strange to me, because these aren't abstract concepts that neckbeards like in order to appear smart, they actually make programming easier. My team (about 15 front end devs) built an extremely large, complex app in a relatively short amount of time with React, and it's scaled surprisingly well. At scale, it's not easy, but that's because any huge app is going to be difficult to build.

Re: Why we chose Vue.js over React

#136

I'm a designer and not a coder, so I feel obliged to provide my comments with salt added up front. That being said, JSX vs. wrapping HTML in if-statements seems like the same kind of trouble to me. I've done a few simple prototypes in Clojure/Script, so my reasoning is heavily influenced by the fact that I know very little about other languages, and only have moderate amount of knowledge about Clojure. The solution I…

That is what React does, though: you write your page using a data structure (in JSX, an XML-based DSL, or you can use the createElement function directly), and then the React engine parses, diffs and renders your data structure into the DOM. This was React's most touted advantage at the beginning: you write what you know (JavaScript), and React handle's the tricky DOM stuff. JSX isn't templates, it's JavaScript.

Clojure(Script) benefits greatly from the fact that Clojure's data structures are much more expressive and robust than JavaScript's, and so a thing like JSX that paints over some of the language's warts is less necessary.

Many people opt for using something like virtual-dom or snabbdom instead, which provide a more Hiccup-like API on a surface level. There are wrappers for React (react-hyperscript) as well.

Re: Why we chose Vue.js over React

#137
post #130

Earlier quoted context omitted.

Check out Weex

Also not Vue based, right? Link for lazy & curious: https://alibaba.github.io/weex/

Technically not yet, but from the official Vue 2.0 release announcement:

> we have started an official collaboration to make Vue 2.0 the actual JavaScript runtime framework for Weex. This will enable users to write universal Vue components that can be reused across Web, iOS and Android! The collaboration is still in early stages, but it will be a big focus for us now that 2.0 is out, so stay tuned!

https://medium.com/the-vue-point/vue-2-0-is-here-ef1f26acf4b...

Re: Why we chose Vue.js over React

#138
post #11

One of the most impressive thing about Vue.js was the ability of the framework to enter a field saturated with dozens of options, that was becoming dominated by a well-resourced oligopoly (Angular, React), and still win over developers jaded from Javascript-fatigue. The give-a-shit factor from Evan (the creator) is extremely high and was key to its success. Inspiration for anyone building a product in an established…

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 finally decided earlier this year it was probably worth my time learning a framework just to get some structure in my code, so I asked a webdev friend if he had any recommendations for a JS framework I should try; he pointed me towards Vue. I had never heard of it and was skeptical, but I started working through the quickstart guide (Vue docs are great, another +1 to Evan!) and I was hooked before I finished the third example. It was night and day from jQuery, but easy to learn. My experience so far is that Vue (in contrast to jQuery) is astoundingly flexible for how terse it is. My code was probably bad, but rewriting a jQuery page in Vue usually halved my linecount.

>no transpilation

This is huge to people who just want enough JS to get their proposed feature working and don't want their whole site to be JS, and to beginners. True, at this point I have started getting comfortable with the npm/webpack/babel/es6 stack and I enjoy the things it makes convenient - but at the beginning it's a pretty nontrivial learning curve and delayed benefit for a dev team that have probably been doing most things on the server with python or php.

>Vue.js looks like a nice middle ground... while also nurturing some of [React's] ideas

YES. My first three tries in Vue were basically little calculators that hit some APIs and got some user input and displayed data. I had no idea what "components" were and my calculators were quick to write and worked great. I figured that if I ever needed to use components, there was time enough to learn about them later.

A month later, I decided to dig in and grok React. After a couple of good tutorials, I finally get components and why they can be great. I've never used Vue's component system, but now I have faith that they are as much a pleasure to use as the rest of it.

The great thing about Vue is that it's modular. It can be as simple or as powerful as you need. If you just want to define some behavior and have an object with standardized access to hold the state of your page, you can do that. If you want to use portable components to reduce duplication of effort, you can do that. If you want to enforce Flux design, vuex[0] is there for you. If you want to write a full SPA and need a router, vue-router[1] will do it. If you want to use JSX, there's a Babel plugin[2] for that. None of these are around to complicate your understanding of things when you're learning, but they are easy to plug in when you need them. This is in pretty strong contrast to my experience with React, where you get hit with a lot all at once. Admittedly, I jumped quickly into using Redux and websockets because I was using that one great tutorial that everyone links[3] - so maybe React by itself isn't too overwhelming. I won't hold my breath though.

[0]: https://github.com/vuejs/vuex

[1]: https://github.com/vuejs/vue-router

[2]: https://github.com/vuejs/babel-plugin-transform-vue-jsx

[3]: https://teropa.info/blog/2015/09/10/full-stack-redux-tutoria...

Re: Why we chose Vue.js over React

#139

Earlier quoted context omitted.

this is a different statement than the sentence i responded to. square or round just indicates the direction of the binding. everything in angular is also vanilla js.

I think what he means is that control statements don't exist in JSX. You have to write Javascript to do if-statements, looping, etc. In React, there is no 'direction' of binding---its all one way, just like in vanilla Javascript, and in fact no binding on anything except low level elements' like divs. Components only receive props, which do not do anything at all until you write code that reads them and runs operatio…

i don't see how sprinkling if-statements in your html is cleaner than "magical attributes" but thats just me :)

Re: Why we chose Vue.js over React

#140

Vuejs looks great for POCs or small projects. It feels better like Angular-1 to start with. I use VueJs a lot for small stuff i.e. usually something that I can fit into one index.html file and forget about it. React killed that simplicity (i.e. stopped supporting it). Angular2 - I can't figure out why anybody uses that. But when it comes to larger projects - I still go back to React, TypeScript and Redux. While Vuejs…

More reliable?
Post reply on HN