6 ms·

It's good to see vue.js getting some love. I believe it would be the preferred Web framework these days if it had backing from FB like React does. Too many pe

It's good to see vue.js getting some love. I believe it would be the preferred Web framework these days if it had backing from FB like React does. Too many people fall into the trap of believing a tech is the best just because some big Corp sponsors it. I fell for Angular once for the same reason.

jbhatab 10y ago
disagree. React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale. I think vue is a perfect fit for gitlab but not quite perfect for facebook or a more complex web app on the front end.
- manigandham 10y ago
  what reasons?
- phasecode 10y ago
  Are there any specific reasons you can point to, rather then a blanket statement?
  - rdsubhas 10y ago
    Two-way binding I guess. Once we get used to one-way binding and immutable data structures, anything else feels indeterministic. (Note: Just guessing what the commenter might have written. I'm a long-term VueJS user)
    - vog 10y ago
      This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings. Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern. I'd prefer framworks like React or Riot any time over two-way-binding.
      - GeneralMaximus 10y ago
        > Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?
        elsurudo 10y ago
        Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps). Not sure on macOS, bindings may still exist there.
        vog 10y ago
        That's exactly my point. The concept of bindings (in the sense of two-way-bindings) hasn't proved to be successful - neither today nor in the past, neither on desktop or in the web. As a more general throught: When comparing concepts or patterns, there are often discussions about which one is better, comparing different but almost equally good options. Choosing the "best" one is hard. So the list of advisable patterns is constantly evolving and changing. However, some concepts clearly didn't pay off over decades across a huge variety of settings. These anti-patterns are quite stable, and more or less just growing, not changing. It may make sense to collect these ones. The "good" concepts may be subject to fashion and evolution, but the "bad" ones are stable and hence worth collecting.
        mkalygin 10y ago
        Could you explain why two-way binding is a bad pattern? Why it hasn't proved to be successful?
        pluma 10y ago
        Simply put: because it's magic. Two-way bindings are great for prototypes because you no longer need to think about how your state gets from one place in your application to another, you just shove your mutable state blob into every last part of your application and the framework does the rest. But what you lose in return is the ability to control when state should change and sight of where changes come from. In the case of POJO state implementations like AngularJS 1 it also means you have to constantly diff the state against what you've last rendered to be able to respond to changes nobody told you about. AngularJS 1 actually tried to optimise this a bit but ultimately it needed to pretty much control everything asynchronous in order for that optimisation to work and more often than not that resulted in hapless beginners wondering why their changes aren't always reflected in the UI (answer: because nobody told Angular it should check). So in other words, your state consists of big balls of mud that may change shape without notice and if you pass one of them to any piece of code you must expect it to do just that without any way to tell until it happens (and good luck trying to figure out where it happened exactly). Compare this to the "one-way data flow" React made popular: your state is a bunch of impenetrable rocks that roll into your application, which can't modify them but can do whatever it wants in response to them (e.g. push pixels around on the screen). If the application wants different rocks, it needs to explicitly tell wherever they came from that they should be different, at which point the application will be fed a different (or maybe identical) set of impenetrable rocks again. In a word this is basically the difference between mutability and immutability, taken to the extreme. Although there's nothing in React forcing you to use immutable data structures, the one-way data flow assumes everything it's fed is immutable unless you say otherwise, and you pass in callbacks to be notified when state should change. On the other hand, in two-way binding your state is mutable and extremely malleable by definition, and thus the implicit expectation for every operation is that it may have changed the state. As a side-note: React actually has a dirty little secret called "context" which is the equivalent of thinking with portals: instead of passing ALL the state into your ENTIRE application's root, you pass the state container to a magical Pez dispenser that wraps your application root and then each component can be wrapped in a container that knows about the dispenser and asks it for a specific part of the state. That's how React-Redux works among other things and it's not entirely unlike dependency injection (except it doesn't happen globally but only in the context of the specific instance of the application).
  - bobbytherobot 10y ago
    I'll take a stab, although I don't share the same absolute stance. I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very little for Vue. I need static analysis for my code to prevent errors, Flow answers that. I need a replayable state for debugging errors, Redux gives you that. None of what I mention about React is its sole domain. You can list off many alternatives. Reading through why people choose Vue, many common needs come up. The one that I find interesting is needing a system that Designers can understand because they code up the HTML and CSS. I doubt that is something that comes up with React teams. In my opinion, if you require a framework, Vue and React are two great options. It comes down to various small differences about your team needs. (Please stay away from Angular though.)
    - burriko 10y ago
      I love both React and Vue, but I feel the need to step in and defend Vue a little here. Of the 3 points you listed, Vue has a section in the official documentation dedicated to Server-Side Rendering, ditto for using it with Typescript for static typing, and it even gives you replayable state with Vuex (the official redux-style library for Vue). They really are both great options.
    - Tenhundfeld 10y ago
      A bit OT but just FYI: I think you mean gamut, not gambit.
  - Longwelwind 10y ago
    React managed to make HTML "statically typed". If I make a typo in the name of a component or the name of an attribute used in a HTML tag property, Typescript will catch it. Since Vue & Angular uses template strings, TS can't do the same check. This makes catching errors and refactoring easier. I used to prefer Vue, but since I've discovered Mobx, I only use React now. It took me a lot of time to properly learn the tools, but I'm pretty happy with them now.
