11 ms·

Why we moved from Angular 2 to Vue.js and why we didn’t choose React

138 points by chillax 9y ago

zerr 9y ago
While we are at it - any success stories with Weex? (a la Vue.js native)
- sgt 9y ago
  A few months later: "Try Weact, a Weex alternative." The speed at which these frameworks pop up is almost exhausting.
  - deleted 9y ago
    [deleted]
  - LeonM 9y ago
    Not almost, it is exhausting to keep up [0]. [0] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4 https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...
  - mrighele 9y ago
    My approach for a JS framework or library is that the time I can hope it will be maintained for is at most the time that it has already been maintained. This way, depending on how long my project is supposed to be supported I can make a reasonable choice about what to use. I call it "JS half-life time".
    - ameliaquining 9y ago
      There's a name for this in the literature: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
      - mrighele 9y ago
        I didn't know about that, thanks for sharing.
sgt 9y ago
We moved from Angular 1.3 to Vue.js. Vue came at a right time and I especially liked its ease of use, similarity to Angular and footprint. The most important thing to me personally was the speed and the development feedback cycle.
- ergo14 9y ago
  I like Vue, but one thing that worries me is that 99% of commits are being made by a single person.
  - baybal2 9y ago
    I like it, a mirror opposite of extreme "designed by committee" practices of big co. funded frameworks. I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new mySerice", or reasons for React's component rendering order peculiarities, or logic behind their choice of syntax. Vue is very bare bones thing. It provides no reactive layer over complex object with non-primitive content. Lack of native support for maps or sets from ES6 is inconvenient a bit, but it is not hard to provide a function wrapper around any logic that uses them. I usually keep all business logic outside of Vue's instance and only wire though its inputs and outputs. What I lack in all common frameworks is the ability to play smoothly with really complex DOM manipulations, like swapping prototypes of a DOM elements and mergings. Trying to do something like complex drag and drop logic usually means doing a lot of "do it within DOM element, or do it within framework's element" thinking
    - wooptoo 9y ago
      ES6 actually supports both Sets and Maps: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
rajeshamara 9y ago
2 flaws with this article. 1) Using a Beta product and complaining on Angular2. You could have waited till the product is matured 2) Blaming for the developers inefficiency on Typescript. If your developers coding speed is reduced blame on your developers. Your title and article appears that something is wrong with Angular2 and moved to Vue.js. Before you post such articles make sure what your write makes sense
- ballenf 9y ago
  He cites two articles going into much more detail on the line of thinking regarding the tradeoff that is static typing. I realize this is one of those tab/spaces kinds of religious debates, but hopefully all sides can acknowledge that we are talking tradeoffs and not universal truths. Maybe one day we'll see loose typing as evil as "goto" statements, but the evidence isn't there yet. IMO.
  - mhd 9y ago
    Goto statements still have their fans, and on the other end of the spectrum you'll find people arguing that things like multiple return statements and exceptions are basically the same. It's hard to find absolute truths in computing. I bet there are a few people who'd like us to ditch that whole binary kerfuffle, too. But yeah, they're trying to be productive in the short term, so it's probably not worth overanalyzing whether a distaste of static typing isn't emblematic of other issues. Getting things rolling has a higher priority...
    - jnbiche 9y ago
      > I bet there are a few people who'd like us to ditch that whole binary kerfuffle, too. https://en.wikipedia.org/wiki/Setun https://en.wikipedia.org/wiki/Setun Knuth has also hypothesized that we may one day start producing ternary computers again due to their efficiency and elegance.
  - striking 9y ago
    Goto statements aren't always (or even usually) evil either. Sometimes I get the feeling no one ever really read past the headline of that paper. Sure, you shouldn't use them unless you really have to, but "really have to" is a line that is difficult to discern. Dijkstra himself noted, "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one."
erokar 9y ago
> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If anything, TypeScript is a bonus. > React mixes both JSX/HTML with JS code which I just don’t like since I strongly believe in separation of concerns and it looks ugly IMHO. This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function. In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern. From Vue.js' documentation: "One important thing to note is that separation of concerns is not equal to separation of file types." [1] > Coding speed was an area Vue.js won by far, not having to learn JSX was of huge help. It should take no more than 20 minutes to learn JSX. 1. https://vuejs.org/v2/guide/single-file-components.html#What-About-Separation-of-Concerns https://vuejs.org/v2/guide/single-file-components.html#What-...
- che_shirecat 9y ago
  > It should take no more than 20 minutes to learn JSX. it should, but in practicality, for most front-end devs especially junior ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times (anecdotal experience) quicker than with React. For most smaller shops/startups Vue is almost always a better idea - it's much easier finding devs (especially remote/<100k comp ones) with previous Angular 1 experience and the learning curve is alot nicer. React is overengineering for most web apps.
  - erokar 9y ago
    You are probably right that Angular 1.x devs will ramp up a bit faster in Vue than React. Angular and Vue both add template syntax to HTML, which will be more familiar to Angular devs. However, I do not think initial ramp up time should matter that much, at least not for long running projects. More important questions are: How will the project scale? How easy will it be to maintain? > React is overengineering for most web apps. This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.
