19 ms·

Why we chose Vue.js over React

• romanovcode 10y ago
  In short: FOTM
• tyingq 10y ago
  I was initially confused about why a Drupal shop would need either Vue.js or React, since Drupal sites are most typically blog like things. Appears it's for their backend though, and this is actually pretty nice: http://pixeljets.com/sites/default/files/why-we-chose-vuejs-over-react-282.gif http://pixeljets.com/sites/default/files/why-we-chose-vuejs-...
  • fabian2k 10y ago
    Drupal is a bit overkill for a blog-like site, my impression is that it is usually used for more complex sites than e.g. Wordpress. With the latest version Drupal 8 there also was a push to make headless Drupal easier, which is pretty much just the Drupal data exposed as an API so that you can create SPAs for it.
    • tyingq 10y ago
      More complex, sure. But it's still very centered around taxonomy with dates/sections, end user editing of nodes with WYSIWYG, page centric tags, etc. Very blog like. Seems like a big hammer for use as a datastore for an SPA.
      • snurycombinator 10y ago
        That was true back in Drupal 6 in 2008. Drupal 7 and 8 use entities, which are arbitrary combinations of fields that can be composed through the UI and accessed through APIs via JS or other methods. One thing we use it for is its user management which is good enough out of the box.
  • dnm 10y ago
    Blog like things? http://www.nba.com/ http://www.nba.com/
    • tyingq 10y ago
      Yes. And you could produce that with wordpress as well using custom post types, with probably a similar amount of headache. They are both CMS systems that primarily handle taxonomy, nodes, tags, WYSIWYG editing, etc.
  • deleted 10y ago
    [deleted]
• adamnemecek 10y ago
  It's been a while since I've needed a front end framework but if react doesn't scratch your itch, you should check out cycle.js. https://cycle.js.org https://cycle.js.org
  • k__ 10y ago
    Really good framework indeed. One of the few who are really good in handling realtime data. Its dataflow-components are much more flexible than React components, which makes it really more flexible.
    • adamnemecek 10y ago
      Also everything I've read from the author http://staltz.com/ http://staltz.com/ I either agreed with (http://staltz.com/all-js-libraries-should-be-authored-in-typescript.html http://staltz.com/all-js-libraries-should-be-authored-in-typ...) or found really illuminating (http://staltz.com/unidirectional-user-interface-architectures.html http://staltz.com/unidirectional-user-interface-architecture...).
  • Roboprog 10y ago
    I stumbled across Cycle.js a few weeks ago. I like the idea, but the examples still seemed a little clumsy. I would like something similar, but a little more opinionated, with some shortcuts for booting up a simple project that sprinkles some "magic markup" in an existing page to drive a backend event handler / mapper-reducer function.
• andrew_wc_brown 10y ago
  MITHRIL JS
• conradk 10y ago
  I've been using Vue.js at work for this kind of thing: http://reassurez-moi.fr/taux-pret-immobilier http://reassurez-moi.fr/taux-pret-immobilier It was as simple as adding Vue.js itself and one JS file for custom code. I tried using Angular but right off the bat, I had to install hundreds of dependencies via NPM. That's what I like about Vue.js. It's simple to reason about for the kind of use case I linked above.
• sergiotapia 10y ago
  My man, a lot of the pain described in this article can be solved by Mobx: https://stackshare.io/mobx https://stackshare.io/mobx One of our engineers at StackShare[0] suggested it and it's fantastic. Mobx is very simple to understand and will make writing a "React" page a real joy again. Redux was way too complicated for what it gave, and just shot term after term after term at me that left me with a headache. I still don't understand Redux proper. >Why do you have to type so much? I know! I nope'd away from Redux because of that same reason. But Mobx clicked for me. And if it clicked for me, it'll click for you. Basically you have a store and you use that store anywhere in your components to share store state. When you update that store state everywhere else updates as well. Simple. Another great reason to use React as opposed to alternatives is react-native. A _lot_ of knowledge transfer between the web and mobile with react native. It's pretty insane. [0] - https://stackshare.io/stackshare/stackshare https://stackshare.io/stackshare/stackshare
  • inglor 10y ago
    I agree 100%, MobX is like a full order of magnitude performance upgrade for me over redux. You can just think of it as "automatix redux + reselect". People think they use redux for immutability but in my experience most people just use it for updating the view when the store changes and end up with a lot of denormalization and stale state. With redux you derive as much state as possible which is great.
  • dfarts 10y ago
    The problem with the JS world.
    • sergiotapia 10y ago
      You can use React vanilla if you want, but you will spend a lot of time keeping props in sync and making sure changes are invoked up the chain. So cool, you nailed that down vanilla - you're awesome. Or you can just Mobx and not worry about it. It's not like you're forced to use Mobx. Even when I worked with Windows Forms in .NET 2.0 you still had to have some way to keep values in sync, and instead of "Mobx" you had some home-grown monstrosity.