- mhd 10y ago
  "at scale"? I hear this a lot of when react gets sold, but apparently most of the time people are using this in the old MongoDB "web scale" meaning, not when it comes to scaling up to complex interfaces (i.e. "we use it like jquery, but get lot of hits/s", not "this is our enterprise CRM desktop that's on par with your average single developer Delphi program").
- M4v3R 10y ago
  > React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale And yet somehow even on my quite powerful Macbook Facebook can halt to a freeze for me when scrolling long feeds or comment threads. One would guess that React would handle those scenarios gracefully, but that doesn't seem to be the case.
  - pluma 10y ago
    You seem to think that because Facebook's website uses React it's a React app. Facebook is no different from other continuously developed applications that evolve organically. In other words: it's probably not a good example for a "best of breed" pure React app. I'm guessing Facebook uses React more on facebook.com than it uses React Native in their mobile app (I think there was an article a while back on HN about the ridiculous amount of packages in their mobile app, which is a testament to their policy of bolting on new code instead of rewriting the old unless actually necessary) but it's a safe guess to say that there's more to facebook.com's frontend than just React.
thewhitetulip 10y ago
Vue has a clean API, just enough. No complex stuff, you can get started in a week!
- jcoffland 10y ago
  Or a day.
nikcub 10y ago
Disagree. React was released in 2013, but use didn't take off until Dan Abramov released his Flux implementation, Redux, in early 2015[0]. That is a full two years of a Javascript view library with the backing of Facebook where it didn't leave much of a mark vs angular. Most of the projects that contributed to React/Redux becoming popular[1] were developed outside of Facebook - altho some of those developers went on to work for Facebook. I'd also argue that it isn't the projects themselves that made it popular, but rather the design philosophy that React/Redux brings to a project that is popular. The Redux part is a Flux implementation, but the React part could also be seen as a "React" implementation - one that certainly has flaws and could probably be improved on much in the same way Flux has been improved on (there are other parts that could use this as well). If you think of the React/Redux style as opposed to React/Redux the code projects i'd characterize it as an ad-hoc, componentized, purely functional and immutable architecture. But that is just listing characteristics, rather than capturing what it is about. Formalizing what it looks like could bring improvements to the ecosystem. I'd also argue that big company backing has little meaning in web application development, unlike enterprise services, hardware and operating systems. I have two enterprise clients who both migrated from jQuery style web applications to Angular 1 largely on the basis of Google's support. They're now both migrating to React/Redux and have been burnt by Google's support - meaning two periods of developer re-training, prototypes, testing and then migrating code in just over a single year. There are similar situations with Microsoft's ASP.NET MVC although they're handling the transition much better. [0] iirc he released it earlier, but first half of 2015 is when React + Redux "hockey stick'd" [1] the term is definitely React/Redux - React isn't (and wasn't) as successful on it's own. Welcome to the new GNU/Linux.
- Vinnl 10y ago
  I very much agree to this. In fact, I'd consider Redux to be more the application of React's ideas to state management than an implementation of Flux: https://vincenttunru.com/A-short-history-of-Javascript-frameworks-a-comparison-of-JQuery-AngularJS-and-React/#react-to-the-rescue https://vincenttunru.com/A-short-history-of-Javascript-frame...