Pigo 9y ago
I've been attempting to learn Angular2 and React, but haven't delved into Vue. Angular2 is just different, but it makes more sense to me than 1 if you take the time to learn the concepts. If you go into 2 thinking your 1 skills will translate, then I get why you'd be frustrated. But I found 1 to be very vague conceptually, so many different ways to do the same thing that you end up with many bad implementations. And compared to React, Angular2 is cake imo. There's so much more materials to draw from, and ui libraries to use, and you have to import so much in order to do the same things in React. That may allow for more flexibility, but it makes the learning curve that much more difficult. I'm still not a fan of Typescript, but it seems important to get familiar with ES6. Also angular-cli and create-react-app are both excellent tools that take a lot of the guess work out of the process, at the very least they show you how to do things right way and keep up to date with what's important.
- camus2 9y ago
  > Angular2 is cake imo. Angular.X totally lacks of vision. For years it didn't know what it wanted to be, pilling up layers of layers of complexity with IoC containers (useless in a weakly and dynamically typed language such as javascript), Some custom HTML that even needs its own parser, Rx.JS (which is self sufficient if you use it, you literally do not need something on top of that). For what result? it's not faster, snappier in the client, lighter when it comes to the payload, not easier to learn or to test or to use. You don't need some ajax libs either, the fetch API already exists. Angular.X is trying to be the "JEE" of the front-end, except it miss the point of JEE which are a bunch of stable specs, which Angular isn't.
  - pas 9y ago
    The vision is finally having a good UI kit. Components, templates, lazy loading, isomorphic/universal JS, precompilation, maintainability, code discoverability, ease of team development, testing, etc. Angular CLI does the compilation, provides the boilerplate management (no need for IDE, if you don't want that), provides the language service (for static checking templates). Google dogfoods it, they are on the latest rc always. Somehow they can manage the API changes/breaks. (And so far it wasn't much problem for us either.) I don't know if rx is now a hard or optional dependency, but at least they haven't NIH-ed another Observable lib.
jinder 9y ago
"We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice." "We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."
- emodendroket 9y ago
  The stuff about a total rewrite to go to regular JavaScript is completely bogus as well. How does this guy think Typescript runs?
- camus2 9y ago
  > "We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice." Angular.2 has been in beta for years. And when it went out of beta it basically became something else. This is not a good thing. It's normal for teams to be excepting at least some level of stability in the library they are using. And now that Angular.X pretends to be using semver, it's going to be even worse. The Angular team doesn't care about stability or lacked vision when they started 2, but a stable API is a valid expectation for a developer team. But it's not surprising as frameworks with huge API surfaces like ExtJS have pulled the same trick for years, with the same results. Their downfall is more the consequence of API breaking than anything else.
  - jinder 9y ago
    If you rely on a beta product you should have no expectation of API stability. It's very easy to blame vendors when it's your own poor decision making that got you in the mess to begin with.
    - camus2 9y ago
      > If you rely on a beta product you should have no expectation of API stability. If i rely on a beta product, i don't expect a complete rewrite of the API when a stable version is released. That's exactly what happened, several times with Angular. Now you can't have it both ways as a vendor. You can't expect people to try out your product and test it in a professional setting then change everything at the last moment either. Or you're saying developers shouldn't even checkout Angular until it is out of beta. If that's what you're saying then the vendor shouldn't expect broad adoption.
keymone 9y ago
everybody who feels so strongly about separation of code from templates - do you realize that down there it's still just bunch of string concat calls? it's literally what ERB templates in Ruby compile to, and similarly in literally every other template language. rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is. it's one of the reasons i love clojurescript's hiccup so much - i'm still clearly writing idiomatic clojure code but now the boundary is not some arbitrary "this file is named .html and this .js", but actual namespaces/functions, where it's obvious from scope and signature what data my templates depend on.
- pweissbrod 9y ago
  I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for. Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together. You write html inside js? or sql inside python? omg noob! Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .
  - emodendroket 9y ago
    My theory is that a lot of us have gone down this road, eventually found the thing getting unwieldy and difficult to maintain, and swearing never again.
- newcomcjoe 9y ago
  Vue 2 allows you to precompile your templates so you're not sending out a bunch of strings of data. Since it uses a virtual DOM, you can use a build tool to compile your templates down to the virtual DOM code to help your application run faster.
- emodendroket 9y ago
  That's not really the point of separation of concerns. It's for the benefit of programmers, especially maintenance programmers, not the machine.
jbergens 9y ago
It's always a bit strange when someone chooses a framework based on how far they get in a few hours or days of testing. For medium sized or larger projects it's much more interesting how it will work long term with a large code base. I'm not saying that Vue is no good or that it was not a good choice for the author, but the way he described their process makes me think that they optimized the wrong thing.
kumarvvr 9y ago
Vue seems to be less taxing on the mind. Compared to React, I feel Vue is more easy to build with. Just my 2 Cents
- sayurichick 9y ago
  I agree. Having used both on small projects I was able to get started and finish quicker on Vue. That being said, I use React more because of the larger community, (easier to find answers, and components) as well as more jobs for React vs Vue. Also, Fiber introduces better animation performance, which i'll eventually use.
  - kumarvvr 9y ago
    Things have become easier with create-react-app though.
    - deleted 9y ago
      [deleted]
deleted 9y ago
[deleted]
ArchReaper 9y ago
Maybe my viewpoint is too 'elitist' or something, but I have a hard time taking this seriously when one of the chief complaints of Typescript is that it is too "difficult" It really makes me question the validity of the rest of the points.
- jcroll 9y ago
  Yeah was interested to hear what their points would be but couldn't get past when they started complaining about typescript.
- hockeybias 9y ago
  Typescript is great and one reason is that it is a superset of JavaScript. I'm concurring wholeheartedly...
- ageofwant 9y ago
  Typescript is not difficult, it just solves problems almost no one has, and makes you do silly things that slow you down. Difficult like in 'petulant child' difficult, not 'what woman want' difficult.
- thehardsphere 9y ago
  While I understand the preference for not wanting it, it is a very "high-level" sort of complaint, and the rest of the points seem similarly "high-level." They could all be valid points, but I wouldn't take any of them purely at face value.
pete_b 9y ago
Angular 2 in beta made bold claims about being 'production ready' which reads 'almost done', it was frustrating just how long it then took to become what I would consider production ready. I consider Angular 4 the first release to produce just about acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changing framework.
- stupidcar 9y ago
  I think this had to more to do with internal pressures at Google than the actual state of the code. They had been working on it for a long time, and, I think were under some pressure to actually ship something. Angular v4 is what the first production version should have looked like. Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually very happy with where it's ended up. It feels like a very good combination of power and flexibility. There are still some complex bits, but it feels more like the complexity is necessary and sanely designed, rather than the craziness of what AngularJS's directive stuff evolved into.
  - growtofill 9y ago
    Would you share some stats about the upgrade? How many LoCs was the codebase and how many man/hours it took?
    - camus2 9y ago
      s/upgrade/rewrite . I don't believe a second there is a reasonable way to upgrade 1.X from 4.X without rewriting all UI related code.