• juandazapata 10y ago
  I'm glad to see that Vue is getting more adepts. Kudos to the core team for making it so easy and accessible for everyone.
• jplusplus 10y ago
  I believe React is popular (among other reasons) because you don't need to learn what is v-if v-else and other repeative commands when you have plain and simple JS equivalents. React has te philosophy "It jusy works", and people love this
  • k__ 10y ago
    Yes, I think the main selling point of React is it's tiny and intuitive API. I don't know how these frameworks compare in bigger sized applications, but if you just do a POC in Angular2, React and Vue.js, then React beats all of them. This probably leads to many people considering React for their new applications. If you go for bigger stuff, I don't know which would be better. I like React, but I also found it a bit cumbersome to create all these Redux actions and stores etc. Also async stuff, especially righ datarate websocket stuff, seem a bit awkward with Redux.
    • Bahamut 10y ago
      Do you have numbers? Angular 2 is quite small if you're using treeshaking.
      • boubiyeah 10y ago
        Not really; it has a big unshakable core
        • Bahamut 10y ago
          Got numbers? I know someone who was able to get a simple app down to below 30kb including polyfills (albeit with a lot of work using Google Closure), and from what I understand that was before AoT compilation was there. Much of the core is shakeable, I don't believe your assertion at all. As you use more features, the app size would grow would be true due to using parts that were previously shakeable becoming unshakable, but that complexity being in a unified language/base of a framework worked on by very smart people is most of the time better than homebrewed business logic by an above average developer
• welanes 10y ago
  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 market: there's almost always room for better.
  • inglor 10y ago
    VueJS is pretty old, old enough to be there when React and Angular were just emerging as viable options. It's great, and I'm grateful for it being around and for Evan's contribution but I think it was pretty lucky timing wise.
    • ceejayoz 10y ago
      Angular was released in 2010. Vue was released in 2014. Bit weird to call it "pretty old", and Angular was well established by then - they announced the v2 preview around the same time.
      • enraged_camel 10y ago
        >>Vue was released in 2014. That makes it pretty old. This is JavaScript we're talking about. :) And Angular 2 is different enough from Angular 1 that it might as well be brand new. So I think the OP's comment is valid.
      • inglor 10y ago
        2014 was the year Angular "really took off" and 2015 was the year React "really took off" (at least, if we trust "Google Trends") Vue is, in its core, very similar to Knockout (which I think is pretty swell). I think coupled with a better DOM abstraction (like React) it can do great thing - that's what MobX does and why I like it. I sympathize with the post's sentiment of giving UI people work.
    • welanes 10y ago
• ronocod 10y ago
  I'm not sold on the whole "code quality" vs "getting things done" mentality here. I think there are diminishing returns in reducing technical debt and keeping a high quality codebase, but the point of doing it that you can maintain a sustained, relatively high "getting things done" rate over the project's lifetime. There are times where you should implement something in a quick and easy way, but if code is going to be present and important for a long time then going the extra mile usually pays off.
  • rockdoe 10y ago
    Some of this reminded me of the discussions about logic-less templates and proponents/opponents of that philosophy.
  • eternalban 10y ago
    > I'm not sold on the whole "code quality" vs "getting things done" mentality here. https://vuejs.org/v2/guide/comparison.html https://vuejs.org/v2/guide/comparison.html Based on above, I don't think the dichotomy you pose is applicable in this comparative case.
• nojvek 10y ago
  Thanks for the detailed write up and comparisons. Also kudos for not bashing other frameworks and giving a level headed comparison. Two big things I noticed that drove you away from react. 1) too many subcomponents: I think jsx can be improved to have logic tags within them. E.g <js:for> and <js:if> tags that the transpiler can move to ternery and array map calls. 2) too much verbosity: something like mobx or deep-observable can help here. Honestly react has become the Java of UI. Going back to fundamentals. All you need is a tiny library that diffs a vdom tree to real dom. And you need a tiny library that allows you to observe a single source of truth object and connect it to view.update() changes. All in all this shouldn't take more than 5kb of code. We all want: good abstractions, fast performance, actionable errors and small library so the page loads in no time.