- pluma 10y ago
  A slight tangent: I'm not sure I agree with giving Redux all the credit. There was definitely already some momentum going when Redux was first released although it certainly acted as a multiplier. It's important to remember that even when Facebook first spoke about Flux there was no Flux library. Facebook's Flux implementation came out very late and even then it pretty much only consisted of the dispatcher. There was no example project to look at so all the "Flux-likes" (of which there were many) tried to look at what FB had presented with an MVC/MVVM mindset and attempt to guess what they meant. This Cambrian explosion of "Flux libraries" (few of which really deserve the title) had mostly fizzled out by the time Dan presented his talk on time travel debugging (i.e. Redux). I guess without Redux the community would have settled on something with a lot more ceremony until Rx gained traction -- we certainly wouldn't have seen libraries like MobX and I'm fairly sure Apollo would have looked quite different. Maybe Relay would have been more popular. That said, your core argument still holds: the React ecosystem, although heavily sponsored by Facebook, is not dependent on Facebook by far. There are alternative engines for JSX that aim to be compatible with React to varying degrees (e.g. Preact and Inferno) and Relay is the only state library out there that's directly tied to Facebook the same way React is. Additionally because it's not a monolothic framework but an ecosystem of libraries, React is more adaptable to change. If React were taken in a direction the community disagrees with and make a hard cut like Angular 2 did, Preact could evolve independently and continue providing compatibility layers for React users. On another tangent: the problem with React/Redux is that neither React nor Redux depend on the other and there are other combinations (like React/MobX or Preact/Redux) that share the same general ecosystem. But I guess the same could be said for early GNU/Linux. I've settled on just talking about "React" the same way I settled on talking about "HTML5" when that became a thing ("Is the new website HTML5?" "Yes, by definition.").
Keluri 10y ago
This isn't a phenomena limited to JS frameworks either. These days, anything corporate-sponsored tends to overtake alternatives (Rust vs Crystal, etc)

jbhatab 10y ago

disagree. React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale. I think vue is a perfect fit for gitlab but not quite perfect for facebook or a more complex web app on the front end.

manigandham 10y ago
what reasons?
phasecode 10y ago
Are there any specific reasons you can point to, rather then a blanket statement?
- rdsubhas 10y ago
  Two-way binding I guess. Once we get used to one-way binding and immutable data structures, anything else feels indeterministic. (Note: Just guessing what the commenter might have written. I'm a long-term VueJS user)
  - vog 10y ago
    This. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings. Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern. I'd prefer framworks like React or Riot any time over two-way-binding.
    - GeneralMaximus 10y ago
      > Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Can you elaborate on this? The last time I wrote a native application was 6 or 7 years ago using Cocoa and Objective-C. If I remember correctly, Cocoa had a mechanism that was similar to two-way binding. Have things changed recently? What do modern iOS/Mac applications use?
      - elsurudo 10y ago
        Cocoa Touch (iOS) got rid of bindings altogether and you manage updates manually (although I use a bindings library to emulate the old OSX bindings support in one of my apps). Not sure on macOS, bindings may still exist there.
        vog 10y ago
        That's exactly my point. The concept of bindings (in the sense of two-way-bindings) hasn't proved to be successful - neither today nor in the past, neither on desktop or in the web. As a more general throught: When comparing concepts or patterns, there are often discussions about which one is better, comparing different but almost equally good options. Choosing the "best" one is hard. So the list of advisable patterns is constantly evolving and changing. However, some concepts clearly didn't pay off over decades across a huge variety of settings. These anti-patterns are quite stable, and more or less just growing, not changing. It may make sense to collect these ones. The "good" concepts may be subject to fashion and evolution, but the "bad" ones are stable and hence worth collecting.
        mkalygin 10y ago
        Could you explain why two-way binding is a bad pattern? Why it hasn't proved to be successful?
        pluma 10y ago
        Simply put: because it's magic. Two-way bindings are great for prototypes because you no longer need to think about how your state gets from one place in your application to another, you just shove your mutable state blob into every last part of your application and the framework does the rest. But what you lose in return is the ability to control when state should change and sight of where changes come from. In the case of POJO state implementations like AngularJS 1 it also means you have to constantly diff the state against what you've last rendered to be able to respond to changes nobody told you about. AngularJS 1 actually tried to optimise this a bit but ultimately it needed to pretty much control everything asynchronous in order for that optimisation to work and more often than not that resulted in hapless beginners wondering why their changes aren't always reflected in the UI (answer: because nobody told Angular it should check). So in other words, your state consists of big balls of mud that may change shape without notice and if you pass one of them to any piece of code you must expect it to do just that without any way to tell until it happens (and good luck trying to figure out where it happened exactly). Compare this to the "one-way data flow" React made popular: your state is a bunch of impenetrable rocks that roll into your application, which can't modify them but can do whatever it wants in response to them (e.g. push pixels around on the screen). If the application wants different rocks, it needs to explicitly tell wherever they came from that they should be different, at which point the application will be fed a different (or maybe identical) set of impenetrable rocks again. In a word this is basically the difference between mutability and immutability, taken to the extreme. Although there's nothing in React forcing you to use immutable data structures, the one-way data flow assumes everything it's fed is immutable unless you say otherwise, and you pass in callbacks to be notified when state should change. On the other hand, in two-way binding your state is mutable and extremely malleable by definition, and thus the implicit expectation for every operation is that it may have changed the state. As a side-note: React actually has a dirty little secret called "context" which is the equivalent of thinking with portals: instead of passing ALL the state into your ENTIRE application's root, you pass the state container to a magical Pez dispenser that wraps your application root and then each component can be wrapped in a container that knows about the dispenser and asks it for a specific part of the state. That's how React-Redux works among other things and it's not entirely unlike dependency injection (except it doesn't happen globally but only in the context of the specific instance of the application).