emodendroket 9y ago
People are already migrating from ng2? It just came out!
- deleted 9y ago
  [deleted]
- bdcravens 9y ago
  ng2 final was released in September 2016, but many were using it well before then, as in the article. (first beta was in January 2016 I believe)
  - emodendroket 9y ago
    I guess maybe it because I am not a frontend person but completely redoing a project in less than two years seems kind of crazy to me.
dugmartin 9y ago
> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. Sure defining a simple JS object has no overhead as opposed to maybe the 15-30 seconds of overhead that creating the Typescript interface entails. But that few additional seconds of overhead gives you this for rest of the (weeks, months and years) of the systems lifetime: 1. Instant IDE/editor code completion and error checking 2. Compile time checked contracts when that object is passed to another function 3. Compile time checks for misspelled or non-existent members of the object. 4. Instant refactoring of member names across files with any number of editors and IDEs 5. A chance to take a little higher level look at the design of your system. After using Typescript for a couple of years now I've found that when I design my types well the overall design and flow of the system tends towards beauty. That is probably why the Haskell folks are always over on the sidelines smirking.
alexro 9y ago
Wait, but TypeScript makes inheritance a joy. So, how you do it - unless you don'r really reuse the implementation?
water42 9y ago
Clickbait. The author switched from Angular 2 beta 9 (not even a release candidate) because he was unable to migrate to Angular 2.0.0 since 'too many things broke to make the upgrade non trivial'. Yet somehow rewriting the entire app in Vue is easier?
- scriptkiddy 9y ago
  You'd be surprised how simple it is to re-write an application in Vue. As someone who just finished doing so, I can say that development speed is like nothing I've ever experienced. The application I rebuilt initially took about 2 months to build with React. I rebuilt it with Vue in 2 weeks by myself. I am not venerating Vue, just simply responding to your concerns about rebuilding entire applications.
  - seanwilson 9y ago
    I did a rewrite from Angular 1 to Vue recently and it didn't take long at all plus it fixed a bunch of bugs that were problematic to fix in Angular. If you write your Angular 1 code in component style, moving them to Vue is pretty straightforward and a lot of the template conversions just involve changing keywords (e.g. ng-if -> v-if).
samblr 9y ago
Have been using angular 1 and I so wish that I had used vue instead. vue is easy and intuitive compared to angular bloat. May be will take less than half hour to understand basics coming from angular. Can anybody share experience with nuxt.js ?
arkadiytehgraet 9y ago
I wonder why nowadays anyone would choose React and give away all patent rights to the E̶v̶i̶l̶ ̶c̶o̶r̶p̶o̶r̶a̶t̶i̶o̶n̶ Facebook (or not, in which case one would need to rewrite the app completely, since he cannot use React anymore). This alone should make choice way easier, if you decided to not use Angular anyway.
thinbeige 9y ago
> JSX was also a problem since we could not reuse HTML code Who has source code in native HTML lying around?
- dwaltrip 9y ago
  Even more, a simple find and replace for "class" to "className", and wrap it in a render function. There, now the HTML is being reused as JSX.