• kimshibal 10y ago
  Our company migrated to vue.js, 6 months ago. Our complex app is messy with JSX, router, and new dev can't keep up with code. Now we start every new app with Vue.js. The gap between junior dev and senior dev comes closer. They can collaborate with less bugs, less problems and less time to develop.
  • jackyb 10y ago
    Interesting. I'm also looking at Vue.js and wondering how it can benefit me. Just one thing that I want to know: how do you do checks and tests in it? Are there any frameworks or tools to do that?
• joatmon-snoo 10y ago
  Out of curiosity, one reason the author mentions (and I know, it's not his selling point) which I've seen others reiterate is that React's render() method doesn't support if statements. I know you can write something like the code below in React, so what exactly does that criticism refer to? function Home(props) { return ( <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> { (() => { if (props.location.query.home) { return ( <p>You specified a home query: { props.location.query.home }</p> ); } else { return ( <p>No home query was specified.</p> ); } })()} </div> ); }
  • M4v3R 10y ago
    Yeah, it's possible in React do to it. But compare that to how Vue handles conditionals: <template> <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> <p v-if="location.query.home">You specified a home query: {{location.query.home}}</p> <p v-else>No home query was specified </p> </div> </template> I don't know about you, but to me this code is 100% more readable than the React example you gave.
    • insin 10y ago
      This is how I've come to write that in React, after giving up on attempting to find a consistent way to write ternaries which I would find acceptable when revisiting them (it just never happened): let Home = ({location}) => <div> <h2>HELLO</h2> <p>Duis a turpis sed lacus dapibus elementum sed eu lectus.</p> {!location.query.home && <p>No home query was specified.</p>} {location.query.home && <p>You specified a home query: {location.query.home}</p>} </div> I usually put all the possible negative cases first because outside of micro-snippets they tend to be short and sweet compared to the positive condition.
      • bestest 10y ago
        Come on people. It's so much simpler: return ( <div> <h2>hello</h2> { location.query.home ? <div>foo</div> : <div>bar</div> } </div> ) Or just replace that with a one-liner like, and put the respective code where it belongs: {location.query.home ? this.renderHomeStuff() : this.renderEtcStuff()} And simple ifs are obvious: <div> <h2>hey</h2> {foo && <div>foobar</div>} </div> Always strive to make your render methods simpler.
• dongslol 10y ago
  I find it completely unbearable to use React with plain JS. I have to use at least Coffeescript and if possible Livescript or Clojurescript. Vanilla JS is just too clunky. The problem with JS is there are too many patterns in the code, like the mentioned list.map(function(whatever) { ... }). Because JS is a medium power language it doesn't let you abstract this stuff with macros or at least rewrite the syntax. Coffee and Live provide some relief, but Clojurescript is heaven.
• caub 10y ago
  I wonder why people need Redux, Using simply React is great and enough if you understand it well
  • exception_e 10y ago
    React is just the UI piece of the puzzle. Here's a nice description of when to use Redux: "[Redux is justified when] you have a piece of data that needs to be used in multiple places in your app, and passing it via props makes your components break the single-responsibility principle (i.e. makes their interface make less sense)" (https://github.com/petehunt/react-howto/issues/12#issuecomment-169546558 https://github.com/petehunt/react-howto/issues/12#issuecomme...) This comment was written for Flux, but it is completely applicable for Redux. When building something non-trivial, there are other pieces you'll want to pull in with React such as routing, messaging, etc.
    • caub 10y ago
      Yea I know what Flux, Redux are, and honestly I think they are completely not needed if you understand and use React well, see comment below
  • ulisesrmzroche 10y ago
    No it's not. You can't communicate cross components with just react, you're stuck on a parent-child relationship.
    • caub 10y ago
      you can by passing right state to the closest common parent. I pass props down, and a custom update function, easy, efficient (with PureComponents)
• jolux 10y ago
  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?
  • heysunshine123 10y ago
    Well, there's a difference between going out of fashion and being revealed as something that shouldn't be used (like Angular and Ember). Maybe Vue is just becoming the new shiny.
    • jolux 10y ago
      So React showed that Angular and Ember shouldn't be used, but Vue is just shinier than React right now?
      • iLoch 10y ago
        No one gets fired for using React. Vue isn't even shinier in my opinion. It makes the same templating mistakes that Angular and Backbone did.
        • human_error 10y ago
          What are those mistakes? I don't do front-end development so my knowledge is very limited with these (I know the names and a basic idea what they do)
          • iLoch 10y ago
            To me, it's the reintroduction of custom templating. I appreciate E4X/JSX syntax because it's just a thin layer of sugar which is compiled to regular JS syntax. It also lacks custom implementations of loops etc, requiring the user to write _Javascript_ not some non-standard templating language.
    • 10y ago
• insin 10y ago
  I think your opinion on putting weird stuff in your HTML attributes vs. putting weird HTML-like stuff in your JavaScript is enough to make an early call on whether you'll prefer React-like libraries or Vue-like libraries. As a programmer, React has been my go-to UI library for quite a while because I see always being in JavaScript mode as a benefit (no invented scope to learn or inject things into, no invented logic to learn, everything is lintable, easy-to-follow state change flow) that's worth the drawbacks (un-pretty conditionals in render(), manually handling form input), but I can also echo the feedback in this article when it comes to having designers working on your components. > JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each. > ...this approach of splitting components into super-dumb components because of JSX restrictions will always put you out of flow when you are solving real business task I don't understand what this has to do with JSX without an example. > ...now you have to create 10 functions to get input from 10 inputs. 80% of these functions will contain single line with this.setState() call Working with forms is definitely one of the most painful parts of React, and one of the differences I most enjoyed when porting our sample app to Vue.js 1.x for inputs which only affect the value they bind (most interesting thing I learnt: the React component structure the original was written with mapped almost verbatim to Vue.js components, the main difference was in flexiblity of what you can pass down the tree - e.g. React components as props, but I believe Vue.js 2.x is now closer to React's flexibility), but most of this section comes across as hyperbolic. Writing onChange handlers which are as generic as you can get away with for the current form is key, but it generalises to setting state based on input names, which can as be simple as the name of the state variable, or a path in state which should be set for simple form input even in deeply-nested forms, plus the appropriate value based on the input type. e.g. if you're doing a simple form with text inputs, selects, radios etc. where checkboxes always correspond to boolean state, you could use this for every field (you don't even have to put it on each input, you can let onChange bubble up to a form with onChange={this.handleChange}): handleChange(e) { let {name, type} = e.target let valueProp = type === 'checkbox' ? 'checked' : 'value' this.setState({[name]: e.target[valueProp]}) } (It's game over for simplicity once you want to do proper, user-friendly form validation, but that's a truth universally acknowledged :))