- bobbytherobot 10y ago
  I'll take a stab, although I don't share the same absolute stance. I've run the gambit when it comes to types of front-end projects. The React community has more focus on scaling React for large teams and companies. This isn't to say Vue can't do any of this, but there is a clear focus in the React community. I need to do isomorphic rendering because of SEO, there is a lot of React documentation on that and very little for Vue. I need static analysis for my code to prevent errors, Flow answers that. I need a replayable state for debugging errors, Redux gives you that. None of what I mention about React is its sole domain. You can list off many alternatives. Reading through why people choose Vue, many common needs come up. The one that I find interesting is needing a system that Designers can understand because they code up the HTML and CSS. I doubt that is something that comes up with React teams. In my opinion, if you require a framework, Vue and React are two great options. It comes down to various small differences about your team needs. (Please stay away from Angular though.)
  - burriko 10y ago
    I love both React and Vue, but I feel the need to step in and defend Vue a little here. Of the 3 points you listed, Vue has a section in the official documentation dedicated to Server-Side Rendering, ditto for using it with Typescript for static typing, and it even gives you replayable state with Vuex (the official redux-style library for Vue). They really are both great options.
  - Tenhundfeld 10y ago
    A bit OT but just FYI: I think you mean gamut, not gambit.
- Longwelwind 10y ago
  React managed to make HTML "statically typed". If I make a typo in the name of a component or the name of an attribute used in a HTML tag property, Typescript will catch it. Since Vue & Angular uses template strings, TS can't do the same check. This makes catching errors and refactoring easier. I used to prefer Vue, but since I've discovered Mobx, I only use React now. It took me a lot of time to properly learn the tools, but I'm pretty happy with them now.
mhd 10y ago
"at scale"? I hear this a lot of when react gets sold, but apparently most of the time people are using this in the old MongoDB "web scale" meaning, not when it comes to scaling up to complex interfaces (i.e. "we use it like jquery, but get lot of hits/s", not "this is our enterprise CRM desktop that's on par with your average single developer Delphi program").
M4v3R 10y ago
> React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale And yet somehow even on my quite powerful Macbook Facebook can halt to a freeze for me when scrolling long feeds or comment threads. One would guess that React would handle those scenarios gracefully, but that doesn't seem to be the case.
- pluma 10y ago
  You seem to think that because Facebook's website uses React it's a React app. Facebook is no different from other continuously developed applications that evolve organically. In other words: it's probably not a good example for a "best of breed" pure React app. I'm guessing Facebook uses React more on facebook.com than it uses React Native in their mobile app (I think there was an article a while back on HN about the ridiculous amount of packages in their mobile app, which is a testament to their policy of bolting on new code instead of rewriting the old unless actually necessary) but it's a safe guess to say that there's more to facebook.com's frontend than just React.