sailfast 9y ago
Just wanted to come here and say thanks to the author for writing up your assessment of their tech stack and the pluses and minuses - it's brave to do so and it's obviously spurred discussion. Thanks for sharing some of your learning and having the guts to put it out there, and congrats on shipping the results. I have a couple of questions: 1) You had two people working on the project - how do you think it would scale out to 10? React's componentized / functional nature allows for that pretty easily which is a consideration for me. 2) Managing JavaScript in templates (html) with Angular 1.x was always weird because you couldn't necessarily tell if the execution was happening in the view or the controller. Does Vue make that any easier when it mixes templates and JS together? I also appreciate knowing that this file is where everything is contained for X element or function. 3) How are the test harnesses?
seanwilson 9y ago
> I didn’t feel Typescript added substantial value and even worse, we noticed that our coding speed was reduced. With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. I highly recommend you to read the following articles before you start using Typescript. It is not the right solution for everyone. If you read the linked article, it's using a graph of the number of GitHub issues labelled "bug" to justify that languages with strong static types don't reduce the number of bugs which isn't meaningful or convincing... > The main thing we didn’t like and we still don’t like about Angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, the decision to use Typescript was already taken and from what I understand, using pure Javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case, getting rid of Typescript meant a full rewrite of the project. ... > I still remember how easy to work with Angular 1 was, it certainly had it’s own problems, but it was nice to work with it compared to other frameworks, something that Angular 2 lost somewhere on the way. I recently moved from Angular 1 because it didn't work well with TypeScript. The rest of my project was in TypeScript and all the bugs were coming from the Angular 1 layer because there was no static checking there. TypeScript is an enormous improvement over plain JavaScript in my opinion in terms of productivity (better refactoring, better autocomplete) and making your code more robust (no unexpected null/undefined variables, no more mixing up strings and arrays). Ignoring TypeScript for large projects is a big mistake. Angular 2 felt too verbose and overly complex so I switched to Vue which has decent add ons to work with TypeScript. If you use JSX for Vue templates as well, you get type checking for your templates.
Zelphyr 9y ago
The thing I find amusing about posts like these is that they come about once every 18 months. Just substitute the left framework for last years shiny and the right for the latest shiny. We developers are nothing if not consistent in our ability to chase the latest shiny. I do wish more developers would take the time to master languages instead of learning new frameworks though.
wambotron 9y ago
I still say Mithril (https://mithril.js.org/ https://mithril.js.org/) is where it's at. I am at a company now that uses Angular 4.x and I'm not impressed with it. IMO, it's a way to make JS seem more like Spring/Java (especially with Typescript) rather than understand how JS works and use it as it is. Not to mention the learning curve even for senior developers. Mithril took me maybe 30 minutes to understand. The entire source (https://github.com/MithrilJS/mithril.js https://github.com/MithrilJS/mithril.js) is easily read in a few hours. They have multiple committers and an active gitter chat room for any problems. Plus you can use JSX if you like it that much. And it has a nice license. More folks need to try it out.
- elbear 9y ago
  I'm using Mithril with TypeScript. It's a great combo. All my Mithril views are stateless and TypeScript makes sure I pass down properly the arguments to the view. It feels almost like I'm writing Elm. Almost.
- seanwilson 9y ago
  Are you not at a disadvantage with it having a smaller community or is there enough content out there? I like to support new innovations but knowing I can easily find a prewritten component for Vue or Angular is a big selling point.
  - wambotron 9y ago
    I never felt like I had any problems, to be honest. It was so quick and easy to write things, I never worried. There are a decent amount of plugins out there on github, though. Give it a shot!
OutsmartDan 9y ago
I just broke your Vue website. http://cl.ly/2I2r2S2v171T http://cl.ly/2I2r2S2v171T
bojanvidanovic 9y ago
I envy how some companies can migrate from one to another framework like that. Beside that, TypeScript is just fine once you get more time with it, you don't need to type everything. On the other side I find Angular more stable framework on the long run.
jordache 9y ago
The author made some really weak arguments. In his comparison matrix, why was Reactivity a criteria? Why did Angular score a "Kind-of"? Reactivity is just another word for the framework's underlying change detection logic. Obviously all of these frameworks have that. The fact that he put the term "reactivity" up on a pedestal and rated angular down tells me the lack of understanding on the author's side
jorblumesea 9y ago
Angular is a application framework, Vue is a view library. It's really frustrating to see these two compared, because they have different purposes and intentions. Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. By the time you slap all of that on top, you may have well just stuck with Angular. I noticed in React by the time you added the required add-ons (mobx or redux, polyfills, react router, styled components) it was extremely heavy. Furthermore, maintaining these addons, with their own release cycles and bugs is an additional burden on a team.
- erokar 9y ago
  Please enlighten me — what kind of state management does Angular give you for free?
- RussianCow 9y ago
  > Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. That's not really true anymore; there is now an official router[1] and state management library[2] for Vue. You don't have to use them, but I think the comparison is still completely fair. [1]: https://github.com/vuejs/vue-router https://github.com/vuejs/vue-router [2]: https://github.com/vuejs/vuex https://github.com/vuejs/vuex
  - jorblumesea 9y ago
    This is a great point, I did not know it was officially in the build. Thanks!
- seanwilson 9y ago
  > Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. Vuex and Vue Router are recommended from the official Vue website, used by most Vue users and work seamlessly together. What else are you missing? The kind of things I want to build with Vue with Vuex and Vue Router are the same kinds of things I could build with Angular 1 and Angular 2 so the comparison makes sense to me.
joelennon 9y ago
> At the time we were thinking about Vue.js vs React, we were also considering rewriting our mobile app and React Native looked like a really good choice. That was a big plus for React since Vue.js didn’t have anything remotely stable that resembles what React Native is trying to do, so the possibility of reusing code between the web and app clients was a huge plus, but I decided that I wasn’t going to consider possibilities that might or might not happen. After all, from my experience, with Node.js I reuse a really insignificant amount of code between the browser and the server. The main benefit of using React if you are considering using React Native is that you and your team won't need to learn another framework in order to build native mobile apps for iOS and Android - if they know React already, they'll be up to speed with React Native very quickly.
- dayvid 9y ago
  Alibaba's working on a Vue-based mobile alternative called Weex. It's still in its infancy, but it's worth checking out: https://weex.incubator.apache.org/ https://weex.incubator.apache.org/ https://github.com/alibaba/weex https://github.com/alibaba/weex
jordache 9y ago
Angular 2+ does require more up front investment. However once you get going, the framework's convention is pretty seamless and on can create rather structured, team friendly projects, and iterate functions quickly. The Angular CLI tool is a must! Without it, the friction to get dive into the Angular 2+ world is significantly more.
davidw 9y ago
No experience with Vue.js or React, but I used Angular 2 recently and I did not like it much. Too much magic, too much 'do our things our way or woe betide you'.
caludio 9y ago
I stopped reading at "The main thing we didn’t like and we still don’t like about Angular 2 is Typescript". Sorry.
stephenhuey 9y ago
What I want to know is, why didn't you choose Aurelia? :)
vladimir-y 9y ago
The article says to me that the team/company had no initial actual need to use TypeScript as seems author doesn't get a point of its purpose (of course code writing will be slower on the initial stage as it's not just about writing the code, but also about defining its structure which gives you the benefits with the growth of the project) and so a bad decision was initially made. In my opinion Vue is ok for the one kind of projects, with smaller team, smaller project lifetime and Angular is ok for other types of projects. React is alien here, ie not really needed.
ralmidani 9y ago
Ember user here, looking for a breath of fresh air from the limitations of Emblem/Handlebars and the endless layers of complex objects. I am enrolled in Udacity's React Nanodegree, but recently took a closer look at Vue. It seems to offer everything React does (VDOM, one-way data flow, centralized state management, support for JSX), but without the patent drama. I previously took a nuanced approach to Facebook's unfair patent license, and will probably never need or want to sue them for patent infringement. But Vue is quite a viable alternative, so I see no reason to reward Facebook's unwillingness to play fair. I plan to finish the Nanodegree, but will probably be skipping React and using Vue for my own real-world projects.

138 points by chillax 9y ago

zerr 9y ago

While we are at it - any success stories with Weex? (a la Vue.js native)

sgt 9y ago
A few months later: "Try Weact, a Weex alternative." The speed at which these frameworks pop up is almost exhausting.
- deleted 9y ago
  [deleted]
- LeonM 9y ago
  Not almost, it is exhausting to keep up [0]. [0] https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4 https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...
- mrighele 9y ago
  My approach for a JS framework or library is that the time I can hope it will be maintained for is at most the time that it has already been maintained. This way, depending on how long my project is supposed to be supported I can make a reasonable choice about what to use. I call it "JS half-life time".
  - ameliaquining 9y ago
    There's a name for this in the literature: https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
    - mrighele 9y ago
      I didn't know about that, thanks for sharing.

sgt 9y ago