• sebringj 10y ago
  My only issue with Vue is using programming flow within tags. This gives me acid flashbacks of coldfusion spaghetti horror.
• caleblloyd 10y ago
  > 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 the other maintainers have run day-to-day operations since then. It's not a "Chinese stack". I've read the source and issues extensively and it is high quality code that welcomes high quality contributions - no matter where people are from.
  • jetter 10y ago
    I was never trying to put anything negative into this statement that both these bright people are Chinese-speaking. I know they both live in US (though it might be unfortunate for us that Qiang is currently doing Go programming in Capital One instead of actively developing Yii2). Yii2 and Vue.js are top notch.
    • caleblloyd 10y ago
      I didn't so much read it as a negative, it's just that readers unfamiliar with the projects may think that "Chinese stack" means 1) code/issues are in Chinese and/or 2) the main contributor base is located in China. I've been a long time user of Yii1 and Yii2. Qiang has created 3 PHP Frameworks between 2004-2015: PRADO, Yii1, and Yii2. At one point he was on a >700 day commit streak with work on Yii2. I can't blame him for needing to focus on his own professional career - OSS doesn't always pay the bills and can be very demanding.
      • jetter 10y ago
        I agree with you, and I definitely do not blame Qiang on choosing his way. I just miss him as Yii2 contributor and visionaire because that could make a real competitor to Laravel some day, in terms of community, and popularity across US and Europe. Right now Yii2 seems to move in direction of becoming a niche framework for Eastern Europe and parts of China, instead.