thewhitetulip 10y ago

Vue has a clean API, just enough. No complex stuff, you can get started in a week!

jcoffland 10y ago
Or a day.

nikcub 10y ago

Disagree. React was released in 2013, but use didn't take off until Dan Abramov released his Flux implementation, Redux, in early 2015[0]. That is a full two years of a Javascript view library with the backing of Facebook where it didn't leave much of a mark vs angular. Most of the projects that contributed to React/Redux becoming popular[1] were developed outside of Facebook - altho some of those developers went on to work for Facebook. I'd also argue that it isn't the projects themselves that made it popular, but rather the design philosophy that React/Redux brings to a project that is popular. The Redux part is a Flux implementation, but the React part could also be seen as a "React" implementation - one that certainly has flaws and could probably be improved on much in the same way Flux has been improved on (there are other parts that could use this as well). If you think of the React/Redux style as opposed to React/Redux the code projects i'd characterize it as an ad-hoc, componentized, purely functional and immutable architecture. But that is just listing characteristics, rather than capturing what it is about. Formalizing what it looks like could bring improvements to the ecosystem. I'd also argue that big company backing has little meaning in web application development, unlike enterprise services, hardware and operating systems. I have two enterprise clients who both migrated from jQuery style web applications to Angular 1 largely on the basis of Google's support. They're now both migrating to React/Redux and have been burnt by Google's support - meaning two periods of developer re-training, prototypes, testing and then migrating code in just over a single year. There are similar situations with Microsoft's ASP.NET MVC although they're handling the transition much better. [0] iirc he released it earlier, but first half of 2015 is when React + Redux "hockey stick'd" [1] the term is definitely React/Redux - React isn't (and wasn't) as successful on it's own. Welcome to the new GNU/Linux.

Vinnl 10y ago
I very much agree to this. In fact, I'd consider Redux to be more the application of React's ideas to state management than an implementation of Flux: https://vincenttunru.com/A-short-history-of-Javascript-frameworks-a-comparison-of-JQuery-AngularJS-and-React/#react-to-the-rescue https://vincenttunru.com/A-short-history-of-Javascript-frame...
pluma 10y ago
A slight tangent: I'm not sure I agree with giving Redux all the credit. There was definitely already some momentum going when Redux was first released although it certainly acted as a multiplier. It's important to remember that even when Facebook first spoke about Flux there was no Flux library. Facebook's Flux implementation came out very late and even then it pretty much only consisted of the dispatcher. There was no example project to look at so all the "Flux-likes" (of which there were many) tried to look at what FB had presented with an MVC/MVVM mindset and attempt to guess what they meant. This Cambrian explosion of "Flux libraries" (few of which really deserve the title) had mostly fizzled out by the time Dan presented his talk on time travel debugging (i.e. Redux). I guess without Redux the community would have settled on something with a lot more ceremony until Rx gained traction -- we certainly wouldn't have seen libraries like MobX and I'm fairly sure Apollo would have looked quite different. Maybe Relay would have been more popular. That said, your core argument still holds: the React ecosystem, although heavily sponsored by Facebook, is not dependent on Facebook by far. There are alternative engines for JSX that aim to be compatible with React to varying degrees (e.g. Preact and Inferno) and Relay is the only state library out there that's directly tied to Facebook the same way React is. Additionally because it's not a monolothic framework but an ecosystem of libraries, React is more adaptable to change. If React were taken in a direction the community disagrees with and make a hard cut like Angular 2 did, Preact could evolve independently and continue providing compatibility layers for React users. On another tangent: the problem with React/Redux is that neither React nor Redux depend on the other and there are other combinations (like React/MobX or Preact/Redux) that share the same general ecosystem. But I guess the same could be said for early GNU/Linux. I've settled on just talking about "React" the same way I settled on talking about "HTML5" when that became a thing ("Is the new website HTML5?" "Yes, by definition.").

Keluri 10y ago

This isn't a phenomena limited to JS frameworks either. These days, anything corporate-sponsored tends to overtake alternatives (Rust vs Crystal, etc)