We moved from Angular 1.3 to Vue.js. Vue came at a right time and I especially liked its ease of use, similarity to Angular and footprint. The most important thing to me personally was the speed and the development feedback cycle.

ergo14 9y ago
I like Vue, but one thing that worries me is that 99% of commits are being made by a single person.
- baybal2 9y ago
  I like it, a mirror opposite of extreme "designed by committee" practices of big co. funded frameworks. I feel purposefulness of Vue's design. There are no gigatons of features and behaviors which make you scratch your head and think "why it is there to begin with" like why Ang2 insists on using observer objects for HTTP responses, or why Ang1 had a such an extensive buildover around its component zoo to do just "new mySerice", or reasons for React's component rendering order peculiarities, or logic behind their choice of syntax. Vue is very bare bones thing. It provides no reactive layer over complex object with non-primitive content. Lack of native support for maps or sets from ES6 is inconvenient a bit, but it is not hard to provide a function wrapper around any logic that uses them. I usually keep all business logic outside of Vue's instance and only wire though its inputs and outputs. What I lack in all common frameworks is the ability to play smoothly with really complex DOM manipulations, like swapping prototypes of a DOM elements and mergings. Trying to do something like complex drag and drop logic usually means doing a lot of "do it within DOM element, or do it within framework's element" thinking
  - wooptoo 9y ago
    ES6 actually supports both Sets and Maps: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

rajeshamara 9y ago

2 flaws with this article. 1) Using a Beta product and complaining on Angular2. You could have waited till the product is matured 2) Blaming for the developers inefficiency on Typescript. If your developers coding speed is reduced blame on your developers. Your title and article appears that something is wrong with Angular2 and moved to Vue.js. Before you post such articles make sure what your write makes sense

ballenf 9y ago
He cites two articles going into much more detail on the line of thinking regarding the tradeoff that is static typing. I realize this is one of those tab/spaces kinds of religious debates, but hopefully all sides can acknowledge that we are talking tradeoffs and not universal truths. Maybe one day we'll see loose typing as evil as "goto" statements, but the evidence isn't there yet. IMO.
- mhd 9y ago
  Goto statements still have their fans, and on the other end of the spectrum you'll find people arguing that things like multiple return statements and exceptions are basically the same. It's hard to find absolute truths in computing. I bet there are a few people who'd like us to ditch that whole binary kerfuffle, too. But yeah, they're trying to be productive in the short term, so it's probably not worth overanalyzing whether a distaste of static typing isn't emblematic of other issues. Getting things rolling has a higher priority...
  - jnbiche 9y ago
    > I bet there are a few people who'd like us to ditch that whole binary kerfuffle, too. https://en.wikipedia.org/wiki/Setun https://en.wikipedia.org/wiki/Setun Knuth has also hypothesized that we may one day start producing ternary computers again due to their efficiency and elegance.
- striking 9y ago
  Goto statements aren't always (or even usually) evil either. Sometimes I get the feeling no one ever really read past the headline of that paper. Sure, you shouldn't use them unless you really have to, but "really have to" is a line that is difficult to discern. Dijkstra himself noted, "The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one."

erokar 9y ago

> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. TypeScript in no way prohibits you from defining a plain old untyped object. Just don't assign a type to it, and it behaves just as it would in plain JS. I wouldn't use Angular 2/4 either, because of its needless complexity and over engineering — but not because of TypeScript. If anything, TypeScript is a bonus. > React mixes both JSX/HTML with JS code which I just don’t like since I strongly believe in separation of concerns and it looks ugly IMHO. This is valid only if you think separation of concerns is the same as separation of technologies. I don't think so. It makes more sense to group code based on function. In fact Vue.js allows single file components that mix HTML, CSS and JS in a way that would violate the author's definition of separation of concern. From Vue.js' documentation: "One important thing to note is that separation of concerns is not equal to separation of file types." [1] > Coding speed was an area Vue.js won by far, not having to learn JSX was of huge help. It should take no more than 20 minutes to learn JSX. 1. https://vuejs.org/v2/guide/single-file-components.html#What-About-Separation-of-Concerns https://vuejs.org/v2/guide/single-file-components.html#What-...

che_shirecat 9y ago
> It should take no more than 20 minutes to learn JSX. it should, but in practicality, for most front-end devs especially junior ones, it's not. Moving Angular 1 devs to Vue gets actual work going 3-4 times (anecdotal experience) quicker than with React. For most smaller shops/startups Vue is almost always a better idea - it's much easier finding devs (especially remote/<100k comp ones) with previous Angular 1 experience and the learning curve is alot nicer. React is overengineering for most web apps.
- erokar 9y ago
  You are probably right that Angular 1.x devs will ramp up a bit faster in Vue than React. Angular and Vue both add template syntax to HTML, which will be more familiar to Angular devs. However, I do not think initial ramp up time should matter that much, at least not for long running projects. More important questions are: How will the project scale? How easy will it be to maintain? > React is overengineering for most web apps. This is a peculiar statement, imo. Have you compared the surface APIs of React and Vue? React's API is much smaller. While Vue might be easier, React comes off as simpler.

Pigo 9y ago

I've been attempting to learn Angular2 and React, but haven't delved into Vue. Angular2 is just different, but it makes more sense to me than 1 if you take the time to learn the concepts. If you go into 2 thinking your 1 skills will translate, then I get why you'd be frustrated. But I found 1 to be very vague conceptually, so many different ways to do the same thing that you end up with many bad implementations. And compared to React, Angular2 is cake imo. There's so much more materials to draw from, and ui libraries to use, and you have to import so much in order to do the same things in React. That may allow for more flexibility, but it makes the learning curve that much more difficult. I'm still not a fan of Typescript, but it seems important to get familiar with ES6. Also angular-cli and create-react-app are both excellent tools that take a lot of the guess work out of the process, at the very least they show you how to do things right way and keep up to date with what's important.