• pacnw 10y ago
  I've used Vue pretty much daily over the last year in a fairly complex app (some 150+ components, Vuex store with 100+ actions, full client side router navigation) and it has been pretty pleasant. I even contribute a nominal amount to the Patreon campaign. However, the upgrade path from v1 to v2 is not a quick undertaking. Certain changes require a revisit to practically all components (e.g. change of 'ready' to 'mounted', v-el to ref etc.) that don't really bring a lot of value to the end user other than change in semantics. The upgrade diagnostic tool is a great feature, but seeing 600+ breaks in your app is not so much fun. Changes in Vuex (e.g. no more vuex: getters in the components, 'dispatch' is now 'commit' in the store modules) translates to significant work in a largish app just to upgrade semantics. Also, the article references the verbosity of Redux with respect to forms. In all fairness, all Flux implementations, including Vuex, have pretty much similar verbosity. Just providing some balancing thoughts for folks to be aware of before investing heavy time in any framework, including this one.
  • agumonkey 10y ago
    I just heard about vuex, any curated resources about it ?
    • pacnw 10y ago
      The main Vuex docs are quite good, with the included shopping cart example. https://vuex.vuejs.org/en/ https://vuex.vuejs.org/en/
• amelius 10y ago
  I once wanted to use React as a virtual DOM library, nothing more. Turned out that I had to create "components" for every div I wanted to draw. Of course, this was a nuisance to the point that I had to let go of React.
  • iLoch 10y ago
    The complexity of creating a component in react is identical to Vue.
  • mambodog 10y ago
    You seem to be mistaken. You don't need to create components if you just want to render some divs. You can just do const {render} = require('react-dom'); const {DOM} = require('react'); render( DOM.div({className="something"}, DOM.div({className="something-else"}, 'some text', ), ), document.getElementById('root'), ); Components become useful pretty quickly as your views grow in size, but even then, function components require very little extra code to use.
    • amelius 10y ago
      Interesting, I didn't know, although I can recall searching through the documentation for answers. Does calling the "render" function multiple times perform the DOM-diffing and updating? And can I be sure that React will not perform updates behind the scenes at other moments than when calling "render"?
      • mambodog 10y ago
        In answer to your first question, yes. See the documentation for `render`: https://facebook.github.io/react/docs/react-dom.html#render https://facebook.github.io/react/docs/react-dom.html#render In answer to your second question, yes, React currently only does anything as a consequence of calling `render`, or `.setState()`/`.forceUpdate()` in the case of a component class (not relevant if you're not using component classes). In future, the (currently experimental) 'fiber' render will allow some rendering to be deferred until after the current call stack has finished (to avoid blocking the UI), but there should be away to tell React to do all rendering synchronously if you desire (which is necessary for eg. rendering on the server). There's no reason why the current behavior couldn't be supported on top of the new experimental renderer though.