camus2 9y ago
> Angular2 is cake imo. Angular.X totally lacks of vision. For years it didn't know what it wanted to be, pilling up layers of layers of complexity with IoC containers (useless in a weakly and dynamically typed language such as javascript), Some custom HTML that even needs its own parser, Rx.JS (which is self sufficient if you use it, you literally do not need something on top of that). For what result? it's not faster, snappier in the client, lighter when it comes to the payload, not easier to learn or to test or to use. You don't need some ajax libs either, the fetch API already exists. Angular.X is trying to be the "JEE" of the front-end, except it miss the point of JEE which are a bunch of stable specs, which Angular isn't.
- pas 9y ago
  The vision is finally having a good UI kit. Components, templates, lazy loading, isomorphic/universal JS, precompilation, maintainability, code discoverability, ease of team development, testing, etc. Angular CLI does the compilation, provides the boilerplate management (no need for IDE, if you don't want that), provides the language service (for static checking templates). Google dogfoods it, they are on the latest rc always. Somehow they can manage the API changes/breaks. (And so far it wasn't much problem for us either.) I don't know if rx is now a hard or optional dependency, but at least they haven't NIH-ed another Observable lib.

jinder 9y ago

"We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice." "We were unable to learn how to use TypeScript properly, so let's abandon gradual typing and suffer a net loss in productivity over the longer term."

emodendroket 9y ago
The stuff about a total rewrite to go to regular JavaScript is completely bogus as well. How does this guy think Typescript runs?
camus2 9y ago
> "We invested in a beta product and then shock horror - it changes before it's released. Let's blame the framework on that poor choice." Angular.2 has been in beta for years. And when it went out of beta it basically became something else. This is not a good thing. It's normal for teams to be excepting at least some level of stability in the library they are using. And now that Angular.X pretends to be using semver, it's going to be even worse. The Angular team doesn't care about stability or lacked vision when they started 2, but a stable API is a valid expectation for a developer team. But it's not surprising as frameworks with huge API surfaces like ExtJS have pulled the same trick for years, with the same results. Their downfall is more the consequence of API breaking than anything else.
- jinder 9y ago
  If you rely on a beta product you should have no expectation of API stability. It's very easy to blame vendors when it's your own poor decision making that got you in the mess to begin with.
  - camus2 9y ago
    > If you rely on a beta product you should have no expectation of API stability. If i rely on a beta product, i don't expect a complete rewrite of the API when a stable version is released. That's exactly what happened, several times with Angular. Now you can't have it both ways as a vendor. You can't expect people to try out your product and test it in a professional setting then change everything at the last moment either. Or you're saying developers shouldn't even checkout Angular until it is out of beta. If that's what you're saying then the vendor shouldn't expect broad adoption.

keymone 9y ago

everybody who feels so strongly about separation of code from templates - do you realize that down there it's still just bunch of string concat calls? it's literally what ERB templates in Ruby compile to, and similarly in literally every other template language. rather than focusing on "omg html in my js" you should focus on "omg presentation code in my business logic code" because that's when you realize where the real boundary is. it's one of the reasons i love clojurescript's hiccup so much - i'm still clearly writing idiomatic clojure code but now the boundary is not some arbitrary "this file is named .html and this .js", but actual namespaces/functions, where it's obvious from scope and signature what data my templates depend on.

pweissbrod 9y ago
I got a theory about that. Somewhere along the way our IDEs and code editors trained us that different languages always belong in different files. Eventually people saw this as an aesthetically tidy arrangement to strive for. Mixing bits of different languages "inline" within the same file got a bad rap despite the fact it was often a sensible approach to organizing common logic together. You write html inside js? or sql inside python? omg noob! Ironically I think our tools have programmed us to think/operate in a specific fashion that was convenient for IDE .
- emodendroket 9y ago
  My theory is that a lot of us have gone down this road, eventually found the thing getting unwieldy and difficult to maintain, and swearing never again.
newcomcjoe 9y ago
Vue 2 allows you to precompile your templates so you're not sending out a bunch of strings of data. Since it uses a virtual DOM, you can use a build tool to compile your templates down to the virtual DOM code to help your application run faster.
emodendroket 9y ago
That's not really the point of separation of concerns. It's for the benefit of programmers, especially maintenance programmers, not the machine.

jbergens 9y ago

It's always a bit strange when someone chooses a framework based on how far they get in a few hours or days of testing. For medium sized or larger projects it's much more interesting how it will work long term with a large code base. I'm not saying that Vue is no good or that it was not a good choice for the author, but the way he described their process makes me think that they optimized the wrong thing.

kumarvvr 9y ago

Vue seems to be less taxing on the mind. Compared to React, I feel Vue is more easy to build with. Just my 2 Cents

sayurichick 9y ago
I agree. Having used both on small projects I was able to get started and finish quicker on Vue. That being said, I use React more because of the larger community, (easier to find answers, and components) as well as more jobs for React vs Vue. Also, Fiber introduces better animation performance, which i'll eventually use.
- kumarvvr 9y ago
  Things have become easier with create-react-app though.
  - deleted 9y ago
    [deleted]

deleted 9y ago

[deleted]

ArchReaper 9y ago

Maybe my viewpoint is too 'elitist' or something, but I have a hard time taking this seriously when one of the chief complaints of Typescript is that it is too "difficult" It really makes me question the validity of the rest of the points.

jcroll 9y ago
Yeah was interested to hear what their points would be but couldn't get past when they started complaining about typescript.
hockeybias 9y ago
Typescript is great and one reason is that it is a superset of JavaScript. I'm concurring wholeheartedly...
ageofwant 9y ago
Typescript is not difficult, it just solves problems almost no one has, and makes you do silly things that slow you down. Difficult like in 'petulant child' difficult, not 'what woman want' difficult.
thehardsphere 9y ago
While I understand the preference for not wanting it, it is a very "high-level" sort of complaint, and the rest of the points seem similarly "high-level." They could all be valid points, but I wouldn't take any of them purely at face value.

pete_b 9y ago

Angular 2 in beta made bold claims about being 'production ready' which reads 'almost done', it was frustrating just how long it then took to become what I would consider production ready. I consider Angular 4 the first release to produce just about acceptable sized app bundle. On the whole though it's a very ambitious project and I think it will be increasingly hard to ignore, we've currently no intention of changing framework.

stupidcar 9y ago
I think this had to more to do with internal pressures at Google than the actual state of the code. They had been working on it for a long time, and, I think were under some pressure to actually ship something. Angular v4 is what the first production version should have looked like. Having just upgraded a large AngularJS v1 project to Angular v4, I'm actually very happy with where it's ended up. It feels like a very good combination of power and flexibility. There are still some complex bits, but it feels more like the complexity is necessary and sanely designed, rather than the craziness of what AngularJS's directive stuff evolved into.
- growtofill 9y ago
  Would you share some stats about the upgrade? How many LoCs was the codebase and how many man/hours it took?
  - camus2 9y ago
    s/upgrade/rewrite . I don't believe a second there is a reasonable way to upgrade 1.X from 4.X without rewriting all UI related code.

emodendroket 9y ago

People are already migrating from ng2? It just came out!

deleted 9y ago
[deleted]
bdcravens 9y ago
ng2 final was released in September 2016, but many were using it well before then, as in the article. (first beta was in January 2016 I believe)
- emodendroket 9y ago
  I guess maybe it because I am not a frontend person but completely redoing a project in less than two years seems kind of crazy to me.

dugmartin 9y ago

> With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. Sure defining a simple JS object has no overhead as opposed to maybe the 15-30 seconds of overhead that creating the Typescript interface entails. But that few additional seconds of overhead gives you this for rest of the (weeks, months and years) of the systems lifetime: 1. Instant IDE/editor code completion and error checking 2. Compile time checked contracts when that object is passed to another function 3. Compile time checks for misspelled or non-existent members of the object. 4. Instant refactoring of member names across files with any number of editors and IDEs 5. A chance to take a little higher level look at the design of your system. After using Typescript for a couple of years now I've found that when I design my types well the overall design and flow of the system tends towards beauty. That is probably why the Haskell folks are always over on the sidelines smirking.

alexro 9y ago

Wait, but TypeScript makes inheritance a joy. So, how you do it - unless you don'r really reuse the implementation?

water42 9y ago

Clickbait. The author switched from Angular 2 beta 9 (not even a release candidate) because he was unable to migrate to Angular 2.0.0 since 'too many things broke to make the upgrade non trivial'. Yet somehow rewriting the entire app in Vue is easier?

scriptkiddy 9y ago
You'd be surprised how simple it is to re-write an application in Vue. As someone who just finished doing so, I can say that development speed is like nothing I've ever experienced. The application I rebuilt initially took about 2 months to build with React. I rebuilt it with Vue in 2 weeks by myself. I am not venerating Vue, just simply responding to your concerns about rebuilding entire applications.
- seanwilson 9y ago
  I did a rewrite from Angular 1 to Vue recently and it didn't take long at all plus it fixed a bunch of bugs that were problematic to fix in Angular. If you write your Angular 1 code in component style, moving them to Vue is pretty straightforward and a lot of the template conversions just involve changing keywords (e.g. ng-if -> v-if).

samblr 9y ago

Have been using angular 1 and I so wish that I had used vue instead. vue is easy and intuitive compared to angular bloat. May be will take less than half hour to understand basics coming from angular. Can anybody share experience with nuxt.js ?

arkadiytehgraet 9y ago

I wonder why nowadays anyone would choose React and give away all patent rights to the E̶v̶i̶l̶ ̶c̶o̶r̶p̶o̶r̶a̶t̶i̶o̶n̶ Facebook (or not, in which case one would need to rewrite the app completely, since he cannot use React anymore). This alone should make choice way easier, if you decided to not use Angular anyway.

thinbeige 9y ago

> JSX was also a problem since we could not reuse HTML code Who has source code in native HTML lying around?

dwaltrip 9y ago
Even more, a simple find and replace for "class" to "className", and wrap it in a render function. There, now the HTML is being reused as JSX.

sailfast 9y ago

Just wanted to come here and say thanks to the author for writing up your assessment of their tech stack and the pluses and minuses - it's brave to do so and it's obviously spurred discussion. Thanks for sharing some of your learning and having the guts to put it out there, and congrats on shipping the results. I have a couple of questions: 1) You had two people working on the project - how do you think it would scale out to 10? React's componentized / functional nature allows for that pretty easily which is a consideration for me. 2) Managing JavaScript in templates (html) with Angular 1.x was always weird because you couldn't necessarily tell if the execution was happening in the view or the controller. Does Vue make that any easier when it mixes templates and JS together? I also appreciate knowing that this file is where everything is contained for X element or function. 3) How are the test harnesses?

seanwilson 9y ago

> I didn’t feel Typescript added substantial value and even worse, we noticed that our coding speed was reduced. With Typescript things that were really easy to do on Javascript like defining a simple object were more complicated to do on Typescript. I highly recommend you to read the following articles before you start using Typescript. It is not the right solution for everyone. If you read the linked article, it's using a graph of the number of GitHub issues labelled "bug" to justify that languages with strong static types don't reduce the number of bugs which isn't meaningful or convincing... > The main thing we didn’t like and we still don’t like about Angular 2 is Typescript. I know Angular 2 can be used with Javascript but again, the decision to use Typescript was already taken and from what I understand, using pure Javascript with Angular 2 is not the ideal way you should be using Angular 2. In any case, getting rid of Typescript meant a full rewrite of the project. ... > I still remember how easy to work with Angular 1 was, it certainly had it’s own problems, but it was nice to work with it compared to other frameworks, something that Angular 2 lost somewhere on the way. I recently moved from Angular 1 because it didn't work well with TypeScript. The rest of my project was in TypeScript and all the bugs were coming from the Angular 1 layer because there was no static checking there. TypeScript is an enormous improvement over plain JavaScript in my opinion in terms of productivity (better refactoring, better autocomplete) and making your code more robust (no unexpected null/undefined variables, no more mixing up strings and arrays). Ignoring TypeScript for large projects is a big mistake. Angular 2 felt too verbose and overly complex so I switched to Vue which has decent add ons to work with TypeScript. If you use JSX for Vue templates as well, you get type checking for your templates.

Zelphyr 9y ago