• guntars 10y ago
  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 && <a>Logout</a> || <a>Login</a>) 2. When you need more markup, put them in an if-else statement in the same render function. render() if (loggedIn) { var login = <a>Logout</a> else var login = <form onSubmit={ ... } /> return <div> { login } </div> 3. With SFC it's trivial to split these out into new components. You can even use bound methods to reuse the component state and props. class Navbar { LoginForm = () => { if (this.state.loggedIn) { ... } else { ... } } render() { const {LoginForm} = this return <div> <LoginForm /> </div> } } 4. And finally, what stops you from creating a custom component that works like this? render() { return <If cond={ this.state.loggedIn }> <Then>Hello { this.state.userName }</Then> <Else>Please log in</Else> </If> } There's a continuum of ways you can structure your code, it just takes some experimentation to find what works for you. After working with Angular templates for a long time and then switching to JSX, I'm never going back to having my markup in a string blob with magical attributes that make it do stuff.
  • vasachi 10y ago
    4. This won't work if one of the branches errors, because they are both evaluated. You can, however, pass a callback. But a simple ternary operator does look better.
  • jmcdiesel 10y ago
    After making some simple <If> <Loop object="">, etc custom components.... I've wondered why they don't exist in react by default, or arent the common pattern. They are very readable... maybe people just dont like the "logic" in a tag... i guess... whatever, made for some really readable code...
    • jetter 10y ago
      Regarding <If> component - here is the guy that suggested this and then admitted that this is a bad approach in a long run: http://stackoverflow.com/a/26152067/1132016 http://stackoverflow.com/a/26152067/1132016
• TekMol 10y ago
  I am still unsure if there is a legit use case for Vue or React over plain HTML+CSS+JS. I can understand the use case for React native. To build native applications on multiple platforms. But what is the use case for React, Angular, Vue etc? Can somebody give a minimal example?
  • edoceo 10y ago
    It's about maintaining complex UI state for me. Not sure how to fit that in a minimal example. Those all look like Vanilla JS can handle it. But when things get big, or sorta complex, or try to have very fine UI behavior for complex workflows then React, Vue or my fave Riot really shine. If it's minimal you don't need these. When it's not you'll be glad you have them.
  • YCode 10y ago
    Not sure what you mean by "legit use case", because you could write just about anything in vanilla, but for React specifically the value of using it comes from state management. By explicitly defining what is state and when you change it the application becomes largely pure/functional and this has a tendency to both decrease bugs and make the application easier to reason about. You could do that in Vanilla as well, but as your apps grow React or whatever.js generally is ready to grow with you, whereas your homebrew solution may not be.
• jondot 10y ago
  While this is a good overview of why _they_ chose Vue over React, I wouldn't risk deriving that you should do the same too. To balance the scale a bit, this is what they gave up, in favor of "shit that just works" (because this is the tone I'm getting from the article): 1. They decided they want off the enormous driving force for developer experience that is Facebook, and more importantly the Facebook codebase that shapes decisions in React, see [1] and [2]. 2. They opted out of major innovation that directly stem from (1), see [3]. 3. Parting with Redux, they also decided to part with a community that thinks functionally. This is a big deal not because of writing "pure functional code", but because these group of people can reason about the implications of bad citizenship on the browser - which really, is something the Javascript community really needs. 4. Moving away from functional-esque (for lack of a better term), they also move away from predictable testing. Forget purity and sideeffects. A good litmus test - think about how easy it is to test any given framework at scale, and if a framework is "built with testing in mind" (read: angular) how many hacks would be involved. When you have good foundations for testing, you can do this [6] and be sure everything can be covered [7] . The only thing I see as a down side with React is the bundle size. The physical size. However I'm not worried one bit because of (1) and (2). For Redux, I take the liberty to use MobX for small-medium projects (which probably is the overwhelming majority of projects), and Redux for large projects, or projects that I want great testing story in (in many ways these correlate, but some times they don't). Redux is "boilerplatey" because it is highly granular. This is why the ecosystem around it exploded. But because of (3) the ecosystem around it has a sharp focus around the patterns and practices it applies, which makes choosing the "wrong" library not such a big deal; in a sense its ecosystem is predictable, because it is simple. JSX or templates, I don't think this deserve a major part of the discussion. Both ideas exists for a long while, and even their predecessors exist for more than a few decades [4] and [5]. I don't think anyone is tilting the scales any where in a major way. I personally am convinced JSX is a new thing because you have first-class IDE support across the board (which you don't have for a given data-properties backed templating language unless it becomes ginormous like Angular). JSX is also simple to hack and you can opt-out or implement your own dumb-templating solution-to-JSX. Having said that, I see Vue coupled with PHP quite a bit, like, it's an informal standard stack, so it may make sense if you're coming from PHP (but then again so did Facebook, right?). Maybe someone can explain that (is it the Laravel backing?). [1] https://facebook.github.io/react/contributing/design-principles.html https://facebook.github.io/react/contributing/design-princip... [2] https://facebook.github.io/react/contributing/implementation-notes.html https://facebook.github.io/react/contributing/implementation... [3] http://isfiberreadyyet.com/ http://isfiberreadyyet.com/ [4] http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts.html http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts... [5] https://en.wikipedia.org/wiki/XSLT https://en.wikipedia.org/wiki/XSLT [6] https://facebook.github.io/jest/ https://facebook.github.io/jest/ [7] https://medium.com/@jondot/how-to-snapshot-test-everything-in-your-redux-app-with-jest-fde305ebedea https://medium.com/@jondot/how-to-snapshot-test-everything-i...
• fnordsensei 10y ago
  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've encountered in Clojure is to represent the entire page as a data structure. Conditionals and transformations are applied directly to this data structure, which is then sent as-is into the rendering pipeline (which commonly seems to be React). The HTML is never really written by hand, it's just a final "coat of paint" on top of the data. To me, this seems far easier to wrap my head around than splicing two languages together in the same file and potentially finding that the interaction between the two is not as harmonious as one may wish. Rendering to HTML, rather than rendering within HTML (so to speak), seems like it would remove the entire decision point where you have to pick between one library or the other based on the quirks of how it looks when it's spliced into HTML.
  • mark_edward 10y ago
    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.
    • vectorjohn 10y ago
      Sounds like they're referring to hiccup.
    • fnordsensei 10y ago
      Start with Figwheel[1] to enable hot-loading code and live reloading: lein new figwheel <app-name> 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 https://github.com/bhauman/lein-figwheel [2]: https://github.com/reagent-project/reagent https://github.com/reagent-project/reagent [3]: https://github.com/omcljs/om https://github.com/omcljs/om
• anupshinde 10y ago
  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 makes it simpler to code, React+TS+Redux make the end-product very much reliable.
  • mixmastamyk 10y ago
    More reliable?
• deleted 10y ago
  [deleted]
• butu5 10y ago
  Vue JS framework is very simple yet powerful, also better in performance wise. Learning curve is very easy. You can pick the fundamentals in a day or two. Within a week you can reach intermediate level. It comes with all the basic stuff of SPA like data binding, event handling, routing, state management, components. I have been creating a video tutorials series on Vue js 2 framework. Vue.js Tutorials: http://www.youtube.com/playlist?list=PLJ6Y8JfXAV-8_2lHNgP1DhCwvB6le3rty http://www.youtube.com/playlist?list=PLJ6Y8JfXAV-8_2lHNgP1Dh...
  • merb 10y ago
    what I always wanted how many Vue instances do I need for a SPA? Do I just export every javascript object and register them globally? how does Vue.JS work with DI?
• cdevs 10y ago
  Can't comment on vue much other than I think it would be the one I would go with if I had to pick one of these js frameworks due to some of the nice projects I've seen in little code. But yii2 for admin panels seems like another great selection for generating quick ugly forms only 5 people might see a month.
• straye 10y ago
  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 opinion SGML/XML should only be used for markup, not program logic. There are a few things I think React got wrong though - handling of children being one. Having different code paths to handle a single child versus multiple children was a design mistake. The Children convenience module is awkward to use. The state life cycle and immutability in React takes a while to get used to. It does seem more complicated than it needs to be and has spawned a plethora of React state management add ons.
  • tannhaeuser 10y ago
    I agree about conditionals and other kind of programming language constructs not belonging in markup. But the point of markup for content-driven web sites is that its a text format and can be contributed by persons other than web developers (authors, site users, syndicated content providers, etc). You can see a modern approach for this is at work here: http://sgmljs.net/docs/sgmlweb.html http://sgmljs.net/docs/sgmlweb.html ("isomorphic" rendering to HTML in the browser and server-side using full SGML, no less). Disclaimer: my project
  • jazoom 10y ago
    Except Vue supports JSX.
• mstijak 10y ago
  I would recommend Cx to anyone building complex forms. It's one package that covers all common problems related to forms - validation, data-binding, multi-value lookup fields, horizontal form layout, theming etc. https://cx.codaxy.com/starter/admin/orders/1 https://cx.codaxy.com/starter/admin/orders/1 Disclaimer: I'm the author.
• albertTJames 10y ago
  I have just learned React !!! That's it, I am learning C++.
  • deleted 10y ago
    [deleted]
• rmason 10y ago
  One small point to add here. Evan You is a pretty amazing individual, but he is no longer alone. There is a core team of six members. I know because the guy who got me interested in Vue.js, Chris V. Fritz, lives in the Lansing, Michigan area and is responsible for the excellent docs on Vue. I haven't been able to locate a list online but I know there's a core member in Paris and another one in Japan.
  • codegeek 10y ago
    Other than Evan, could this be the list ? https://github.com/orgs/vuejs/people https://github.com/orgs/vuejs/people
    • rmason 10y ago
      You might be correct, heard that the core team would be expanding to 17. That list is more than 17 but the names that I recognize are on that list. Bottom line is that Vue.js is growing up to better handle the popularity it's getting.
• halis 10y ago
  The author says they don't like purity and immutability, because it limits their ability to "get stuff done". But in the long run you get many benefits, whether you have 1000 developers or one. Namely that a whole class of bugs will be eliminated and you can do quick reference comparisons to tell if something changed. Every time I go to look at Vue I can't stand the fact that it DOESN'T have JSX. I've used every template system you can think of and they always fall apart when things get hard. JSX is basically JavaScript but a much easier and nicer syntax (basically HTML). You get the same flexibility with Elm, but even there you don't get the nice JSX syntax: ul [class "grocery-list"] [ li [] [text "Pamplemousse"] , li [] [text "Ananas"] , li [] [text "Jus d'orange"] ] The one criticism I happen to agree with is certain aspects of using forms in React. Checkboxes and radio buttons are pretty buggy and stupid. Kind of unacceptable at this point.
  • pm 10y ago
    If I remember correctly the latest version of Vue.js does support JSX.
  • ggregoire 10y ago
    You should check this: https://vuejs.org/v2/guide/render-function.html#JSX https://vuejs.org/v2/guide/render-function.html#JSX
  • elbear 10y ago
    For Elm, there's elmx https://github.com/pzavolinsky/elmx https://github.com/pzavolinsky/elmx
• Steeeve 10y ago
  With all the evangelism I've seen on HN about React, I have yet to see a cohesive post about the benefits that it provides that makes it worth the investment in learning. Nor have I seen a seen a good review of tooling that provides a good path for someone who wants to try it out. What I do see, are arguments that "it can do that too if you only knew how to use it!" That and a lot of sample code that embeds html within the code, which frankly looks like a delegation nightmare. (and scattered postings about documentation not being up to date) You could downvote me. Or... you could point me to a helpful and up to date resource or recent posting that is actually helpful. Or better yet, write one.
  • matt4077 10y ago
    https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app
• jayajay 10y ago
  This is a great article, thanks for sharing. "Not being able to put plain old IF condition to some block of HTML code sucks" In my usage of React, I found that this limitation forces me to use functions to break down my code, a skill which is simply required when working on large projects. Of course, that's what everyone else says, too. "JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each." Truth to this -- React can make things slower when your project is inherently monolithic, but you're tempted to abstract things into ugly Listwrappers, ListViews, ListViewData, ListViewDataContainers, etc. It gets ugly if you aren't good at abstracting things very well. React should approached with caution. I think this guy has the right idea, don't put all your eggs into the React basket. Don't underestimate the cunning of Mark Zuckerberg. If possible, don't rely on React, because if you create something groundbreaking, you will be in for a legal situation with Facebook.
• dirkg 10y ago
  The arguments against Redux (which this article doesn't really make, but still) are very valid - it is a nice abstraction and way to think about data flow, but its simply too much boilerplate. Almost every Redux example is tons of repetitive code because of this, and that's before you add in middleware, thunk, saga, reselect etc. Yes I know Dan himself wrote a bunch of articles on how you don't really need to use it and how its conceptually simple, none of that changes what most of the libs and code looks like. I don't have the answer but I can't help but think there has to be a better way to handle this. We had templates and generics decades ago exactly to reduce repetitive boilerplate. Redux should never have been adopted in its current form. Its exactly the sort of thing that should be handled by a framework/tooling for you. Imagine if for every React component you had to write a custom parser/resolver/reconciler, all of which had 99% common code and just passed params around. That's what redux boils down to.
• sapeien 10y ago
  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.
• marclave 10y ago
  "JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each." this stuck with me the most
• hoodoof 10y ago
  You don't need to use Redux, and I don't - it gives me nothing I need and adds complexity.
• mikebay 10y ago
  Facebook products? - no thanks. Vue and Riot roooocks!
• johntran 10y ago
  "I expect Vue to become a primary JS framework in 16-24 months if Evan You makes right steps, at least around backenders and smaller teams of frontenders." When Vue.js gets a big enough community passionate enough to host their own conference, we'll be able to consider this as a possibility. :)
  • posva 10y ago
    Ha, well just wait for 2017
• marcfawzi 10y ago
  Vue.JS could have a better shot at being respected if it drops the mixing of declarative and imperative code (logic in HTML) as that introduces a dichotomy in its world view that is hard to eliminate.
• thewhitetulip 10y ago
  It has been quite some time since I started writing front end code, tried understanding angular, left it. I was lucky that I came across Vue.JS via HN, it was gitlab's post. I haven't ever tried React, because Vue is amazing. With nearly no knowledge of JS, I was able to write an app in Vue reading just the official docs, they are downright amazing. I faced the issue of webpack et al, thus I started writing a guide to write vue apps in vanilla JS, https://github.com/thewhitetulip/intro-to-vuejs https://github.com/thewhitetulip/intro-to-vuejs This is a work in progress. I feel Vue is gaining ground because of it's simple syntax, there isn't much magic to it, just enough magic.
  • jgorn 10y ago
    Thanks for posting. I've just had a quick glance over the first chapter of your book and I like the simple approach you take to explaining the core elements of vue.js and SPAs. Will be keeping an eye on your progress.
    • thewhitetulip 10y ago
      Thank you :-) I plan to finish everything off in the next few days. The chapter5 contains a working version of the code, but it sure needs some refactoring. If you want, I'll email you when the book is done. Leave an email id somehow :)
• mikebay 10y ago
  I would stay far from Facebook products. Never know when you have been sued or forbidden to use they products. Haha these all boils down to freedom end of the day for me. I would not ever choose Facebook, Google or Twitter products for anything. They business is simply censorship packaged in fancy boxes.