The thing I find amusing about posts like these is that they come about once every 18 months. Just substitute the left framework for last years shiny and the right for the latest shiny. We developers are nothing if not consistent in our ability to chase the latest shiny. I do wish more developers would take the time to master languages instead of learning new frameworks though.

wambotron 9y ago

I still say Mithril (https://mithril.js.org/ https://mithril.js.org/) is where it's at. I am at a company now that uses Angular 4.x and I'm not impressed with it. IMO, it's a way to make JS seem more like Spring/Java (especially with Typescript) rather than understand how JS works and use it as it is. Not to mention the learning curve even for senior developers. Mithril took me maybe 30 minutes to understand. The entire source (https://github.com/MithrilJS/mithril.js https://github.com/MithrilJS/mithril.js) is easily read in a few hours. They have multiple committers and an active gitter chat room for any problems. Plus you can use JSX if you like it that much. And it has a nice license. More folks need to try it out.

elbear 9y ago
I'm using Mithril with TypeScript. It's a great combo. All my Mithril views are stateless and TypeScript makes sure I pass down properly the arguments to the view. It feels almost like I'm writing Elm. Almost.
seanwilson 9y ago
Are you not at a disadvantage with it having a smaller community or is there enough content out there? I like to support new innovations but knowing I can easily find a prewritten component for Vue or Angular is a big selling point.
- wambotron 9y ago
  I never felt like I had any problems, to be honest. It was so quick and easy to write things, I never worried. There are a decent amount of plugins out there on github, though. Give it a shot!

OutsmartDan 9y ago

I just broke your Vue website. http://cl.ly/2I2r2S2v171T http://cl.ly/2I2r2S2v171T

bojanvidanovic 9y ago

I envy how some companies can migrate from one to another framework like that. Beside that, TypeScript is just fine once you get more time with it, you don't need to type everything. On the other side I find Angular more stable framework on the long run.

jordache 9y ago

The author made some really weak arguments. In his comparison matrix, why was Reactivity a criteria? Why did Angular score a "Kind-of"? Reactivity is just another word for the framework's underlying change detection logic. Obviously all of these frameworks have that. The fact that he put the term "reactivity" up on a pedestal and rated angular down tells me the lack of understanding on the author's side

jorblumesea 9y ago

Angular is a application framework, Vue is a view library. It's really frustrating to see these two compared, because they have different purposes and intentions. Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. By the time you slap all of that on top, you may have well just stuck with Angular. I noticed in React by the time you added the required add-ons (mobx or redux, polyfills, react router, styled components) it was extremely heavy. Furthermore, maintaining these addons, with their own release cycles and bugs is an additional burden on a team.

erokar 9y ago
Please enlighten me — what kind of state management does Angular give you for free?
RussianCow 9y ago
> Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. That's not really true anymore; there is now an official router[1] and state management library[2] for Vue. You don't have to use them, but I think the comparison is still completely fair. [1]: https://github.com/vuejs/vue-router https://github.com/vuejs/vue-router [2]: https://github.com/vuejs/vuex https://github.com/vuejs/vuex
- jorblumesea 9y ago
  This is a great point, I did not know it was officially in the build. Thanks!
seanwilson 9y ago
> Vue just renders components. There's no state management, built in routing, or any of the other things you get for free with Ember/Angular/etc. Vuex and Vue Router are recommended from the official Vue website, used by most Vue users and work seamlessly together. What else are you missing? The kind of things I want to build with Vue with Vuex and Vue Router are the same kinds of things I could build with Angular 1 and Angular 2 so the comparison makes sense to me.

joelennon 9y ago

> At the time we were thinking about Vue.js vs React, we were also considering rewriting our mobile app and React Native looked like a really good choice. That was a big plus for React since Vue.js didn’t have anything remotely stable that resembles what React Native is trying to do, so the possibility of reusing code between the web and app clients was a huge plus, but I decided that I wasn’t going to consider possibilities that might or might not happen. After all, from my experience, with Node.js I reuse a really insignificant amount of code between the browser and the server. The main benefit of using React if you are considering using React Native is that you and your team won't need to learn another framework in order to build native mobile apps for iOS and Android - if they know React already, they'll be up to speed with React Native very quickly.

dayvid 9y ago
Alibaba's working on a Vue-based mobile alternative called Weex. It's still in its infancy, but it's worth checking out: https://weex.incubator.apache.org/ https://weex.incubator.apache.org/ https://github.com/alibaba/weex https://github.com/alibaba/weex

jordache 9y ago

Angular 2+ does require more up front investment. However once you get going, the framework's convention is pretty seamless and on can create rather structured, team friendly projects, and iterate functions quickly. The Angular CLI tool is a must! Without it, the friction to get dive into the Angular 2+ world is significantly more.

davidw 9y ago

No experience with Vue.js or React, but I used Angular 2 recently and I did not like it much. Too much magic, too much 'do our things our way or woe betide you'.

caludio 9y ago

I stopped reading at "The main thing we didn’t like and we still don’t like about Angular 2 is Typescript". Sorry.

stephenhuey 9y ago

What I want to know is, why didn't you choose Aurelia? :)

vladimir-y 9y ago

The article says to me that the team/company had no initial actual need to use TypeScript as seems author doesn't get a point of its purpose (of course code writing will be slower on the initial stage as it's not just about writing the code, but also about defining its structure which gives you the benefits with the growth of the project) and so a bad decision was initially made. In my opinion Vue is ok for the one kind of projects, with smaller team, smaller project lifetime and Angular is ok for other types of projects. React is alien here, ie not really needed.

ralmidani 9y ago

Ember user here, looking for a breath of fresh air from the limitations of Emblem/Handlebars and the endless layers of complex objects. I am enrolled in Udacity's React Nanodegree, but recently took a closer look at Vue. It seems to offer everything React does (VDOM, one-way data flow, centralized state management, support for JSX), but without the patent drama. I previously took a nuanced approach to Facebook's unfair patent license, and will probably never need or want to sue them for patent infringement. But Vue is quite a viable alternative, so I see no reason to reward Facebook's unwillingness to play fair. I plan to finish the Nanodegree, but will probably be skipping React and using Vue for my own real-world projects.